Proxy errors can come from several different layers of the request path.
A failed request might originate from:
That distinction matters because changing proxies is not the correct fix for every proxy-related failure.
For example, an HTTP 407 genuinely indicates a proxy-authentication problem. A 429 usually means the destination is rate limiting traffic. A 502 can mean a gateway received an invalid upstream response, while a connection timeout may indicate network congestion, an unhealthy proxy, or excessive concurrency.
The fastest way to troubleshoot proxy problems is therefore:
Identify the failure layer → classify the error → apply the appropriate fix → measure whether it improves.
This guide covers the 10 proxy errors teams encounter most often in scraping, crawling, automation, testing, and API workflows.
| Error | What It Usually Means | First Thing to Check |
|---|---|---|
| 407 Proxy Authentication Required | Proxy credentials are missing or rejected | Username, password, IP allowlist |
| 403 Forbidden | Destination refuses the request | Access policy, session, IP reputation |
| 429 Too Many Requests | Request rate is too high | Rate limit and concurrency |
| 502 Bad Gateway | Gateway received an invalid upstream response | Proxy and upstream health |
| 503 Service Unavailable | Service is temporarily unavailable | Server load and provider status |
| 504 Gateway Timeout | Gateway waited too long for upstream | Latency, timeout settings |
| Connection Timeout | Connection or response exceeded timeout | Network path and proxy health |
| Proxy Connection Refused | Proxy endpoint cannot accept connection | Host, port, firewall |
| DNS Resolution Failure | Proxy or target hostname cannot resolve | DNS configuration |
| TLS / CONNECT Tunnel Error | HTTPS tunnel or TLS negotiation failed | Protocol, certificates, proxy type |
One important point: not every HTTP error returned while using a proxy is a proxy error.
HTTP 407 explicitly represents proxy authentication. HTTP 502 and 504 are gateway-oriented errors. Codes such as 403 and 429 commonly originate from the destination application rather than the proxy itself. HTTP specifications make these distinctions explicit.
HTTP 407 Proxy Authentication Required means the proxy server requires authentication and the client has not supplied acceptable proxy credentials.
This is one of the clearest genuine proxy-specific HTTP errors.
A proxy returning 407 should normally include a Proxy-Authenticate response header indicating that authentication is required.
Typical causes include:
First verify the proxy configuration.
For a standard authenticated proxy:
http://username:password@proxy.example.com:8080
If the provider uses IP allowlisting, verify that the actual public IP of your crawler server is authorized.
Also check:
Do not confuse:
Authorization
with:
Proxy-Authorization
They serve different authentication layers.
HTTP 403 Forbidden means the server understood the request but refuses to fulfill it.
When proxies are involved, teams often immediately assume the proxy IP has been blocked.
Sometimes that is true.
But a 403 can also result from:
A 403 is therefore not automatically proof that the proxy is bad.
Start by comparing the same request across:
If only a subset of proxy addresses fails, investigate proxy reputation or pool health.
If every connection receives the same 403, inspect:
Production systems should classify failures before rotating proxies. A structured scraper-block debugging process can help distinguish target restrictions from proxy infrastructure failures.
HTTP 429 Too Many Requests indicates rate limiting.
This is primarily a traffic-management signal, not a request to rotate proxies as fast as possible.
Common triggers include:
Reduce request pressure.
Useful controls include:
Respect Retry-After when the server provides it.
A simple retry pattern might be:
Attempt 1 → wait 2 seconds
Attempt 2 → wait 4 seconds
Attempt 3 → wait 8 seconds
Attempt 4 → wait 16 seconds
Use a maximum retry budget.
Do not allow retries to run indefinitely.
For high-volume systems, use status-aware retry strategies for 429, 403, and 5xx responses rather than treating every response identically.
HTTP 502 Bad Gateway means a server acting as a proxy or gateway received an invalid response from an upstream server.
A request path might look like:
Application
↓
Proxy Gateway
↓
Upstream Server
If the gateway receives an invalid upstream response, it may return 502.
Possible causes include:
Determine whether the problem follows:
If only one proxy IP produces 502 errors:
remove it temporarily from the active pool.
If every proxy receives 502 errors against the same target, the upstream destination may be experiencing problems.
Use controlled retries with backoff rather than immediate retry storms.
HTTP 503 Service Unavailable usually means a server is temporarily unable to handle the request.
Possible causes include:
A 503 may originate from:
First identify who generated the response.
Inspect:
If the destination is temporarily overloaded, rotating proxies will not solve the problem.
Use:
If the 503 occurs only through a particular proxy endpoint, test other proxies from the same pool.
HTTP 504 Gateway Timeout means a gateway or proxy did not receive an upstream response within the time it was prepared to wait.
Conceptually:
Client
↓
Proxy
↓
Waiting...
↓
Upstream did not respond in time
This differs from 502.
A 502 generally means the gateway received an invalid upstream response.
A 504 means the gateway did not receive the required response quickly enough.
Measure latency across:
Potential fixes include:
Do not simply increase timeout values indefinitely.
Long timeouts can hide unhealthy infrastructure and consume worker capacity.
A timeout occurs when a connection or response takes longer than the client allows.
There are two important categories.
The client cannot establish the connection quickly enough.
Possible causes:
The connection succeeds, but the response does not arrive within the allowed period.
Possible causes:
Configure explicit timeout values instead of relying blindly on library defaults.
For example:
connect timeout = 5 seconds
read timeout = 20 seconds
Then measure timeout rates per proxy.
A proxy producing repeated timeouts should enter cooldown or be removed from active rotation.
Also monitor concurrency. A proxy may look slow because your own application has saturated:
The PTW guide to proxy concurrency limits explains how client, provider, and target limits can interact.
A connection-refused error means the client reached the network destination but could not establish a connection to the proxy service.
Browser tools may display messages such as:
ERR_PROXY_CONNECTION_FAILED
Command-line tools may report:
Connection refused
Typical causes include:
Check the endpoint directly.
For example:
curl -x http://proxy.example.com:8080 https://example.com
Then verify:
Also confirm whether the provider expects:
HTTP
HTTPS
SOCKS4
SOCKS5
A SOCKS endpoint configured as an HTTP proxy may fail even though the server itself is online.
DNS failures occur when either the proxy hostname or destination hostname cannot be translated into an IP address.
Common errors include:
Could not resolve proxy
Name or service not known
DNS_PROBE_FINISHED_NXDOMAIN
There are two separate questions:
Can the client resolve the proxy?
and:
Who resolves the destination hostname?
That second question matters especially with SOCKS proxies.
With some configurations, DNS resolution occurs locally.
With others, the proxy performs DNS resolution.
For example, many SOCKS clients distinguish between:
socks5://
and remote-DNS behavior such as:
socks5h://
depending on the library.
Check:
Test separately:
nslookup proxy.example.com
and:
dig proxy.example.com
If the proxy hostname resolves but destination requests fail, investigate where target DNS resolution occurs.
HTTPS traffic through an HTTP proxy usually requires a tunnel.
The client asks the proxy to establish a connection using the HTTP CONNECT method:
Client
↓
CONNECT example.com:443
↓
Proxy
↓
TLS session with destination
Failures in this process may appear as:
ERR_TUNNEL_CONNECTION_FAILED
SSL certificate error
TLS handshake failed
Proxy CONNECT aborted
Common causes include:
First verify that the proxy supports the protocol you are using.
Then test HTTP and HTTPS separately.
For example:
curl -x http://proxy.example.com:8080 http://example.com
followed by:
curl -x http://proxy.example.com:8080 https://example.com
If HTTP works but HTTPS fails, investigate:
Do not disable certificate verification as a permanent production fix.
That removes an important security control.
This distinction is one of the most important parts of proxy troubleshooting.
Consider the full request path:
Application
↓
Local Network
↓
Proxy
↓
Internet
↓
Destination
An error can occur at every layer.
| Failure | Likely Layer |
|---|---|
| Cannot resolve proxy hostname | DNS/client |
| Connection refused | Proxy/network |
| 407 | Proxy authentication |
| TLS tunnel failure | Proxy/network/TLS |
| 502 | Gateway/upstream |
| 504 | Gateway/upstream |
| 403 | Usually destination/access policy |
| 429 | Usually destination rate limiting |
| 500 | Usually destination application |
| Timeout | Could occur across multiple layers |
Avoid treating every failed request as evidence of a bad proxy.
When errors appear in production, use the same diagnostic sequence every time.
Log:
Do not reduce everything to:
request failed
If appropriate and permitted, compare the same request through the normal network.
This helps determine whether the destination itself is failing.
Hold everything else constant.
If:
Proxy A → fails
Proxy B → succeeds
the issue may be proxy-specific.
If:
Proxy A → fails
Proxy B → fails
Proxy C → fails
Direct → fails
the problem likely exists elsewhere.
Compare failures by:
Averages can hide localized failures.
Do not use:
failure → retry immediately
Use:
failure
↓
classify
↓
appropriate response
For example:
407 → fix authentication
429 → slow down
502 → inspect gateway/upstream
504 → investigate latency
timeout → inspect network and capacity
Not every error deserves a retry.
| Error | Retry? | Recommended Response |
|---|---|---|
| 407 | Usually no | Fix credentials first |
| 403 | Conditional | Diagnose cause |
| 429 | Yes, later | Backoff and reduce rate |
| 502 | Often | Controlled retry |
| 503 | Often | Backoff |
| 504 | Often | Backoff and investigate latency |
| Connect timeout | Conditional | Try healthy proxy |
| Connection refused | Usually not immediately | Check endpoint |
| DNS failure | Conditional | Check resolver |
| TLS error | Usually no | Fix configuration |
Retry policies should also include:
Otherwise one failed request can become dozens of additional requests.
Production proxy reliability should be measured over time.
Track:
A single timeout is usually insignificant.
A timeout rate increasing from:
0.5% → 2% → 7% → 15%
is an infrastructure signal.
Good proxy performance monitoring should make these trends visible before they cause widespread job failures.
Some failures have nothing to do with IP reputation.
Rotating after every 500, 503, or authentication error wastes proxy capacity.
Immediate retries can multiply traffic and make an overloaded system worse.
403 has many possible causes.
Confirm the source before replacing proxies.
A long timeout does not repair a bad network path.
Measure latency and remove persistently unhealthy endpoints.
Many apparent proxy problems are resolver problems.
Test DNS independently.
The bottleneck may be:
The proxy cannot fix an overloaded crawler.
When a proxy request fails, check:
This sequence eliminates most proxy problems far faster than randomly switching providers or rotating addresses.
There is no universal single most common error, but HTTP 407, 403, 429, proxy connection timeouts, 502/504 gateway errors, DNS failures, and connection-refused errors are among the issues frequently encountered in proxy-backed applications.
HTTP 407 means the proxy requires authentication and the supplied proxy credentials are missing or invalid. Check username/password credentials, IP allowlisting, and proxy authentication configuration.
A 403 normally means the destination refuses the request. Possible causes include permissions, session problems, geographic restrictions, target policy, or IP reputation. It does not automatically mean the proxy is broken.
429 usually means requests are being sent faster than the destination permits. Reduce concurrency, apply backoff, and respect Retry-After when provided.
502 Bad Gateway means a server acting as a proxy or gateway received an invalid response from an upstream server. Test whether the problem follows one proxy, an entire gateway, or the destination.
A 502 indicates an invalid upstream response. A 504 indicates the gateway did not receive an upstream response within the required time.
Possible causes include an unhealthy proxy, destination latency, excessive concurrency, network congestion, or overly short timeout settings. Measure connect and read timeouts separately where possible.
It usually means the browser could not establish a connection to the configured proxy. Verify the proxy hostname, port, protocol, firewall, and provider availability.
No. Rotation is appropriate for some proxy-specific or IP-specific failures, but it will not fix incorrect credentials, DNS configuration, server-side 5xx failures, or excessive request rates.
Compare the same request through multiple proxies and, where appropriate, through a normal connection. Log errors per proxy and target. If the failure follows one IP, it is more likely proxy-specific; if it occurs across every route, investigate the destination or client configuration.
The fastest way to fix proxy problems is to stop treating every failure as the same problem.
The 10 most common proxy-related errors fall into several categories:
Each requires a different response.
A production proxy system should therefore use error classification, controlled retries, health monitoring, concurrency limits, and proxy-specific metrics rather than simply rotating to another IP whenever something goes wrong.
The objective is not to eliminate every error. It is to identify failures quickly, respond appropriately, and prevent isolated errors from becoming expensive retry storms or full pipeline outages.
Nicholas Drake is a seasoned technology writer and data privacy advocate at ProxiesThatWork.com. With a background in cybersecurity and years of hands-on experience in proxy infrastructure, web scraping, and anonymous browsing, Nicholas specializes in breaking down complex technical topics into clear, actionable insights. Whether he's demystifying proxy errors or testing the latest scraping tools, his mission is to help developers, researchers, and digital professionals navigate the web securely and efficiently.