ERR_CONNECTION_RESET Fix Guide

Problem

A page fails with ERR_CONNECTION_RESET (Chromium net error -101, “Error 101”). The TCP connection opened — the handshake completed — and then a RST segment arrived and tore it down. This is what errno calls ECONNRESET, “connection reset by peer.” Unlike a graceful close, which exchanges FIN packets and lets in-flight data drain, a RST is an abortive close: RFC 9293 defines it as an instruction to immediately drop the connection and discard any state. The data you were waiting for is gone.

The distinction from its siblings is the whole diagnosis. A refusal (ERR_CONNECTION_REFUSED) is a RST in answer to your SYN: the connection never opened. A timeout (ERR_CONNECTION_TIMED_OUT) is a SYN that got no answer. A reset means you got in and were then thrown out.

Symptoms

• The page starts to load, or loads partially, and then dies — it is not an instant “can’t be reached.”
• curl reports Recv failure: Connection reset by peer or Empty reply from server.
• It often works on one network (mobile data) and resets on another (corporate or ISP Wi-Fi).
• The error is not ERR_CONNECTION_REFUSED (instant, never opened) or ERR_CONNECTION_TIMED_OUT (long hang).

Top 3 Causes

1. The server aborted the connection - The origin app crashed or was OOM-killed mid-request, a worker hit a hard timeout, or the code closed the socket abortively. A socket closed with SO_LINGER set to 0 sends a RST instead of a FIN, discarding the send and receive buffers. The handshake succeeded, so the connection got further than a refusal — it opened, then the origin pulled the plug.
2. A middlebox in the path injected the RST - A firewall, IPS, or DPI appliance lets the SYN through, then forges a RST once it inspects the request — the TLS SNI, the HTTP Host header, or the payload. Because the reset is off-path, it can originate from a device that is neither client nor server. The tell is that the same URL works from a different network and resets behind one organization’s egress.
3. A protocol or port mismatch - Speaking plaintext HTTP to a TLS port, or offering a TLS version or cipher the server has disabled, makes some servers reset the connection instead of returning a clean TLS alert. A hard reset during the handshake lands here; a clean alert would surface as ERR_SSL_PROTOCOL_ERROR instead.

Diagnose with DechoNet

• HTTP Check from an external vantage point. If the request resets from outside your network too, the problem is the server or its edge. If it only resets from your network, a middlebox between you and the server is injecting the RST.
• Port Check to see whether the TCP handshake even completes. If the port shows open (it answered the SYN with SYN/ACK) but the request still resets, the TCP layer is healthy and the reset comes during the request or TLS phase — the application or a content-inspecting middlebox, not basic reachability.
• DNS Lookup to confirm you are hitting the intended origin, not a stale IP or the wrong edge node that resets unfamiliar traffic.

If the connection never opens (instant refusal), use the ERR_CONNECTION_REFUSED fix. If it hangs and never answers, use the ERR_CONNECTION_TIMED_OUT fix. If a clean TLS alert is the actual failure, see the ERR_SSL_PROTOCOL_ERROR fix.

Resolution Checklist

• Reproduce from a second network (a phone hotspot, a different ISP). If it works there, a middlebox on the first network is injecting the reset and the server is fine.
• Check origin and application logs for crashes, OOM kills, or worker timeouts at the moment of the reset.
• Look for abortive closes in the stack: SO_LINGER 0, a reverse proxy resetting a dead upstream, or a load balancer or stateful NAT sending a RST on an idle keepalive connection.
• Disable local interference one at a time — VPN, antivirus “HTTPS scanning,” a corporate proxy — and retest.
• Verify protocol and port: HTTPS to 443, plaintext only to plaintext ports, and confirm the server still supports the TLS version your client offers.
• Re-run HTTP Check after each change to confirm the request now completes instead of resetting.

When to Escalate

• Escalate to the service owner if the reset reproduces from multiple external networks while Port Check shows the port open. The connection opens and then dies, which points at the application or its edge — not the path to it.
• Escalate to network or security owners if the reset only appears behind one organization’s firewall or DPI. That is an injected RST you cannot fix from the server side; it has to be allowed at the inspection layer.