How to Flush DNS on Windows, macOS, Linux, and Browsers

You changed a DNS record, the change is live at your authoritative server, every public resolver you check agrees — and one laptop in the office is still loading the old site. Someone suggests flushing DNS. Someone else says it will not help. Both of them are partly right.

Flushing the DNS cache is a real fix for a real problem, and it is also the most over-prescribed troubleshooting step in networking. Knowing which caches actually exist, and which one you are emptying, is the difference between diagnosing a problem and performing a ritual.

The four caches between you and a website

When you request a name, the answer can be sitting in several places, and they are independent.

The browser keeps a small cache of resolved names. The operating system keeps a resolver cache below that. On Linux desktops, and on many routers, a local forwarder such as systemd-resolved or dnsmasq keeps a third. And somewhere upstream, your ISP's recursive resolver — or whichever public resolver you use — holds the copy it fetched, with a TTL attached.

"Flushing DNS" almost always means clearing the middle two: the operating system's cache and, if it is running, the local forwarder. The browser cache is a separate step. And the upstream recursive resolver is not yours to flush at all — it will expire on its own schedule, which is the whole reason DNS changes take time to appear. Try it on DNS Checkers Check DNS Propagation

What flushing can and cannot fix

Flushing helps when you have changed a record, the TTL has genuinely expired, resolvers you check are returning the new value, and one machine is still holding an old answer. That is a stale local cache, and clearing it is exactly the right move.

Flushing does not help when the authoritative answer is wrong — you will simply cache the wrong answer again. It does not help when an upstream resolver is still inside its TTL window; your local cache is not the one being stubborn. It does not help with a CDN or proxy caching page content rather than DNS. And it cannot affect anyone else's machine.

The useful test is straightforward. Ask an external resolver for the record. If it returns the value you expect and the local machine does not, you have a local cache problem. If the external resolver also returns the old value, you are waiting on a TTL and flushing will achieve nothing.

Windows

The classic command has not changed:

ipconfig /flushdns

It clears the DNS client resolver cache. Two related commands are worth having in your notes. ipconfig /displaydns dumps the current contents, which is useful for proving that a stale entry exists before you clear it. And if the cache is locked by another process, restarting the service does the same job more forcefully:

net stop dnscache
net start dnscache

If you use a VPN client or a third-party security suite, it may run its own resolver with its own cache. Clearing the Windows cache will not affect it, and you will need to disconnect and reconnect instead.

macOS

Modern macOS clears its DNS caches with a pair of commands:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

The first flushes the directory service cache, the second tells the responder process to reload. Older releases used different incantations, and it is not worth memorising them unless you maintain old machines — the two above cover the versions you are likely to meet.

If you have a VPN or a local DNS proxy installed, check whether it caches separately. Some security tools do, and they will keep serving old answers after a system flush.

Linux

Linux has no single command, because there is no single resolver. You have to identify which one is running.

With systemd-resolved, the common case on modern distributions:

resolvectl flush-caches

With nscd, the older name service cache daemon, restart it or invalidate just the hosts database:

sudo nscd -i hosts

With dnsmasq, usually on routers and small networks:

sudo systemctl restart dnsmasq

And if none of those are installed, your distribution may be caching nothing locally at all, in which case the operating system cache is not your problem.

The honest answer for many Linux systems is that the useful command depends on the distribution and on what has been installed on top of it. Check which of these services is running before assuming you have flushed anything.

Browsers

Browsers keep their own caches, and they are not touched by an operating system flush.

In Chrome and other Chromium browsers, open chrome://net-internals/#dns and use the option to clear the host cache. The adjacent socket pool page is worth visiting too, because a pooled connection to the old address will happily keep serving requests even after the name resolves correctly.

In Firefox, the equivalent lives at about:networking#dns, with a button to clear the DNS cache.

Safari has no exposed interface for this. Fully quitting the browser clears its cache, which is usually sufficient.

One caveat: if your site is served over HTTPS and you recently changed a certificate, what you are fighting may be HSTS rather than DNS. Chromium browsers expose that at chrome://net-internals/#hsts, and it behaves nothing like a DNS cache.

Routers, VPNs and mobile devices

Home routers frequently run a caching forwarder and frequently run it for months. If every device on the network is showing the same stale answer while your phone on mobile data shows the correct one, the router's cache is the likely suspect, and a reboot clears it.

VPNs add a second resolver and a second cache, and many reconnect to a different exit node each time, which means the answer you get can change depending on nothing more than when you connected.

Mobile operating systems cache aggressively and expose no controls at all. If a phone is stuck, toggling aeroplane mode is usually the only lever you have.

The commands people get wrong

A few of the well-known commands are frequently used in a way that leaves the cache intact.

On Windows, ipconfig /flushdns needs its leading slash and no space, and it should run in a normal command prompt rather than a shell where it has been aliased to something else. Running it while a VPN client is connected can clear the system cache while the VPN's own cache keeps answering.

On macOS, the two commands are usually quoted together and it is common to run only the first. dscacheutil -flushcache on its own leaves the responder process running with its own state; the killall -HUP mDNSResponder is what makes it reload.

On Linux, the most common mistake is running resolvectl flush-caches on a system where systemd-resolved is not installed. The command can exist as a stub and return no error while changing nothing at all. Confirm the service is running before you trust the result.

In browsers, clearing the host cache without clearing the socket pool is the usual oversight. The name resolves correctly afterwards, but the browser keeps reusing its existing connection to the old address until that connection is closed.

The myth worth naming

You will occasionally see a website claim it can "flush your DNS" for you. It cannot.

Flushing a local cache requires local privileges on the machine doing the lookup. A web page has no access to your operating system's resolver cache or to your router. Any site offering to do it is at best mislabelling a server-side change and at worst trying to get you to install something.

The same applies in reverse: you cannot flush a visitor's cache from your server, no matter how much you would like to. The only lever you control is the TTL you published in advance. Try it on DNS Checkers Flush DNS Guide

When flushing is the wrong answer

If more than one machine is affected, stop. A handset of stale cache on a single device is a local cache problem. Ten machines showing the same wrong answer is a DNS problem, and flushing all of them is a way of feeling productive while the real issue waits.

Likewise, if the TTL on the record has not expired yet, flushing is premature. You are not fixing anything; you are clearing a cache that will immediately refill with the same old answer from upstream.

The order that actually works

Start by asking an external resolver what it returns. If it already returns the new value, your problem is local. If it returns the old value, wait for the TTL or fix the record.

Once you have established the problem is local, flush in order: the browser first, since it is quickest, then the operating system, then any local forwarder or router. Then close and reopen the connection rather than simply refreshing, so stale sockets are discarded too.

Finally, confirm the fix rather than assuming it. Re-resolve the name on the machine that was broken, and confirm it now matches what the outside world sees. Try it on DNS Checkers Lookup All DNS Records

Flushing is a genuinely useful tool. It is just a narrower one than its reputation suggests — and the more precisely you can say which cache you are emptying, the less often you will need to reach for it.