How to Flush Your DNS Cache on Windows, macOS, and Linux

When a website moves, an email record changes, or a typo in a DNS record gets fixed, your computer can keep showing the old answer for a while. That is your local DNS cache doing its job a little too well. Flushing it forces your machine to ask for fresh records. This guide gives the exact commands for Windows, macOS, and Linux, plus how to clear a browser's own private DNS cache, which trips people up constantly.

What the DNS cache actually is

Every DNS answer carries a TTL (time to live) in seconds. Your operating system, and sometimes your browser, stores answers for that long so it does not have to ask again on every click. Flushing wipes those stored answers early. It does not change anything on the public internet; it only resets what your own device remembers.

That distinction matters. If a record is still wrong after you flush, the problem is upstream (your ISP's resolver or the authoritative record itself), not your machine.

Flush DNS on Windows

Windows caches DNS in the DNS Client service. One command clears it. Open Command Prompt or PowerShell (no administrator rights needed for the flush itself) and run:

C:\> ipconfig /flushdns
Successfully flushed the DNS Resolver Cache.

Related commands are worth knowing when you are debugging:

# See what is currently cached
C:\> ipconfig /displaydns

# Release and renew your DHCP lease (also re-reads DNS servers)
C:\> ipconfig /release
C:\> ipconfig /renew

If flushing does not help, restart the DNS Client service from an elevated prompt:

C:\> net stop dnscache
C:\> net start dnscache

Flush DNS on macOS

Modern macOS keeps DNS in two cooperating pieces, so a complete flush needs two commands joined together. This single line works on Sonoma, Sequoia, Ventura, Monterey, and the versions around them:

$ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

The first half clears the Directory Services cache; the second signals the mDNSResponder process to reload. Running only one half gives an incomplete flush on current macOS. You will be prompted for your admin password, and a successful run prints no output, which is normal.

On much older releases the responder process had a different name. If you are on a legacy Mac, the equivalents are:

Flush DNS on Linux

Linux has no single cache by default; it depends on what resolver or caching daemon your distribution runs. Check which one you have, then flush that one.

systemd-resolved (Ubuntu, Fedora, most modern distros)

# Flush the cache
$ sudo resolvectl flush-caches

# Confirm it worked (Current Cache Size should drop to 0)
$ sudo resolvectl statistics

# Older systemd uses the systemd-resolve binary
$ sudo systemd-resolve --flush-caches

nscd (Name Service Cache Daemon)

$ sudo systemctl restart nscd
# or
$ sudo nscd -i hosts

dnsmasq

$ sudo systemctl restart dnsmasq

If none of these services exist on your system, your machine probably does not cache DNS at all and queries go straight to your configured resolver each time. In that case there is nothing local to flush.

Do not forget the browser cache

This is the step people miss. Chromium-based browsers (Chrome, Edge, Brave, Opera) keep their own in-memory DNS cache that an OS-level flush does not touch. If the site still loads wrong after flushing the OS, clear the browser cache too.

• Chrome, Edge, Brave: visit chrome://net-internals/#dns (or edge://net-internals/#dns) and click Clear host cache, then clear the socket pool at chrome://net-internals/#sockets.
• Firefox: Firefox refreshes its internal cache quickly, but you can disable and re-enable network prediction, or simply restart the browser, to force fresh lookups.

Browsers that use secure DNS (DNS over HTTPS) may also resolve through a provider that is entirely separate from your OS settings. If that is enabled, a system flush will not change what the browser resolves.

A clean retest sequence

When you need to be sure you are seeing a genuinely fresh answer, flush every layer in order before testing.

1. Flush the operating system cache using the command for your platform above.
2. Clear the browser host cache if you are testing in a browser.
3. Query a public resolver directly to compare, for example nslookup example.com 1.1.1.1 on Windows or dig @1.1.1.1 example.com elsewhere.
4. If the public resolver and your freshly flushed machine agree but still show old data, the record change has not propagated yet at the resolver level.

Flushing from a router or home server

Many home networks run a DNS cache on the router itself, so even a perfectly flushed computer gets a stale answer handed back from the gateway. If a change still will not appear after clearing the OS and browser caches, the router is the likely culprit.

• Consumer routers: reboot the router, or look in its admin panel for a "clear DNS cache" or "restart DNS" option under the network or DHCP settings.
• Pi-hole, AdGuard Home, or a local resolver: restart the DNS service or use its built-in flush control. For Pi-hole, restarting the DNS resolver from the admin dashboard clears cached answers.
• Unbound or BIND on a server: use the control utility to flush specific names rather than the whole cache, for example unbound-control flush example.com or rndc flushname example.com.

Flushing the router matters because every device on the network inherits its cache. One stale entry there can make an entire household or office see the old record long after each individual machine has been cleared.

When flushing will not help

Flushing fixes stale answers stored on your own device. It cannot speed up the wider internet. If you recently changed a record, three things outside your control are still at work:

• The old TTL. Resolvers everywhere will hold the previous value until the TTL you had set before the change expires.
• ISP resolver caches. Your provider's recursive resolvers cache independently of your machine.
• Negative caching. If a name did not exist when first queried, the NXDOMAIN result is cached too, so a newly created record can take time to appear.

Because the real question during a change is usually "has the new record reached everyone, not just me?", a local flush only answers half of it. To see your record resolve from dozens of networks worldwide at once, run it through the Valla DNS propagation checker and watch which regions have updated. Pair that with our guides on choosing TTL values and reading a dig response, and you will know the difference between a stale local cache and a change that simply needs more time.