Technology · PRACTICAL GUIDE
curl error 56 “Recv failure”? Find the reset stage before retrying
“Connection reset by peer” proves that a receive path ended abruptly; it does not name the machine or process that caused it. Preserve the effective curl runtime, byte direction and last completed protocol stage, then correlate the owner before changing TLS, HTTP versions, firewalls or retry policy.
“Connection reset by peer” proves that a receive path ended abruptly; it does not name the machine or process that caused it. Preserve the effective curl runtime, byte direction and last completed protocol stage, then correlate the owner before changing TLS, HTTP versions, firewalls or retry policy.
CURLE_RECV_ERROR is code 56 and means receiving network data failed. A TCP reset can be emitted by an endpoint or an on-path function; curl alone cannot prove which one.
1. Freeze the failing request safely
Record the exact curl executable, `curl -V`, URL host and port, proxy variables, container or service identity, DNS result and a secret-redacted command. Preserve exit 56, time, request ID and bytes sent or received.
Before any retry, classify the method and side effects. GET and HEAD are often replayable but not universally harmless; POST, PUT and uploads may have reached the application even when the response was reset. Use the application’s idempotency mechanism or confirm server state first.
2. Mark the last completed stage
Run one controlled reproduction with `--verbose` or a secret-redacted timed trace. Mark the last confirmed boundary: TCP connect, proxy CONNECT, TLS handshake, request headers, request body, response headers or response body.
Direction matters. A reset while curl is still uploading points to a different investigation than a reset after status and response bytes arrived. Preserve Content-Length, transfer encoding and byte counts without storing credentials or sensitive bodies.
3. Correlate the connection owner
Match the timestamp, client tuple, hostname, protocol and request ID against origin, reverse-proxy, load-balancer and egress logs. A TCP reset names a connection event, not necessarily the origin application.
If direct and proxied paths differ, compare only one variable at a time. If another client succeeds, first prove it used the same DNS answer, address family, proxy, TLS policy, HTTP version, credentials and payload.
4. Change one cause, not five knobs
Repair the boundary that owns the first contradictory evidence: make the server read or reject the request cleanly, correct proxy routing or idle policy, stop a crashing worker, or fix a protocol expectation. Do not disable TLS verification or force HTTP/1.1 merely because those changes alter timing.
Use `--retry` only after classifying the operation and the documented retry conditions for the installed curl version. A retry that succeeds can still hide duplicate work or a deterministic reset threshold.
5. Accept the same path and payload
Repeat from the same user, executable, network route and payload class. Require exit 0, the expected status and complete body or checksum, no reset in peer logs and a second clean run.
Keep a compact before-and-after ledger: last good stage, bytes in each direction, reset observer, correlated owner log, one configuration or code change, and the acceptance result. That evidence makes recurrence diagnosable instead of mysterious.
