Home/Blog/Proxy Error Codes

Developer Guide

Proxy Error Codes: 407, 429, 502 and Fixes

Proxy failures come from three different layers - your auth, the target's rules, and the transport underneath. This is a diagnostic taxonomy: read the code, find the layer, apply the right fix instead of blindly retrying.

9 min read·Last updated: July 2026

Quick Answer

Proxy errors split into three layers. 407 is a proxy auth problem (fix the credentials). 403 is a block and 429 is rate limiting (rotate or back off, honoring Retry-After). 502/503 are server-side gateway errors (back off and retry). ECONNRESET and "tunnel connection failed" are transport faults below HTTP (retry on a fresh connection).

→4xx = the client or target: check auth, then whether you are blocked or throttled
→5xx = the gateway or upstream: usually transient, retry with backoff
→Socket errors (ECONNRESET, tunnel failed) never reach HTTP - handle them separately

The fastest way to waste a proxy pool is to treat every failure the same - retry, retry, retry. A 407 will never fix itself with a retry; a 403 usually needs a different IP, not more requests; a 429 needs you to slow down. This guide maps each code to the layer it comes from and the action that actually clears it. It sits between recovering from IP bans (the block problem) and exponential backoff for proxy retries (the retry algorithm). New to proxies entirely? Start with what a mobile proxy is.

First, find the layer

Every proxy error belongs to one of three layers, and the layer decides the fix:

4xx - client side

407, 403, 429

Your request or your rate. Fix auth, rotate, or slow down.

5xx - server side

502, 503, 504

The gateway or upstream. Back off and retry.

Transport

ECONNRESET, tunnel failed

The socket itself. No HTTP status ever arrives.

A key distinction from RFC 9110: a status code below 500 is the client's or target's decision about this request, while 5xx means the server (or a gateway in the path) failed to fulfill an otherwise valid request.

407 Proxy Authentication Required

407 is defined in RFC 9110 as the proxy-side twin of 401. The proxy - not the target - is rejecting you because the request lacks valid credentials for the proxy itself. The proxy responds with a Proxy-Authenticate header describing the scheme, and the client is expected to repeat the request with a Proxy-Authorization header.

There are two equivalent ways to supply those credentials:

•URL auth - embed them in the proxy URL: http://user:pass@host:port. Most clients turn this into the header for you.
•Header auth - send Proxy-Authorization: Basic <base64(user:pass)> explicitly.

The common misconfigurations that produce a stubborn 407:

×Putting credentials on the target URL instead of the proxy URL.
×Sending Authorization (for the target) when the proxy wants Proxy-Authorization.
×A password with special characters that is not URL-encoded in the proxy URL.
×Stripping the header across a redirect or a CONNECT tunnel so it never reaches the proxy.

A quick way to isolate it is a one-line request with explicit credentials - see the mobile proxy with curl walkthrough for the exact --proxy-user syntax.

403 vs 429: a block or a speed limit?

These two look similar in a log but demand opposite responses.

403 Forbidden (RFC 9110) means the target understood the request and refuses to authorize it. Re-authenticating will not help, and re-sending the same request from the same IP will not either - the target has decided against this request or the identity behind it. When 403s cluster on one IP, that IP or its fingerprint is the problem. The fix is a cleaner identity, covered in how to recover from an IP ban and, on the rotation side, in IP rotation best practices.

429 Too Many Requests (defined in RFC 6585) means the opposite: the request was acceptable, you have simply sent too many in the window. It is a temporary, recoverable state. The correct response is to slow down - and if the server sends a Retry-After header, honor it exactly rather than guessing.

Rule of thumb: a 403 is about who is asking, so change the identity (rotate the IP). A 429 is about how fast, so change the pace (back off, then rotate only if the limit is per-IP). Reaching for rotation on a 429 without slowing down just spreads the same overload across more addresses.

Honoring the Retry-After header

RFC 9110 defines Retry-After as the server's explicit signal for how long to wait. It appears most often on 429 and 503 responses, and it can take two forms:

•delta-seconds - a non-negative integer, e.g. Retry-After: 120.
•HTTP-date - an absolute time, e.g. Wed, 21 Oct 2015 07:28:00 GMT.

A robust client parses both and only falls back to exponential backoff when the header is missing. Honoring the server's stated delay is both faster (you retry exactly when allowed) and safer (you avoid piling on during the cooldown). The full algorithm, with jitter and code, is in exponential backoff for proxy retries.

502, 503, 504: gateway vs upstream

The 5xx family means the request was fine but a server in the path could not fulfill it. Which server, and whether it is the target or the proxy, depends on the exact code:

•502 Bad Gateway - a server acting as a gateway or proxy received an invalid response from the upstream server (RFC 9110). Note that if the origin sends a valid HTTP error, that error should be passed through instead of a 502 - so a 502 points at a broken hop, not a normal rejection.
•503 Service Unavailable - the server is temporarily unable to handle the request, typically overload or maintenance. Unlike a 429's "you specifically are over quota," a 503 is usually "the service is down for everyone right now." It commonly carries a Retry-After.
•504 Gateway Timeout - the gateway waited for the upstream and got nothing in time. Check target latency and your request timeout before blaming the proxy.

Diagnosing target vs proxy: if the same request fails with a 5xx through the proxy but succeeds directly, suspect the proxy hop; if it fails both ways, the target is genuinely unavailable and no amount of rotation helps. Either way, 5xx errors are usually transient - back off and retry, and escalate to rotation only if a specific exit keeps producing them.

Transport failures: ECONNRESET and CONNECT tunnels

Below HTTP is the TCP socket, and some failures never produce a status code at all. These show up as thrown errors in your client rather than a response object.

ECONNRESET is a POSIX socket error surfaced by Node.js (and most runtimes) that means the peer sent a TCP RST - the connection was open and then forcibly closed "by peer." A frequent cause is a pooled keep-alive socket that a proxy or load balancer already dropped while it sat idle: you find out only when you write the next request onto the dead connection. Server-side timeouts and mid-transfer disconnects produce it too. Treat it as retryable on a fresh connection, and consider limiting keep-alive reuse if it recurs.

"Tunnel connection failed" relates to how HTTPS travels through a forward proxy. Per RFC 9110, the client first sends an HTTP CONNECT request asking the proxy to open a tunnel to the target; only a 2xx response establishes it, after which the proxy blindly forwards bytes in both directions. If the proxy cannot reach the target, or you are not authenticated, it returns an error and tools surface a message such as tunnel connection failed or Received HTTP code 407 from proxy after CONNECT.

When you see a CONNECT failure, read the status code inside the message. A 407 there is still an auth problem; a 403 or 502 there is a reachability or upstream problem. The tunnel error is the envelope - the code inside tells you which of the sections above applies.

Cause-to-fix reference table

One row per error, mapped to the layer and the action that actually clears it.

Error	Likely cause	Fix
407	Missing or wrong proxy credentials	Fix auth: correct user:pass, use Proxy-Authorization or URL auth
403	Target blocked the request or IP	Rotate to a clean IP / adjust fingerprint - not backoff
429	Rate limited (too many requests)	Honor Retry-After, back off; rotate only if limit is per-IP
502	Invalid response from upstream via gateway	Back off and retry; if persistent, a hop is broken
503	Service overloaded or in maintenance	Honor Retry-After, back off and retry
504	Upstream did not answer in time	Raise timeout, check target reachability, retry
ECONNRESET	Socket reset by peer (idle pool, timeout)	Retry on a fresh connection, limit keep-alive, add backoff
tunnel failed	CONNECT could not open the HTTPS tunnel	Read the inner status code; verify creds, target, sticky session

Note where sticky sessions versus rotation land: a login or multi-step flow that breaks mid-session usually wants a sticky IP so state survives, whereas a 403 or a per-IP 429 wants rotation. Matching the two to the error, rather than defaulting to one, is most of the fix.

Where the proxy network fits

Auth fixes clear 407s and backoff clears transient 5xx, but the errors that eat the most time are 403s and per-IP 429s - and those are about the reputation of the exit IP. Carrier-grade mobile IPs share the same CGNAT pools as ordinary phone subscribers, so they carry higher default network trust than datacenter ranges and reset naturally as the carrier reassigns them.

That does not change what a status code means - a 403 is still a block - but it changes how often you hit one and how cleanly a rotation lands. Background on the identity layer is in what a mobile proxy is.

Frequently asked questions

What does a 407 Proxy Authentication Required error mean?

407 means the proxy in front of the target needs credentials and the request did not include valid ones. Per RFC 9110, the proxy replies with a Proxy-Authenticate header, and the client must resend with a Proxy-Authorization header (or credentials embedded in the proxy URL). It is the proxy equivalent of a 401.

What is the difference between a 403 and a 429?

A 403 Forbidden means the target understood the request and refuses to authorize it - a block that re-sending unchanged will not clear. A 429 Too Many Requests means you are being rate limited and can retry later, ideally after honoring the Retry-After header. 403 is a wall; 429 is a speed limit.

Should I retry a 502 or 503 error?

Yes, usually. Both are server-side 5xx errors that are often transient. A 503 Service Unavailable may carry a Retry-After header telling you when to come back; honor it. For 502 Bad Gateway, back off and retry, and if it persists the upstream target or the gateway path is genuinely broken rather than busy.

What causes ECONNRESET when using a proxy?

ECONNRESET is a socket-level error, not an HTTP status: the peer sent a TCP RST, so the connection was forcibly closed. Common causes are an idle keep-alive socket that the proxy or load balancer already dropped, a server-side timeout, or a mid-transfer disconnect. Retry on a fresh connection and add backoff.

What does "tunnel connection failed" mean on a CONNECT request?

For HTTPS through a forward proxy, the client sends an HTTP CONNECT to open a tunnel to the target. Only a 2xx response establishes it. If the proxy cannot reach the target or you are not authenticated, it returns an error and tools report a message like "tunnel connection failed" or "Received HTTP code 407 from proxy after CONNECT." Check the CONNECT status code, credentials, and target reachability.

Does the Retry-After header use seconds or a date?

Either. RFC 9110 allows Retry-After to be a non-negative integer number of seconds (delta-seconds) or an absolute HTTP-date. A robust client parses both formats and falls back to exponential backoff when the header is absent.

Sources

Related Guides