Connection reset by peer (ECONNRESET)
ID: networking/connection-reset
Version Compatibility
| Version | Status | Introduced | Deprecated | Notes |
|---|---|---|---|---|
| any | active | — | — | — |
Root Cause
The remote host sent a TCP RST packet, forcibly closing the established connection. This typically indicates the server process crashed, the connection was idle too long and was reaped, a load balancer or proxy intervened, or the server is overwhelmed.
genericWorkarounds
-
85% success Implement retry logic with exponential backoff and investigate the root cause
1. Add retry logic with exponential backoff (e.g., 1s, 2s, 4s, 8s delays) 2. Check server logs for crashes or errors at the time of reset 3. Monitor server resource usage: top, vmstat, ss -s 4. Check if a load balancer or reverse proxy is terminating idle connections 5. Verify the server's connection limit: ulimit -n and sysctl net.core.somaxconn 6. If the server crashed, fix the underlying server bug or resource exhaustion
-
80% success Configure keepalive probes and idle timeout settings across the connection chain
1. Set TCP keepalive on the application socket: setsockopt(SO_KEEPALIVE) 2. Configure system keepalive: sysctl -w net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_intvl=10 net.ipv4.tcp_keepalive_probes=6 3. Check load balancer idle timeout (e.g., AWS ALB defaults to 60s) and set keepalive interval below it 4. For HTTP, use Connection: keep-alive headers and ensure server supports them 5. Monitor for connection resets: ss -s to track reset counts
Dead Ends
Common approaches that don't work:
-
Immediately retry the same request in a tight loop without backoff
80% fail
If the server is overwhelmed or rate-limiting connections, rapid retries will make the problem worse. The server will continue resetting connections, potentially leading to IP bans or exhausting client resources with failed connections.
-
Increase the TCP keepalive interval on the client only
70% fail
If the reset is caused by an intermediate device (load balancer, NAT gateway) timing out idle connections, the client-side keepalive must be shorter than the intermediary's timeout. However, client-only keepalives do not help if the server or intermediary does not support or respond to them, or if the reset is caused by server crashes.