A few weeks ago I was scrolling through a forum thread and half the posts complained about the same Chrome error, all worded slightly differently. “err_network_changed keeps popping up when I am on hotel Wi-Fi.” “I get it every time my Mac wakes from sleep.” “It only happens on one specific site, but other browsers work fine.” All three problems are actually the same underlying behavior, and once you see how Chrome is thinking about it, you can usually pin down which trigger you have in about two minutes.
The error is Chromium’s internal code -21. The two lines Chrome prints above it, “Your connection was interrupted” and “A network change was detected,” describe the same event. Your laptop handed the browser one route to a server, then handed it a different route mid-request. Your operating system considers that a perfectly normal handoff. Chrome considers it a reason to cancel the page and give up. That mismatch is the whole story. The site never saw your request reach a complete state. Your ISP never lost the connection. Chrome is the only thing that decided to bail.
This is a debugging article, not a tutorial. The fixes are layered because the triggers are layered. None of the steps are destructive, and the most common ones are reversible in under a minute.
What Chrome is actually saying when it bails
Chrome has a reason for canceling the request, and the reason is not what most readers assume. The browser does not know whether the new network path your laptop just announced is one you intended to use, a captive portal asking you to log in, or a hostile network pretending to be the one you were on. Retrying on the new route could send your next request to a bad place. Canceling forces you to reload with intent, which is safer in adversarial settings.
The downside is that Chrome also fires this on totally mundane path changes. Your mesh router swaps you from 2.4 GHz to 5 GHz without telling you. Your DHCP lease renews and your machine gets a new address. Your VPN client cycles its tunnel. None of those are security events, but Chrome treats them all the same way.
The other code that gets confused with this one is net::err_internet_disconnected. That one means your device genuinely has no network. If other apps and other browsers work, you do not have that error. You have err_network_changed, which means your network is up but Chrome lost faith in the path.
Things to keep in your head before you start changing anything:
- Chrome is the only thing that gave up. The site did not reject you.
- Your internet is up. Reloading usually works because the path has settled.
- The trigger is a route change, not a connection failure.
- The error is Chromium code -21 in the system-error block.
- Reload works most of the time. That is the cheapest fix.
Where the actual trigger lives
In my experience, the trigger falls into one of three buckets, and your laptop’s behavior usually tells you which bucket without any extra debugging. The first bucket is the laptop itself, mostly the Wi-Fi driver and how it handles band and access-point transitions. The second bucket is something on your network path that just changed, like a router rebooting, a mesh node shuffling your laptop to a stronger one, or a DHCP renew. The third bucket is software on the laptop that sits between your browser and the network, almost always a VPN client or a proxy that you forgot you installed.
You can usually tell which bucket you are in by watching the error pattern. If err_network_changed fires when you walk from one room to another, you are in the first bucket. If it fires immediately after you sit down at a desk and dock into Ethernet, you are in the second. If it fires at random times with no obvious cause, including when your laptop is just sitting open on a desk, you are in the third bucket, and the culprit is almost always a VPN that cycles its tunnel on a schedule you did not know about.
The reason the bucket matters is that it tells you where to fix the problem. Bucket one is a laptop or driver setting. Bucket two is a router setting. Bucket three is a piece of software on your machine. You do not need to touch the other two layers if you know which one is yours.
The first thing I check on someone else’s laptop
I always ask the same question first: are you on Wi-Fi, and does your laptop move around? If the answer is yes, my next stop is the router admin page. Most consumer routers ship with band steering on by default, which means the router decides whether your laptop should be on the 2.4 GHz or 5 GHz band and switches you silently when it thinks the signal is better. Mesh systems add fast roaming on top, which is the same idea but for moving between access points instead of between bands.
Both features look great on paper. Both of them are exactly the behavior that triggers err_network_changed. The handoff happens in under a second, your network stack treats it as routine, and Chrome cancels anything in flight. You see the error, reload, and reload works because by then your laptop has settled on its new band or node.
The fix is to turn those features off. Band steering goes off in the wireless settings of the router admin page, usually under a heading like “Wi-Fi” or “Wireless.” Fast roaming, sometimes labeled 802.11r, lives in the same area on mesh systems. With both off, your laptop stays on one band and one access point unless you physically disconnect, which means Chrome almost never sees a mid-load route change.
Trade-off is real. Your laptop may stick to a slower band at the far end of the house, and roaming between rooms takes a beat longer. In a small space with strong signal, you will not notice. In a large house where you depend on roaming, you may see a few extra reloads but the error stops. I have never seen a case where disabling both made things measurably worse.
The first two moves, before any deeper settings:
- Power-cycle the router. Thirty seconds off, then back on. Wait for lights to settle.
- Open the router admin page and disable band steering if it is on.
- Disable fast roaming if you are on a mesh system.
- Pin your laptop to a single band for testing.
The hidden culprit behind half of “I have no idea why this started”
The sneaky one is the VPN or proxy you forgot you installed. This is the case I see most often when someone emails me a screenshot of err_network_changed and says it started a week ago out of nowhere. The trigger was almost never a week ago. The trigger was the day they installed a privacy browser extension or set up a corporate VPN six months ago and forgot about it.
VPN clients cycle their tunnels in the background. Some of them reconnect every hour. Some reconnect whenever your laptop wakes from sleep. Some reconnect when the underlying network changes, which is exactly the moment Chrome is most sensitive. When the tunnel cycles, every request in flight dies, and Chrome reports it as err_network_changed.
Stray proxy settings are the other half of this case. They get added by old corporate VPNs, by uninstalled software that left settings behind, and occasionally by malware. They look harmless in the list, which is exactly why they survive.
The test is simple. Pause your VPN, reload the failing page, and see whether the error goes away. If it does, the VPN is the cause. The fix depends on the client. Some have a kill switch that needs to be off. Some need a different protocol. A few just need a full reinstall. There is no single cure because every VPN client behaves a little differently.
Trade-off is real. If you rely on the VPN for actual privacy, you do not want to leave it off. The cleanest answer is to find a VPN client that does not aggressively cycle its tunnel, or set it to a stable single server. Split tunnel mode, which routes only specific apps through the VPN, is worth trying before you turn the whole thing off.
Things to try in order:
- Pause your VPN and reload the failing page. If the error goes away, that is your answer.
- Open the proxy settings and uncheck anything you did not deliberately configure.
- Disable the “Automatically detect settings” toggle if it is on.
- Try your VPN client on split tunnel or a stable single-server mode.
- Restart the browser fully after every change. Do not trust reload.
When the browser and resolver are the problem
If the router is fine and you have no VPN running, the next layer is Chrome itself plus the resolver underneath it. Chrome keeps a cache of DNS answers and image files. When that cache gets stale or partially corrupted, the browser can lose track of which connection path it was using, and that confusion can fire err_network_changed even when nothing about your network has changed.
Clearing cached images is harmless. Open Chrome, go to Settings, then Privacy and Security, then Clear Browsing Data, and pick Cached Images and Files. You will just refetch images the next time you visit a site, which is fine. If you are on a metered connection and want to save bytes, clear only the cache and not the full history.
Flushing DNS is the second step. Both Windows and macOS have a built-in command for it. After that, if your ISP’s default resolver is slow or unreliable, switch to a public one. Cloudflare at 1.1.1.1 and Google at 8.8.8.8 are the two most common picks.
The trade-off with switching resolvers is the privacy angle. You are now sending every domain lookup on your machine to that provider. For most people that is a clean win on speed and reliability, but you are trusting a third party with a record of what you resolve. Cloudflare publishes a privacy commitment and audits it. Google has the same caveat that they have other ways to learn what you are doing. If you would rather not route through either, Quad9 at 9.9.9.9 is a third option that leans toward privacy.
In order, so you do not lose your place:
- Clear cached images and files in Chrome settings.
- Flush DNS with the OS-appropriate command.
- Switch to a public resolver like 1.1.1.1 or 8.8.8.8 if your ISP’s is slow.
- Restart Chrome fully after every change.
- Test the page that was failing, in the same conditions.
Trade-offs
Most of these fixes trade automatic optimization for predictable behavior. Disabling band steering means your laptop may sit on a slower band at the edge of your house. Turning off fast roaming means walking between rooms takes a beat longer. Pinning to a fixed Wi-Fi band means the connection is less clever when you move. None of these are deal-breakers for most people, but they are real costs that show up in everyday use. The upside is that Chrome stops canceling pages mid-load, which is the whole point of doing them.
Switching DNS resolvers is its own trade-off. You give your machine’s DNS lookups to a third party. For most people that third party is faster and more reliable than the ISP default, but you are now trusting them with a record of every domain you resolve. Cloudflare publishes a privacy commitment and lets you audit it. Google does too, with the same caveat that Google has other ways to learn what you are doing. If you would rather not route through either, Quad9 at 9.9.9.9 is a third option that leans further toward privacy at the cost of some speed.
The VPN trade-off is the hardest one. If you actually need a VPN for privacy, work access, or to reach a region-locked resource, you do not want to turn it off. The honest answer is that some VPN clients are just noisier than others, and finding one that does not aggressively cycle its tunnel is more useful than disabling the VPN. If you are using a corporate VPN that you cannot choose, your only lever is to ask IT to enable split tunnel for your browser traffic.
If you only do one thing from this article, restart your router and disable band steering. Those two changes resolve most err_network_changed cases on home networks, and they are both reversible.