Proxy Error Codes Explained: 407, 429, 502 and the Rest

The single most useful habit in proxy debugging is asking one question before anything else: did the proxy answer, or did the target? Everything downstream of that question is straightforward, and almost every hour wasted on this comes from skipping it.

Errors from the proxy

407 Proxy Authentication Required

The proxy rejected your credentials, or you sent none. This is the most common error and almost always one of four things: a typo in the username or password, a client that does not send proxy credentials at all, IP authentication configured but your current address not on the allowlist, or an expired plan. All eight causes and their tests are in the full 407 guide.

Check it directly with curl before touching your application. If curl -x user:pass@host:port https://example.com works and your code does not, the problem is in how your client passes credentials — a common gap with tools that support proxies but not proxy authentication.

Connection refused / timeout on connect

Nothing is listening where you are dialling. Wrong port is the usual cause — HTTP and SOCKS5 endpoints normally differ. A local firewall or corporate network blocking outbound connections on non-standard ports is the second most common, and an expired or deprovisioned IP the third.

502 Bad Gateway

The proxy accepted your request but could not complete the upstream fetch. On residential pools this is normal background noise: exits are real devices, and devices go offline mid-request. A small percentage of 502s is expected and the correct handling is an immediate retry on a new exit.

504 Gateway Timeout

The upstream took longer than the timeout allowed. Either the target is slow, or your timeout is tighter than a residential round trip warrants. Residential exits routinely add 200–400ms before the target does any work, so a 5-second total timeout is optimistic.

Errors from the target

403 Forbidden

The site refused you. The request arrived intact — this is a judgement about who you appear to be. Common causes are a flagged exit IP, headers inconsistent with the browser you claim to be, a missing cookie the site expects, or a TLS fingerprint that does not match your User-Agent.

Test whether it is the IP or the request: retry the identical request on a different exit. If it succeeds, the exit was flagged. If it fails again, your request shape is the problem and rotating forever will not help. The 403 guide walks through each layer that can produce one.

429 Too Many Requests

You exceeded the target's rate limit for that identity. Honour any Retry-After header, lower your per-exit rate, and spread load across more exits. Retrying immediately on the same exit typically extends the penalty — the 429 guide covers how to work out what is being counted.

503 Service Unavailable

Ambiguous: either genuine overload, or a polite refusal from a bot-protection layer. Check the body. A real 503 is short-lived and affects everyone; a protection page will usually say something about verifying your browser.

Quick reference

A diagnosis order that works

1. 1Reproduce with curl. Removes your application from the equation entirely.
2. 2Hit an IP echo service through the proxy. If the exit IP comes back, the proxy layer is fine and the problem is with the target.
3. 3Retry on a different exit. Distinguishes a flagged IP from a bad request shape.
4. 4Compare against a browser on the same connection. If the browser succeeds where your client fails, your headers or TLS fingerprint are the difference.
5. 5Check the response body, not just the status. Bot walls return plenty of 200s and informative 503s.

Log the status code, the exit IP, the target host and the timestamp on every request. Individual errors are rarely informative; the distribution across exits and hosts is where the answer lives.