ERR_CONNECTION_CLOSED

The short version: Reload once, since a single closed connection is often transient. If it persists, test in an incognito window and with any HTTPS-scanning security software disabled, because both extensions and TLS inspection cause this. If you run the website, compare your proxy's response timeout against how long the failing page actually takes: a close that only affects slow pages is a timeout, not a fault.

Key takeaways

• ERR_CONNECTION_CLOSED is Chromium net error -100. The connection was closed unexpectedly while the browser was still waiting for data, so no HTTP response ever arrived.
• It is an orderly TCP FIN rather than an abrupt RST, which is what distinguishes it from a reset. Something chose to end the connection instead of something breaking it.
• That politeness usually points at software with a timeout: a reverse proxy, a load balancer, or an HTTPS-inspecting security product ending the connection deliberately.
• A 502 is not the same failure. A 502 means the proxy survived and reported the problem over HTTP; a closed connection means nothing survived long enough to answer at all.
• When only the slow or heavy pages fail, the cause is almost always a response timeout in the chain rather than anything intermittent.

Error type

Browser connection error (Chromium net error -100)

Whose side

Either: the server chain, or a local security tool

Fix difficulty

Moderate

Common cause

The connection closed before any response arrived

What does ERR_CONNECTION_CLOSED mean?

ERR_CONNECTION_CLOSED is Chromium net error -100, and it describes a very specific moment in a request. The browser resolved the name, opened a TCP connection, completed the TLS handshake if the page was HTTPS, and sent its request. Then, before any response headers came back, the other end closed the connection. Because it closed rather than reset, the shutdown was orderly: a TCP FIN rather than an RST. Something on the other side decided to end the conversation, which is a meaningfully different situation from something breaking it.

That distinction is the most useful thing about this error. Deliberate closes come from software making a decision, and the software that makes such decisions is almost always sitting between the browser and the application. A reverse proxy or load balancer that hits its response timeout will close the connection to the client. A security product inspecting HTTPS terminates the original connection to do so, and closes it if its own inspection fails. The application itself is a less common cause, because a running application usually manages to return a 500 or a 502 instead. When you see this error, the layer to suspect is the one in the middle.

-100

The Chromium net error number behind this message, defined in net_error_list.h

FIN

The orderly TCP close that distinguishes this from a reset, which sends RST instead

60 s

A common default proxy read timeout, and the usual reason slow pages close while fast ones do not

How the ERR_CONNECTION_CLOSED error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com

This site can't be reached

The connection was closed unexpectedly.

ERR_CONNECTION_CLOSED

• ERR_CONNECTION_CLOSED
• net::ERR_CONNECTION_CLOSED
• The connection was closed unexpectedly
• This site can't be reached, the connection was reset or closed
• Empty reply from server
• Connection closed by peer

Closed, reset, empty and 502

These four are easy to confuse because all of them interrupt a request, and each points at a different layer.

How a connection ends, and what each ending means

The browser reports these separately because the underlying TCP behaviour differs, and each points somewhere different.

What causes ERR_CONNECTION_CLOSED?

• A reverse proxy or load balancer hitting its response timeout and closing the connection, which is why heavy pages fail while light ones succeed.
• A security suite or antivirus inspecting HTTPS traffic, which terminates the original connection and closes it when inspection fails or times out.
• A browser extension that proxies or rewrites requests, which is why the page often works in an incognito window.
• Keep-alive mismatches, where the server closes an idle connection at the moment the browser reuses it, so the request lands on a socket already being shut down.
• An application or worker process that exits while handling the request, closing its socket without writing a response.
• MTU or fragmentation problems on the path, especially over VPNs, where large responses fail while small ones succeed.
• A corporate proxy or content filter terminating connections it cannot inspect or classify, which affects one network only.

How to find the cause fast

1. Note whether it is all pages or only slow ones. Only slow pages failing is a timeout, and that alone narrows the search to the proxy layer.
2. Try an incognito window with extensions disabled. Working there points at an extension or at cached state in your normal profile.
3. Disable HTTPS scanning in your security software specifically, rather than the whole product, and retest.
4. Run curl -v and watch where it stops. A connection closing after the request but before any headers confirms the failure is below HTTP.

Terminal

curl -v https://example.com/report> GET /report HTTP/1.1* Empty reply from server# request sent, connection closed before any header came back

How ERR_CONNECTION_CLOSED looks from the outside

This failure produces no HTTP status code, which is exactly what makes it easy to miss. A monitor that only checks whether the host answers may well see a successful connection on a light path while the pages that matter are being closed mid-response, and a check that treats any answer as success will not notice at all. Because the usual cause is a timeout, the failure also correlates with load: it appears when responses slow down and disappears when they speed up, which makes it intermittent in exactly the way that defeats manual testing. Checking the URLs that actually take time, and alerting on the response rather than the connection, is what surfaces it.

How to fix ERR_CONNECTION_CLOSED

If you are a visitor

1. Reload the page once. A single closed connection is often transient and does not recur.
2. Open the page in an incognito window. If it works there, an extension or cached state in your normal profile is responsible.
3. Disable HTTPS or SSL scanning in your antivirus or security suite, which is one of the most common local causes of this error.
4. Turn off extensions one at a time, paying particular attention to anything that proxies, filters, or rewrites traffic.
5. Try a different network. A failure that follows you is server-side or browser-side; one that does not is equipment on that network.
6. Disconnect any VPN, which can also introduce MTU problems that break large responses while small ones succeed.
7. If only one website is affected and it fails everywhere you try, the problem is on their side and there is no local fix.

If you run the website

1. Compare your proxy or load balancer response timeout against how long your slowest legitimate responses take. A mismatch here is the single most common cause.
2. Align keep-alive timeouts so the server does not close idle connections at the moment a client reuses them. The server's idle timeout should exceed the load balancer's.
3. Check application and worker logs for processes exiting mid-request, which closes the socket without writing a response.
4. Look for out-of-memory kills or worker recycling that terminates requests in flight, particularly on the heaviest endpoints.
5. Test the failing endpoints with curl -v from outside your network to see exactly where in the exchange the connection ends.
6. Return a real error status where you can. A 502 or 504 is far easier for a visitor and for your own logs than a bare closed connection.

Still not fixed? Next steps

• Check whether the failure tracks page weight. If the slow endpoints fail and the light ones do not, look for a response timeout in the proxy or load balancer rather than for a fault.
• Reproduce it with curl -v. Seeing the connection close after the request is sent but before headers arrive confirms the failure is below HTTP, which rules out application-level causes.
• Test with HTTPS inspection disabled in any security suite. These products terminate and re-establish TLS, and a failure inside that layer surfaces exactly like this.
• Compare a different network. A close that follows you across networks points at the server or the browser profile; one that only occurs on a single network points at equipment there.
• On the server side, check proxy timeouts and keep-alive settings against how long your slowest legitimate responses take, since the mismatch between them is the usual root cause.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

See exactly where the connection ends

curl -v https://example.com/slow-report
# > GET /slow-report HTTP/1.1
# * Empty reply from server
# request sent, connection closed before any response header

Raise the proxy timeout to match a slow endpoint

# nginx: default read timeout is 60s
location /reports/ {
  proxy_pass          http://app;
  proxy_read_timeout  180s;
  proxy_send_timeout  180s;
}
# raise deliberately, and only for the paths that need it

Keep the upstream idle timeout above the balancer's

# if the server closes idle connections first, the balancer reuses
# a socket that is already shutting down and the client sees a close
# balancer idle timeout : 60s
# server keepalive_timeout: 75s   <- must be the longer of the two

How to prevent ERR_CONNECTION_CLOSED

A closed connection returns no status code at all, so a check that merely confirms the host answers will report the website up while the pages people actually use are being cut off. It is worse than that in practice, because the usual cause is a timeout: the failure appears under load and vanishes when you go looking for it. Pulsetic checks your website and endpoints from multiple locations every 30 seconds and alerts you by email, SMS, voice call, Slack, Discord, Telegram, or webhook when a URL stops returning what you expect, so a proxy quietly closing your slowest pages shows up as a pattern rather than as scattered complaints.

Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.

Sources and further reading

The specifications and vendor documentation this guide is written from, plus deeper reading on the parts it only summarises.

• Chromium network error list (net_error_list.h)
• RFC 9293: Transmission Control Protocol
• MDN: Connection management in HTTP/1.x