net::err_internet_disconnected is one of the most misread error codes in modern computing, and I want to spend a minute on why it is so easy to misread, because that is what keeps people Googling it at the wrong moment.
The error fires at the worst time. You have two minutes before a call, you open a tab, and Chrome refuses to load anything. Your eyes go to the Wi-Fi icon. The icon shows full bars. You walk to the router, you unplug it, you plug it back in, you wait two minutes, and nothing changes. That is the moment when the wrong mental model of the error starts costing you time. The error reads like a hardware fault. It is not.
What the message is really saying
The string looks scary. It is a plain English sentence once you translate it. Chrome is reporting that the path between your device and the public internet is broken. The part most people miss is timing. Chrome surfaces this error before it ever tries to resolve the site’s address through DNS (Domain Name System, the lookup service that turns example.com into the IP address your computer actually talks to), so the website is never at fault here. Your operating system told Chrome no usable network exists, and Chrome bailed. Chromium logs the same fault internally as net error -106, and that negative integer is what you would see if you ran Chrome with verbose logging turned on.
The way to think about it: the OS is the messenger, not the source. The OS is telling Chrome “there is no path to the wider internet from this device right now”, and Chrome is refusing to bother trying. That can mean a dozen things, but they split into a few buckets. The connection from your computer to the access point is dead. The link between the router and the ISP is dead. A captive portal (the login page a hotel or café hotspot forces you through before granting real internet access) is in the way. The OS has cached something stale. A security app has decided Chrome is no longer allowed to talk to the network. Those are the only real possibilities, and the order of how often they show up is roughly: captive portal, security app, dead router link, ISP outage, OS state.
A working Wi-Fi icon does not rule any of those out. The icon only proves your laptop is talking to the router. If the router has lost its own line out to the internet, the icon stays full while every browser fails. Even an Ethernet cable connected to a powered-down switch will report a working link while every browser refuses to load a page. So step one of the diagnostic is to stop trusting the Wi-Fi icon and start running actual tests.
Why I used to blame the router every time
The router is the obvious culprit. It is also, in my experience, the culprit maybe one time in five. Most of the other four times the fix was somewhere I had to actually read the error and notice what it was telling me, not what I assumed it was telling me.
Two design decisions in error display nudge us toward blaming the wrong thing. First, the error wording is unusually specific, so people notice it and remember it. Second, the indicator that ought to disambiguate the situation, the Wi-Fi icon, is misleading because it only proves the link to the router and not the link to the wider internet. Both nudges push you toward the physical device in the room with you, even though that device is rarely the source of the failure.
The pattern that keeps showing up, in three different networks over the last year, is that the named error has very little to do with what is actually broken. The boring fix was the right fix every time, and the boring fix is what I am writing down here so I stop Googling it myself.
How I triage it now
Before I open any control panel, I run a one-line test that tells me where the fault lives. Open a terminal or command prompt and run ping 1.1.1.1 (a packet sent to Cloudflare’s public DNS resolver that confirms your computer can reach the wider internet). If the ping fails, the network is down at the device level, and I am looking at the router or ISP. If the ping works but a browser fails, I am looking at the browser’s network stack, a security app, or the VPN. That one test saves me from an hour of guessing.
Once I know where the fault is, the fix list shrinks dramatically. If the ping fails, the problem is the modem, the router, or my ISP, and the only moves that matter are a power cycle and a call to my ISP. If the ping works, the problem is the browser or the security app, and I have a different short list of moves. The cross-browser test matters too: open the same address in Firefox, Edge, Brave, or Safari. Firefox reports “Server not found” or “The connection was reset” for the same fault, and the others show close variants. The underlying failure is the same across all of them. If only Chrome fails, I am looking at browser state. If all of them fail, I am looking at the device.
Trade-offs
Light fixes cover the vast majority of real cases, and the heavy fixes are usually overkill. Power cycle, captive portal check, and security pause are enough on their own in something like nine out of ten cases I have seen. Network-stack resets, driver updates, and registry edits are the right moves only when those simple ones do not work.
Skip the Windows Network Reset, which some forums recommend. It wipes saved Wi-Fi passwords, VPN settings, and a handful of other things you will have to re-enter. The simple fix done in the right order has the same effect without the collateral damage. Editing the registry to change TCP parameters can leave you with three new bugs. Skip those unless you have a real reason to use them.
- One more cause that public guides bury: the VPN kill switch (the safety feature in VPN software that blocks all internet traffic the moment the encrypted tunnel drops). If the error started right after you quit or crashed a VPN client, the kill switch is almost certainly still armed. Open the VPN app, disconnect cleanly, and close the kill switch. No router fiddling will help until you do.
- Captive portals are easy to miss. Public hotspots remember devices that have signed in before, and they skip the sign-in page on subsequent connections. The right move is to forget the network, reconnect, and accept the sign-in page when it appears.
- Stale Wi-Fi profiles from old networks can take priority over your home network without telling you. Delete the stale profile from the saved networks list and reconnect.
- Quitting a VPN cleanly is its own lesson. A hard quit leaves the kill switch armed. The next browser session sees no usable network and blames the router.
What I would tell past me
Before posting to a forum, gather the diagnostic receipt first: a screenshot of the error itself, the output of ipconfig /all on Windows or ifconfig on Mac, the names of any security apps you have running, and a quick test in a non-Chromium browser. With those four pieces, the right answer usually shows up in the first reply.
Start with the ping test. Walk through power cycle, captive portal, and security pause in sequence. Run the network-stack reset only if the first three did not change anything. The error feels scarier than it is. The fix is almost always one of the boring ones, and that is the part of the story nobody bothers to write down.