Fix ERR_CONNECTION_CLOSED: Causes and Solutions

ERR_CONNECTION_CLOSED means the remote server dropped the TCP connection before your browser received a response. Chrome sent the request, but instead of data it got a reset (TCP RST) or silence. The cause is almost always on the server, a firewall, an antivirus, or a faulty network, and only rarely the browser itself.

This guide covers every source of the error: the server closing the connection, antivirus and proxies cutting traffic, network and MTU problems, TLS handshake resets, and server overload or crashes. Below you will find how to localize the fault in five minutes and how to fix it as a user and as an administrator, with curl, chrome://net-internals, and nginx log analysis.

What ERR_CONNECTION_CLOSED means

The error belongs to the Chromium network layer (code net::ERR_CONNECTION_CLOSED). It fires when a connection was established or being established, but the other side closed it without a valid HTTP response. At the TCP level this is usually an RST (reset) packet instead of the expected ACK with data. Unlike ERR_CONNECTION_REFUSED, where nothing is listening on the port, here the connection reaches the server but is cut off halfway.

It is important to distinguish this from neighboring errors. ERR_CONNECTION_RESET means the connection was dropped mid-transfer. ERR_CONNECTION_TIMED_OUT means no response arrived within the allotted time. ERR_CONNECTION_CLOSED means the server actively terminated the session. Their diagnostics partly overlap, but the root causes differ.

Causes of ERR_CONNECTION_CLOSED

It is easiest to group causes by layer: client, network, and server. That makes it clear where to look. The table below lists typical sources and the signs of each.

The server closed the connection (TCP RST)

The most common scenario. The web server or its upstream (PHP-FPM, the application) aborted processing and sent an RST. Causes include a process segfault, exceeded fastcgi/proxy timeouts, memory exhaustion triggering the OOM killer, or an upstream config error. The browser only sees the closure; the details live in the server logs.

Antivirus, firewall, and proxy

Many antivirus products (Kaspersky, ESET, Avast) intercept HTTPS to inspect traffic, substituting a certificate. If their web-protection module conflicts with the site or an outdated TLS setup, the connection is dropped. Corporate proxies and gateway SSL inspection do the same. The tell-tale sign is that the error only reproduces on a specific network or a managed PC.

Network and MTU problems

If the server response is large and there is a hop along the path with a smaller MTU and blocked fragmentation (blackhole PMTUD), big packets get lost and the connection hangs and drops. This is more common over VPN, PPPoE, and tunnels. Small pages open, heavy ones do not.

TLS handshake reset

If the server only supports outdated protocols (TLS 1.0/1.1) or an incompatible cipher suite, modern Chrome may get a reset during the handshake. The same happens with a wrong SNI configuration, a missing intermediate certificate, or strict security settings on a load balancer.

How to tell where the problem is

Before fixing anything, localize the source. Run through this checklist; it separates client from server in a couple of minutes:

• Another browser — if Firefox or Edge open the site, the problem is in the Chrome profile or extensions.
• Incognito mode — rules out extensions and part of the cache.
• Another device on the same network — if the error persists there, it is the network or server, not your PC.
• Another network (mobile data instead of Wi-Fi) — if that helps, an ISP or local gateway is cutting the session.
• Server logs — if everyone hits the error, check the web server error.log.

Chrome's built-in tool gives the precise network picture. Open the connection events:

chrome://net-internals/#events
# in older versions use chrome://net-export/ to record a log

# flush the socket and host cache without restarting the browser:
chrome://net-internals/#sockets  -> Flush socket pools
chrome://net-internals/#dns      -> Clear host cache

From the terminal the fastest way is to probe the server directly, bypassing the browser and its extensions:

curl -v https://example.com/
# see at which stage the drop happens:
#  * Connected to ...        — TCP is up
#  * TLSv1.3 handshake ...   — a reset here means a TLS problem
#  * curl (56) Recv failure  — the server closed the connection

# probe only the TLS handshake separately:
openssl s_client -connect example.com:443 -servername example.com

How to fix it as a user

If only you hit the error, go from simple to complex:

1. Reload the page and restart the router — some drops clear on a fresh session.
2. Temporarily disable the antivirus web/HTTPS-protection module and test again.
3. Turn off VPN, the system proxy, and suspicious Chrome extensions.
4. Flush the socket and DNS cache via chrome://net-internals (see above).
5. Reset the Windows network stack with the commands below and reboot.

# Windows — reset the network stack and DNS:
ipconfig /flushdns
netsh winsock reset
netsh int ip reset
# then reboot

# check the system proxy (there should be no foreign address):
netsh winhttp show proxy

If the site then opens in another browser but not Chrome, create a new Chrome profile or reset settings. A corrupt socket pool and damaged profile data are a frequent cause of the "error only in Chrome" pattern.

How to fix it on the server

If the error reproduces for everyone and from curl, the problem is on the server. Start with the logs — they point to the exact reason for the drop.

# nginx — look for upstream resets and timeouts:
tail -f /var/log/nginx/error.log
# typical lines:
#  upstream prematurely closed connection
#  recv() failed (104: Connection reset by peer)
#  upstream timed out (110: Connection timed out)

# PHP-FPM upstream state:
systemctl status php-fpm
journalctl -u php-fpm --since "10 min ago"

Then act on the cause you found:

• Upstream crash — check dmesg | grep -i oom for the OOM killer, raise the PHP-FPM/application memory limits, and fix fatal errors.
• Timeouts — align fastcgi_read_timeout/proxy_read_timeout in nginx with the backend's real response time.
• Keepalive and limits — check worker_connections, keepalive_timeout, and the worker pool limits if drops happen under load.
• TLS — enable TLS 1.2/1.3, a current cipher suite, and add the intermediate certificate to the chain.

How to check

To confirm the server responds with correct headers again and no longer drops the connection, use our tools. Run the HTTP header checker — it shows the status code, redirects, and response headers without interference from your antivirus or extensions. To assess TLS and security headers, use the security scanner: it reveals an outdated protocol, an incomplete certificate chain, and other handshake-reset causes.

Related connection errors

ERR_CONNECTION_CLOSED rarely arrives alone — similar errors with different root causes live nearby. It helps to understand them too:

• ERR_CONNECTION_REFUSED: nothing listening on the port
• ERR_CONNECTION_RESET: dropped mid-transfer
• ERR_CONNECTION_TIMED_OUT: no response in time

Frequently Asked Questions

Is ERR_CONNECTION_CLOSED my problem or the server's?

Test the site in another browser, in incognito, and from a different device on the same network. If the error disappears in any of them, the problem is local: antivirus, extensions, a proxy, or the Chrome profile. If the site fails everywhere and from curl, the cause is on the server or in the ISP's network.

Why does the site open on my phone but not my computer?

Most likely the computer has an active antivirus HTTPS-inspection module, a system proxy, or a VPN that breaks the connection. The phone on mobile data takes a different route without those intermediaries. Disable web-traffic protection and the proxy on the PC and test again.

Can antivirus cause ERR_CONNECTION_CLOSED?

Yes, and it is one of the most common causes. Antivirus software intercepts HTTPS for inspection by substituting a certificate. When it conflicts with the site or an outdated TLS setup, the connection drops. Temporarily disable the antivirus web protection: if the error clears, add an exclusion for the domain you need.

How is ERR_CONNECTION_CLOSED different from ERR_CONNECTION_RESET?

With CLOSED the server ends the connection, often before any useful data or during the handshake. With RESET the connection is dropped mid-exchange by an RST packet. The causes partly overlap (network, firewall, server), but RESET is more often tied to an active intermediary interfering with the stream.

How do I see exactly what breaks the connection?

Run curl -v https://your-site/ and watch where the drop happens: before TLS, during the handshake, or while receiving data. In parallel open chrome://net-internals/#events. On the server read the nginx error.log — lines about premature close and connection reset point to the source.

Does clearing the cache and resetting the network help?

Often yes, when the cause is local. Flush the socket and DNS cache in chrome://net-internals, run ipconfig /flushdns and netsh winsock reset, then reboot. That clears stuck connections and a corrupt socket pool. If the error is server-side, a client reset won't help — fix the server configuration.

Sources: MDN: HTTP status and semantics, Chromium: network logging and net-error codes.