"Connection reset by peer" in CI

By Kaveh Alemi·Latchkey

The connection was open and then received a TCP RST, so it was torn down by the peer or an intermediary. This is distinct from a timeout: something actively refused to continue rather than the packets being silently dropped.

What this error means

curl fails with "Recv failure: Connection reset by peer" (exit 56), or a client library reports "Connection reset by peer" after the connection had already been established.

curl: (56) Recv failure: Connection reset by peer

Common causes

A firewall or proxy resets disallowed traffic

Some middleboxes send an RST rather than silently dropping, for example when a request violates a policy or exceeds a limit.

The server closed the connection under load

An overloaded or restarting server can reset in-flight connections, producing an RST at the client.

How to fix it

Retry and isolate whether it is deterministic

1. Retry the request a few times; a transient reset often clears.
2. If it resets every time on a specific host, suspect a policy-based reset by a proxy or firewall.
3. Test the same host directly to compare behavior.

curl -v --retry 3 --retry-connrefused https://api.example.com/ -o /dev/null

Check for a middlebox resetting the traffic

If resets are consistent for one destination, review proxy or firewall rules that may RST that host, port, or request pattern.

How to prevent it

• Add retries so transient resets do not fail the job.
• Review proxy and firewall policies for hosts that reset consistently.
• Keep request sizes and rates within any documented middlebox limits.

Frequently asked questions

Related guides

References

• GitHub Actions documentation