ERR_SOCKET_NOT_CONNECTED comes from inside Chrome, not from the network. It means the browser reached for a socket it believed was open, and found it was not - so the request was never sent. Once you know that, the search space collapses to your own machine.
Why this is almost always local
Chrome keeps a pool of open connections and reuses them, which is why a second page on the same site loads faster than the first. If something closes one of those pooled sockets without Chrome noticing - a proxy, an inspecting antivirus, a VPN cycling, or the OS reclaiming it - the next request that picks it up fails at the moment of writing. The server was never contacted, so nothing about the server can explain it.
Confirm it in one step: load the same URL in a different browser. If Firefox or Edge opens it, you are debugging Chrome, not a website.
On a phone (Android or iPhone)
Most people who search this error are on a phone, where the desktop steps further down don't all apply. Same idea, phone version: make Chrome open fresh connections, and take anything that sits between Chrome and the network out of the way. Try these in order and reload after each:
- Switch networks for a moment. Turn Wi-Fi off and load the page on mobile data, or the other way round. Or switch airplane mode on for ten seconds and off again. Either way Chrome has to open new connections.
- Close Chrome completely, then reopen it. On Android: Settings > Apps > Chrome > Force stop. On iPhone: swipe Chrome away in the app switcher.
- Turn off any VPN, ad blocker or "security" app that filters traffic. Many of them work as a VPN on the phone itself. On Android a key icon in the status bar means one is running; on iPhone, look under Settings > VPN. If the page loads with it off, that app is the cause.
- Clear Chrome's cached files. In Chrome: menu (⋮) > Settings > Privacy and security > Delete browsing data, tick "Cached images and files" only, and delete.
- If it only happens inside another app (a link opened from Instagram, WhatsApp or a shopping app): open the same link in Chrome itself, from that app's menu. If Chrome loads it, update Chrome and, on Android, "Android System WebView" from the Play Store. In-app browsers use WebView.
Still failing on both Wi-Fi and mobile data, with every filtering app off? Then it's worth checking whether the site itself is down. See the one case where it is not local below.
The fixes, in the order worth trying them
1. Flush the socket pools
This directly clears the state the error is about, and it is instant:
chrome://net-internals/#sockets → Flush socket pools
chrome://net-internals/#dns → Clear host cache
Do both, then reload. For a one-off, this is usually the whole fix.
2. Test in incognito with extensions disabled
Incognito runs without most extensions by default, which makes it a fast test rather than a fix. If the page loads there, an extension is intercepting connections. Ad blockers with network-level filtering, VPN extensions, and privacy tools that route requests are the usual candidates. Re-enable them one at a time to find which.
3. Check the proxy configuration
A stale proxy setting is one of the most common non-obvious causes, particularly a leftover from software that has since been uninstalled. On Windows, look under Settings → Network & Internet → Proxy and turn off both "Automatically detect settings" and any manual proxy you are not deliberately using. On macOS the same lives under Network → Details → Proxies. From a terminal on Windows you can see what is configured with:
netsh winhttp show proxy
and clear it with netsh winhttp reset proxy from an elevated prompt.
4. Look at security software
Antivirus products that scan HTTPS traffic sit between Chrome and the network by design, terminating connections and re-establishing them. When that machinery misbehaves, this error is one of the symptoms. Disable HTTPS or web scanning specifically, rather than the whole product, load the page once, and turn it back on. If that was the cause, add an exception instead of running unprotected.
5. Reset Chrome's network state
If the error persists across restarts, reset the browser's networking configuration. Chrome's settings have a "Restore settings to their original defaults" option that clears the proxy configuration, extensions and cached network state together. Bookmarks and saved passwords are kept.
On Windows it is also worth resetting the OS network stack, which clears Winsock layers that third-party software has inserted:
netsh winsock reset
netsh int ip reset
ipconfig /flushdns
Reboot afterwards - these do not take effect until you do.
The one case where it is not local
If several people on different networks report the same error on the same site at the same time, look at whatever sits in front of the origin. A load balancer or CDN that accepts a connection and then drops it without a response can leave Chrome holding exactly the kind of dead socket that produces this. Test the origin directly to separate the two:
curl -sS -o /dev/null -w '%{http_code}\n' --resolve yourdomain.com:443:ORIGIN_IP https://yourdomain.com
If the origin answers cleanly and the public hostname does not, the proxy layer is where to look. If both answer, you are back to a client-side cause and the list above applies.
FAQ
How do I fix ERR_SOCKET_NOT_CONNECTED on my phone?
Switch between Wi-Fi and mobile data (or toggle airplane mode), fully close and reopen Chrome, and turn off any VPN, ad-blocking or security app that filters traffic. If the error only appears inside another app's browser, open the link in Chrome and update Chrome and Android System WebView from the Play Store.
Is the website down when I see this?
Almost never. This error is raised inside Chrome's own networking layer when it finds a socket in an unusable state, before or as the request is written. Load the same URL in a different browser - if it works, the site is fine and Chrome's state is the problem.
Why does it only happen in Chrome?
Because it is Chrome's own error string, raised by its socket pooling. Chrome reuses connections aggressively, and a pooled socket that was closed by a proxy or by security software can be picked up and written to before Chrome notices it is dead. Other browsers pool differently and surface the same underlying event as a reset or a generic failure.
Could a proxy setting cause this even if I do not use a proxy?
Yes. A proxy configuration left behind by uninstalled software, or a PAC script that no longer resolves, will silently break connections. Check the system proxy settings and turn off automatic proxy detection, which is a frequent culprit on Windows machines.
I disabled my extensions and it still happens. What next?
Look at software outside the browser: HTTPS-inspecting antivirus, corporate endpoint agents, and VPN clients all intercept connections at the socket level. Disable them one at a time, load the page, and re-enable. If the error stops for one of them, the fix is an exception in that product rather than leaving it off.
Does resetting Chrome's settings fix it?
It often does, because it clears the proxy configuration, extension state and network settings together. Try the targeted steps first - flushing socket pools and testing in incognito - since a full reset also discards things you may want to keep.
Originally published on the Getwebup blog.
This article was created with the help of AI.
Top comments (0)