- Chrome's DNS cache is cleared at chrome://net-internals/#dns. Clearing browsing data does not touch it.
- Clear the socket pool at chrome://net-internals/#sockets too, or an already-open connection keeps using the old address.
- Chrome caches separately from your operating system, so you usually need to flush both.
- None of this changes what anyone else sees. Their caches expire on the record's TTL, whatever you do locally.
- Lower a record's TTL to 300 seconds at least 24 hours before a planned migration, so the world updates in minutes rather than hours.
How do I clear the DNS cache in Chrome?
Open chrome://net-internals/#dns and click Clear host cache. Chrome keeps its own DNS cache, entirely separate from Windows, macOS or Linux, and clearing browsing history has no effect on it. This is why a site can resolve correctly in a terminal and still show the old server in Chrome. If you are checking whether a server is reachable at all rather than which address it has, a terminal speed test answers that separately.
- 1Type
chrome://net-internals/#dnsinto the address bar and press Enter. It will not autocomplete or appear in search suggestions. - 2Click Clear host cache. There is no confirmation; the button simply works.
- 3Switch to
chrome://net-internals/#socketsand click Flush socket pools. Without this, connections that are already open keep going to the old address. - 4Close and reopen the tab you were testing in, then reload with Ctrl+Shift+R (Cmd+Shift+R on macOS) to bypass the content cache as well.
Step three is the one people skip
Chrome keeps HTTP connections alive and reuses them. Clearing the host cache does not close a socket that is already connected to the old IP address, so the site keeps loading from the old server and it looks like the flush failed. Flush the socket pools as well, every time.
| Browser | How to clear its DNS cache |
|---|---|
| Chrome | chrome://net-internals/#dns then #sockets |
| Edge | edge://net-internals/#dns then #sockets |
| Brave | brave://net-internals/#dns then #sockets |
| Firefox | about:networking#dns then Clear DNS Cache |
| Safari | No internal cache: flush macOS instead |
Every Chromium browser uses the same page under its own scheme.
How do I flush the operating system DNS cache?
Your operating system caches separately again. If a record is still wrong after clearing Chrome, this is the next layer down, and often the one actually holding the stale answer.
:: Command Prompt or PowerShell, run as Administrator
ipconfig /flushdns
:: Confirm the cache is empty
ipconfig /displaydns
:: PowerShell equivalent
Clear-DnsClientCache# Ventura, Sonoma and later
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Confirm the resolver restarted
sudo log show --predicate 'process == "mDNSResponder"' --last 1m | tail -5# systemd-resolved (Ubuntu 18.04+, most modern distributions)
sudo resolvectl flush-caches
resolvectl statistics
# dnsmasq
sudo systemctl restart dnsmasq
# nscd, on older systems
sudo systemctl restart nscd
# Which resolver are you actually running?
systemctl is-active systemd-resolved dnsmasq nscd 2>/dev/nullHow do I check what the internet actually sees?
This is the check that matters after a DNS change. Your own machine is the least reliable place to test it from, because it sits behind at least three layers of cache. Query the authoritative nameservers directly and compare against a couple of public resolvers.
# What your machine currently believes
dig example.com +short
# Ask specific public resolvers, bypassing everything local
dig @1.1.1.1 example.com +short # Cloudflare
dig @8.8.8.8 example.com +short # Google
# Ask the authoritative nameservers themselves: the source of record
dig example.com NS +short
dig @ns1.yourprovider.com example.com +short
# Full trace from the root servers down
dig example.com +trace
# How much longer will caches hold the old answer?
dig example.com | grep -A1 'ANSWER SECTION'Windows has no dig
Use nslookup example.com 1.1.1.1 instead, or install the BIND tools. Resolve-DnsName example.com -Server 1.1.1.1 in PowerShell gives similar output with TTLs included.
| What you get back | Means |
|---|---|
| Authoritative server has the new IP, resolvers do not | Change is correct: caches are simply still holding the old TTL |
| Authoritative server still has the old IP | The change never saved, or you edited the wrong zone |
| Different public resolvers disagree | Propagation in progress. Normal, and it resolves itself |
| Nothing resolves at all | Nameserver delegation is broken, which is a different problem |
Row two is the one worth checking first. It is more common than people expect.
Why is my site still showing the old server?
There are more caches in the path than most people realise. If the record itself is correct everywhere and the site is still unreachable, the problem is the server rather than DNS, and the system logs are the place to start. Otherwise work down these caches in order: each one is independent, and any single one of them will keep showing you the old answer.
- 1Chrome's own cache and socket pool. Both, as above. Test in a private window as a quick check, though private mode does share the socket pool.
- 2Your operating system's resolver. Flushed with the commands in the previous section.
- 3Your router. Most home routers cache DNS and never expose a flush button. Reboot it, or test from mobile data to take it out of the path entirely.
- 4Your ISP's resolver. Nothing you can do but wait for the TTL. Query 1.1.1.1 directly to prove the record itself is correct.
- 5A hosts file entry. Easy to forget months later. Check /etc/hosts on macOS and Linux, or C:\Windows\System32\drivers\etc\hosts on Windows. It overrides DNS entirely.
- 6A CDN or proxy in front of the site. The DNS may be right while the proxy still points at the old origin. That is a configuration change, not a cache.
# macOS and Linux
grep -v '^#' /etc/hosts | grep -v '^$'
# Windows, in an Administrator PowerShell
Get-Content C:\Windows\System32\drivers\etc\hosts | Select-String -NotMatch '^#'The fastest way to take every local cache out of the picture is to test on your phone with wifi turned off. Different device, different resolver, different network. If the site is correct there, the record is fine and everything you are seeing is local.
How do I make a DNS change propagate quickly?
You cannot flush anyone else's cache. What you can do is make the cached lifetime short before you make the change, so the world picks up the new value in minutes instead of hours. This has to happen in advance, and it is the single most useful thing you can do before a migration.
- 1At least 24 hours before, lower the TTL on the records you will change to 300 seconds. Every resolver has to expire the old long TTL before it will honour the short one, which is why the lead time is not optional.
- 2Confirm the low TTL is live with
dig example.com | grep -A1 'ANSWER SECTION', reading the number before the record type. - 3Make the change. Caches now hold the old answer for at most five minutes.
- 4Keep the old server running for at least 24 hours regardless. Some resolvers ignore short TTLs, and a stale answer that reaches a working server is invisible to visitors.
- 5Raise the TTL back to 3600 once you are settled, so you are not paying for a lookup on every visit.
Never switch DNS and shut down the old server together
Propagation is not instant and some resolvers hold records well beyond their TTL. Leaving the old server answering for a day costs almost nothing and is the difference between a quiet migration and a day of intermittent errors that only some visitors see.
If you are moving a site rather than just changing a record, the DNS is only one part: the files, the database, the URLs stored inside it and the TLS certificate all need sequencing too. Our WordPress migration service handles the whole cutover, including keeping both origins live until the change has settled.
Frequently asked questions
Does clearing browsing data clear Chrome's DNS cache?
No. The DNS host cache is separate from cookies, history and cached files, and clearing browsing data leaves it untouched. You have to use chrome://net-internals/#dns specifically, then flush the socket pools at chrome://net-internals/#sockets.
Why does the site still load from the old server after I flushed DNS?
Almost always an open connection in Chrome's socket pool, which the host cache flush does not close. Flush the socket pools too. If it persists, the cache is further out: your router, your ISP's resolver, or a hosts file entry you forgot about.
How long does DNS propagation actually take?
As long as the record's TTL, from the moment each resolver last looked it up. A TTL of 3600 means up to an hour; 86400 means up to a day. Lowering the TTL to 300 at least 24 hours before a change shrinks the window to about five minutes.
How do I check DNS from a different location?
Query public resolvers directly: dig @1.1.1.1 example.com and dig @8.8.8.8 example.com. That bypasses every cache on your machine and network. Testing from a phone on mobile data gives you a genuinely independent second answer.
Can I force other people's browsers to update?
No. Every resolver and browser between you and them holds its own cache and expires it on the TTL it was given. The only control you have is setting a short TTL in advance, and keeping the old server answering until the change has fully settled.
About G7Cloud Engineering
Articles written by the engineers who build and run G7Cloud: UK managed hosting and the AI Website Builder. We write about what we operate every day: containers, backups, databases, and the small-business websites that run on them.
More about G7Cloud →
