What's the difference between 403 and 407?

403 (Forbidden) means the destination server understood the request but refused it — e.g., your IP is blocked, or you don't have permission. 407 (Proxy Authentication Required) means the proxy itself wants credentials and didn't get them. 407 happens at the proxy layer; 403 happens at the origin.

Why am I getting 502 Bad Gateway through a proxy?

502 means the proxy received an invalid response from the upstream server. Three common causes: the target site is down, the target rate-limited the proxy and returned malformed data, or there's a TLS handshake failure between proxy and origin. Switch to a different proxy IP or wait 30 seconds and retry.

Is 503 a proxy problem or a target problem?

503 (Service Unavailable) is almost always a target problem — the destination site is overloaded or in maintenance. The proxy is just relaying that response. Retry with backoff (start at 5 seconds, double on each retry, cap at 5 minutes).

What does 407 Proxy Authentication Required mean?

Your proxy is configured but the credentials are missing or wrong. Verify your proxy URL includes username:password (e.g., http://user:pass@proxy.example.com:8080) or that the auth header is being passed. Most libraries strip auth headers on redirect — check the redirect chain.

Why do I get 429 only when using a proxy?

Two possibilities: (1) the proxy IP is in a rate-limited range from previous abuse, or (2) the proxy is too slow and your retries pile up faster than the target releases the rate limit. Switch to a higher-quality proxy tier or add longer backoff. See our HTTP 429 guide for the full retry strategy.

Does Cloudflare 1020 mean my proxy is bad?

Cloudflare 1020 (Access Denied) means the target site's Cloudflare WAF blocked the request based on a custom firewall rule — usually IP reputation, country, or pattern matching. The proxy IP is on Cloudflare's flag list. Use a higher-trust residential or ISP proxy.

Should I retry proxy errors automatically?

Retry 408, 429, 502, 503, 504 with exponential backoff (these are transient). Do NOT retry 400, 401, 403, 407, 415 — they're permanent client/auth errors that will fail every time. Always cap retries at 3-5 attempts to avoid cascading failures.

How do I tell if the error is from the proxy or the destination?

Send the same request without the proxy. If it succeeds, the proxy is at fault. If it fails identically, the destination is the problem. Errors specific to the proxy layer: 407, sometimes 502 (proxy → origin TLS failures). Errors specific to the destination: 401 (their auth), 403 (their IP block), 503 (their downtime).

Proxy Error Codes: Causes & Fixes (2026)

Daniel K.

Mon Apr 27 2026

Quick verdict: Proxy server errors fall into two buckets — errors from the proxy itself (407, some 502s) and errors from the destination that the proxy is just relaying (403, 404, 429, 503, 504). Knowing which side is responsible is the first debugging step. This guide covers the eight most common codes, the one-line fix for each, and which retries are safe.

Every code below has been tested through SpyderProxy's residential, datacenter, and mobile pools. Where a deep-dive guide exists for a specific error, you'll find the link inline.

Quick Reference Table

Code	Meaning	Side	Retry safe?
401	Unauthorized (target needs login)	Destination	No
403	Forbidden (IP/region/path blocked)	Destination	No (rotate IP)
407	Proxy authentication required	Proxy	No (fix creds)
408	Request timeout	Either	Yes (backoff)
415	Unsupported media type	Destination	No
429	Too many requests	Destination	Yes (backoff + rotate)
502	Bad gateway	Proxy or upstream	Yes (short backoff)
503	Service unavailable	Destination	Yes (long backoff)
504	Gateway timeout	Proxy or upstream	Yes (backoff)

HTTP 401 Unauthorized

What it means: The destination resource requires authentication and your request didn't include valid credentials. The proxy is just passing this through from the origin.

Fix: Add Authorization header (Authorization: Bearer <token> or Basic auth). If the API uses cookies or signed sessions, log in first and reuse the cookie/session token.

Don't confuse with 407. 401 is from the destination; 407 is from the proxy.

HTTP 403 Forbidden

What it means: The destination understood the request but refused it. Typical causes: your IP is on a block list, your country is geo-restricted, the URL path is forbidden, or anti-bot detection flagged the request.

Fix: Rotate to a clean residential IP, add realistic browser headers (User-Agent, Accept-Language), match TLS fingerprint to a real browser. For full debugging, see our HTTP 403 deep-dive.

HTTP 407 Proxy Authentication Required

What it means: The proxy itself wants credentials and didn't get them. Note: this comes from the proxy, not the destination.

Fix: Verify your proxy URL or config includes the username and password. Common library patterns:

# curl
curl -x http://USER:[email protected]:8080 https://api.example.com

# Python requests
import requests
proxies = {"https": "http://USER:[email protected]:8080"}
r = requests.get("https://api.example.com", proxies=proxies)

# Node fetch (with proxy-agent)
import { HttpsProxyAgent } from "https-proxy-agent";
const agent = new HttpsProxyAgent("http://USER:[email protected]:8080");
fetch("https://api.example.com", { agent });

Watch for: auth headers stripped on redirect (curl needs --proxy-anyauth; Python requests preserves them by default).

HTTP 408 Request Timeout

What it means: The proxy or destination didn't receive the complete request in time. Often a slow network, a slow client, or a stalled TCP connection.

Fix: Retry with a fresh connection. If chronic, increase timeout settings on the client side. Check the proxy region — a US client routing through an Asian proxy adds 200ms+ RTT.

HTTP 415 Unsupported Media Type

What it means: The destination understood the request but the Content-Type header is not one it accepts.

Fix: Set Content-Type explicitly to what the API expects, usually application/json for REST endpoints. Full debugging at our HTTP 415 guide.

HTTP 429 Too Many Requests

What it means: The destination's rate limiter triggered. Could be per-IP, per-account, per-endpoint, or per-API-key.

Fix: Honor the Retry-After header if present. Otherwise use exponential backoff with jitter. For sustained workloads, rotate IPs through a rotating residential pool. Full strategy in our HTTP 429 guide.

HTTP 502 Bad Gateway

What it means: The proxy got an invalid response from the upstream server. Three sub-cases:

Origin is down or restarting. Wait 30-60 seconds and retry.
TLS handshake failure between proxy and origin. Try a different proxy region or switch to HTTPS-tunneling SOCKS5.
The proxy itself is overloaded. Switch to a different IP from the pool.

Fix: Single retry after 5-10s. If 502s persist on every retry, the destination is down and you should pause the workflow.

HTTP 503 Service Unavailable

What it means: The destination server is overloaded, in maintenance, or under DDoS. Almost always the destination's problem, not the proxy's.

Fix: Long exponential backoff (start at 30s, double, cap at 10 minutes). Don't retry aggressively — you'll prolong the destination's outage and risk getting your IP flagged when service restores.

HTTP 504 Gateway Timeout

What it means: The proxy waited for a response from upstream but didn't get one in time. Different from 502 (which gets an invalid response) — 504 gets nothing at all.

Fix: Retry once with a 30-second wait. If chronic, the destination has structural problems and your scraper should switch endpoints or pause.

Cloudflare-Specific Codes (1015, 1020, 1006, 1010, 1003)

Cloudflare returns proprietary error codes for their WAF rejections. Quick reference:

1015 — rate limiting at the Cloudflare layer (similar to 429).
1020 — custom firewall rule blocked you (often IP reputation or country).
1006 / 1010 — IP banned at Cloudflare layer.
1003 — direct IP access blocked (use the domain, not the IP).

Full breakdown at our Cloudflare error codes guide. The fix is almost always: rotate to a higher-trust residential IP and match a real browser's TLS fingerprint.

How to Tell Which Side Is Responsible

The fastest debugging trick: send the same request without the proxy.

If it succeeds without the proxy → the proxy is at fault.
If it fails identically → the destination is the problem.
If you get a different error → there's a config mismatch (auth headers stripped, etc.).

Verify proxy connectivity independently with SpyderProxy's proxy checker or IP lookup. If those work, the proxy is fine; the issue is upstream.