What's the difference between ERR_CONNECTION_CLOSED and ERR_CONNECTION_RESET?

They map to two different TCP packets. Chromium's net_error_list.h defines ERR_CONNECTION_CLOSED (-100) as a connection closed by a TCP FIN — a graceful 'we're done' — and ERR_CONNECTION_RESET (-101) as a connection reset by a TCP RST — an abrupt kill. CLOSED means something finished the connection cleanly before your response was complete; RESET means something tore it down hard.

Why does the same page sometimes load and sometimes throw ERR_CONNECTION_CLOSED?

Intermittent closes usually point at keep-alive and timeout settings. A server (or proxy) that closes idle or slow connections — Apache's KeepAliveTimeout, nginx's client_header_timeout — will send a FIN that Chrome reports as ERR_CONNECTION_CLOSED on the next reused connection. It looks random because it depends on timing, not the URL.

Could antivirus or a VPN cause ERR_CONNECTION_CLOSED?

Yes. Security software that inspects HTTPS sits in the middle of the TLS handshake. If its interception certificate isn't trusted by the server, or it dislikes the handshake, it closes the connection — and the browser sees the FIN, not the antivirus. Disabling HTTPS scanning temporarily is the fastest way to rule this out.

Views: 18

ERR_CONNECTION_CLOSED in Chrome: Fix Checklist

ERR_CONNECTION_CLOSED means a TCP FIN closed the connection mid-request. Check TLS, keep-alive, antivirus, and reachability. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Chrome shows a blank page with This site can't be reached and the detail ERR_CONNECTION_CLOSED (sometimes written net::ERR_CONNECTION_CLOSED).

Symptoms

The error is intermittent — reload sometimes fixes it, sometimes doesn’t.
Other sites load fine, so it isn’t your whole network.
It started after enabling a VPN, a new antivirus, or a server config change.

What ERR_CONNECTION_CLOSED actually means

The error name is precise, and the precision is the diagnostic. Chromium’s net_error_list.h defines ERR_CONNECTION_CLOSED (-100) as “A connection was closed (corresponding to a TCP FIN).” A FIN is the polite way to end a TCP connection: one side says “I’m done sending.” The problem is the timing — that FIN arrived while Chrome was still waiting for your response. Something on the path decided the conversation was over before it actually was.

That one detail rules a lot out. This is not DNS (the name resolved), and it’s not a refused connection (a refusal is ERR_CONNECTION_REFUSED, -102, a RST or ICMP at connect time). The connection got far enough to be established and then was closed under you. Its loud cousin, ERR_CONNECTION_RESET (-101), is a TCP RST — an abrupt reset rather than a graceful FIN. And ERR_EMPTY_RESPONSE (-324) is “the server closed the connection without sending any data,” which is a FIN that arrived even earlier, before a single byte of response. Knowing which of these you have tells you where to look.

Top 3 Causes

TLS interception by security software - Antivirus, a corporate proxy, or a VPN that scans HTTPS inserts itself into the handshake. If the server rejects its certificate or the rewritten handshake, the connection is closed and Chrome reports the FIN. This is the single most common cause of an intermittent, machine-specific ERR_CONNECTION_CLOSED.
Server keep-alive and timeouts closing the connection - Browsers reuse connections. If the server or a reverse proxy closes idle or slow ones — KeepAliveTimeout and MaxKeepAliveRequests in Apache, client_header_timeout and keepalive_timeout in nginx — the next request on that reused socket meets a FIN. The result looks random because it depends on connection age, not the page.
An origin or middlebox dropping the connection - A firewall rule, an overloaded backend, or an MTU/protocol mismatch on the path can terminate the connection mid-flight. Here the close is coming from the network, not your machine, and it tends to be reproducible from more than one client.

Diagnose with DechoNet

HTTP Check from outside your network — if it succeeds while your browser fails, the close is local to your machine (antivirus, VPN, proxy), not the server.
SSL Check to confirm the TLS handshake completes cleanly against the origin, which isolates certificate and interception problems.
Port Check to verify the target port is actually reachable and not being dropped by a firewall.

Resolution Checklist

Reproduce from a second device or network. If only your machine fails, suspect local interception first.
Temporarily disable antivirus HTTPS/SSL scanning and any VPN, then retry — this rules in or out the most common cause fast.
Run an external HTTP check; success there points the finger at your local environment, failure points at the server or path.
If the error is intermittent under load, review server and proxy keep-alive and timeout settings for connections being closed too aggressively.
Confirm TLS completes against the origin and the certificate chain is valid end to end.
Clear the browser’s socket pool (chrome://net-internals → close idle sockets) to drop stale reused connections.

When to Escalate

If an external check also fails, the close is server- or network-side — hand the timeouts, firewall rules, and proxy config to whoever owns the origin.
If it only happens on a managed/corporate network, the HTTPS-inspecting proxy is the likely culprit; that’s a conversation for IT, not a setting you can change in the browser.