ERR_CONNECTION_RESET: what it means and how to fix it

ERR_CONNECTION_RESET means the connection between your browser and the server was forcibly closed during the communication. The browser successfully reached the server (unlike a timeout where nothing comes back), but something terminated the connection before the response was delivered. The server, a firewall, a proxy, or something in the network path sent a TCP RST (reset) packet, which abruptly kills the connection.

Chrome displays “This site can’t be reached” with the error code ERR_CONNECTION_RESET. Firefox shows “The connection was reset.” Safari displays “Safari can’t open the page.”

This error is frustrating to diagnose because it can originate from any layer between your browser and the server. The connection was established, which rules out DNS and basic connectivity issues. Something actively killed it, which is different from a timeout (no response) or a refusal (nothing listening).

How ERR_CONNECTION_RESET differs from other connection errors#

Understanding the differences narrows the diagnosis immediately.

ERR_CONNECTION_REFUSED means the server actively rejected the connection. Nothing is listening on the port, or a firewall sent back a rejection. The connection was never established. See SSH connection refused for the same mechanism on port 22.

ERR_CONNECTION_TIMED_OUT means the browser sent a connection request and got no response at all. The packets disappeared. Either the server is down, a firewall is silently dropping packets, or there is a routing issue.

ERR_CONNECTION_RESET means the connection was established (or at least started) and then something forcibly terminated it. A TCP RST packet was sent, which is an abrupt “this conversation is over” signal. This is different from a graceful close (TCP FIN), which is how normal connections end.

For the broader picture of all these errors and how they appear in the browser, see “This site can’t be reached”.

Server-side causes#

These affect all visitors, not just you.

Firewall or WAF terminating connections

The most common server-side cause. A firewall rule, an intrusion detection system, or a web application firewall like ModSecurity identifies the request as suspicious and kills the connection.

This happens when:

• Your IP address has been flagged by rate limiting or brute force detection
• The request matches a WAF rule (unusual headers, large POST body, suspicious query parameters)
• Fail2ban has banned your IP after repeated failed login attempts
• The server’s firewall has a rule that drops connections from certain IP ranges or countries

How to diagnose:

# Check if the server is reachable at all
ping example.com

# Test if the port is open (connection refused vs reset vs timeout)
nc -zv example.com 443

# Try from a different IP (mobile data, VPN)
curl -Iv https://example.com 2>&1 | head -10

If the site works from a different IP or network but not from yours, your IP is likely blocked. Check with the hosting provider or server administrator to see if your IP appears in the firewall’s ban list.

On Hostney, the bot detection system can challenge or block IPs that exhibit automated behavior. If a legitimate user is caught by the system, their IP can be whitelisted through the control panel’s firewall settings.

Nginx closing the connection

Nginx can reset connections for several reasons:

client_body_timeout exceeded. If the client takes too long to send the request body (a large file upload, a slow connection), Nginx closes the connection.

# Default is 60s, increase for large uploads
client_body_timeout 120s;

send_timeout exceeded. If the client takes too long to receive the response (slow download, unstable connection), Nginx resets.

# Default is 60s
send_timeout 120s;

reset_timedout_connection is enabled. When this directive is on, Nginx sends a RST instead of a FIN for timed-out connections. This frees server resources faster but produces ERR_CONNECTION_RESET on the client side instead of a timeout error.

# This causes RST instead of graceful close on timeout
reset_timedout_connection on;

Worker connections exhausted. If Nginx has no available connections (all slots in worker_connections are in use), new connections may be reset. This is rare on properly configured servers but can happen during traffic spikes or DDoS attacks.

Check the Nginx error log for connection-related entries:

grep -E "reset|timed out|connection" /var/log/nginx/error.log | tail -20

PHP-FPM crashing mid-request

If PHP-FPM accepts a request and then crashes during processing (segfault, out of memory, max execution time), the connection between Nginx and PHP-FPM drops. Nginx may pass this back to the browser as a connection reset, a 502 Bad Gateway, or a blank page, depending on when the crash occurs.

Check the PHP-FPM error log:

grep -E "segfault|signal|SIGKILL|exited" /var/log/php-fpm/error.log | tail -20

And the system log for OOM (Out Of Memory) kills:

dmesg | grep -i "killed process" | tail -10

SSL/TLS handshake failure

If the browser starts a TLS handshake and the server cannot complete it (misconfigured certificate, unsupported TLS version, cipher mismatch), some servers send a RST instead of a proper TLS alert. This produces ERR_CONNECTION_RESET instead of the more specific ERR_SSL_PROTOCOL_ERROR or ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Test the SSL configuration:

openssl s_client -connect example.com:443 < /dev/null 2>&1 | head -20

If this fails with “Connection reset by peer” or produces no output, the SSL configuration on the server is the problem. Check that the certificate files exist, the Nginx ssl_certificate paths are correct, and the TLS protocol versions are supported.

Server overloaded

An overloaded server that cannot process new connections may reset them. When CPU, memory, or the TCP backlog is exhausted, the kernel may send RST packets for new connections it cannot handle. This is similar to what produces 521 errors when Cloudflare is in front.

Check server resources:

uptime          # Load average
free -m         # Memory
df -h           # Disk space
ss -s           # Connection statistics

If load average is significantly above the number of CPU cores, or if memory is exhausted, the server needs either more resources or fewer concurrent connections (through caching, bot blocking, or connection limiting).

Client-side causes#

These affect only you, not other visitors.

Antivirus or security software intercepting HTTPS

Antivirus programs that perform HTTPS inspection (Avast, AVG, Kaspersky, ESET, Bitdefender) insert themselves into the TLS connection between your browser and the server. If the interception fails, the antivirus terminates the connection, producing ERR_CONNECTION_RESET.

How to test: Temporarily disable the antivirus’s web protection or HTTPS scanning feature. If the error goes away, the antivirus is the cause.

Fix: Add the affected site to the antivirus’s exception list, or disable HTTPS scanning entirely if you trust your network. Some antivirus products have known compatibility issues with specific websites and browsers.

Firewall or security software on your machine

Beyond antivirus, local firewall software can cause resets. Windows Firewall, macOS Application Firewall, or third-party firewalls (Norton, McAfee, ZoneAlarm) may block connections to specific sites or ports based on rules you did not configure intentionally.

How to test: Temporarily disable the firewall and try the site. On Windows: Settings > Privacy & Security > Windows Security > Firewall & network protection > turn off for your active network. On macOS: System Preferences > Security & Privacy > Firewall > Turn Off Firewall.

Re-enable the firewall after testing. If disabling it fixes the error, check the firewall rules for entries that block the affected site or port 443.

VPN or proxy interference

VPNs route your traffic through their servers. If the VPN’s infrastructure has a problem, connection resets can occur. Some VPN protocols are also detected and blocked by certain networks, causing resets.

Corporate proxies that inspect HTTPS traffic (Zscaler, Blue Coat, Forcepoint) can reset connections when they encounter content they cannot inspect or that violates a policy. If the proxy cannot handle the server’s TLS configuration or the response contains content types the proxy does not understand, it terminates the connection.

How to test: Disconnect the VPN and try the site directly. If it works without the VPN, the VPN is the issue. For corporate proxies, try the site from a non-corporate network (mobile data) to confirm the proxy is the cause.

Corrupted network stack or browser state

On Windows, corrupted Winsock or TCP/IP configuration can cause connection resets to specific sites or all sites.

Fix:

# Reset Winsock
netsh winsock reset

# Reset TCP/IP stack
netsh int ip reset

# Flush DNS
ipconfig /flushdns

Restart the computer after running these commands. This resets the network configuration to defaults and clears any corruption. For flushing DNS specifically, see the dedicated guide covering all platforms.

On macOS, reset the network stack by going to System Preferences > Network, selecting your active connection, clicking Advanced, and removing and re-adding the network service. Or from the terminal:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

On Linux:

sudo systemd-resolve --flush-caches
sudo systemctl restart NetworkManager

Browser-specific issues

Stale cache, corrupted cookies, or a malfunctioning browser extension can trigger connection resets for specific sites.

How to test:

1. Try the site in an incognito/private window (disables extensions and uses clean cookies)
2. Try a different browser entirely
3. Clear the browser’s cache and cookies for the affected site

If it works in incognito but not in your normal browser, a cookie or extension is the cause. Disable extensions one at a time to identify the culprit.

ISP or network-level interference

Some ISPs and corporate networks actively reset connections to specific sites, services, or types of traffic. This is more common in countries with internet censorship, but it also occurs on corporate networks that block certain categories of websites.

How to test: Try from a completely different network (mobile data instead of Wi-Fi, or a friend’s network). If the site works on a different network, the issue is with your ISP or network.

Fix: A VPN bypasses ISP-level interference by encrypting your traffic so the ISP cannot inspect or reset it. If the issue is corporate network filtering, you need the network administrator to add an exception.

Diagnosing ERR_CONNECTION_RESET step by step#

Step 1: Is it just you?

Try the site from a different device on a different network (mobile data). If it works everywhere else, the problem is on your end (antivirus, VPN, network, browser).

Step 2: Can you connect at all?

# Test basic connectivity
curl -Iv https://example.com 2>&1 | head -20

If curl succeeds but the browser fails, the issue is browser-specific (extension, cache, antivirus). If curl also gets a reset, the issue is at the network or server level.

Step 3: Is it SSL-related?

# Test SSL specifically
openssl s_client -connect example.com:443 < /dev/null 2>&1 | head -10

If the SSL handshake fails with “Connection reset by peer,” the server’s SSL configuration is broken.

Step 4: Is your IP blocked?

Try from a different IP address (VPN, mobile data, a proxy). If the site works from a different IP, your IP is blocked at the firewall level.

Step 5: Check server logs

If you have access to the server:

# Nginx error log
grep -E "reset|connection" /var/log/nginx/error.log | tail -20

# Firewall/fail2ban
grep "Ban" /var/log/fail2ban.log | tail -20

# PHP-FPM
grep -E "signal|segfault|SIGKILL" /var/log/php-fpm/error.log | tail -20

Quick reference#

For other connection errors, see ERR_SSL_PROTOCOL_ERROR for SSL-specific failures and “This site can’t be reached” for the full range of browser connection errors. For server-side 5xx errors that happen after the connection is established, see 502 Bad Gateway and 503 Service Unavailable.