ERR_CONNECTION_RESET: causes and fixes

What ERR_CONNECTION_RESET means

Unlike ERR_CONNECTION_REFUSED, which fires before any data moves, a reset happens after the TCP handshake succeeded and the connection was already exchanging data. Something along the path, or one of the endpoints itself, then sends an RST packet that ends the connection without the usual close sequence. The browser has no way to tell whether the RST came from the server, a middlebox such as a firewall or load balancer, or the client's own network stack, so the message stays generic regardless of the cause.

A normal TCP close involves a FIN exchange in both directions, which lets each side finish sending what it already queued. An RST skips that entirely: whatever was in flight is discarded, and any data the server had already started writing but the client had not yet received is lost. That is why a reset partway through a large file download or a long API response often leaves a visibly truncated result rather than a clean failure before anything loaded.

How the error appears

Chrome shows "This site can't be reached ... ERR_CONNECTION_RESET" partway through loading, sometimes after part of the page has already rendered. curl reports it directly:

curl -v https://example.com/api/report
* TLSv1.2 (IN), TLS alert, close notify
* OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) Recv failure: Connection reset by peer

On the server side, nginx logs a matching line for the same event: readv() failed (104: Connection reset by peer) while reading upstream. A reset that happens consistently at the same byte count or the same number of seconds into a request points to a size or timeout limit somewhere on the path, rather than a random network glitch.

What causes ERR_CONNECTION_RESET

• A firewall, IDS, or WAF drops the connection mid-stream. A rule that matches partway through a request or response, rather than at connection time, produces a reset instead of an immediate refusal.
• MTU or packet fragmentation problems. A path with a smaller MTU than either endpoint expects can corrupt large packets, and some misconfigured routers respond by resetting the connection instead of fragmenting correctly.
• TLS inspection by antivirus software or a corporate proxy. Interception that fails partway through a handshake or a response often resets the connection rather than failing gracefully.
• A server worker process crashes mid-request. An application error, an out-of-memory kill, or a worker restart during a deploy all leave an open connection with nothing left to answer it.
• A keep-alive timeout mismatch between client and server or proxy. If a load balancer's idle timeout is shorter than the backend's, it can reset a connection the backend still considers active.
• ISP interference or traffic shaping. Some ISPs reset long-lived or high-bandwidth connections, particularly for streaming or large downloads, as a form of traffic management.

How to tell whose fault it is

Test the same request from a second network, such as mobile data instead of office Wi-Fi. If it works there, a local firewall, antivirus, or proxy is intercepting the connection. If the reset happens identically everywhere, the cause sits on the server side or in a WAF rule in front of it. An HTTP check run from multiple locations at once shows whether the reset is universal or limited to one network, without you needing a second device to test from.

How to fix ERR_CONNECTION_RESET

If you are a visitor

1. Restart your router or modem. A stuck NAT table entry or a stale connection state on consumer routers is a common, easy-to-clear cause.
2. Disable any VPN or proxy and reload. If the reset stops, the VPN or proxy is intercepting or mishandling the connection.
3. Turn off HTTPS scanning in your antivirus, usually listed under "web protection" or "SSL/TLS scanning," and retry. If that fixes it, add the site to an exclusion list rather than leaving scanning off.
4. Check for an unusually low MTU setting if you are on a VPN or a mobile hotspot; lowering it slightly on the client can resolve resets tied to fragmentation.

If you run the site

1. Check application and system logs for a crash or an out-of-memory kill around the time of the reset. A worker process dying mid-request is one of the most common causes.
2. Review WAF and IDS rules and their logs. A rule that resets connections matching certain payloads or rates can look identical to a random network failure until you check the security log specifically.
3. Align keep-alive timeouts across the stack. On nginx, set the proxy-facing timeout to match or exceed the backend's own:

   keepalive_timeout 65s;
   proxy_read_timeout 65s;

   A mismatch here is a frequent cause of resets under load, when the frontend closes a connection the backend still expects to use.
4. Watch for upstream reset messages in the reverse proxy log, such as upstream prematurely closed connection while reading response header from upstream, which points directly at the backend application rather than the network.
5. Reload after any change rather than editing in place: nginx -t && systemctl reload nginx validates the configuration before it takes effect.

How to prevent ERR_CONNECTION_RESET

A reset that only appears under load, or only for large responses, rarely shows up during a quick manual check, since it depends on timing or size thresholds that a single request may not hit. Ongoing HTTP monitoring that checks status code and body content on a schedule from 300+ checkpoints in 158 cities catches an intermittent reset pattern that a one-off test would miss, and alerts by email, SMS, voice call, Slack, Telegram and more as soon as it starts.

Related errors

• ERR_CONNECTION_REFUSED happens when the connection never gets established in the first place.
• ERR_CONNECTION_TIMED_OUT happens when nothing answers the connection attempt at all.
• This site can't be reached covers the full set of connection errors Chrome groups under one heading.

Frequently asked questions

Does ERR_CONNECTION_RESET mean I was hacked?

No. It almost always points to a network device, a firewall rule, antivirus interception, or a server-side crash, not to an attack on your device.

Why does this only happen with large file downloads?

Large transfers are more likely to hit an MTU mismatch, a proxy timeout, or a size limit configured on a firewall or load balancer, all of which can end a connection mid-stream that a small request would finish before triggering.

Can my own antivirus cause this?

Yes. HTTPS scanning features that intercept and re-encrypt TLS traffic sometimes fail on specific sites or large responses and reset the connection instead of passing it through.

Is a reset worse than a timeout?

Not inherently. A reset means something actively ended the connection, which is often easier to diagnose than a timeout, where nothing happens and you cannot tell whether the packet ever arrived.

Why does the reset happen at the same point every time?

A consistent byte count or elapsed time before the reset usually points to a fixed limit, such as a proxy timeout, a maximum response size, or a keep-alive setting, rather than a random fault.

Can a mobile carrier reset my connections?

Some carriers do reset long-lived connections as part of network management, particularly on congested cells or for high-bandwidth transfers like video streaming. If the same request works reliably over Wi-Fi but resets on mobile data, carrier-level interference is a reasonable explanation.