Error: read ECONNRESET (Connection Reset by Peer): Causes and Fixes

ECONNRESET is the operating system error «Connection reset by peer» (errno 104 on Linux). The Node.js docs describe it as: «A connection was forcibly closed by a peer. This normally results from a loss of the connection on the remote socket due to a timeout or reboot. Commonly encountered via the http and net modules.» (Node.js common system errors). Typical forms:

Error: read ECONNRESET
    at TCP.onStreamRead (node:internal/stream_base_commons)  { errno: -104, code: 'ECONNRESET', syscall: 'read' }

Error: socket hang up   { code: 'ECONNRESET' }

«socket hang up» is the http client's variant: the http docs list an 'error' event with message 'Error: socket hang up' and code 'ECONNRESET' when the connection closes before a response arrives. Python reports the same condition as ConnectionResetError: [Errno 104] Connection reset by peer, curl as Recv failure: Connection reset by peer.

It is not a refused connection: ECONNREFUSED happens before the connection exists. ECONNRESET means the connection was open and then torn down with a TCP RST.

The first row is the classic Node.js case. Since Node.js 19 the default http agent uses keep-alive with a 5-second timeout, and a Node.js server closes idle keep-alive sockets after server.keepAliveTimeout, which defaults to 5000 ms (http docs). When the client picks a pooled socket at the same moment the server closes it, the request is written into a closing connection and fails with ECONNRESET or «socket hang up».

Every hop has its own idle timeout, and the rule is the same at each one: the side that keeps a connection open longer must be upstream. If a load balancer keeps idle connections to your Node.js app for 60 seconds while the app closes them after 5, the balancer will occasionally send a request into a socket the app just closed, and clients see 502 errors or resets. Raise the app's timeouts above the balancer's:

const server = http.createServer(app);
server.keepAliveTimeout = 65_000; // longer than the balancer's idle timeout
server.headersTimeout   = 66_000; // keep it above keepAliveTimeout

In nginx in front of Node.js, a reset from the app appears in the error log as recv() failed (104: Connection reset by peer) while reading response header from upstream and the client gets a 502. Related proxy-side message: upstream prematurely closed connection.

1. Log the whole error, including code, syscall and the remote address, and record whether the socket was reused:

   req.on('socket', (s) => console.log('reused:', req.reusedSocket));
   req.on('error', (e) => console.error(e.code, e.syscall, e.message));

2. If failures hit reused sockets, retry once. Node's http docs suggest exactly this for keep-alive races: retry when req.reusedSocket is true and the error is ECONNRESET, but only for idempotent requests (GET, PUT, DELETE), never a payment POST.
3. Make the client give up idle sockets first. Set the client agent's idle timeout below the server's keep-alive timeout, or disable keep-alive for a misbehaving upstream: new http.Agent({ keepAlive: false }).
4. Check the far side. Look for restarts at the failure times (journalctl -u app --since '-1h', kubectl get pods restart counts, dmesg -T | grep -i oom).
5. Find who sends the RST when it is reproducible:

   tcpdump -ni any 'host 203.0.113.10 and tcp[tcpflags] & tcp-rst != 0'

   A reset that the server never sent was injected by a firewall or middlebox.
6. Test TLS separately if it fails during connect: openssl s_client -connect api.example.com:443 -servername api.example.com.

# Hammer the endpoint with pauses around the keep-alive timeout
for i in $(seq 1 20); do curl -sS -o /dev/null -w '%{http_code} ' https://api.example.com/health; sleep 5; done
# 200 200 200 ... with no 'Connection reset by peer'

Watch the error rate in application logs for a day: keep-alive races are rare per request but steady under load. To confirm the host and port answer from outside your network, use the ping and port checker.

• EPIPE — writing to a connection the peer already closed
• ECONNREFUSED — nothing listening, the connection never opened
• ETIMEDOUT — no answer at all within the timeout
• ERR_CONNECTION_RESET — the same reset seen in Chrome
• The connection was reset — the Firefox page for it