ERR_CONNECTION_CLOSED: What It Means & How to Fix It

What Is ERR_CONNECTION_CLOSED?

ERR_CONNECTION_CLOSED is the Chrome and Edge error that reads "This site can't be reached. example.com unexpectedly closed the connection." In Chromium it is net error -100, defined as "A connection was closed (corresponding to a TCP FIN)." (net_error_list.h)

A FIN is the normal way to end a TCP connection, unlike a reset (RST), which aborts it: one side closed its end, on purpose or because the program holding it stopped. The problem is the timing. The other side hung up before the browser got the page, so there was nothing to show.

Something chose to end your connection early. It could be the website's server, a CDN in front of it, a filter on your network, or software on your own computer. The fixes below show you which.

Where the Close Happens: Usually the HTTPS Handshake

Chromium's networking code tells us where to look. When a connection ends during the TLS (HTTPS) handshake, the encryption layer turns that end-of-connection into ERR_CONNECTION_CLOSED. After the handshake it depends on the protocol: on HTTP/1.1, a fresh connection that gets its request through and is then closed without an answer shows ERR_EMPTY_RESPONSE; on HTTP/2 the same close shows ERR_CONNECTION_CLOSED.

Chrome also retries a request automatically when an old, reused connection closes underneath it, so you rarely see the error from that. As a result, an ERR_CONNECTION_CLOSED page on an HTTPS site means something hung up while the secure connection was being set up, or, on an HTTP/2 site, right after the request was sent. That points to whatever handles TLS or HTTP along the path: your antivirus's HTTPS scanner, a VPN or proxy, a filtering box on your network, the site's CDN, or the web server itself.

What Causes ERR_CONNECTION_CLOSED?

Fix 1: Try Another Network to Find the Culprit

Open the page on your phone using mobile data (Wi-Fi off), or on another computer on a different network.

• Works elsewhere: the close comes from your device or network. Continue with Fixes 2 to 6.
• Fails everywhere: the website's server or CDN is hanging up. Only the owner can fix that. If it's your site, skip to the website owners section below.
• Check the certificate from outside: DNS Robot's SSL Checker connects to the site and shows whether the HTTPS handshake succeeds and which certificate is served. (For sites on Cloudflare it shows the certificate from public CT logs, because Cloudflare refuses connections from our main checker.)

Fix 2: Turn Off VPN and Proxy

VPN servers and proxies handle every connection you make, and when they're overloaded or blocked they often end connections at the handshake. Disconnect the VPN completely, then check for a proxy:

• Windows 11: Settings → Network & internet → Proxy. Under Manual proxy setup, select Edit next to Use a proxy server, turn it off and select Save. If Use setup script is on and your workplace didn't set it, turn that off too.
• macOS: System Settings → Network → your connection → Details… → Proxies → turn them off.
• Browser extensions that act as a VPN or proxy count too. Test in an Incognito window, where extensions are off by default.

Fix 3: Pause Antivirus HTTPS Scanning

Security suites that inspect encrypted traffic sit in the middle of every HTTPS handshake. If the scanner can't negotiate with a site, for example because of a newer TLS feature or an unusual certificate, it often just closes the connection.

Look for a setting named HTTPS scanning, Web Shield, SSL/TLS protocol filtering or Scan encrypted connections, turn only that off, and reload. If the page loads, add the site as an exclusion and turn scanning back on. Updating the antivirus often fixes it permanently.

Fix 4: Change DNS to Rule Out Filtering

Some ISPs and network filters block sites by pointing the domain at their own server, which may then hang up on HTTPS connections. Compare what your computer gets (nslookup example.com) with DNS Robot's DNS Lookup: big sites on CDNs can return different addresses in different places, but an answer such as 0.0.0.0, a private address, or an address belonging to your ISP or filter means your resolver is redirecting you.

Switch to a public resolver such as Cloudflare (1.1.1.1), Google (8.8.8.8) or Quad9 (9.9.9.9), then flush your DNS cache and try again. If your network also blocks encrypted DNS, see this network is blocking encrypted DNS traffic.

Fix 5: Flush Socket Pools and Clear Site Data

• Chrome socket pools: open chrome://net-internals/#sockets and click Flush socket pools, so Chrome stops reusing connections that may be stale.
• Site data: click View site information at the left of the address bar → Cookies and site data → Manage on-device site data → delete, so cookies and cached data for that site start fresh.
• Update the browser: go to chrome://settings/help. Older builds can fail handshakes with servers that use newer TLS features.
• Skip "Clear SSL state": the button in Windows Internet Options clears the TLS cache that Windows' own apps use. Chrome and Edge keep their own, so it does nothing for this error.

Fix 6: Reset the Network Stack and Restart the Router

If several sites fail on one device only, reset its network configuration. Restart the router too, which clears its connection table. On Windows, run these in an administrator Command Prompt, then restart:

netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

Windows 11 also has Settings → Network & internet → Advanced network settings → Network reset, which reinstalls the network adapters. On a Mac, remove the Wi-Fi network from System Settings → Wi-Fi and join it again.

Fix ERR_CONNECTION_CLOSED on Android and iPhone

• Switch networks: Wi-Fi to mobile data or the other way round, to find out whether a network filter is involved.
• Turn off VPN, ad-blocking and "security" apps. Many of them route traffic through a local VPN and inspect it.
• Android Private DNS: Settings → Network & internet → Private DNS → Automatic. See the Private DNS guide for what each option does.
• Update Chrome or Safari through the app store, and update the operating system if it's several versions behind.
• Reset network settings: on iPhone, Settings → General → Transfer or Reset iPhone → Reset → Reset Network Settings. On Android, Settings → System → Reset options → Reset Bluetooth & Wi-Fi (and Reset Mobile Network Settings if mobile data also fails).

For Website Owners: Why Your Server Hangs Up

If visitors on many networks get ERR_CONNECTION_CLOSED, test the TLS handshake yourself from a machine outside your network. openssl s_client shows exactly where it stops:

# Full handshake with SNI (the hostname visitors use)
openssl s_client -connect example.com:443 -servername example.com </dev/null

# Good: a "Certificate chain" block and "New, TLSv1.3, Cipher is ..." (or TLSv1.2)
# Bad: "no peer certificate available", "Cipher is (NONE)" and "SSL handshake has read 0 bytes",
#      often after "unexpected eof while reading" (OpenSSL 3) or "read:errno=0" (macOS's built-in openssl)
#      = the server (or something in front of it) closed the handshake
# "Verify return code: 0 (ok)" and "Protocol: TLSv1.3" appear even when it fails, so don't rely on them

# Test a specific protocol version
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null

Then check these, in order:

• SNI and certificates: every hostname visitors use, both example.com and www.example.com, needs a server_name entry and a certificate that covers it. In nginx a name with no server block gets the default server's certificate (a name-mismatch warning, not this error), and ssl_reject_handshake on gives ERR_SSL_UNRECOGNIZED_NAME_ALERT. A bare close for one name can come from a proxy or load balancer in front, such as an Envoy-based gateway with no route for it.
• Protocols: serve TLSv1.2 and TLSv1.3. Very old configurations that offer only TLS 1.0/1.1, or unusual cipher lists, fail with current browsers. The SSL Checker shows the certificate and chain visitors receive.
• Connection limits: if nginx logs worker_connections are not enough, or a firewall connlimit or DDoS rule kicks in, new connections are dropped or closed under load. Raise the limits or find the traffic source.
• CDN and WAF: check the CDN's security events for the affected visitors. Bot protection and geo-blocking rules can close connections from whole regions.
• Logs: look in the web server's error log for SSL_do_handshake() failed lines around the time of the reports. nginx logs most client-side handshake failures at the info level, so with the default error level you may see nothing: set error_log /var/log/nginx/error.log info; briefly while you investigate.

ERR_CONNECTION_CLOSED vs Reset vs Empty Response vs SSL Errors

Our related guides: ERR_CONNECTION_RESET, ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH and ERR_CONNECTION_REFUSED.

If the request got through and the server then sent nothing, see ERR_EMPTY_RESPONSE.