ERR_CONNECTION_RESET means a TCP connection that had been established was abruptly torn down — a RST packet arrived. This is a genuinely different failure from a refusal or a timeout, and the difference tells you where to look. Something was there, the conversation had begun, and something killed it.
Reset vs refused vs timed out ¶
| Error | What happened at the network level | Points at |
|---|---|---|
| REFUSED | Host answered "nothing listening here" | Wrong port, service down |
| TIMED_OUT | No answer at all; packets vanished | Firewall dropping, host gone |
| RESET | Connection established, then killed | Middlebox, proxy, or the server mid-request |
A reset is the most informative of the three, because it proves a working path existed. The question is only who decided to end it.
The usual culprits ¶
- A firewall or DPI middlebox that inspected the connection and decided to kill it. Corporate networks, school networks, and some national filters do exactly this, often at the point the TLS handshake reveals the hostname — which is why the connection dies a moment after opening rather than immediately.
- Antivirus or "web shield" software intercepting HTTPS locally. It terminates TLS on your machine and can reset connections it dislikes.
- A protocol mismatch — a client offering a TLS version the server has disabled sometimes gets a reset rather than a clean alert.
- The server crashing mid-request, or a load balancer dropping a backend while your connection was on it.
- Genuinely bad networking hardware — a failing router or a saturated NAT table.
Narrowing it down ¶
- Try mobile data. If the site loads on cellular and resets on Wi-Fi, the reset is coming from your network — router, firewall, or ISP — and not from the site.
- Disable local security software temporarily, particularly anything advertising HTTPS scanning.
- Try a different browser. Isolates a browser-specific TLS configuration.
- Check whether the site answers for anyone else. A probe from outside your network settles it: if four independent probe methods reach the origin cleanly, the reset is local to your path, and the site is up.
If you run the server ¶
Resets that correlate with load usually mean connections are being dropped under pressure — check backlog limits and worker counts. Resets on specific paths often mean a WAF rule is killing requests rather than answering them with a 403; rejecting loudly is friendlier and far easier for users to report accurately.
When it happens only on large requests ¶
A reset that appears specifically on file uploads or long form submissions is usually a size limit enforced by disconnection rather than by an error page. Proxies and WAFs frequently cut a connection the moment a body exceeds a configured maximum, because refusing politely would require buffering the whole thing first. The tell is that small requests to the same endpoint succeed.
If you run the server, the fix is to align the limits along the whole path — a 10MB cap at the proxy and a 100MB cap at the application means the proxy wins and the application never gets to explain why.
Resets that follow a pattern ¶
Time the failures. A reset at a consistent interval into the connection points at an idle timeout somewhere in the path. A reset immediately after the TLS handshake points at hostname-based filtering. A reset only at peak hours points at capacity — connection tables, worker limits, or a NAT device out of ports.
FAQ ¶
Does a connection reset mean the site is down?
Not by itself. A reset proves a connection was established, which means something was alive at that address. Check from another network before concluding the site is at fault.
Why does it happen on one site only?
That pattern usually means filtering. A firewall or filter matched that specific hostname — often at the TLS handshake, where the requested name becomes visible — and killed the connection.
Can a VPN fix it?
If a local or ISP-level middlebox is the cause, yes, because the traffic becomes opaque to it. That is a useful diagnostic even if you do not want to browse through a VPN permanently.