Read SOCKS5 Connection Failure Codes
Identify whether SOCKS negotiation, authentication, or the requested destination failed before treating every SOCKS error as a dead proxy.
A SOCKS5 server can accept your TCP connection and still reject the request to reach a destination. Read the reply in the correct stage before deciding which endpoint failed.
Method selection comes first. Username/password authentication, when selected, has its own result. Only afterward does the server return the reply for a CONNECT or another SOCKS command. A byte value from one stage cannot be interpreted using another stage's table.
Request replies identify different failures
| Reply value | Meaning in the SOCKS5 request reply |
|---|---|
| 0x01 | General server failure. |
| 0x02 | Connection not allowed by the ruleset. |
| 0x03 | Network unreachable. |
| 0x04 | Host unreachable. |
| 0x05 | Connection refused. |
| 0x06 | TTL expired. |
| 0x07 | Command not supported. |
| 0x08 | Address type not supported. |
For example, a request-level refusal is reported after reaching the SOCKS service. It is different from your operating system refusing the initial TCP connection to that service.
An address-type error can concern an IPv4, IPv6, or hostname representation. It does not automatically mean that the entire endpoint lacks SOCKS5 support. Similarly, an unsupported UDP command says nothing conclusive about a separate TCP CONNECT request.
Collect the context that makes the code useful
Keep the proxy address, command, target host and port, address family, and DNS mode with the result when writing an error report. Server-side policy logs are useful when you administer the endpoint. A ruleset rejection is a reason to inspect the applicable permission, not to increase a connection timeout.
The reply is the server's report, not a full independent diagnosis of the destination network. Client wording also varies. Record the stage and the underlying reply when available rather than relying only on a short translated error message.