ERR_CONNECTION_CLOSED: what it means and how to fix it

What ERR_CONNECTION_CLOSED means

Chromium defines CONNECTION_CLOSED (-100) as "A connection was closed (corresponding to a TCP FIN)". A FIN is the orderly way to end a TCP connection: the sender says it has no more data. A reset is the abrupt way, and Chrome reports that as ERR_CONNECTION_RESET. With ERR_CONNECTION_CLOSED the connection was ended politely, but at a moment when Chrome still waited for the TLS handshake or for the response.

Chrome does not use the code for every early close. Its source code treats a plain HTTP/1.x connection that closes without sending any byte in two ways. If the connection is new, Chrome reports ERR_EMPTY_RESPONSE. If the connection was reused from an earlier request, Chrome keeps ERR_CONNECTION_CLOSED, and a comment in the code gives the reason: it is "much more likely the server closed the socket before it received the request". Chrome then resends the request on another connection, so a visitor rarely sees an error from that case alone.

In practice the error page appears mostly on HTTPS. If the peer closes while the TLS handshake is running, Chrome usually reports ERR_CONNECTION_CLOSED. The same code is used when an HTTP/2 connection is closed by the peer, which fails every request that was waiting on that connection. RFC 9113 says an endpoint SHOULD send a GOAWAY frame before it closes an HTTP/2 connection, so the other side knows which requests were processed. A server or load balancer that closes without one leaves the browser with this error.

How the error appears

Chrome shows "This site can't be reached" with the text "example.com unexpectedly closed the connection" and the code ERR_CONNECTION_CLOSED. It suggests checking the connection, checking the proxy and the firewall, and running Windows Network Diagnostics. Firefox usually reports a close during the TLS handshake as "Secure Connection Failed" with the code PR_END_OF_FILE_ERROR. The command line shows more detail:

curl -sS http://example.com/
curl: (52) Empty reply from server

curl -sS https://example.com/
curl: (35) TLS connect error: error:0A000126:SSL routines::unexpected eof while reading

The first case is a plain HTTP request on a new connection, where Chrome says ERR_EMPTY_RESPONSE. The second is a close during the TLS handshake; the wording depends on the TLS library, and this one comes from OpenSSL 3. openssl s_client shows the same event as "unexpected eof while reading" with "SSL handshake has read 0 bytes":

openssl s_client -connect example.com:443 -servername example.com </dev/null

A connection that was reused and closed by the server shows up in curl -v when two URLs share one connection. curl notices the dead connection and retries, which is what Chrome does as well:

* Connection died, retrying a fresh connect (retry count: 1)

ERR_CONNECTION_CLOSED vs similar errors

Chrome shows all of these under the same "This site can't be reached" heading, so the code underneath tells them apart. The numbers are Chromium's internal error codes.

Error	What happened at the network or protocol level	Where to look first
ERR_CONNECTION_TIMED_OUT (-118)	The SYN went out and nothing came back, neither SYN-ACK nor RST, until the client gave up.	Firewalls that drop packets, and whether the host is up.
ERR_SSL_PROTOCOL_ERROR (-107)	The peer answered, but its data was not valid TLS, for example plain HTTP on a TLS port.	The protocol the port really speaks, and the TLS settings of the server.
ERR_CONNECTION_CLOSED (-100)	The peer sent a FIN. Chrome had no complete response, often during the TLS handshake or on an HTTP/2 connection.	The edge in front of the site: default server blocks, load balancer, proxy, firewall, security software.
ERR_CONNECTION_RESET (-101)	The connection was open, then an RST ended it during the handshake or the transfer.	Proxy, WAF and application logs at that moment; antivirus, VPN or filtering on the client's network.
ERR_EMPTY_RESPONSE (-324)	A new HTTP/1.x connection opened, the request went out, and the server closed it without sending any data.	Crashed workers, and connections closed on purpose (nginx's return 444).
ERR_CONNECTION_ABORTED (-103)	The local network stack gave up because data it sent was never acknowledged.	Packet loss on the link, a flaky Wi-Fi connection, or a firewall that drops traffic in the middle of a transfer.

What causes ERR_CONNECTION_CLOSED

• A catch-all server closes the connection. The request reached a server block that does not know the host name, for example after a typo in server_name or when DNS still points at an old server, and that block is set to close the connection.
• A firewall, proxy or filter ends the connection. Security appliances, school and company networks, parental controls and some national filters can close a connection instead of resetting it, and so can TLS inspection that fails on one site.
• An idle connection is closed at the wrong moment. A server or load balancer closes an idle keep-alive connection while the browser is sending a request on it. RFC 9112 allows this: a client, server or proxy may close a connection at any time.
• A server process stops. A crash, an out-of-memory kill, a recycled worker, or a restart during a deploy closes the sockets of the process.
• An HTTP/2 connection ends without GOAWAY. Idle limits and per-connection request limits close connections that carry many requests.
• The TLS endpoint of the server gives up. A TLS library that fails on the ClientHello, or a TLS terminator that is overloaded or restarting, can end the handshake with a plain close.
• Software on the visitor's computer interferes. Antivirus HTTPS scanning, a VPN, a proxy setting, or a stale hosts file entry that sends the domain to the wrong server.

Server-side causes and configuration

Work from the edge inward: the CDN or load balancer first, then the web server, then the application. For each hop, find out whether the connection from the browser ends there.

See who sends the FIN

On the server, capture only the packets that carry FIN or RST flags while you reproduce the error:

sudo tcpdump -ni any 'tcp port 443 and (tcp[tcpflags] & (tcp-fin|tcp-rst) != 0)'

A line with Flags [F.] is a FIN, and Flags [R] or [R.] is a reset. If the first FIN comes from the server address directly after the client's first packets, the server or the edge in front of it closes the connection. If no packets from the client reach this machine at all, the connection is closed before it gets here.

Catch-all server blocks and wrong IP addresses

Many nginx setups have a default server that rejects unknown host names. The nginx documentation says the non-standard code 444 "closes a connection without sending a response header":

server {
    listen 443 ssl default_server;
    ssl_certificate     /etc/ssl/default/fullchain.pem;
    ssl_certificate_key /etc/ssl/default/privkey.pem;
    return 444;   # close the connection, send nothing
}

That block is correct on its own. It becomes a problem when your real site does not match any other block: a typo in server_name, a missing www name, or a domain that DNS points at the wrong machine. Visitors then get a closed connection, which can show as ERR_CONNECTION_CLOSED or as ERR_EMPTY_RESPONSE. List the names the server answers for, and test one server directly even when DNS says otherwise:

sudo nginx -T | grep -n server_name
dig +short example.com
curl -vk --resolve example.com:443:203.0.113.10 https://example.com/

The --resolve option makes curl connect to the address you give while it still sends the right host name. If one address works and another closes, the second one leads to a server that does not serve the site. The who hosts a website guide shows how to find out which provider owns an address.

Keep-alive and idle timeouts

A front proxy must give up on an idle backend connection before the backend does. If the backend closes first, the proxy may send its next request on a connection that is already closed. The same applies between a load balancer and its targets. AWS documents a default idle timeout of 60 seconds for its Application Load Balancer and recommends that the idle timeout of the application be longer; otherwise the visitor can get a 502 Bad Gateway. Node.js closes idle connections after 5 seconds by default, far below that value:

const http = require('node:http');
const server = http.createServer(app);
server.keepAliveTimeout = 65 * 1000;   // longer than the 60 s idle timeout of the load balancer
server.listen(3000);

nginx keeps idle client connections for 75 seconds by default (keepalive_timeout 75s;). When a backend closes the connection before it sends a response, nginx logs upstream prematurely closed connection while reading response header from upstream. The ERR_CONNECTION_RESET guide covers the proxy side of this problem in more detail.

Crashes and restarts

sudo journalctl -k --since "1 hour ago" | grep -i -E "out of memory|killed process"
sudo journalctl -u myapp --since "1 hour ago" --no-pager

Match a worker's death or restart to the timestamps of the failed requests. A crash can produce either error: the client sees a FIN or an RST depending on whether the process still had unread data when its sockets closed.

How it looks from the outside

• Closed from every location, during the handshake: the server or the edge closes unknown or broken TLS connections. Check the default server, the certificate for the requested name, and the DNS records.
• Closed from some locations only: one of several IP addresses returned by DNS does not host the site, a CDN node in that region is unhealthy, or a filter on that network closes the connection.
• Plain HTTP works, HTTPS closes: the problem is in the TLS layer, such as the certificate, the handling of the server name, or a terminator in front of the server. The SSL handshake failed guide covers the handshake itself.
• Closed now and then, at random: idle timeouts, recycled workers, or one unhealthy server behind a load balancer.
• Fine from every checkpoint, closed only for you: the cause is your network or your device, such as antivirus, a VPN, a proxy, the hosts file, or your provider.

The HTTP checker checks a host's HTTP status, response time and server availability from locations worldwide, so you can tell a site-wide close from one tied to a single network.

How to fix ERR_CONNECTION_CLOSED

If you are a visitor

1. Reload the page once or twice. A connection that the server had just closed is replaced by a new one on the next try.
2. Try another network, such as mobile data instead of Wi-Fi. If the site loads, the cause is on your network or device.
3. Turn off the VPN and any proxy. On Windows, open Settings > Network & internet > Proxy. On macOS, run scutil --proxy to see the proxy settings.
4. Pause HTTPS scanning in your antivirus (often called web protection or SSL/TLS scanning) and retry. If that helps, add an exception for the site instead of leaving the scan off.
5. Reset Chrome's connections. Open chrome://net-internals/#sockets and click "Close idle sockets" and "Flush socket pools". On the "DNS" tab of the same page, click "Clear host cache".
6. On Windows, refresh the network stack. Run these in a Command Prompt as administrator, then restart:

   ipconfig /flushdns
   netsh winsock reset
   netsh int ip reset

7. Check the hosts file for an old entry that sends the domain to another server: C:\Windows\System32\drivers\etc\hosts on Windows, /etc/hosts on macOS and Linux.
8. Disable extensions or use a private window. If the error disappears, turn the extensions back on one at a time.

If you run the site

1. Reproduce it from outside your network with curl -v https://example.com/ and openssl s_client. A close during the handshake points at the TLS endpoint; a close after the request points at the web server or application.
2. Check which address DNS returns and test each address with --resolve.
3. Capture the FIN with tcpdump to see which hop sends it.
4. Read the logs of every hop: load balancer or CDN, web server error log, application log, and WAF or IPS rules that close connections instead of returning an error page. Look for upstream errors, crashes and restarts at the failure time.
5. Check server blocks, certificates and default servers for the names you serve. Reload safely with sudo nginx -t && sudo systemctl reload nginx.
6. Align idle timeouts: the backend's keep-alive timeout must be longer than the timeout of the proxy or load balancer in front of it.

Catching closed connections early

Closed connections often affect one region or one of several servers, and a quick check from your own network may miss both. HostTracker has monitored websites since 2004 and checks them from 300+ checkpoints in 158 cities. It sends alerts by email, SMS, voice call, Slack, Telegram and more, so a pattern such as "closed from two regions only" shows up in the results instead of in visitor complaints.

Frequently asked questions

What is the difference between ERR_CONNECTION_CLOSED and ERR_CONNECTION_RESET?

Closed means the peer sent a FIN, the orderly end of a TCP connection. Reset means the peer sent an RST, which ends the connection at once and discards data that was in flight. The reset guide covers the second case.

Is ERR_CONNECTION_CLOSED my fault or the website's fault?

You cannot tell from the message. Load the site from another network or run a check from several locations. If it loads there, the problem is on your device or network. If it fails everywhere, the site or its edge closes the connections.

Why does it happen only on HTTPS sites?

The TLS handshake is a common place for Chrome to meet a closed connection, because that is the first step where a firewall, a default server or a TLS terminator can decide to end the exchange. Plain HTTP on a new connection is reported as ERR_EMPTY_RESPONSE instead.

Why does a reload fix it sometimes?

When a server closes an idle keep-alive connection just as Chrome reuses it, the next attempt uses a fresh connection. Chrome retries many of these requests on its own, so the error page appears only when the retry fails too.

Can a VPN or antivirus cause ERR_CONNECTION_CLOSED?

Yes. Both sit between the browser and the site. A VPN gateway or a company proxy can close connections that it is set up to refuse, and antivirus HTTPS scanning can end a connection when it fails to inspect it.

Does clearing the browser cache help?

Usually not, because the HTTP cache is not involved. The connection pools and the DNS cache are. Use the "Flush socket pools" and "Clear host cache" buttons in chrome://net-internals.

Why do I get ERR_CONNECTION_CLOSED on localhost?

The development server probably crashed or restarted while handling the request. Read the terminal where it runs for an exception or an exit message.

Sources and further reading

• Chromium net error list: the definitions of CONNECTION_CLOSED (-100) and the other codes in the table above.
• RFC 9112, HTTP/1.1: section 9.5 on failures and timeouts, and section 9.6 on closing a connection.
• RFC 9113, HTTP/2: section 6.8 on the GOAWAY frame, and section 9.1 on connection management.
• nginx rewrite module: the return directive and the special code 444.