ERR_CONNECTION_RESET: The Connection Was Reset. How to Fix

net::ERR_CONNECTION_RESET is Chromium error -101: «A connection was reset (corresponding to a TCP RST)» (net_error_list.h). The TCP connection was established, then something sent a reset packet that tore it down: during the TLS handshake, while the request was being sent, or while the response was arriving. Chromium also maps the operating system's ECONNRESET and broken-pipe errors to this code.

The RST does not have to come from the server. Any device in the path that can see the connection can inject one: a firewall, a corporate proxy, an antivirus that scans HTTPS, or an ISP filter that reads the host name in the TLS ClientHello. It is not a refused connection (an RST in answer to the very first SYN gives ERR_CONNECTION_REFUSED), not a timeout, and not a certificate error.

If the error appears on one network but not another (home Wi-Fi fails, mobile data works), the reset is coming from that network: its firewall, proxy, or filtering by the ISP. If it appears on one computer only, look at that machine's antivirus, VPN client or proxy settings. If it appears everywhere, the server or its hosting firewall is sending the reset.

Server-side resets have a short list of causes: a firewall rule such as -j REJECT --reject-with tcp-reset (fail2ban and similar tools can add these), a process that closes a socket while unread data is still in its receive buffer (the kernel then sends RST), nginx's reset_timedout_connection on, an upload rejected with 413 while the browser is still sending the body, and a full listen queue when net.ipv4.tcp_abort_on_overflow is set to 1 (with the default of 0 the kernel drops instead, and clients time out).

A reverse proxy does not pass an upstream reset through to the browser; it turns it into an error status. nginx logs recv() failed (104: Connection reset by peer) while reading response header from upstream and returns 502; Cloudflare returns 520 when the origin drops the connection. So if visitors of a proxied site see ERR_CONNECTION_RESET, the reset happens between them and the proxy (their network, an ISP filter, security software) or at the proxy itself, not at your origin.

On your own edge, check which rules answer with a reset rather than silently dropping:

iptables -S | grep -i 'tcp-reset'
nft list ruleset | grep -i 'reset'
grep -rn 'reset_timedout_connection' /etc/nginx/

1. Reproduce from outside and from the server itself. If curl -v https://example.com/ works on the server (through its public IP) but fails from a client network, the reset is in the path.
2. Test host-name filtering. Send the same handshake with a different SNI:

   openssl s_client -connect 203.0.113.10:443 -servername example.com </dev/null
   openssl s_client -connect 203.0.113.10:443 -servername example.org </dev/null

   If only the real name is reset, a filter in that network reacts to the host name.
3. See who sends the RST. Capture on the server while a failing client retries:

   tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-rst != 0'

   If the client receives a reset that never left your server, something in between injected it.
4. Check firewall and fail2ban rules for tcp-reset and for a ban on the client's IP.
5. Check the listener and kernel: ss -ltn 'sport = :443', nstat -az TcpExtListenOverflows, dmesg -T | grep -i 'killed process' for crashed workers.
6. Check DNS: compare dig +short example.com with dig +short example.com @1.1.1.1. A stale record or a resolver that substitutes its own address sends visitors to a machine that resets them; see resolver checks and fixes.

Step-by-step walkthrough for visitors and owners: ERR_CONNECTION_RESET fix guide.

1. Try mobile data or another Wi-Fi. If the site opens there, the reset comes from your original network.
2. Turn off a VPN or proxy, or turn one on if your network filters the site, and retry.
3. Pause antivirus HTTPS or web scanning briefly; these products sit in the middle of TLS connections and can reset them.
4. Turn on secure DNS: Chrome Settings > Privacy and security > Security > Use secure DNS. It helps when your provider's resolver sends you to the wrong address.
5. On Windows, if every site resets, run netsh winsock reset from an administrator prompt and reboot.

Clearing the browser cache does not affect resets: no response was received. If the site fails on every network and device, it is the server's problem, not yours.

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
# 200
openssl s_client -connect example.com:443 -servername example.com -brief </dev/null

Run both from the network that failed, not only from the server. To test whether the host and port answer from outside your network, use the ping and port checker.

• ERR_EMPTY_RESPONSE — closed cleanly, with no data
• ERR_ADDRESS_UNREACHABLE — no route to the server's IP
• ERR_SSL_PROTOCOL_ERROR — the TLS handshake failed rather than being reset
• ERR_CONNECTION_CLOSED — closed with a TCP FIN instead of RST
• ERR_HTTP_RESPONSE_CODE_FAILURE — the server answered, but with an error status