How to Fix ERR_CONNECTION

TL;DR

ERR_CONNECTION_CLOSED is Chromium net error -100, and the comment next to it in the source ties it to a TCP FIN. The connection was established and then closed by the other side before Chrome received a usable response. That rules out name resolution failures and refused connections, both of which have their own error codes, and points at whatever handled the socket after the handshake: a browser extension, local security software, a filtering middlebox, a proxy, or the origin server. Work outward from your own machine, and if your traffic passes through a proxy, reproduce the request with curl before you touch a single browser setting.

Most troubleshooting lists for this error open by saying Chrome could not connect to the server. That is not what the code reports, and starting from the wrong definition sends you through a long checklist of steps that have nothing to do with the problem. The connection did open. Something on the path decided to hang up. In this article, we'll explore what the error reports at the TCP level and how to trace the close back to its source.

Reading the Error at the TCP Level

Chromium assigns this error the value -100, and the entry in net_error_list.h describes it as a connection that was closed, corresponding to a TCP FIN. A FIN is a graceful shutdown. It comes from a peer that completed the handshake and then decided it was finished. That is a different event from -101, ERR_CONNECTION_RESET, which maps to an RST, and from -102, ERR_CONNECTION_REFUSED, which means nothing was listening on the port at all.

The distinction narrows the search considerably. Because the socket opened, DNS resolved and the route worked. Whatever went wrong happened after that, so the fault sits with something that handled the connection once it was live. On a personal machine that is usually an extension or a security product sitting inside the TLS session. On a filtered network it is usually a middlebox reading the SNI and closing connections to domains it does not like.

Also Read: HTTP 499 Explained

How to Fix ERR_CONNECTION_CLOSED

Working Outward From Your Own Machine

Test the same URL outside Chrome first. If curl and a second browser both load the page, the problem is browser-side and you can leave the network alone.

Extensions are the most common cause. Open chrome://extensions, disable everything, reload the page, then switch them back on one at a time. Blockers and anything with security or privacy in the name are worth checking before the rest.

If that changes nothing, reset the local network stack and clear the resolver cache. On Windows, run netsh winsock reset, netsh int ip reset, and ipconfig /flushdns from an elevated prompt, then reboot.

Antivirus and firewall software come next. Products that scan HTTPS traffic insert themselves into the TLS session, and a failed inspection ends with the socket closing. Turn off the HTTPS scanning feature specifically rather than the entire product, then retest. Disabling IPv6 clears the error on some setups, but treat that as a workaround rather than a fix, since address selection order follows RFC 6724 and has behaved that way for over a decade.

If the site is yours, check keep-alive timeouts before anything else. Apache closes idle connections at KeepAliveTimeout and NGINX at keepalive_timeout, and a value set too low produces this error during ordinary browsing. The Keep-Alive header tells you what the server is advertising.

When a Proxy Sits in the Path

Reproduce the request on the command line before changing browser settings:

ABAP

curl -v -x http://user:pass@gateway.proxyon.io:8000 https://example.com

Read the verbose output for the CONNECT exchange. A 200 response to CONNECT means the tunnel opened, so a close after that point came from the proxy or the origin rather than from your configuration. If curl reports an empty reply once the tunnel is up, the proxy took the request and then dropped the socket. Free and public proxy lists do this constantly, since the endpoints are overloaded or already dead.

Malformed credentials produce the same symptom on some gateways, which close the connection instead of returning a 407. Run your endpoint through the proxy formatter to confirm the host, port, and credential syntax are correct before assuming the pool is at fault. From there, residential proxies hold connections open on targets that close them for datacenter ranges, while datacenter proxies are fine on anything without aggressive filtering.

Also Read: Proxy SwitchyOmega Explained

FAQ Section

Is ERR_CONNECTION_CLOSED the same as ERR_CONNECTION_RESET?

No. Closed maps to a TCP FIN and reset maps to a TCP RST. A FIN is a clean shutdown, an RST is an abrupt one, and they usually point to different causes.

Why does the error only appear on one website?

A single affected site rules out your network stack and points to that specific connection. Look at TLS inspection, an extension rule matching that domain, or SNI-based filtering on the network you are using.

Can a proxy cause ERR_CONNECTION_CLOSED?

Yes. A proxy that accepts the CONNECT request and then drops the socket produces exactly this error in Chrome. Testing the same request with curl tells you whether the tunnel opened before the close.

Does clearing the browser cache fix it?

Rarely. Cached data is not involved in a transport-level close, so it is worth a single attempt and not much more.

Final Thoughts

ERR_CONNECTION_CLOSED tells you the connection was live and then ended, which is more information than most fix lists give it credit for. Start with extensions and TLS-scanning security software, since those account for the majority of cases on a single machine. If a proxy is in the path, reproduce the request with curl and read the CONNECT exchange before changing anything else.

How to Fix ERR_CONNECTION_CLOSED (2026)