Proxy Error Codes: 407, 403, 429, 502 and 504 Fixed

Proxy error codes tell you where a request failed: at the proxy (407), at the target site (403, 429), or in the gateway hop between them (502, 504). Fix the right layer and most errors disappear. This guide explains what each code means, who sent it, and the first fix to try, with a retry snippet you can drop into a scraper. It applies to any provider, including BuyProxy's residential proxies.

Proxy Error Codes at a Glance

407 Proxy Authentication Required

A 407 means the proxy itself rejected your credentials before your request ever reached the target. Per MDN, the proxy answers with a Proxy-Authenticate header and expects you to repeat the request with a Proxy-Authorization header. In practice the cause is almost always one of these:

• A typo in the username or password, or an unescaped special character in the password inside the proxy URL.
• The wrong host or port for the proxy line you generated.
• Your client sending credentials to the wrong place, such as setting them for the target site instead of the proxy.
• Targeting parameters in the username that were edited by hand and no longer parse.

Test the line on its own first with curl -x "http://USER:PASS@HOST:PORT" https://api.ipify.org. If that works and your code does not, the problem is in your client configuration. Our setup guide shows working configuration for Python, Node and cURL.

403 Forbidden

A 403 from the target means it understood the request and chose to refuse it. It is a block, not necessarily a permanent ban, and the usual cause is that the site distrusts either the IP or the request fingerprint. Work through the layers in order:

1. IP type. Hosting ranges are widely flagged. If you are on datacenter IPs, switch to residential; see residential vs datacenter proxies.
2. Rotation. Request a fresh IP and try again. If a new IP succeeds, the old one was flagged.
3. Trust tier. For strict targets, a higher-trust pool such as Premium Residential may be justified.
4. Request fingerprint. Send realistic headers (user agent, accept-language) and make sure your TLS and HTTP behaviour looks like a normal browser. A clean IP cannot rescue a request that looks like a script.
5. Geography. Some content is restricted by country, so confirm the exit location matches what the page expects.

429 Too Many Requests

A 429 means you hit a rate limit, and MDN notes that limits can apply per IP address, per user or across the whole server. The response may carry a Retry-After header telling you how long to wait, in seconds or as a date. Fix it in three steps:

• Back off. Wait for the time in Retry-After if present, otherwise use exponential backoff.
• Cap concurrency. Fewer parallel requests per domain keeps you under per-IP limits.
• Rotate. Because limits are often counted per IP, a rotating pool gives each request a fresh quota. See how rotating residential proxies work for when to rotate and when to stick.

Note that the BuyProxy management API has its own limit of 60 requests per minute per key, separate from proxy traffic. It only applies to calls such as generating lines or checking balances, and the rate limits docs explain how to handle it.

502 Bad Gateway and 504 Gateway Timeout

Both codes come from a gateway, and the difference is what the gateway got back. A 502 means it received a response from the upstream server but the response was invalid. A 504 means it received no response at all within its timeout, as MDN explains. Causes include a target that is down or overloaded, a slow exit connection, or a TLS failure between the proxy and the target. Because residential exits run over consumer connections, an occasional slow or dead exit is normal.

Retry with a new IP, wait a few seconds between attempts, and raise your client timeout if the target is genuinely slow. If one target returns these errors constantly while others work, the problem is that target rather than your proxy.

A Retry Wrapper That Handles All of Them

This function retries transient failures with backoff, honours Retry-After, and refuses to retry credential errors, since repeating a 407 can never succeed. It assumes a rotating proxy, so each retry gets a fresh IP.

import random
import time

import requests

PROXY = "http://USER:PASS@HOST:PORT"
PROXIES = {"http": PROXY, "https": PROXY}
RETRY_STATUS = {429, 502, 503, 504}


def fetch(url, attempts=5):
    for attempt in range(attempts):
        try:
            r = requests.get(url, proxies=PROXIES, timeout=30)
        except requests.exceptions.ProxyError:
            # Includes failed proxy auth (407) when tunnelling HTTPS: do not hammer it.
            raise
        except requests.RequestException:
            time.sleep(2 ** attempt + random.random())
            continue

        if r.status_code in RETRY_STATUS:
            wait = r.headers.get("Retry-After", "")
            delay = int(wait) if wait.isdigit() else 2 ** attempt + random.random()
            time.sleep(delay)
            continue
        return r
    raise RuntimeError(f"gave up on {url}")

For repeated 403s, retrying is the wrong tool: change the IP type or the request fingerprint instead. And if you want to know how reliable your setup actually is, the proxy testing guide has a benchmark script that logs every failure code.

Frequently Asked Questions

Q: What does a 407 proxy error mean?
The proxy rejected your credentials before forwarding the request. Check the username, password, host and port, and make sure your client sends the credentials to the proxy rather than the target.

Q: Why do I get 403 errors even with a proxy?
The target is refusing the request, usually because it distrusts the IP type or the request fingerprint. Datacenter IPs are widely flagged, so try residential, rotate the IP, and send realistic browser headers.

Q: How do I fix a 429 Too Many Requests error?
Slow down, cap concurrency per domain, honour the Retry-After header if present, and rotate IPs so each request gets a fresh per-IP quota.

Q: What is the difference between 502 and 504?
A 502 means the gateway got an invalid response from the upstream server. A 504 means it got no response in time. Both are usually fixed by retrying through a different IP.

Q: Should I retry every failed request?
No. Retry transient failures such as 429, 502 and 504 with backoff, but do not retry 407, since the credentials will still be wrong, and change your approach rather than retrying repeated 403s.

Summary

Read the code first: 407 is a credentials problem at the proxy, 403 and 429 come from the target, and 502 and 504 come from a gateway that could not get a good response. Fix credentials, switch IP type or rotate, back off on rate limits, and retry gateway errors through a fresh IP.

Get residential proxies from $0.99/GB on BuyProxy →