ERR_CONNECTION_RESET

What’s actually happening

The connection drops partway, often on a specific URL, a large upload, or a request with an unusual payload, while the rest of the site is reachable. It can be intermittent and is easy to blame on the user's network, but a server- or proxy-side reset will reproduce from multiple networks. The TCP socket got an RST rather than a clean FIN, so the browser never received a real HTTP response.

Common causes

• A backend worker crashing (segfault, OOM kill) and the kernel resetting the half-open socket.
• A WAF or firewall (ModSecurity, Cloudflare, a cloud security group) dropping or resetting connections it judges malicious — a payload that trips a rule, or a rate limit.
• An MTU / MSS mismatch over a tunnel or VPN, where large packets get black-holed and the connection stalls then resets (path MTU discovery blocked by an over-zealous firewall).
• A keep-alive mismatch behind a proxy, where the upstream closes an idle connection the proxy still thinks is open, producing a reset on the next request.
• TLS negotiation failure — client and server share no protocol/cipher, so the handshake is aborted with a reset (sometimes surfaces as this rather than an SSL error).

How to fix it

1. Reproduce from a second network and with curl -vHit the URL from a different connection (phone on cellular, a remote server) and run 'curl -v https://site/path'. 'Connection reset by peer' confirms it's server/proxy-side, not the user's wifi. If only one specific request resets, the payload or URL is tripping something.
2. Check WAF / firewall logs for that requestLook at the ModSecurity audit log (/var/log/modsec_audit.log), Cloudflare's Firewall Events, or your cloud provider's security-group/flow logs. If a rule is matching, you'll see the request flagged at the failure time. Tune or whitelist the rule rather than disabling the WAF wholesale.
3. Look for crashes in the backend logsSame drill as a truncated response: PHP-FPM log, 'dmesg' for OOM kills, web server error_log. A worker dying mid-request resets the socket. If a specific large request triggers it, you're probably hitting a memory limit on that code path.
4. Test for an MTU problemIf resets happen over a VPN/tunnel or only on large requests, try lowering the interface MTU (e.g. 1400) or clamp MSS on the gateway. If that fixes it, path MTU discovery is being blocked and you need to clamp MSS or unblock ICMP fragmentation-needed packets.