Troubleshooting guide · website-errors · Published 2026-08-16 · 3 min read
ERR_CONNECTION_RESET in Chrome explained
ERR_CONNECTION_RESET explained: what TCP reset means, server and client causes, and the debugging order that fixes it.
- ·What a reset means
- ·Check the client side
- ·Check the server side
What a connection reset means
ERR_CONNECTION_RESET is Chrome's message when the server or an intermediate device aborts the TCP connection while it is still in use. A normal close sends a FIN packet; a reset sends an RST packet, which tells both sides that the connection was dropped without a clean finish. The browser interprets that as "the connection was reset" and shows the error instead of a page.
The reset can come from many places: the origin server, a load balancer, a firewall, a security module, or something on the visitor's own network. Because the message is generic, the debugging order is to decide which side reset the connection before changing anything.
Check the client side first
- Different network. Try the same URL from a phone on mobile data and from a wired connection. If only one network fails, the reset is on that network or its gateway, not the site.
- Different browser. If the site opens in a clean browser profile but resets in the default one, an extension or a VPN it routes through is the cause.
- VPN or proxy. Corporate and consumer VPNs insert an intercepting device; a mismatch in how it forwards TLS or HTTP/2 can produce a reset. Disable it and retest.
- Antivirus HTTPS scanning. A security suite that decrypts traffic can reset TLS checks it does not like. Whitelist the site temporarily to rule it out.
Check the server side
- Read the origin access log. A reset that reaches the server shows a request opened and closed with a 4-byte
Rin the connection state, often followed by the client stopping mid-response. - Watch for a WAF or rate limit. Security modules frequently reset over-aggressive bots. If the reset is specific to certain probes, test while a WAF rule is relaxed.
- Modern stack resets. On HTTP/2, a server that cannot honour a request can reset a stream with the
RST_STREAMframe, which surfaces to the browser as a connection problem. Check match a recent server or CDN config change with the first resets. - Load balancer and TLS. A TLS handshake reset points at termination layers. Test a direct origin IP and a TLS-checker, then compare.
| Cause | Typical reset point | Fix |
|---|---|---|
| Extension or VPN | Browser or client gateway | Clean profile, disable VPN |
| Antivirus HTTPS scan | Local intercepting proxy | Whitelist, disable scan |
| WAF / bot rule | Edge security module | Review rule, allow the client |
| HTTP/2 stream reset | Origin or CDN | Check server config change |
| Server resource cut | Origin | Review logs and limits |
A worked example
A visitor reports the reset on one URL only. Start on mobile data: it loads, so the site is fine. In the original browser profile, disable the ad-blocker for the domain and the reset clears, confirming a client-side HTTP(S) filter. That kind of isolation is the fastest path and is why every reset investigation should rule out the client before touching the server.
When the reset keeps happening
If the reset reproduces for many users, focus on the server and its edge. Re-trace the request with the CDN bypassed, confirm the origin can hold the connection, then inspect the access and error logs together. The timed out and domain resolution guides cover the neighbouring causes you can rule out in the same pass.