Proxy errors are frustrating because the message rarely points at the real cause. You get a 407, an ECONNREFUSED, or a tunnel failure, and the same error can come from a typo, a wrong port, or a dead address. This is a field guide to the errors you actually hit when wiring proxies into code, what each one really means, and how to fix it fast instead of guessing.
407 Proxy Authentication Required
This is the most common and the most misread. A 407 means the proxy wants credentials and did not get valid ones. It almost never means your password is wrong in the account sense. It means the credentials did not reach the proxy in the form it expected.
- Check that your client puts the username and password where it looks for them. Some read the proxy URL, some want a separate auth object, some need a
Proxy-Authorizationheader. - If your password has special characters like
@or:, URL-encode them, or the parser splits the URL in the wrong place. - For HTTPS through an HTTP proxy, make sure auth is attached to the CONNECT request, not just the inner request.
Fix the placement and the 407 disappears without touching the account at all.
ECONNREFUSED and ETIMEDOUT
These are connection-level, before any auth. ECONNREFUSED means nothing is listening at that host and port. ETIMEDOUT means the packets went out and nothing came back.
- Double-check the host and port. A wrong port is the single most common cause of ECONNREFUSED.
- Confirm the protocol matches the port. Pointing an HTTP client at a SOCKS port, or the reverse, fails here.
- If it worked yesterday and not today on a shared pool, the address may be dead or blocked. This is where private addresses save hours, because they are not shared with strangers who can kill them.
Tunnel failed / socket hang up
For HTTPS you often see tunneling socket could not be established or socket hang up. This is the CONNECT tunnel failing. Common causes are an HTTP-only proxy being asked to tunnel in a way it does not support, a missing proxy agent in Node, or the proxy dropping the connection because the address is flagged.
- In Node, use an explicit agent such as
https-proxy-agentorhpagentrather than relying on default handling. - Confirm the proxy actually supports CONNECT for the target port.
- Retry on a fresh address. A tunnel that fails on one exit often succeeds on the next, which is the whole point of rotation.
Intermittent failures at scale
The nastiest case is when everything works in a single test and fails at volume. That is rarely a code bug. It is rate limiting: too many requests from one address in a short window, so the proxy or the target starts refusing. The fix is not more retries against the same address, it is spreading load across a rotating pool so no single exit trips the limit.
Where a clean pool removes half these errors
A lot of proxy debugging is really debugging a bad pool. Shared, oversold, or recycled addresses produce exactly the intermittent ECONNREFUSED and tunnel failures that look like code bugs. WinGate provides private proxies with SOCKS5 and standard auth, so credentials are simple and the address is yours alone, not pre-flagged by someone else. The rotating pool spreads load so the intermittent-at-scale failures stop, traffic is unlimited, and it speaks HTTP, HTTPS, and SOCKS5 so you can rule out protocol mismatches. There is a free 2 hour test, so you can point your failing setup at a clean pool and see how many of these errors were the addresses rather than your code.
The takeaway: 407 is placement, ECONNREFUSED and ETIMEDOUT are host, port, or a dead address, tunnel failures are CONNECT or a missing agent, and intermittent failures at scale are rate limits. Match the error to its real cause, retry on fresh addresses, and start from a clean private pool so you are debugging your code and not someone else's burned IPs.
Top comments (0)