ERR_CONNECTION_CLOSED is Chrome's way of saying the other end terminated the connection before the browser got a response. The page reads "This site can't be reached" with "unexpectedly closed the connection." Firefox usually shows "The connection was interrupted" or "Secure Connection Failed," and Safari shows a generic failure.
At the network level, the connection opened (so the server's IP is reachable and something listens on the port), but then a FIN or abrupt close arrived early. This differs from a refused connection, where nobody accepts at all. It is also distinct from ERR_EMPTY_RESPONSE, where the request was sent and the connection closed without any response bytes. In practice the boundary is blurry, since Chrome chooses the name depending on when the close happened, so use the steps in both pages.
Find where in the exchange it closes
curl -v --max-time 20 https://example.com/ -o /dev/null
Read the verbose output:
- Closes before "Connected": network or firewall problem on the path.
- Closes during TLS lines (
* TLSv1.3 (OUT), TLS handshake, Client hello): TLS configuration, SNI or filtering problem. - Closes after
> GET / HTTP/2with "Empty reply from server" or "Connection reset": the application, web server or a WAF dropped the request.
If you are a visitor
- Reload once and try another page on the same site. A single page failing points to a server-side limit on that URL.
- Check antivirus and firewall. Security suites that scan web traffic can drop connections. Disable web protection briefly to test.
- Disable extensions or use incognito. Privacy and VPN extensions can close connections.
- Turn off VPN or proxy. Some VPN endpoints are blocked by the site and answer by closing the connection. See ERR_PROXY_CONNECTION_FAILED.
- Flush DNS and reset sockets. On Windows,
ipconfig /flushdnsandnetsh winsock reset. In Chrome, openchrome://net-internals/#socketsand flush socket pools. - Try another network. If mobile data works, the home router, ISP filter or a school or office firewall is interfering.
- Check the site's size limits. Uploading a large file and getting this error often means the server cut the connection mid-upload; see nginx 413 request entity too large.
If you own the site
Server rules that drop connections on purpose
Some configurations intentionally close without replying. nginx's non-standard return 444; closes the connection with no response. Rate limiting tools (fail2ban, CSF, ModSecurity, cloud firewalls) may drop clients that exceeded a threshold. Search your config:
grep -rn "return 444" /etc/nginx/
sudo fail2ban-client status
sudo iptables -L -n | grep DROP
If the visitor's IP appears in a ban list, unban it and tune the rule. Services like Cloudflare may instead present Error 1015 or Error 1020.
TLS problems
A server that breaks off during the handshake can produce this error. Check the certificate with the SSL Checker and offered protocol versions with the TLS Version Checker. Old clients that cannot negotiate a modern protocol may be dropped immediately rather than shown an alert.
Process crashes and worker limits
If the backend dies mid-request, the web server may close the connection. Look at logs around the failure time:
sudo journalctl -u php8.2-fpm --since "15 min ago"
sudo tail -n 50 /var/log/nginx/error.log
dmesg | grep -i -E "oom|segfault"
Out-of-memory kills and segfaults are common culprits. Increase memory, reduce worker concurrency, or fix the failing code. Also review connection limits: exhausted workers or worker_connections may cause new connections to be dropped.
Keep-alive and timeouts mismatches
A load balancer or proxy may close an idle connection that the origin still considers open, and then a reused connection fails. Keep the origin's keep-alive timeout longer than the balancer's idle timeout. In nginx, keepalive_timeout controls this at the edge, and keepalive_timeout inside upstream blocks (nginx 1.15.3 and later) controls it for backend connections. Similarly, see nginx upstream timed out for upstream timing issues.
Firewall or security group
If only some regions or networks fail, a network ACL, security group or provider-level filter may drop them. Compare results with Down From Where and check inbound rules for port 443. The Port Checker verifies that the port is open from outside.
HTTP/3 or QUIC quirks
If the site advertises HTTP/3 and some networks block UDP 443, Chrome normally falls back to TCP, but broken middleboxes can still cause trouble. Temporarily removing the Alt-Svc header helps determine if QUIC is involved.
Confirm the fix
- Run the Website Health Check for DNS, TLS and HTTP in one report.
- Fetch the page with the HTTP Status Checker from our servers and confirm a normal status code returns.
- Use Down From Where to compare reachability from several locations.
- Put an uptime monitor on the URL to catch a recurrence.
Next steps
- Read ERR_CONNECTION_REFUSED vs timed out vs reset.
- See the sibling error ERR_EMPTY_RESPONSE.
- Work through why is my website down.
- Investigate backend timing in 504 Gateway Timeout fixes.
FAQ
Is ERR_CONNECTION_CLOSED the same as ERR_CONNECTION_RESET?
They are close. Reset means a TCP RST arrived; closed means the connection ended (typically a FIN) before a response. Both mean something terminated the connection, and the diagnostic steps overlap.
Why does it only happen on large uploads?
A proxy or web server limit (body size, timeout or buffering) is probably cutting the connection. Increase the relevant limits and test with a smaller file.
Can a firewall on my own PC cause it?
Yes. Local firewalls and web-shield features can close connections they classify as suspicious. Test with the feature disabled.
Does the site owner see anything in logs?
Often not, if the connection died before the application. Check the web server, load balancer and firewall logs for the same timestamp.
Get notified when this fix updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.