Writing

ipconfig /flushdns

Published 17 September 2026

The command, then the check that proves it did anything, then the part that actually matters: there are three caches /flushdns cannot touch, and when one of them is holding the stale answer you can flush all day and nothing will change.

The command

ipconfig /flushdns

If you arrived looking for how to flush DNS on Windows, that is it. Run it in Command Prompt or PowerShell. Mind the slash: ipconfig flushdns without one does not flush anything; it prints the usage text, which is easy to skim past as though it worked.

On current Windows, PowerShell has its own equivalent, and it is the better one to know:

Clear-DnsClientCache

They do the same thing: empty the Windows DNS Client cache. Neither restarts anything, drops connections, or changes a setting. It is a safe command to run on a machine someone is working on.

Check it actually did something

Almost every guide stops at the command. The useful half is verifying it, and Windows will tell you plainly:

ipconfig /displaydns

Immediately after a flush this should be all but empty. If you would rather read something than scroll a wall of records:

Get-DnsClientCache | Measure-Object

Zero means the cache is genuinely empty and the fault is elsewhere, which is worth knowing in ten seconds rather than after the third flush. To look at a single name:

Get-DnsClientCache -Entry example.com

When the command itself fails

Two failures are common and mean different things.

"The requested operation requires elevation." Open Command Prompt or PowerShell as administrator.

"Could not flush the DNS Resolver Cache: Function failed during execution." Usually the DNS Client service is not running. Check it, and note what the second line tells you:

Get-Service Dnscache

If it is stopped, start it, but treat that as a symptom rather than the fix, because something stopped it. With Dnscache down Windows still resolves names; it simply caches nothing, asking the server every time. Slower, and it hides the very problem you are trying to diagnose.

The three caches /flushdns cannot touch

This is the reason flushing so often appears to do nothing. The Windows resolver cache is one of several places an answer is held, and it is the only one this command reaches.

The browser, which is now the usual culprit

Chrome and Edge keep a host cache of their own, and more importantly many installs now do their own DNS over HTTPS: resolving names directly to a provider over an encrypted connection, never asking Windows at all. When that is on, ipconfig /flushdns is not merely insufficient; it is irrelevant, because the browser was never using the cache you just emptied.

Clear the browser's own cache at chrome://net-internals/#dns (or edge://net-internals/#dns) with Clear host cache. The secure-DNS setting itself lives in Privacy and security settings.

The tell is simple and worth ten seconds: if a name resolves correctly in nslookup but the browser still goes to the old address, stop flushing Windows. The browser is answering its own question.

The hosts file

C:\Windows\System32\drivers\etc\hosts is read, not cached, so flushing cannot remove what it puts there. A leftover line from a migration two years ago outranks DNS entirely and survives every flush. Entries from it do appear in ipconfig /displaydns, which misleads people into thinking the flush failed.

The negative cache, which catches everyone

Windows caches failures as well as successes. When a lookup returns "no such name", that non-answer is remembered for about five minutes by default, and the value is set in the registry under Dnscache\Parameters\MaxNegativeCacheTtl.

This produces a specific and maddening sequence. You create a DNS record, test it too early, get "no such name", and Windows now holds that failure. The record is live, the world can see it, and your machine keeps insisting it does not exist. It is not the record and it is not propagation.

Flushing clears negative entries along with the rest, which is why the flush that "finally made it work" often gets the credit instead. If you want to see them before you flush, they are the entries with no data in ipconfig /displaydns.

Which cache is stale: in thirty seconds

Rather than flushing and hoping, ask the layers separately. Each answer narrows it:

nslookup example.com
nslookup example.com 1.1.1.1

The first uses whatever resolver Windows is configured with; the second forces a public one, bypassing your router and ISP. If they disagree, the stale answer is upstream of you and no local flush will help: you are waiting out a TTL. If they agree and your browser still disagrees, the browser is the problem. To see which resolver the first one actually used:

Get-DnsClientServerAddress -AddressFamily IPv4

What flushing is not for

• A name that has never resolved. Flushing clears wrong answers. It cannot produce an answer that does not exist: check the record is actually published first.
• "Speeding up" the connection. An empty cache is briefly slower, not faster. Every name has to be asked again.
• Propagation. There is no such process. There are TTLs, and other people's resolvers honouring them. Your flush has no effect on anyone else's cache, and theirs has none on yours.
• Connectivity faults. If nothing resolves at all, the question is whether you can reach a resolver: a different problem, and one an unreachable host or no route to host will tell you more about than DNS will.

On a Mac the commands differ but the reasoning is identical: see clearing the DNS cache on a Mac, or the flush DNS command for every OS including Linux, where there is often no cache to flush at all.