Common proxy errors and how to fix them

Proxy errors look cryptic and are mostly not. A handful of failure modes cover nearly every broken proxy you will ever meet, and each one leaves a distinctive fingerprint. This is the decoder. Find your error below, and you will usually know the fix within a paragraph.

ECONNREFUSED: connection refused

Your machine reached the server, and the server actively said no. Nothing is listening on that port. Either the port number is wrong, the proxy process crashed, or the service was retired and the provider forgot to tell you.

Fix: check the port against your provider dashboard character by character. If it matches, the proxy is down and the ticket goes to the provider. This one is never a settings problem on your side.

ETIMEDOUT: connection timed out

Your request went out and nothing ever came back. Unlike a refusal, a timeout means something silently ate your packets: a firewall, an overloaded server, or an IP allowlist that does not include you.

Fix: the allowlist is the first suspect. Many providers only accept connections from IPs you registered in their dashboard. If you are testing from a new machine, a cloud server, or an online checker, that machine's IP is probably not on the list. Add it, or switch the proxy to username and password authentication. If the allowlist is fine, try again later. Overloaded free proxies time out at rush hour and recover at 4am.

407: proxy authentication required

The most honest error in the list. The proxy wants credentials and did not accept what it got, either because none were sent or because they were wrong.

Fix: send them as part of the address, user:pass@host:port. Watch out for special characters in passwords, which need URL encoding (an @ inside a password will confuse every parser on earth). Also check whether your provider issues per-proxy credentials or account-wide ones. They differ more often than you would think.

403: forbidden

Someone in the chain looked at your request and flatly refused it. Unlike a 407, which asks for credentials, a 403 is a closed door. The tricky part is working out who closed it, because both the proxy and the destination can answer with the same code.

Fix: request a different site through the same proxy. If everything comes back 403, the proxy itself is refusing you. The usual culprits are an expired subscription, a used-up bandwidth balance, or a provider that answers unauthorized IPs with 403 instead of 407, so check the dashboard and your credentials. If only one destination returns 403, the proxy is fine and that site is blocking its exit IP. That is a reputation problem, not a configuration one, and residential vs datacenter proxies explains why some addresses get refused on sight.

429: too many requests

The destination is rate limiting the address you arrive from. Your proxy works, your request was fine, there have just been too many of them recently from that exit IP.

Fix: slow down, add delays between requests, or rotate across more addresses. One catch with shared proxies: other customers' traffic counts against the same exit IP, so you can be over the limit before your first request of the day. If you see 429s on a fresh session, that is usually why, and a dedicated address or a bigger rotation pool is the way out.

ENOTFOUND: hostname not found

DNS could not turn the proxy's hostname into an address. Either the hostname is misspelled or the provider decommissioned it.

Fix: spelling first, dashboard second. Providers rotate gateway hostnames and the old ones die. Copy the current hostname fresh from the dashboard rather than from your six-month-old config file.

ECONNRESET and socket hang up

The connection opened and then the other side slammed the door mid-conversation. This is the vaguest family of errors, and it usually means one of three things: you are speaking the wrong protocol (HTTP to a SOCKS port or vice versa), the proxy kills connections it does not like, or the server is flapping under load.

Fix: try the other protocol first. Testing a SOCKS5 proxy as HTTP, or the reverse, produces exactly this signature and takes ten seconds to rule out. Our checker lets you switch protocol from a dropdown, so run it once each way.

502 and 503 from the proxy itself

The proxy answered you properly and reported that it could not do its job: 502 means it failed to reach the destination, 503 means it is at capacity. Rotating residential gateways return these when the pool has no healthy exit for your request.

Fix: not much on your end. Retry with backoff, or ask for a different exit country if your provider supports targeting. Persistent 503s on a paid plan are worth a support conversation about pool capacity.

The proxy works, but the website blocks it anyway

No error at all, just captchas or access-denied pages at the destination. The proxy is alive and its reputation is dead. The address sits on a blocklist, its datacenter origin is being flagged, or the previous renter abused it.

Fix: this is not a configuration problem, it is a shopping problem. See residential vs datacenter proxies for why some addresses get blocked on sight and what to buy instead.

A five-minute debugging routine

1. Run the proxy through the online checker and read the exact error.
2. Wrong-port and dead-server errors: verify against the provider dashboard.
3. Auth errors: re-copy credentials, check for special characters, mind the format.
4. Timeouts: think allowlist. Where are you testing from, and does the proxy know it?
5. 403s: request a second site through the proxy to learn who is refusing you.
6. Resets: flip the protocol and test again.
7. Still stuck? Test from your own machine with curl, following this guide, to rule out location-specific blocks.

Ninety percent of broken proxies fall to the first six steps. The last ten percent are genuinely the provider's problem, and the error message you collected is exactly what their support team needs to hear.