Error: read ECONNRESET / socket hang up

// client: retry idempotent calls on a transient reset
for (let i = 0; i < 3; i++) {
  try { return await fetch(url); }
  catch (e) { if (e.cause?.code !== 'ECONNRESET' || i === 2) throw e; }
}

What you're seeing

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

// or, when no response ever arrived:
Error: socket hang up
    at connResetException (node:internal/errors:720:14)
  code: 'ECONNRESET'

The behaviour is essentially the same across Node.js 18, 20, and 22. Modern Node powers fetch() with Undici, so the examples below use the built-in fetch — but the causes and fixes apply equally to axios, node:http, and database drivers.

Fix 1 — Retry idempotent requests (most common)

When: occasional resets on GET/PUT/DELETE calls to an API or database driver.

async function getWithRetry(url, tries = 3) {
  for (let i = 0; i < tries; i++) {
    try {
      return await fetch(url);
    } catch (e) {
      const code = e.cause?.code || e.code;
      if (code !== 'ECONNRESET' || i === tries - 1) throw e;
      await new Promise(r => setTimeout(r, 200 * 2 ** i)); // backoff
    }
  }
}

Most resets are one-off (a recycled load-balancer socket, a brief network blip). A single retry with exponential backoff clears the majority. Only retry requests that are safe to repeat — see the POST note below.

Same pattern with axios — check err.code the same way:

import axios from 'axios';

async function getWithRetry(url, tries = 3) {
  for (let i = 0; i < tries; i++) {
    try {
      return await axios.get(url);
    } catch (err) {
      if (err.code !== 'ECONNRESET' || i === tries - 1) throw err;
      await new Promise(r => setTimeout(r, 200 * 2 ** i));
    }
  }
}
// or offload it entirely with the axios-retry plugin

Fix 2 — Reuse sockets safely with a keep-alive agent

When: high request volume; the first request after an idle gap resets.

import { Agent } from 'undici';

// recycle idle sockets before the server drops them
const agent = new Agent({
  keepAliveTimeout: 10_000,      // close our idle sockets at 10s
  keepAliveMaxTimeout: 30_000,
});

await fetch(url, { dispatcher: agent });

The classic intermittent ECONNRESET is a stale pooled socket: your agent hands you a connection the server closed seconds ago. Setting your keep-alive timeout below the server's idle timeout means you never reuse a dead one.

Fix 3 — Rule out a proxy, VPN, or TLS inspector

When: it only happens on a work network, a VPN, or against one specific host.

# reproduce outside Node — if curl also resets, it's the network path
curl -v https://api.example.com/health

# honor the corporate proxy in Node
export HTTPS_PROXY=http://proxy.corp:8080
node app.js

TLS-inspecting firewalls reset handshakes they can't decrypt, and proxies reset hosts on a blocklist. If curl -v outside Node fails the same way, the fix is network/proxy configuration, not your code.

Fix 4 — Stop client disconnects from crashing the server

When: your own HTTP server logs ECONNRESET and sometimes the process dies.

server.on('request', (req, res) => {
  req.on('error', (err) => {
    if (err.code === 'ECONNRESET') return;   // client went away — safe to ignore
    console.error(err);
  });
});

In Express, catch it in an error-handling middleware (four args) so a disconnect doesn't bubble up:

// error-handling middleware — must be registered last, with 4 args
app.use((err, req, res, next) => {
  if (err.code === 'ECONNRESET') return;   // client disconnected — ignore
  next(err);                               // let real errors flow on
});

A browser tab closed mid-request or a cancelled fetch resets the socket. That's normal traffic, not a bug — you just need a per-socket/per-request error handler so the unhandled event doesn't crash Node.

Fix 5 — Raise timeouts for slow or large transfers

When: big uploads/downloads or slow upstreams reset partway through.

// server: allow slow clients more headroom
server.requestTimeout = 60_000;
server.headersTimeout = 65_000;
server.keepAliveTimeout = 61_000;   // keep > upstream/LB idle timeout

POST note: never blindly retry a non-idempotent POST — the server may have already processed it. Add an idempotency key so a retry is safe, then apply Fix 1.

Why this happens

TCP has a "forcible close": one side sends an RST packet and the connection dies immediately, discarding anything in flight. When your side next tries to read, the OS returns ECONNRESET ("connection reset by peer"). Node surfaces the raw read failure as read ECONNRESET; when the socket closes before a full HTTP response is parsed, Node instead reports socket hang up. Either way the trigger is on the other end — a server crash, an idle-timeout on a proxy/load-balancer, a pool recycling a connection, or a firewall dropping the flow. That's why the durable fixes are resilience (retry, keep-alive tuning) rather than a one-line code change.

Where it comes from