How to Fix cURL Proxy Errors (7, 56, and 60)

Your scraper runs clean for an hour, then one line of output changes to curl: (56) Recv failure: Connection reset by peer and the job stalls. cURL's exit codes are blunt but precise, and that is good news: three of them, 7, 56 and 60, cover almost every proxy failure you will meet. Each one points at a different leg of the connection, and each has a real fix that is not "run it again." This is the code-level companion to our full cURL proxy guide. If you need the flag reference first, start there, then come back here when something breaks.

What do cURL proxy errors 7, 56, and 60 mean?

curl 7 means curl could not open a TCP connection to the proxy: it is dead, the port is wrong, or a firewall is blocking it. curl 56 means the connection was made then broke mid-transfer, usually a proxy resetting an overloaded or mismatched connection. curl 60 means the TLS certificate could not be verified, often a proxy intercepting HTTPS.

The pattern to hold onto: the exit code tells you how far the connection got before it died. That alone rules out most wrong guesses.

curl 7: Failed to connect to the proxy

Exit code 7 is CURLE_COULDNT_CONNECT. curl tried to open a TCP connection to the proxy and could not. Nothing about the target site is involved yet, because the request never got past its first hop.

curl -x http://203.0.113.7:8080 https://example.com/
# curl: (7) Failed to connect to 203.0.113.7 port 8080 after 9 ms: Couldn't connect to server

Older curl builds print the underlying OS reason instead, most often Connection refused. Same exit code, same meaning.

Why it happens with proxies. Three causes account for nearly all of it:

• The proxy is dead. With free proxies this is the default state, not the exception. Most entries on any public list are down at any given moment.
• Wrong port for the scheme. A scheme with no port uses a default, and the SOCKS default is 1080, not 8080. Point socks5h:// at a bare host and curl dials 1080 whether or not anything is listening there:

curl -x socks5h://203.0.113.7 https://example.com/
# curl: (7) Failed to connect to 203.0.113.7 port 1080 after 6 ms: Couldn't connect to server

• A firewall is refusing you. A local or network firewall can reject the connection before it ever leaves your machine.

The real fix. Confirm the proxy is actually alive before you use it, and give dead ones a short leash so they fail fast instead of hanging:

curl -x http://203.0.113.7:8080 --connect-timeout 5 https://example.com/

If it still returns 7, the proxy is the problem, so swap it. Our proxy checker tells you in one shot whether a proxy is alive, fast and anonymous, and every entry on the free proxy list shows when it was last verified. When you are picking a SOCKS scheme, socks5h:// is usually what you want, since the proxy does the DNS lookup; the cURL guide covers that choice in full.

curl 56: Recv failure and connection resets

Exit code 56 is CURLE_RECV_ERROR, a failure while receiving data. Unlike 7, the connection did get made, then broke underneath you.

curl -x http://203.0.113.7:8080 https://example.com/
# curl: (56) Recv failure: Connection reset by peer

You may also see it worded as a refused tunnel, which is still exit 56:

curl: (56) Received HTTP code 403 from proxy after CONNECT

Why it happens with proxies.

• The proxy dropped the connection. Overloaded proxies accept you, then reset the socket mid-transfer when they run out of capacity. Free proxies do this constantly.
• Protocol mismatch. If you aim an HTTP proxy scheme at a port that is actually speaking SOCKS (or the reverse), the two ends exchange bytes they cannot parse and the connection resets. A live proxy on the wrong scheme fails here as a 56, where a closed port would have failed earlier as a 7:

curl -x http://198.51.100.14:1080 https://example.com/
# curl: (56) Recv failure: Connection reset by peer

• The proxy refuses to tunnel. For HTTPS targets curl asks the proxy to CONNECT to the host and port. A proxy whose policy blocks that destination aborts the tunnel, which shows up as the Received HTTP code 403 from proxy after CONNECT form. This is common on ports other than 443. A proxy that needs credentials instead returns Received HTTP code 407 from proxy after CONNECT, which we decode in 407 Proxy Authentication Required.

The real fix. Rotate to a fresh proxy first, since an overloaded one is the usual culprit. If a new proxy behaves the same way, check the scheme against the proxy's real protocol, and use curl -v to watch the CONNECT exchange and see exactly where it aborts. One note on symptoms: a reset (56) is not the same as a stall that ends in a timeout. If the transfer hangs and then times out (curl 28, or an HTTP 504 from the proxy), that is a different failure with different causes, mapped in our 504 through a proxy guide.

curl 60: SSL certificate problem

Exit code 60 is CURLE_PEER_FAILED_VERIFICATION. The TLS handshake got far enough to present a certificate, and curl could not verify it against its trusted CA store.

curl -x http://203.0.113.7:8080 https://example.com/
# curl: (60) SSL certificate problem: unable to get local issuer certificate
# More details here: https://curl.se/docs/sslcerts.html
#
# curl failed to verify the legitimacy of the server and therefore could not
# establish a secure connection to it.

Why it happens with proxies. A plain HTTP proxy tunnels HTTPS untouched, so it should never cause this. When a proxy does trigger 60, it is doing one of these:

• TLS interception. Some corporate and filtering proxies terminate your TLS, read the traffic, then re-encrypt with a certificate signed by their own CA. Your machine does not trust that CA, so curl correctly rejects it.
• An HTTPS proxy with a self-signed cert. If you connect to the proxy itself over TLS with -x https://, and its certificate is self-signed, the proxy leg fails verification.
• A stale CA bundle. Not the proxy's doing, but an out-of-date local certificate store fails the same way.

Why -k is the wrong fix. The tempting one-liner is -k (--insecure), and you should resist it. -k disables certificate verification for the target, the site you actually care about. That does make the error disappear, but it also blinds you to a genuine man-in-the-middle and hides the fact that something is tampering with your traffic. You lose the ability to tell a legitimate corporate proxy apart from an attacker.

Scope the trust instead of removing it:

# WRONG: stops verifying the target, the thing you most want verified
curl -k -x http://203.0.113.7:8080 https://example.com/

# Scoped: skip verification only for an HTTPS proxy's own certificate
curl --proxy-insecure -x https://203.0.113.7:8080 https://example.com/

# Right for a TLS-intercepting proxy: trust its root CA, keep target verification on
curl --cacert /path/to/corp-root-ca.pem -x http://203.0.113.7:8080 https://example.com/

--proxy-insecure is the precise counterpart to -k: it relaxes verification for the proxy connection only and leaves the target's certificate fully checked. Better still, trust the certificate explicitly with --proxy-cacert (for an HTTPS proxy leg) or --cacert (for an intercepting CA), so verification stays on end to end. If the cause is just an old bundle, update your system ca-certificates package rather than turning anything off.

Read the exit code, then isolate

Every one of these resolves faster when you let the exit code point you, then change one variable at a time:

1. Same request, different proxy. Fixes it? The first proxy was dead or overloaded. That covers most 7s and 56s.
2. Same request, no proxy. Works without a proxy? The proxy or its certificate is the problem, not the target. That covers most 60s and CONNECT-refusal 56s.
3. Same proxy, -v added. The verbose CONNECT and TLS lines show the exact hop that failed.

Two or three commands and the guessing stops. Keep a verified pool within reach so a dead proxy is a swap and not an incident: the free proxy list re-checks its entries every few minutes, the proxy checker confirms any single proxy before you trust it, and the full cURL proxy guide holds the flag reference behind every fix above.