ERR_CONNECTION_RESET: What It Means and How to Fix It

ERR_CONNECTION_RESET appears as "This site can't be reached. The connection was reset." The TCP connection was established, and then something sent a reset (RST) packet or abruptly closed it before the page finished loading. The sender can be the server, a firewall, a proxy, an antivirus product on your computer, or a device in between.

Because the connection began successfully, DNS and routing are probably fine. The question is who killed the connection and why. Compare ERR_CONNECTION_REFUSED (rejected up front) and ERR_CONNECTION_CLOSED (closed during the handshake).

If you are a visitor

1. Reload once or twice. A single reset can come from a busy server or a flaky Wi-Fi link.
2. Check the address. A site that only serves HTTPS can reset a plain http:// request on port 80, or the reverse.
3. Disable VPN and proxy. Many resets come from VPN and proxy middleboxes. See ERR_PROXY_CONNECTION_FAILED.
4. Pause antivirus HTTPS scanning. Products that inspect encrypted traffic can reset connections they cannot parse. Turn off web or HTTPS scanning briefly to test, then re-enable it.
5. Try another network. If mobile data works, your router, ISP or workplace firewall is resetting traffic. Content filters often send resets for blocked categories.
6. Disable browser extensions by testing in an incognito window, where most are off.
7. Flush DNS and reset network settings. On Windows, ipconfig /flushdns and netsh winsock reset, then restart.
8. Lower the MTU only as a last step. If large pages fail but small ones work, an MTU mismatch (common with VPNs) may be dropping fragments.

If you own the site

Find the layer that sends the reset. Capture it rather than guessing.

1. Reproduce with curl

curl -v https://example.com/ 2>&1 | head -n 25

Messages like Connection reset by peer or Recv failure: Connection reset by peer confirm it. Note whether it happens during the TLS handshake (before any HTTP/ line) or after the request is sent.

2. Resets during the TLS handshake

Suspect a TLS mismatch or a firewall that inspects the ClientHello. Check what versions and ciphers you offer with the TLS Version Checker and the certificate chain with the SSL Checker. Servers or WAFs that only accept legacy protocols reset modern clients; see ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

3. Resets after the request is sent

The backend probably crashed or closed the socket. Read the error logs around the failure time:

sudo tail -n 100 /var/log/nginx/error.log
sudo journalctl -u php8.2-fpm --since "10 minutes ago"
dmesg | grep -i -E "killed process|out of memory"

Typical findings: a PHP-FPM or Node worker killed by the out-of-memory killer, a segfault, or a worker restart (max_requests) in the middle of a response. Fix the crash rather than the symptom. Related developer-side errors: Node ECONNRESET and nginx 499.

4. WAF, rate limiting and intrusion tools

Security tools sometimes reset connections they consider abusive: ModSecurity, fail2ban-style bans, DDoS protection, or a hosting provider's firewall. If resets hit certain IPs, URLs or user agents only, look at those rules. Check whether the IP is listed with the Blacklist Checker.

5. Keepalive and idle timeout mismatches

If a load balancer closes idle connections sooner than your backend, requests reusing a dead connection get reset. Set the backend keepalive timeout longer than the load balancer's idle timeout. In nginx, compare keepalive_timeout and the upstream's settings.

6. Large uploads and request limits

A body that exceeds a limit may be reset instead of answered with a clean error, especially on older stacks. Look at nginx 413 and PHP's post_max_size.

7. HTTP/2 and HTTP/3 problems

If only some browsers fail, test the protocol with the HTTP/2 and HTTP/3 Checker, then see ERR_HTTP2_PROTOCOL_ERROR and ERR_QUIC_PROTOCOL_ERROR.

8. Capture the packets

When logs stay silent, capture on the server and look for who sends the RST:

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

If the RST source IP is not your server, a middlebox is responsible.

Verify

1. Repeat the curl -v test several times and from another region with Down From Where.
2. Confirm the port with the Port Checker.
3. Keep an Uptime Monitor running to catch intermittent resets.

Next steps

• Read connection errors explained.
• Review Why is my website down?.
• See ERR_EMPTY_RESPONSE for a closely related symptom.
• Check Fix 502 Bad Gateway if a proxy sits in front.

FAQ

Is ERR_CONNECTION_RESET my fault or the site's?

It can be either. Test another network and device: if they fail too, look at the site; if they work, look at your own antivirus, VPN or router.

Why does it happen only occasionally?

Intermittent resets often come from overloaded workers, idle timeout mismatches or flaky links. Log timestamps and match them to server logs.

Can a VPN cause it?

Yes. VPNs and proxies can reset or mangle connections, especially with MTU problems or when the exit node is blocked by the site.

Does clearing the cache fix it?

Rarely. The failure is at the connection level, not in cached content.

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.