Skip to content
Latchkey

CI "Connection reset by peer" - Fix ECONNRESET on Runners

An already-open connection was abruptly closed by the other end (or something in between) with a TCP RST. The transfer was underway and then cut off - a transient failure that usually succeeds on retry.

What this error means

A download or API call fails partway through with Connection reset by peer, ECONNRESET, or curl: (56) Recv failure. The connection had been established, so it is not a DNS or firewall problem - something dropped it mid-stream.

CI log
curl: (56) Recv failure: Connection reset by peer
# or
Error: read ECONNRESET
    at TLSWrap.onStreamRead (node:internal/stream_base_commons)

Common causes

The remote or a proxy dropped the connection

An overloaded server, a load-balancer recycling backends, or a proxy idle-timeout sends a RST mid-transfer. None of it reflects a problem in your build.

Transient network instability

A brief network glitch between the runner and the remote can break an in-flight connection, surfacing as a reset.

How to fix it

Retry the transfer

A reset is transient; a clean retry typically completes the transfer.

Terminal
curl --retry 5 --retry-delay 2 --retry-all-errors -fSL "$URL" -o out

Reduce strain on the connection

  1. Lower download concurrency so you are not hammering one endpoint.
  2. Pull from a mirror or pull-through cache that is less loaded.
  3. For package managers, set their built-in retry counts higher.

How to prevent it

  • Use bounded retry-with-backoff around network transfers.
  • Prefer mirrors/caches over a single hot upstream.
  • Tune client and package-manager retry settings for CI.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →