Proxy Error Codes Guide: How to Fix 407, 403, 429, 502 and Timeouts

A proxy error code tells you which layer stopped the request. 407 means the proxy doesn't recognize you, 403 and 429 usually mean the target site rejected the request, and 502 and 504 mean the connection between the proxy and the target broke down. Timeouts and "tunnel connection failed" messages follow the same logic: first find out who produced the error, then fix that layer.

This guide sorts the most common codes into three groups: authentication, target site rejections, and network/timeout errors. For each one, you'll get the typical cause, where to look first, and what it looks like in cURL and Python. The examples use the WeProxy gateway address gw.weproxy.com.tr:8989; USER and PASSWORD are the credentials from your dashboard.

Who produced the error: the proxy or the target site?

Every proxied request involves two separate connections. The first runs between the client and the proxy. The second runs between the proxy and the target site. The error code is produced on one of these two connections, and that's also where the fix belongs.

For HTTPS requests, the client first sends CONNECT example.com:443 to the proxy. If the proxy returns 200 Connection Established, the tunnel is up and every HTTP code after that comes from the target site. If the proxy fails to set up the tunnel, the error arrives in the CONNECT response: 407, 403, 502 and so on. The quickest way to see this distinction is the output of curl -v:

curl -v -x "http://USER:[email protected]:8989" https://api.ipify.org

If you see the line < HTTP/1.1 200 Connection established in the output, the proxy did its job. If the error shows up after that line, the problem is on the target side. If the response to the CONNECT line is an error, the problem is in the proxy connection. Plain HTTP (non-TLS) requests have no CONNECT; here, response headers such as Server, Via or cf-ray give away where the code came from.

As a rule of thumb:

• 407 always comes from the proxy.
• 403, 429 and CAPTCHAs are usually the target site's decision.
• 502, 503 and 504 mean the proxy couldn't reach the target or didn't get a response in time.
• Client-side errors (curl: (7), ProxyError, ERR_PROXY_CONNECTION_FAILED) appear when the proxy can't be reached at all, before any HTTP code is even produced.

407 Proxy Authentication Required

407 means the proxy won't accept the request without authentication. The code is defined in RFC 9110: the proxy sends a Proxy-Authenticate header in its response, and the client carries its credentials in a Proxy-Authorization header on the next request.

The most common causes:

1. Wrong username or password. Picking up a leading or trailing space when copying from the dashboard is very common.
2. Special characters aren't encoded. If the password contains @, :, /, # or %, it needs percent-encoding inside the proxy URL. The password p@ss is written as p%40ss in the URL. Without encoding, the client treats everything after the @ as the host.
3. The IP whitelist doesn't match. If you authenticate by IP instead of sending credentials, the IP you're connecting from must be registered in the dashboard. If your home IP has changed, or your server connects from a different IPv6 address, you'll get 407.
4. The client isn't sending credentials. Some libraries only read proxy credentials from the URL, while others require a separate parameter. Browser extensions, on the other hand, expect a pop-up prompt for password-protected proxies.
5. Plan expiry or balance. Credentials for an inactive plan won't be accepted, even if they're correct. Check your plan's status in the dashboard.

WeProxy plans let you use username/password and IP whitelist authentication together over both HTTP and SOCKS5. If you'll be using your credentials in several tools, don't write the format by hand: use the proxy format converter to switch between ip:port:user:pass and URL formats.

To encode the password safely in Python:

from urllib.parse import quote

user = "USER"
password = quote("p@ss:w0rd/1", safe="")
proxy = f"http://{user}:{password}@gw.weproxy.com.tr:8989"
proxies = {"http": proxy, "https": proxy}

403 Forbidden and 429 Too Many Requests

403 means the request was understood but refused. When you're using a proxy, it's usually produced by the target site's security layer (a WAF, bot protection or a CDN rule). When the proxy itself returns 403, it's typically during the CONNECT stage, for a port or target that isn't allowed.

Typical causes of a target-side 403 are: the IP address has a poor reputation, the IP type doesn't suit the site (for example, a site that blocks datacenter IPs wholesale), there's a country restriction, or the request headers don't look like a real browser. Switching IPs may be your first reflex, but until User-Agent, Accept-Language and cookie consistency are fixed, a new IP will get the same response.

429, on the other hand, is plainly a rate limit. It's defined in RFC 6585, and the server usually tells you how long to wait via a Retry-After header. The counter is typically kept per IP and kicks in when you send many concurrent requests from the same exit IP.

WeProxy plans have no limits on concurrent connections or threads. So when you get a 429, the side imposing the limit is almost always the target site. What to do:

• Respect the Retry-After value; if there isn't one, use exponential backoff (1, 2, 4, 8 seconds).
• Reduce the concurrency piling up on a single IP.
• Rotating the IP on every request works well for jobs that don't need a session. For jobs that do, use a sticky session; see the sticky vs rotating guide for the difference.
• For targets that require high-trust IPs, choose a rotating residential proxy, or an ISP proxy if you need a single identity over a long period.

Growing your IP pool to get around a rate limit is not a solution if it violates the target's terms of use. Automation should stay within what the target permits and follow the acceptable use rules.

502, 503 and 504: the proxy couldn't reach the target

These three codes form the "gateway" family and indicate that the proxy ran into a problem on the target side.

502 Bad Gateway: The proxy connected to the target but didn't get a valid response, or couldn't establish the connection. The target server may be down, the proxy may have failed to resolve the target domain, or the exit device in the residential pool may have gone offline mid-connection. Because residential and mobile IPs come from real devices, an occasional 502 is normal; retrying is usually enough.

503 Service Unavailable: The target server or an intermediate layer is temporarily unavailable. The target site's maintenance page or overload protection returns this code. If there's a Retry-After header, respect it.

504 Gateway Timeout: The proxy didn't get a response from the target in time. A slow API, a distant geography or a heavy page can trigger this code. Choosing an exit country close to the target server helps shorten the distance between the proxy and the target.

To tell them apart, open the same URL without a proxy as well. If you get the error without the proxy too, the problem is with the target site. If you only get it through the proxy and it clears up on retry, a single exit in the pool is having trouble. If it keeps happening, tell the support team which target, what time and which plan it occurred with.

Timeouts and connection errors

Timeouts happen at two different stages, and each one tells you something different:

• Connect timeout: The client couldn't open a TCP connection to the proxy. The gateway address is wrong, the port is closed, or the local network/firewall is blocking the connection.
• Read timeout: The connection was established but the response timed out. This is usually caused by a slow target or a long response chain.

To separate the two, give your library two separate timeout values. In Python requests, timeout=(10, 30) allows 10 seconds to connect and 30 seconds to read. If you pass a single value, both stages use it and diagnosis becomes harder.

If the proxy can't be reached at all, check the local side first: use the port checker tool to confirm that port 8989 on gw.weproxy.com.tr appears open from the outside, then check that your own network allows outbound traffic to that port. Corporate networks and some cloud providers block outbound traffic to non-standard ports.

In browsers, the same situation shows up under different names. Chrome shows ERR_PROXY_CONNECTION_FAILED when it can't connect to the proxy, and ERR_TUNNEL_CONNECTION_FAILED when it connects to the proxy but can't set up the tunnel. Behind the second one, there's a proxy response such as 407 or 502.

Error code reference table

curl: (35) most often appears when you try to connect to an HTTP proxy using the https:// scheme. The scheme in the proxy URL describes the proxy's protocol, not the target's. Even for HTTPS targets, the proxy address is written with http://.

SOCKS5 error replies

SOCKS5 doesn't use HTTP codes. Under RFC 1928, the proxy answers a connection request with a "reply" field. Libraries usually display this value as a message:

Authentication is a separate step in SOCKS5 (RFC 1929). If the username/password is rejected, the connection closes with a message along the lines of "authentication failed"; this is the equivalent of 407 in HTTP. To have DNS resolved on the proxy side, use socks5h:// instead of socks5://; otherwise you'll get a DNS leak. Details are in the DNS leak guide, and the protocol differences are covered in HTTP vs SOCKS5.

Catching errors and retrying in Python

requests raises proxy errors as distinct exception types. Catching them all with a single except wipes out your diagnosis. The example below retries with backoff on transient codes (429, 502, 503, 504) and reports permanent errors separately:

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

proxy = "http://USER:[email protected]:8989"

retry = Retry(
    total=5,
    backoff_factor=1,
    status_forcelist=[429, 502, 503, 504],
    allowed_methods=["GET", "HEAD"],
    respect_retry_after_header=True,
)

session = requests.Session()
session.mount("http://", HTTPAdapter(max_retries=retry))
session.mount("https://", HTTPAdapter(max_retries=retry))
session.proxies = {"http": proxy, "https": proxy}

try:
    r = session.get("https://api.ipify.org?format=json", timeout=(10, 30))
    print(r.status_code, r.text)
except requests.exceptions.ProxyError as e:
    print("Proxy rejected the request or is unreachable (407 / connection):", e)
except requests.exceptions.ConnectTimeout:
    print("Timed out connecting to the proxy: check the port and firewall")
except requests.exceptions.ReadTimeout:
    print("Target didn't respond: change the read timeout or exit country")
except requests.exceptions.SSLError as e:
    print("TLS error: check the proxy scheme", e)

For HTTPS targets, 407 doesn't arrive as an HTTP response; it comes inside a ProxyError with the message "Tunnel connection failed: 407". Don't add 407 to the retry list: retrying with wrong credentials won't change the result. For examples in more languages, see the Python integration and Node.js integration pages.

Step-by-step troubleshooting order

1. Note your IP address without the proxy using the My IP tool.
2. Confirm that the gateway port is reachable with the port checker tool. If it isn't, the problem is on your local network.
3. Request your IP through the proxy with curl -v -x ... https://api.ipify.org. If the IP returned is the proxy exit, authentication and the tunnel are working.
4. Repeat the same command with the target URL. If the error is in the CONNECT response, look at the proxy side; if it comes after the tunnel, look at the target side.
5. Separately confirm that the proxy is working in general with the proxy checker.
6. For 429 and 403, review concurrency, headers and IP type. For 502/504, test without the proxy and separate the read timeout.
7. If the problem persists, contact the support team with the target URL, error code, time (with timezone) and plan name. Attaching your curl -v output, with the password removed, speeds up diagnosis.

Most proxy errors fit into three sentences: 407 is about credentials, 403 and 429 are the target's decision, and 5xx errors and timeouts are about the path between the proxy and the target. Once you tie an error to the right layer, you can make the right call between switching IPs, fixing your password, or waiting.