Flush DNS Cache on Windows, macOS, Linux, and Mobile

Flush DNS Cache on Windows, macOS, Linux, and Mobile

DNS caching speeds up lookups, but when records change or a bad answer is cached, it turns into a liability and you keep hitting the wrong destination. A flush forces fresh queries to your configured resolvers and often fixes “site can’t be reached,” redirect loops after a migration, or TLS name mismatch errors.

Before you dive in, remember there are multiple caches: your OS, your browser, a local resolver (systemd-resolved, nscd, dnsmasq), your router, your ISP’s recursive resolvers, and CDNs. Flushing one layer helps only if that layer holds the stale entry; upstream caches still obey their time-to-live (TTL).

Below are copy-paste steps for Windows, macOS, Linux, and mobile, plus optional browser actions and reliable ways to verify the results so you’re not guessing.

When Flushing DNS Actually Helps

Flush after you change DNS (A/AAAA/CNAME/MX/NS), move a site to a new IP, switch DNS servers, correct a bad hosts entry, or see intermittent failures after VPN or captive portal changes. It also helps when a browser pins a stale connection; combine an OS flush with closing the browser or clearing its own host cache.

Windows: Clear the System Resolver Cache

Open Command Prompt as administrator and run ipconfig /flushdns; you should see “Successfully flushed the DNS Resolver Cache.” Inspect current entries with ipconfig /displaydns to confirm it’s empty or to view cached TTLs.

PowerShell Alternatives and Checks

Run Clear-DnsClientCache to flush, Get-DnsClientCache to inspect, and Resolve-DnsName example.com to query specific records (add -Type A or -Type AAAA as needed).

Chromium-Based Browsers on Windows

Chrome and Edge keep an in-browser host cache; type chrome://net-internals/#dns or edge://net-internals/#dns and click “Clear host cache.” Then visit chrome://net-internals/#sockets or edge://net-internals/#sockets and “Flush socket pools” to drop warm connections. If your build doesn’t expose these pages, close all browser windows (or clear browsing data) and retest.

macOS: Flush mDNSResponder and Directory Service Caches

Open Terminal and run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. There’s no success message; the commands reset both Directory Services caches and mDNSResponder’s unicast and multicast state on current macOS versions.

macOS: Useful Validation

To log resolver stats temporarily, run sudo killall -INFO mDNSResponder and watch the Console app for cache details. Functionally, you can just re-query with dig example.com (or dig AAAA example.com) and confirm the answer and TTL match the authoritative view.

Linux: Which Resolver Are You Using?

glibc itself doesn’t cache; a local service usually does. First check if systemd-resolved is active with systemctl is-active systemd-resolved. If active, flush with sudo resolvectl flush-caches (older releases: sudo systemd-resolve --flush-caches) and verify with resolvectl statistics—look for “Current Cache Size: 0.”

If You Use nscd

Flush just hosts with sudo nscd -i hosts (or sudo nscd --invalidate=hosts depending on build); confirm with sudo nscd -g. Restarting the service also clears cache on many distros: sudo systemctl restart nscd.

If You Use dnsmasq

Restart to drop cache: sudo systemctl restart dnsmasq (SysVinit: sudo service dnsmasq restart). If your config includes clear-on-reload, you can send pkill -HUP dnsmasq to clear without a full restart.

If You Run BIND Locally

Flush the recursive cache with sudo rndc flush, or target a single name with sudo rndc flushname example.com; use rndc dumpdb -cache to inspect dump output if needed.

Mobile: Practical Steps on iOS and Android

iOS/iPadOS: There’s no command to flush DNS only; toggle Airplane Mode off and on, toggle Wi-Fi off and on, or reboot. As a last resort, use Reset Network Settings (Settings → General → Transfer or Reset → Reset → Reset Network Settings), which also clears saved Wi-Fi and VPN profiles.

Android (9+ with Private DNS)

Go to Settings → Network & Internet → Private DNS. Switch between “Private” and “Automatic,” or update the provider hostname, then toggle Airplane Mode or reboot to force fresh lookups. Private DNS uses DNS-over-TLS and can pin a resolver until you change it.

Browser-Level Caches (Optional but Often Necessary)

Chrome/Edge: Use the net-internals pages noted above to clear host cache and flush socket pools; closing all windows also drops in-memory host cache and connections.

Firefox: Visit about:networking#dns and click “Clear DNS Cache.” Firefox’s host cache is in memory, so quitting the browser also discards it; if DNS-over-HTTPS is enabled, flushing the OS cache won’t affect the resolver the browser is using—restart the browser or clear from that page.

Verification: Don’t Trust, Test

After a flush, do two checks: 1) query locally and confirm the answer and TTL match expectations; 2) query authoritative or third-party recursive resolvers to confirm you’re not fighting an upstream cache.

Quick Local Queries

On Windows use nslookup example.com or Resolve-DnsName example.com; on Unix-like systems use dig example.com, and add +trace to follow delegation from the root to the authoritative servers.

TTL and Negative Caching Reality

Upstream caches will continue to serve prior answers until TTLs expire; there’s no client-side override. Negative answers (like NXDOMAIN when a record didn’t exist yet) are cached according to policy derived from the zone’s SOA, so if you probed too early you may need to wait or query a different recursive resolver temporarily.

Common Pitfalls and Gotchas

VPNs and split DNS can send different apps to different resolvers; disconnect the VPN and flush again if results don’t match across apps. Browsers often keep warm connections; if the new IP still doesn’t load after a flush, clear the browser’s host cache or flush socket pools. Finally, routers or ISP resolvers may hold stale data; testing with a different recursive resolver or querying authoritative name servers helps isolate where the stale answer lives.

Flush DNS Cache on Windows, macOS, Linux, and Mobile (FAQ)

Yes on devices you control; then verify the live answer and TTL using a quick DNS Lookup so you know you’re seeing the authoritative data, not a cached one.

They’re independent; clearing the OS cache won’t touch the browser’s host cache or warm connections, so after big changes clear both or use a Private/Incognito window.

Check your active DNS server and WAN IP in a simple checker like My IP Address, then query a hostname and note which recursive resolver returns the answer.

Upstream resolvers and CDNs honor the previous TTL, so they may serve the old record until it expires; try a different recursive resolver or query the authoritative name server directly.

It can; flush the OS and browser, then test AAAA answers specifically or run an IPv6 Test to confirm your v6 path is clean.

It’s safe, but you trade away the latency benefits of caching; use it for real changes or breakage, not as routine housekeeping.

Effectively yes for most cases; reboot or toggle Airplane Mode to force fresh resolver sessions and new lookups.

Then you likely don’t have a system cache to flush there; restart whichever cache you do use (nscd, dnsmasq, or a local BIND) or clear the browser cache and re-test.