Fix ERR_CONNECTION_RESET: This site can't be reached, connection was reset

The Error

This site can't be reached.
The connection was reset.
ERR_CONNECTION_RESET

This one is annoying because it's vague. The browser received a TCP RST packet mid-handshake, or the server dropped the connection before sending any HTTP data. The culprit could be client-side (browser, firewall, VPN, antivirus), network-side (router, ISP, proxy), or server-side (app crash, firewall rules, misconfigured TLS).

Root Causes

Browser or OS-level TCP stack issue (stale sockets, corrupted state)
Antivirus / security software intercepting HTTPS and sending RST
VPN or proxy dropping the connection
Server firewall blocking your IP or resetting on port 443/80
Server process crashed or restarted mid-connection
Misconfigured SSL/TLS causing handshake failure → RST
MTU mismatch on the network path
Corrupted browser profile or extension interfering with requests

Fix 1: Quick Browser-Side Reset

Start here — covers 40% of cases.

# Flush DNS cache
# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo systemd-resolve --flush-caches

Then clear the browser socket pool. In Chrome, go to:

chrome://net-internals/#sockets

Click Flush socket pools. Clear DNS from the same page:

chrome://net-internals/#dns

Try the site again. If it loads — stale sockets were the culprit.

Fix 2: Disable Antivirus / VPN Temporarily

SSL inspection in antivirus software is a surprisingly common cause. Kaspersky, Avast, and ESET all MITM your HTTPS connections at the OS level. When they can't process a TLS handshake cleanly, they send RST instead.

Disable the antivirus temporarily and retry
If it loads — go into antivirus settings and turn off HTTPS/SSL scanning, or add the site as an exception
Same for VPN: disconnect, retry. If it works, the VPN's traffic routing or firewall rules are the problem

Fix 3: Reset Windows Network Stack

On Windows, corrupted Winsock or TCP/IP settings cause this more often than you'd expect.

# Run as Administrator
netsh winsock reset
netsh int ip reset
netsh int tcp reset
ipconfig /release
ipconfig /flushdns
ipconfig /renew

Restart after running these. This resets the entire network stack to defaults.

Fix 4: Check MTU Size

MTU mismatch is a sneaky one — the connection starts fine but RSTs on larger packets. Test with a large ping payload:

# Windows
ping -f -l 1472 8.8.8.8

# macOS / Linux
ping -M do -s 1472 8.8.8.8

If this fails with "Packet needs to be fragmented," your MTU is set too high. Drop it to 1452 — the standard for PPPoE connections:

# Windows — replace "Wi-Fi" with your actual interface name
netsh interface ipv4 set subinterface "Wi-Fi" mtu=1452 store=persistent

# Linux
sudo ip link set dev eth0 mtu 1452

Find your interface name first:

# Windows
netsh interface show interface

# Linux
ip link show

Fix 5: Server-Side Diagnosis

Other users hitting the same error? Then look at the server. Run these to figure out what's actually sending RST:

# Check if your server is RST-ing connections
tcpdump -i eth0 'tcp[tcpflags] & tcp-rst != 0' -n

# Check if the process is running
systemctl status nginx   # or apache2, your app

# Check if firewall is resetting connections
iptables -L -n -v | grep REJECT
iptables -L -n -v | grep DROP

# Check server logs for connection errors
tail -f /var/log/nginx/error.log
journalctl -u nginx -f

Common server fixes:

Restart the web server if it's stuck or in a zombie state
Check tcp_reset_on_error and timeout settings — aggressive values cut off slow clients early
Behind a load balancer? Verify health check config. Backends marked "down" get their connections reset immediately

Fix 6: TLS/SSL Issues

A failed TLS handshake almost always ends in RST. Test it directly from the command line:

# Test TLS handshake manually
openssl s_client -connect yoursite.com:443 -tls1_2
openssl s_client -connect yoursite.com:443 -tls1_3

# Check certificate validity
curl -vI https://yoursite.com 2>&1 | grep -E '(SSL|TLS|certificate|expire)'

Expired cert, hostname mismatch, or unsupported TLS version will all surface here. Fix the cert or update the TLS config accordingly.

Fix 7: Try a Different DNS

Unlikely to cause RST directly, but occasionally ISP DNS returns bad IPs that respond with RST. Worth a quick swap:

# Windows — via PowerShell:
Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1","8.8.8.8")

# Linux — edit /etc/resolv.conf or use nmcli:
nmcli con mod "your-connection" ipv4.dns "1.1.1.1 8.8.8.8"
nmcli con up "your-connection"

Verification

Once you've applied a fix, run these to confirm the connection is actually clean:

# Basic connectivity test
curl -v https://yoursite.com

# Watch the TCP handshake timing
curl -v --trace-time https://yoursite.com 2>&1 | head -40

curl works but Chrome still errors? That's browser-specific. Try incognito first to rule out extensions. If incognito loads fine, disable extensions one by one. Still broken in incognito? Create a fresh Chrome profile — a corrupted profile can persist socket state across sessions.

Prevention & Tips

Keep antivirus SSL scanning disabled for development domains, or configure proper exceptions
On servers, set reasonable TCP keepalive and timeout values — overly aggressive settings cut off slow clients
Monitor your server's connection reset rate: netstat -s | grep reset
Debugging whether a client IP falls within an allowed CIDR block? ToolCraft's Subnet Calculator handles the math without needing any local tooling

Quick Checklist

Flush DNS + socket pools in browser
Disable VPN/antivirus, retest
Run Winsock reset (Windows)
Check MTU with large ping
Verify server process is running + check logs
Test TLS handshake with openssl
Try incognito / different browser