Self-Healing CI: Recovering a Proxy / Egress Connection Reset
A request reset on its way through an egress proxy hit a momentary network problem, not a broken proxy config -- the same request usually succeeds on a retry.
The problem
An outbound request fails with a connection reset (ECONNRESET) as it passes through an egress proxy or NAT gateway. The proxy config and the destination are fine; the connection was reset by a transient condition on the path. A human re-runs the job and the request completes unchanged.
Error: read ECONNRESET
# or
curl: (56) Recv failure: Connection reset by peer (via proxy)Why it happens
Outbound traffic in CI often flows through a shared egress proxy or gateway. A brief overload, an idle-connection reset, or upstream congestion on that path can reset a connection mid-request even though the proxy is configured correctly and the destination is up.
It is transport flakiness on the egress path, not a configuration error: nothing about the request changed, and the same call succeeds once the connection is retried.
The manual fix
Manual mitigations for an egress reset:
- Re-run the job to retry the request.
- Add retry-with-backoff around outbound calls so one reset does not fail the step.
- Enable keepalives or connection reuse to reduce new-connection churn through the proxy.
How this gets automated
A connection reset on the egress path has a recognizable transient signature, and the safe response is to retry with backoff. A self-healing CI pipeline detects the reset, retries the request, and only escalates if the destination stays unreachable, distinguishing a momentary egress blip from a real proxy or destination problem.