How to fix ERR_CONNECTION_RESET and "connection reset by peer"

What ERR_CONNECTION_RESET means

ERR_CONNECTION_RESET in Chrome, and Connection reset by peer in curl, SSH, scp or git, both mean the same thing: something on the path sent a TCP packet with the RST (reset) flag, and your connection was torn down on the spot. The other end, or a device pretending to be the other end, deliberately aborted the conversation.

Under the TCP specification (RFC 9293), a reset is sent when a packet arrives for a connection that no longer exists, or when an application aborts a connection instead of closing it normally. Your browser then shows the reset page; command-line tools print the error and exit.

The useful question is who sent the RST. It can be the web server, a process that died behind it, a firewall or intrusion prevention system, an ISP filter, a corporate proxy, or antivirus software on your own computer.

Quick-fix checklist

1. Load the same URL on mobile data instead of Wi-Fi. If it works there, the problem is on your network side, not the site.
2. Turn off any VPN, proxy or browser extension that filters traffic, and pause HTTPS scanning in your antivirus. Retry.
3. Run curl -v https://example.com/ and note at which step it fails: before the TLS handshake, during it, or after the request is sent.
4. If you own the site, check the web server error log and the system log for crashes or killed processes at the exact time of the failure.
5. If it only fails on uploads or large forms, check request size limits.
6. If it only fails under load, check worker limits such as PHP-FPM pm.max_children.

Visitor side vs site owner side

Visitor-side causes

Antivirus HTTPS scanning, VPNs and proxies

Security suites that inspect encrypted traffic sit in the middle of every HTTPS connection, and many reset a connection they object to rather than show an error. VPN clients and corporate proxies do the same when a policy blocks a destination. Disable each in turn; if one fixes it, add an exception rather than leaving protection off.

ISP or network filtering

Some networks block sites by injecting a reset as soon as they see a hostname they filter. The tell-tale sign is that the site works on another network and fails instantly on the filtered one. There is nothing the site owner can change on the server to stop this.

MTU and misbehaving routers

MTU problems, common with PPPoE broadband and some VPNs, usually cause hangs, but a faulty router or firewall can answer oversized packets with a reset. Restart the router, try a wired connection, and test with the VPN off.

Server-side causes

The web server or application crashed or was killed

If the process holding the socket dies mid-request with unread data waiting, the kernel answers with a reset instead of a normal close. If the process sits behind a reverse proxy such as nginx, the visitor more often gets a 502 Bad Gateway; if the front-end web server itself dies, they get a reset or a refused connection. On Linux the most common killer is the out-of-memory (OOM) killer. Check for it right after a failure:

sudo dmesg -T | grep -i -E "killed process|out of memory"
sudo journalctl -k --since "1 hour ago" | grep -i oom
sudo systemctl status nginx php8.3-fpm

Replace the service names with the ones you run. If your application process appears in the OOM lines, you need more RAM, fewer workers, or a fix for whatever is leaking memory.

Keep-alive connections closed by the other side

Servers close idle keep-alive connections after a timeout; in nginx, keepalive_timeout defaults to 75 seconds. If a client or a reverse proxy reuses a connection at the same moment the upstream closes it, the request lands on a dead socket and comes back as a reset. In a reverse-proxy set-up, make sure the upstream application keeps idle connections open longer than the proxy does, not shorter. Also check whether nginx's reset_timedout_connection (off by default) has been switched on: it makes nginx reset timed-out connections instead of closing them.

PHP-FPM and worker limits

In PHP-FPM, pm.max_children caps how many requests are served at the same time. When every child is busy, new connections wait in the pool's listen backlog (listen.backlog). Once that fills, new connections to PHP-FPM fail: behind nginx the visitor usually sees a 502 or 504, while other front ends or proxies may reset the connection. Look in the FPM log for a warning that the pool reached pm.max_children, then raise it only as far as your RAM allows. Also check request_terminate_timeout: when it is set, PHP-FPM kills the worker after that time, and the visitor sees the request die.

sudo grep -i "max_children" /var/log/php*-fpm.log
grep -E "^pm|request_terminate_timeout" /etc/php/8.3/fpm/pool.d/www.conf

Firewalls, IPS and web application firewalls

Host firewalls (nftables, iptables, ufw), intrusion prevention systems and web application firewalls can all be set to reject with a TCP reset instead of silently dropping. A rule that blocks an IP after a few failed logins, or a WAF rule triggered by a form that contains code-like text, produces exactly this error for one visitor and nobody else. Check the logs for that visitor's IP.

sudo nft list ruleset | grep -i reject
sudo iptables -L -n -v | grep -i reset

TLS misconfiguration

If the reset arrives during the handshake, check the certificate chain, the protocols and ciphers on offer, and that the server is actually speaking TLS on port 443. Test from outside:

curl -v https://example.com/
openssl s_client -connect example.com:443 -servername example.com

If openssl s_client fails instantly but a plain TCP connection to port 443 succeeds, the TLS layer is the problem.

Request size limits

nginx rejects request bodies larger than client_max_body_size (1 MB by default) with a 413 error, and its own documentation notes that browsers cannot correctly display that error. In practice the visitor often sees a reset or a blank failure on the upload. Raise the limit in the relevant server or location block, and keep PHP's upload_max_filesize and post_max_size in line with it:

client_max_body_size 64m;

How to diagnose it step by step

1. Browser DevTools. Open the Network tab, reload, and look at the failed request. Note whether it fails on the first document or only on one asset or upload.
2. curl -v. The verbose output shows the TCP connect, the TLS handshake and the request. A reset right after the connect points at a firewall or filter; one during the handshake points at TLS, or at a filter that reads the hostname (SNI) in the TLS ClientHello; one after the request is sent points at the application or a WAF.
3. Server logs. Read the web server error log and the application log for the exact timestamp. Something usually shows a crash, a limit or a blocked IP. Run dmesg -T for OOM kills and segmentation faults.
4. tcpdump. If you still cannot tell who sends the reset, capture resets on the server with sudo tcpdump -ni any "tcp[tcpflags] & tcp-rst != 0 and port 443". If the server never sends an RST but the visitor receives one, something in between generated it.

Connection reset by peer in SSH, scp and git

The same error appears with SSH-based tools, and the causes are similar. Check these first:

• Too many unauthenticated connections. OpenSSH's MaxStartups (default 10:30:100) starts refusing new connections at random once ten are waiting to authenticate, which bots scanning port 22 can easily cause. OpenSSH 9.8 and later also enable PerSourcePenalties, which temporarily refuses an address after failed logins or connections that never authenticate.
• A firewall or fail2ban rule has blocked your IP after failed attempts.
• Idle sessions dropped by a NAT router or firewall. Send keepalives from the client with ServerAliveInterval 30 in ~/.ssh/config, or set ClientAliveInterval on the server.
• Large git pushes or clones over HTTPS hitting a proxy or server request limit. Switch the remote to SSH, or raise the limit on the server.

Run ssh -vvv user@host to see how far the connection gets, and read journalctl -u ssh (or sshd, depending on the distribution) on the server for the matching entry.

Connection resets on Bigdomainhost

On a KVM VPS you have root access, so every server-side check above is yours to run. The server firewall denies inbound traffic by default except SSH on port 22, so if a new site resets or refuses connections on ports 80 or 443, open them in the per-instance firewall rules in the panel first. If a firewall change locks you out of SSH, use the out-of-band console in the panel to get back in. The networking and firewall docs explain the defaults.

Web & cPanel hosting runs on LiteSpeed and includes Imunify360, which adds a web application firewall; WordPress hosting also runs on LiteSpeed. If resets happen only on one form, or only from your IP after failed logins, send support the time, your IP and the URL so the block can be checked.

If resets start right after moving a site, the migration guide covers the DNS and SSL checks. Support is available 24x7 on phone and WhatsApp at +91 75994 50220, or at support@bigdomainhost.com.

Sources (checked 15 November 2026)

• IETF: RFC 9293: Transmission Control Protocol (TCP)
• nginx.org: Module ngx_http_core_module
• PHP Manual: FPM configuration
• OpenBSD manual pages: sshd_config(5)