Why Flushing the DNS Cache Fixes Odd VPN Behavior
Your device remembers the answers to recent name lookups so it does not have to ask again. Those cached answers survive connecting or disconnecting a VPN, so a site you loaded before the tunnel came up can keep resolving to the address it had then — even though your traffic is now leaving from somewhere else entirely.
Clearing the cache forces fresh lookups through the current path. It is one of the few pieces of common troubleshooting advice that has a specific, explainable reason behind it.
What is cached and for how long
Several caches sit in front of the network, each with its own lifetime.
The operating system cache holds answers for as long as the record’s time-to-live specifies, which can be seconds or hours depending on the domain.
Browser caches are separate and shorter, and browsers may keep connections open to an address even after the cached name entry expires.
The resolver’s cache, on the server side, is shared with everyone else using it. You cannot clear this one, and it is why a change can appear stale even after you clear everything locally.
The hosts file is not a cache but behaves like a permanent one — an entry there wins over any lookup.
The layering is described in how DNS resolution works, and it means “clearing the cache” is really several actions with different reaches.
The specific problems it solves
Cached entries cause a recognisable set of symptoms after a connection change.
A site still shows the wrong region. Large services return different addresses depending on where the lookup came from. Resolve before connecting, and you get an address near your real location; the cached entry then keeps sending you there after the tunnel is up, so the site behaves as if you never connected. Nothing is leaking — you are just talking to the endpoint you were pointed at earlier.
A site is unreachable after connecting. The cached address may be one that is not routable from the VPN server’s network, or a load balancer that no longer wants that connection. Requests time out while everything else works.
A leak test disagrees with itself. Testing tools are hostnames too. A cached entry can send you to a test endpoint chosen for your pre-connection location, producing results that look inconsistent — which makes checking for leaks frustrating until you clear first.
Changes take effect for some sites and not others. Different domains have different record lifetimes, so the cache expires unevenly. This is the giveaway that caching rather than configuration is the problem.
Old settings appear to persist. If you changed which resolver you use, cached answers from the previous one keep being served until they expire — so the change looks like it did nothing. Relevant whenever you adjust your VPN’s DNS setting.
How to clear each layer
Work outward from the application.
The browser. Browsers have an internal DNS cache and a socket pool, both reachable from their diagnostic pages. Closing and reopening the browser clears much of it. This is the layer to try first because it is the fastest and most commonly the culprit.
The operating system. Each platform has a command that flushes the resolver cache: Windows via ipconfig /flushdns, macOS by restarting the resolver daemon, and Linux by restarting whichever local caching service is in use — which varies by distribution, and on some systems there is no local cache at all.
The connection. Disconnecting and reconnecting the VPN re-establishes the tunnel and re-applies the client’s resolver settings, which is worth doing after a flush so the fresh lookups use the intended resolver.
The router. Routers often cache too, and a router flush or reboot clears it for every device. Relevant mainly when the VPN runs on the router rather than on individual devices.
There is nothing risky about any of these. The only cost is that the next lookup for each name takes slightly longer.
When flushing will not help
Being clear about the limits keeps it from becoming a ritual.
- Persistent leaks. If your provider’s resolver is receiving your queries because the client never replaced the system settings, fresh lookups will go to the same wrong place. Flushing changes nothing; the configuration has to change.
- A tunnel that is not up. If the virtual adapter does not exist or is not carrying default traffic, resolution is not the problem.
- Region blocks based on your address. A service that identifies the VPN’s address range and refuses it is not making a DNS decision, and no cache change will alter that.
- Resolver-side caching. Your resolver’s own cache is not yours to clear, and its entries can be minutes or hours old.
- Hosts file entries. These are not cleared by a flush and will keep winning until removed.
The distinguishing question is whether the wrong behaviour is uniform or patchy. Uniform failure points at configuration; patchy, name-by-name failure points at caching. When configuration is the real issue, the sequence in why your VPN is not working is a better starting point.
Reducing how often it matters
Two habits cut down on cache-related confusion.
Connect before you browse. If the tunnel is up before you load anything, every lookup happens through it and there is no stale pre-connection entry to trip over. Most clients can connect automatically at startup, which makes this the default without thinking about it.
Flush as part of a deliberate change. Whenever you switch server locations, change resolvers, or start troubleshooting, flush first so that what you observe reflects the current configuration rather than the previous one. It removes an entire class of misleading result before you begin.
The reason it earned its reputation
Caching produces symptoms that look exactly like something serious. Wrong region, unreachable sites, inconsistent leak tests, settings that seem ignored — all of them plausibly indicate a broken VPN, and all of them can be a name your device looked up two minutes before the tunnel came up.
It is worth trying first not because it fixes everything but because it is quick, harmless, and eliminates a common cause. When it does not help, you have also learned something useful: the problem is in configuration or routing, and that narrows the search considerably.