SOCKS5

An HTTP proxy understands HTTP. It reads requests, can modify headers, and only handles web traffic. SOCKS5 does none of that: it opens a tunnel and moves bytes. Whatever protocol the application speaks travels through unchanged.

The handshake, step by step

The client opens a TCP connection and sends a greeting: version byte 0x05, a count of authentication methods, then the method identifiers it supports. The server answers with the one it chose — 0x00 for no authentication, 0x02 for username and password, or 0xFF meaning none of the offered methods is acceptable, after which the connection closes.

If the server chose 0x02, a subnegotiation defined in RFC 1929 follows: a version byte of 0x01 — not 0x05, a detail that trips a surprising number of implementations — then the username length, the username, the password length and the password. The server replies with 0x01 and a status byte, where zero means success and anything else closes the connection.

Only then comes the request itself: version 0x05, a command byte (0x01 CONNECT, 0x02 BIND, 0x03 UDP ASSOCIATE), a reserved zero, an address type (0x01 for IPv4, 0x03 for a domain name, 0x04 for IPv6), the address, and a two-byte port in network order. The reply carries a status byte of its own — 0x00 success, 0x02 connection not allowed by ruleset, 0x05 connection refused by the destination. Reading that byte is how you tell a credential problem apart from a dead upstream.

SOCKS5 against SOCKS4 and HTTP

• SOCKS4 carries TCP only, over IPv4 only, with no real authentication beyond a plaintext user identifier, and it cannot pass a hostname at all until the SOCKS4a extension.
• An HTTP proxy parses and can rewrite requests, forwards only HTTP, and for TLS relies on the CONNECT method — where the hostname still crosses in plaintext before the tunnel is established.
• SOCKS5 adds negotiated authentication, IPv6, optional UDP, and remote hostname resolution, while remaining indifferent to what is inside the stream.

The DNS leak, concretely

The address type byte decides who resolves the hostname. Send 0x03 with a domain name and the proxy resolves it at the exit. Send 0x01 with an IPv4 address and you have already resolved it yourself, using whatever resolver your host network hands out — typically the real ISP’s. The result is a request that arrives from Brazil over a connection whose DNS lookup came from your office, minutes earlier, from a resolver in another country.

curl encodes exactly this distinction: the socks5:// scheme resolves locally, socks5h:// resolves at the proxy. The h is the entire difference and it is easy to omit. To prove which one you are actually using, request a unique subdomain of a zone you control and read the authoritative log — the resolver that asked is the one doing your lookups.

UDP, and why it matters on Android

UDP ASSOCIATE is advertised far more often than it is implemented. That matters more each year, because QUIC — HTTP/3 over UDP port 443 — is now the default transport for a large share of Android app traffic, and WebRTC and plain DNS are UDP as well. If the tunnel silently refuses UDP, well-behaved apps fall back to TCP and merely run slower, while others fail in ways that look like an unstable connection rather than a proxy limitation, which is why this symptom is usually misdiagnosed.

What to check before you commit

• Run curl -v -x socks5h://user:pass@host:1080 against an IP information endpoint, then run the same call with socks5:// and compare. Different behaviour means your DNS is not going where you assumed.
• Test a UDP path explicitly rather than trusting the feature list.
• Prefer username and password authentication over IP whitelisting. A whitelist breaks the moment your own egress address changes, and for a fleet behind CGNAT or a dynamic line, it changes.
• Confirm the default port. SOCKS5 conventionally listens on 1080, but provider gateways rarely do, and a refused connection is often just the wrong port.

A phone does not only make web requests. Apps use their own protocols, push notifications hold persistent connections open, and a growing share of the traffic is UDP. Routing at the device level means routing all of it — which is why a provider that only offers a browser extension cannot serve a device-level setup at all, whatever its pool size.