SOCKS5 vs HTTP Proxies

With curl, `socks5://` resolves the hostname on your machine and sends the resulting IP address to the proxy. `socks5h://` sends the hostname and lets the proxy resolve it. The single letter changes two things that matter enormously.

First, it leaks. Local resolution means your DNS resolver — your ISP's, your cloud provider's, your office network's — sees every hostname you are collecting from. For anything competitively sensitive that is a disclosure you did not intend to make.

Second, it breaks geo-targeting. Large sites answer DNS differently by region, so resolving in Frankfurt and connecting through an exit in São Paulo can send you to a European edge node while you believe you are collecting Brazilian content. The data looks fine and is quietly wrong, which is the worst failure mode there is. Always resolve at the proxy: `socks5h` in curl, `proxy_dns` in most SOCKS libraries, and for HTTP proxies it is already the default because you send the hostname in the request.

Through an HTTP proxy, an HTTPS request begins with `CONNECT host:443`. The proxy opens a TCP connection to that host and, from the 200 response onward, relays bytes without being able to read them. Your TLS session is negotiated end to end with the destination; the proxy sees the hostname in the CONNECT line and the SNI field, and nothing else.

Through SOCKS5, the client negotiates authentication, issues a CONNECT command naming the same host and port, and gets the same opaque byte relay. The handshakes differ in shape and in a couple of round trips; the security properties are identical.

This is why the folklore that SOCKS5 is more anonymous does not survive inspection for web traffic. Inside a CONNECT tunnel an HTTP proxy is exactly as blind as a SOCKS5 proxy is. The genuine difference — that an HTTP proxy could add or rewrite headers — only applies to plaintext HTTP, which almost nothing uses any more.

The clear cases are the ones where the traffic is not HTTP. A database client speaking the PostgreSQL or MySQL wire protocol, an SSH session, an SMTP connection, a custom TCP protocol, a WebSocket connection established outside a browser: an HTTP proxy cannot carry any of them, and SOCKS5 carries all of them without knowing what they are.

UDP is the other case. SOCKS5 defines UDP association, which some clients use for DNS and for real-time protocols. HTTP proxies have no equivalent, and no amount of configuration adds one.

The subtler case is tooling that expects a system-wide proxy. SOCKS5 sits neatly under a whole process — via a wrapper, a VPN-style client, or an operating system setting — where an HTTP proxy setting is honoured only by applications that look for it. If you need everything a process does to go through the proxy rather than only its HTTP calls, SOCKS5 is the tool.

Credentials go in the URL for both: `http://user:pass@host:port` and `socks5h://user:pass@host:port`. Targeting parameters are usually appended to the username, which means an unescaped separator in a password breaks parsing in ways that look like an authentication failure. URL-encode credentials before assuming the endpoint is refusing you.

Failure messages differ usefully. An HTTP proxy answers 407 when credentials are wrong, which is unambiguous. SOCKS5 returns a one-byte status in the handshake, and most clients surface it as a generic connection error — so when a SOCKS5 endpoint fails without explanation, test the same credentials over HTTP first. That one substitution identifies the problem far faster than reading client logs.

Finally, check what your framework does by default. Several popular HTTP clients silently resolve locally when handed a `socks5://` URL and give no warning at all. Our proxy tester reports the exit address it actually observed, which is the fastest way to confirm the traffic left where you expected.