Proxy connection failed: diagnose the exact connection stage
The phrase proxy does not work hides several independent stages: name resolution, connection to the proxy endpoint, authentication, tunnel creation, destination connection, and TLS. The correct remedy depends on the first stage that failed. Rotating an IP or replacing equipment before identifying that boundary often does not help and may erase useful evidence.
Key points in one minute
- If the proxy Host itself cannot be resolved, authentication has not started; destination DNS is a separate stage.
- Connection refused and timeout are different observations, but neither identifies one certain cause.
- A 407 is an authentication challenge from an HTTP proxy, not a destination-account block.
- A plain HTTP request, HTTP CONNECT, and a SOCKS5 request are separate branches; a failure can involve proxy policy or destination reachability.
- Verify health against two authorized destinations while recording the failing stage and time.
Map the chain first
If Host is a domain name, the application resolves the proxy name first; a numeric Host does not need that step. The paths diverge after the TCP connection. A plain HTTP request through a forward proxy carries the destination and, when needed, Proxy-Authorization in that request. An HTTP client uses the separate CONNECT method for a tunnel, while SOCKS5 negotiates an access method, performs that method's authentication, and then sends its own CONNECT request. The client or proxy can resolve the destination name depending on the protocol and application settings. After a tunnel or relay succeeds, HTTPS performs TLS negotiation and certificate-name validation separately.
Record the exact error text and code, time, protocol, and a sanitized proxy identifier. Never attach a complete command containing a password. Before enabling verbose client logs, confirm that authorization headers and secret-bearing URLs are redacted.
DNS, refused connections, and timeouts
If the proxy hostname cannot be resolved, authentication has not started: check the Host value, local DNS, and typing. Do not confuse this with destination DNS, which the client or proxy can perform after connecting. Connection refused means the attempt reached an address but was actively rejected. A timeout means only that the operation did not complete before its deadline; filtering, routing, overload, or an unavailable node are all possible causes.
Authentication and 407
A 407 response confirms that the HTTP proxy was reachable enough to request authentication. Check the protocol, port, username, password, stray whitespace, and whether that application supports proxy authentication. Do not rotate the mobile IP to fix a 407: this status describes a proxy authentication requirement, not the exit address. A 407 alone does not reveal whether the proxy made any internal attempt to reach the destination.
SOCKS5 authentication and connection requests have their own stages and reply codes. A SOCKS reply such as host unreachable or connection refused concerns the attempt to reach the destination through the proxy and does not necessarily mean the proxy port itself is unavailable.
HTTP request, tunnel, TLS, and the destination
If a plain HTTP request through a forward proxy fails, inspect the proxy authentication exchange, proxy rules, and destination response separately. If HTTP CONNECT or a SOCKS5 connection request is denied, use the exact code, destination host and port, proxy policy, and destination reachability; the failure does not name one certain cause. Once a tunnel or relay exists, a certificate, hostname, or TLS-version error belongs to the protected destination leg. Never disable certificate validation just to obtain a green result.
One website is not the whole line
Test two authorized control destinations and the problematic service separately. If control destinations work while one website returns 403, 429, or 5xx, the proxy transport may be healthy. Respect destination policy and Retry-After; do not launch automated rotation or equipment repair from one external indicator.
Practical checklist
- 1Record the exact error code, time, and application.
- 2Verify Host and port without exposing credentials.
- 3Identify the first incomplete connection stage.
- 4Separate 407 from tunnel errors and destination responses.
- 5Compare two authorized control destinations.
- 6Do not replace equipment before a stage-level diagnosis.
Sources and documentation
This material is based on primary, official, and technical sources. The article is an original summary written for this knowledge base.