Your operating system caches DNS lookups for performance. When a site moves to a new IP, that cached entry can keep you locked on to the old one until the cache expires. Flushing forces a fresh lookup.
Why DNS caching exists
Every page load triggers DNS lookups (one per unique hostname). If your OS asked an upstream resolver for every lookup, browsing would be substantially slower. So Windows, macOS, and Linux all keep a local cache that honors the TTL set by the authoritative DNS server. Reads from cache are sub-millisecond; reads from a remote resolver are 10–60 ms.
The cost: when records change, you keep seeing the old answer until the cached entry expires. Flushing the cache clears every entry immediately and forces the next lookup to go upstream.
Commands by OS
Windows (10, 11, Server)
Open Command Prompt as administrator and run:
ipconfig /flushdnsYou should see "Successfully flushed the DNS Resolver Cache." No reboot needed. To inspect the cache before or after, use ipconfig /displaydns.
macOS (Ventura, Sonoma, Sequoia)
Open Terminal and run both commands together:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderThe first clears the system DNS cache; the second restarts the multicast DNS responder so apps pick up the change. macOS gives no confirmation message — silence means it worked.
Linux (systemd-resolved, default on Ubuntu 18.04+)
sudo resolvectl flush-cachesTo verify, run resolvectl statistics and check that Current Cache Size dropped to 0.
If your distro uses a different resolver:
- nscd —
sudo systemctl restart nscd - dnsmasq —
sudo systemctl restart dnsmasq - BIND —
sudo rndc flush
Chrome and Edge (browser-level cache)
Chrome maintains a process-level DNS cache on top of the OS cache. Visit:
chrome://net-internals/#dnsClick "Clear host cache". Edge uses the same panel at edge://net-internals/#dns. Firefox does not maintain a separate user-facing DNS cache.
iOS and Android
Mobile OSes don't expose a flush command. The reliable workarounds:
- Toggle airplane mode on then off — most app DNS caches drop on connection state change.
- Reboot the device — guaranteed cache clear.
When flushing actually helps
Flushing is the right move when:
- A site you can normally reach started failing for you specifically (and a multi-region check confirms the site itself is up).
- You just changed your DNS resolver (e.g. switched to Cloudflare's
1.1.1.1). - A site recently migrated CDNs (you may be holding the old IP).
- You modified
/etc/hostsor local DNS settings.
When flushing won't help
Flushing only clears your cache. It does nothing for:
- Confirmed global outages — the site is down, not stale on your end.
- ISP-level DNS issues — your ISP's recursive resolver has its own cache. Switch to
1.1.1.1or8.8.8.8as a workaround. - Browser-cached error pages or service-worker stale content — clear browser cache instead.
- Firewall / proxy / corporate-network blocks — DNS resolved fine, the connection was blocked at a different layer.
If a flush doesn't help, run the rest of the "is it down for everyone or just me" diagnostic — DNS is one of three common causes of "down for me" symptoms.
Verifying the flush worked
Re-run a DNS lookup for the affected hostname:
nslookup example.com
dig example.comCompare the returned IP to what you expected. If it still shows an old IP after flushing, the issue is upstream (your router or ISP resolver), not your local cache.
FAQ
How long does the local DNS cache hold an entry?
By default, the entry's TTL — usually 60–3600 seconds, set by the authoritative server. macOS clamps very short TTLs to a minimum of about 10 seconds; Windows respects the server-supplied TTL up to 24 hours.
Is there any harm in flushing the cache?
No. Worst case is the next few lookups are 10–60 ms slower than usual. The cache rebuilds within a minute of normal browsing.
Should I flush before reporting an outage?
Yes — flushing rules out a stale-cache false positive in 15 seconds. Reports filed before flushing are more likely to be local issues.