Proxy Error Codes Explained: How to Fix 403, 407, 502, 504

Proxy error codes are diagnostic signals, not dead ends. Every error tells you exactly where in the request chain something broke — whether the issue is authentication, the proxy gateway, the target server, or the network path between them. The problem is that proxy errors are often ambiguous: a 502 from a proxy means something entirely different from a 502 from the target site, and confusing the two sends you down the wrong debugging path.

The critical distinction: errors generated by the proxy infrastructure versus errors forwarded from the target. When your proxy provider's gateway rejects your request, it generates its own HTTP error. When the proxy successfully connects to the target but the target returns an error, the proxy forwards that error back to you. Some providers add custom headers (like X-Proxy-Error or Via) that identify whether the error originated at the proxy layer. Check these headers first — they immediately narrow the problem space by half.

This guide covers every proxy error code you will encounter in production, what causes each one, and specific steps to resolve them. Bookmark it. You will need it at 2 AM when your scraping pipeline throws 504s and your dashboards go red.

A 407 means the proxy gateway rejected your credentials or received no credentials at all. This error always originates from the proxy — the target server never sees your request because the proxy stops it before forwarding.

Common causes and fixes:

• Missing credentials — Your HTTP client is not sending the Proxy-Authorization header. Some libraries require explicit proxy auth configuration separate from setting the proxy URL. Verify your client is actually sending the header by capturing outbound traffic with a local packet analyzer or enabling verbose/debug logging.
• Wrong format — Credentials should be Base64-encoded in the format username:password. If your password contains special characters like @, :, or #, they must be URL-encoded when embedded in a proxy URL (%40, %3A, %23). The character @ is the most common culprit because it conflicts with the user:pass@host URL syntax.
• Expired or revoked credentials — Check your proxy provider dashboard to confirm the credentials are still active. Some providers expire credentials after inactivity periods or when billing lapses.
• IP whitelisting mismatch — If using IP-based authentication, your current public IP might have changed. Run curl ifconfig.me to check your outbound IP and compare it to your whitelisted addresses. VPNs, ISP rotations, and load balancers all change your outbound IP silently.
• Wrong port — Some providers use different ports for different authentication methods or proxy types. Verify you are connecting to the correct port for your auth method.

A 403 is the most misdiagnosed proxy error because it has two completely different causes depending on where it originates. You need to determine the source before attempting any fix.

403 from the proxy means the proxy gateway is refusing to process your request. Causes include: your account has exceeded its bandwidth or request quota, the target domain is on the provider's restricted list (some providers block requests to banking, government, or specific protected sites), or your subscription tier does not include the proxy type or geo-location you requested.

403 from the target site means your request reached the target but was rejected. This is the more common scenario and indicates active bot detection. Causes and fixes:

• IP reputation — The proxy IP has been flagged by the target site. Rotate to a fresh IP. If you consistently get 403s across many IPs, the detection is fingerprint-based, not IP-based.
• User-Agent blocking — Missing, outdated, or obviously non-browser User-Agent strings trigger 403s on many sites. Use a current browser User-Agent and ensure it is consistent with your other headers.
• Geographic restriction — The target site blocks traffic from the proxy IP's country. Switch to a proxy in an allowed region.
• Missing headers — Some sites require specific headers (Accept, Accept-Language, Referer) and return 403 when they are absent. Compare your request headers to those sent by a real browser using developer tools.
• Rate-triggered block — You have exceeded the target's request threshold and been blocked. Slow down and rotate IPs more aggressively.

A 502 means an intermediary (your proxy) received an invalid response from the upstream server (the target). In proxy contexts, this typically means the proxy established a connection to the target server, but the target's response was malformed, incomplete, or the connection dropped mid-transfer.

Proxy-side 502 causes:

• DNS failure — The proxy could not resolve the target hostname. This happens when the target domain has recently changed DNS records and the proxy's DNS cache is stale, or when the domain simply does not exist. Verify the target URL is correct and the domain resolves from a regular connection.
• Connection refused by target — The proxy resolved the hostname and attempted a TCP connection, but the target server refused it. The target may be down, blocking the proxy's IP at the firewall level, or not accepting connections on the expected port.
• Target dropped the connection — The TCP handshake succeeded, but the target closed the connection before sending a complete HTTP response. This often indicates server-side rate limiting that kills connections rather than returning proper HTTP error codes.
• SSL handshake failure — The proxy could not complete the TLS handshake with the target. This can happen when the target uses certificate pinning, requires specific TLS versions, or the proxy's exit node has outdated TLS libraries.

Fixes: First, verify the target site is accessible from a direct connection (no proxy). If it is, the issue is between the proxy exit node and the target. Try a different proxy IP, a different geographic region, or a different proxy type. If 502s persist across multiple IPs and regions, the target may be blocking your proxy provider's IP ranges at the network level.

A 504 tells you the proxy waited for a response from the target server and gave up before one arrived. The request was sent, the target is presumably processing it, but the proxy's timeout threshold was exceeded. This differs from a 502 in an important way: a 502 means a bad response was received, while a 504 means no response was received within the allowed time.

Common causes:

• Target server is slow — The target is under heavy load or the requested page requires significant server-side processing (complex search queries, large database lookups). The page would eventually load, but not within the proxy's timeout window.
• Proxy timeout too low — Your proxy provider has a default timeout (often 30-60 seconds) that may be insufficient for slow targets. Some providers allow you to configure timeout values via request parameters or dashboard settings.
• Geographic distance — The proxy exit node is far from the target server, adding round-trip latency that pushes total response time past the timeout. A residential proxy in Brazil connecting to a server in Japan adds significant base latency.
• Connection queuing — The proxy or target has reached its connection limit, and your request is waiting in a queue. Under high concurrency, queuing delays stack up and eventually trigger timeouts.

Fixes: Increase your client-side timeout to match or exceed the proxy's timeout. If the provider allows configuring proxy-side timeouts, increase them for slow targets. Reduce concurrency to prevent connection queuing. Use proxy exit nodes geographically close to the target server. If a specific page consistently times out, it may require a direct connection or a different approach entirely.

These two errors both indicate overload, but from different perspectives.

429 Too Many Requests comes from the target site's rate limiter. You have sent more requests than the target allows within its rate window. The response often includes a Retry-After header specifying how many seconds to wait before trying again. This error is almost always triggered by scraping too aggressively from too few IPs.

Fixes for 429:

• Increase your IP rotation rate — distribute requests across more IPs so each IP stays under the rate limit.
• Add delays between requests. If the Retry-After header is present, respect it.
• Implement exponential backoff: after a 429, wait 2 seconds, then 4, then 8 on consecutive 429s from the same target.
• Check whether the rate limit is per-IP, per-session, or per-account. Session-based limits require rotating sessions, not just IPs.

503 Service Unavailable means the server cannot handle the request right now. It might be overloaded, undergoing maintenance, or deliberately throttling traffic. In proxy contexts, 503 can also come from the proxy provider itself when their infrastructure is overloaded or a specific proxy pool is exhausted.

Fixes for 503: If from the target, reduce request rate and retry after a delay. If from the proxy provider, try a different proxy endpoint, region, or proxy type. Check the provider's status page for known outages. If 503s are intermittent, implement retry logic with jitter — staggered retries prevent thundering herd problems where all your threads retry simultaneously.

These errors occur below the HTTP layer — no HTTP response is received at all. They indicate TCP connection failures between your client and the proxy, or between the proxy and the target.

ECONNREFUSED — The proxy server actively rejected your connection. The proxy host is reachable, but nothing is listening on the port you connected to. Causes: wrong port number, proxy service is down, firewall blocking your IP at the TCP level. Fix: verify the proxy hostname and port are correct. Test with curl -v -x http://proxy:port http://example.com to see the raw connection attempt. If the port is correct, the proxy service itself may be down — check the provider's status page.

ETIMEDOUT — Your client waited for a TCP connection to the proxy and no response came. The proxy host is unreachable or a firewall is silently dropping packets. Causes: wrong hostname, DNS resolution failure for the proxy host, network-level blocking between you and the proxy, proxy server is completely down. Fix: verify DNS resolution of the proxy hostname with nslookup. Try connecting from a different network. Check if a corporate firewall or VPN is blocking outbound connections on the proxy port.

ECONNRESET — The connection was established but then forcibly closed by the remote side. Causes: the proxy server crashed mid-request, a network device (firewall, load balancer) between you and the proxy terminated the connection, or the proxy's connection to the target was reset and it propagated the error. Fix: retry the request. If ECONNRESET is persistent, check for network devices that might be inspecting and terminating proxy traffic. Some corporate firewalls terminate connections that look like proxy tunnels.

TLS errors through proxies are confusing because there are two separate TLS connections involved: your client to the proxy (if using HTTPS proxy endpoints) and the proxy to the target (for HTTPS targets). A TLS error could originate at either layer.

Certificate verification failed — Your client cannot verify the proxy's or target's SSL certificate. Through a CONNECT tunnel, your client performs TLS directly with the target, so certificate errors usually relate to the target, not the proxy. Causes: the target's certificate expired, is self-signed, or your system's CA certificates are outdated. Fix: update your CA certificate bundle. In development, you can disable certificate verification (verify=False in Python requests), but never do this in production — it enables man-in-the-middle attacks.

SSL handshake failure — The client and server could not agree on TLS parameters. Causes: your client requires TLS 1.3 but the proxy or target only supports TLS 1.2, cipher suite mismatch, or the proxy's exit node has outdated SSL libraries. Fix: check which TLS versions your client supports and compare with the proxy and target requirements.

SSL tunnel errors — These occur specifically with HTTPS targets when the proxy's CONNECT tunnel setup fails. The proxy might not support CONNECT, might block CONNECT to certain ports, or might require different authentication for CONNECT tunnels. Fix: verify the proxy endpoint supports HTTPS targets. Some providers use separate ports or endpoints for HTTP versus HTTPS traffic. Check provider documentation for CONNECT tunnel configuration.

When a proxy request fails, work through this diagnostic sequence to isolate the cause systematically instead of guessing:

Step 1: Can you reach the proxy?
Test a basic TCP connection to the proxy host and port. If this fails (ECONNREFUSED, ETIMEDOUT), the problem is between you and the proxy. Check hostname, port, DNS, firewall, and VPN settings. The target site is irrelevant at this stage.

Step 2: Does authentication succeed?
If the proxy is reachable but returns 407, fix your credentials. Check format, encoding, IP whitelist, and account status. Nothing else matters until auth works.

Step 3: Can the proxy reach the target?
Test with a simple, reliable target like http://httpbin.org/ip. If this works but your actual target fails, the problem is target-specific. If even simple targets fail with 502 or 504, the proxy's outbound connectivity has issues — contact the provider.

Step 4: Is the target blocking you?
If simple targets work but your target returns 403 or serves CAPTCHAs, the target's anti-bot system is blocking you. Try a different proxy IP, improve your request headers, reduce request rate, or switch proxy type.

Step 5: Is it intermittent?
If the same request sometimes succeeds and sometimes fails, track the error pattern. Random failures across many IPs suggest provider instability. Failures that correlate with specific IPs suggest those IPs are banned or unhealthy. Failures that increase over time suggest the target is progressively blocking your traffic pattern.

At each step, change only one variable at a time. Changing the proxy, the target, and the headers simultaneously makes it impossible to identify which change fixed the problem.

Production proxy pipelines need error handling that diagnoses and recovers from failures automatically, without human intervention at 2 AM.

Classify errors into categories:

• Retry-immediately — ECONNRESET, 502, 503. These are often transient. Retry once with a fresh proxy IP.
• Retry-with-backoff — 429, 504, ETIMEDOUT. These indicate overload. Wait before retrying, increasing the wait on each consecutive failure.
• Rotate-and-retry — 403 from target. The current IP or fingerprint is detected. Switch IP, update headers, then retry.
• Fix-and-retry — 407, ECONNREFUSED. These require configuration changes (credentials, port, hostname) before retrying.
• Abort — Persistent 403 across many IPs, consistent SSL errors, provider account suspension. These require investigation and cannot be resolved by automated retries.

Set per-error retry limits. Three retries for transient errors, one retry for auth errors (if it fails twice, your credentials are wrong, not temporarily glitchy), and zero retries for abort-class errors. Log every error with the full context: timestamp, proxy IP used, target URL, error code, response headers, and retry count. This log is your primary diagnostic tool when patterns of failures emerge.

Implement circuit breakers for target domains. If a domain returns errors on more than 30% of requests within a 5-minute window, pause requests to that domain and recheck after a cooldown period. This prevents burning through proxy bandwidth on a target that is actively blocking you or experiencing an outage.