On Windows, ipconfig /displaydns shows entries in the local DNS client resolver cache, and ipconfig /flushdns clears that local cache. This can help when one Windows device keeps using an old answer or a recently corrected name still appears missing. It does not edit a website's authoritative DNS records, clear caches on upstream resolvers or change your public IP address.

Before clearing the cache, record the failing name and current result, then inspect the local entry. Keep the same network and VPN settings during the comparison so that a change of DNS server does not confuse the result. A successful flush confirms that Windows cleared its client cache; whether the lookup problem is fixed requires a separate check.

Open Command Prompt as an Administrator

On Windows 11, open Start, type Command Prompt in the search box, then select Run as administrator for Command Prompt. Approve the permission request if you are authorized to do so. On a managed work or school computer, ask the device administrator for help if your account cannot open an elevated terminal.

First write down the exact full domain name that fails, such as www.example.com, and the symptom you see. Distinguish a missing DNS answer or an old address from a connection failure after the correct address has been resolved. If the application already reaches the expected address, flushing DNS is unlikely to solve a later HTTP, TLS or server error.

You can use the same terminal for both inspection and the flush, and these two commands also apply to Windows 10. There is no need to release a DHCP lease or reset the network stack as a prerequisite for clearing the DNS client cache. If device policy blocks the operation, follow the administrator's troubleshooting procedure rather than changing unrelated settings.

Display the DNS Client Cache

Run ipconfig /displaydns. The output shows the DNS client resolver cache, including recently obtained records and entries preloaded from the local Hosts file. Look for the failing name and its record type. An entry may contain a positive answer or indicate a cached negative result from an earlier lookup.

Save only the small relevant part of the output if you need to compare before and after. The complete cache can reveal domains used by applications, so handle it as potentially private information. The absence of a name from the display does not prove that no other cache exists: a browser or upstream recursive resolver may have a separate answer, and an application may reuse a connection without looking up the name again.

The display command reads the client cache without changing it; it does not make a fresh query to an authoritative nameserver. If the displayed answer is old, check whether the configured DNS resolver would return the same answer before deciding that the Windows cache is responsible. For a comparison query, you can use the nslookup command described below and keep its result alongside the cached entry.

Flush the Local Cache

Run ipconfig /flushdns. This clears dynamically added entries and cached negative responses from the Windows DNS client resolver cache. Check that the command reports a successful flush before retesting; if it reports an error, retain that message for troubleshooting. The wording of the confirmation can differ with the Windows display language.

A successful message means the local Windows DNS client cache was cleared. It does not mean that an upstream recursive resolver has refreshed its own copy, that a DNS provider has published new zone data or that a browser has closed existing connections. A local Hosts file mapping can still affect a name after a flush because it remains part of the device's configuration.

Avoid running unrelated commands such as ipconfig /release, ipconfig /renew or a broad network reset simply to perform this flush. Those commands address other configuration and connectivity tasks. Adding them without a separate reason can disrupt a connection while doing nothing to fix an incorrect authoritative record.

Retest the Same Name

Repeat the action that failed in the affected application and record whether the same name still fails. You can also run ipconfig /displaydns again to inspect entries created by new lookups. An application with its own DNS cache or an existing connection may not need a new Windows DNS lookup, so its behavior and the client-cache display may differ.

To compare the DNS server's response, run nslookup -type=A www.example.com., replacing the example name with the full name you are investigating and keeping the final dot. Use -type=AAAA instead when investigating an IPv6 address record. Check which DNS server the output identifies and record its answer or error. This query bypasses the Windows DNS client cache, so it provides a server comparison rather than proof that the application used the cleared cache.

If the Old Answer Returns

If the server still returns an old address, compare it with the authoritative answer for that exact name and record type. The recursive resolver may still hold an unexpired copy, or the authoritative servers may still publish the old value. Make the comparison within the appropriate network: a private name or a service with location-dependent answers may legitimately have different results elsewhere.

A recursive resolver can also retain a negative answer for a recently created name and return it again after a local flush. Repeatedly clearing the Windows cache will not remove that upstream entry. If the server already returned the expected answer before the flush and the application starts working afterward, the local cache may have contributed, but the timing alone does not prove the cause.

If the problem remains, keep the before-and-after results with the device, name, record type and time tested. A browser using its own DNS service may receive an answer different from the server shown by nslookup, while a correct address can still lead to a connection or server error. These details help separate a remaining DNS problem from a failure that occurs after name resolution.