SOCKS5 vs HTTP proxies: what the difference actually is
Both carry your traffic; they disagree about how much they understand it. When that matters and when it does not.
Mara Lindqvist
Network engineering
28 Jul 2026 · 6 min read
An HTTP proxy speaks HTTP. It parses your request, can read and modify headers, and knows what a URL is. A SOCKS5 proxy speaks nothing in particular — it opens a TCP connection to a host and port and shovels bytes in both directions without caring what they mean.
What follows from that
- SOCKS5 carries any TCP protocol. HTTP proxies carry HTTP, plus anything you can tunnel through CONNECT.
- HTTP proxies can cache, filter and rewrite. SOCKS5 cannot, because it does not know what it is carrying.
- SOCKS5 has slightly lower overhead per connection, though not enough to notice at typical volumes.
- SOCKS5 can resolve DNS at the proxy. HTTP proxies always do, since they see the hostname.
socks5h, not socks5
The h suffix means the hostname is resolved by the proxy rather than locally. Without it your machine performs the DNS lookup, which is slower and leaks the fact that you are about to visit a site your traffic supposedly is not coming from.
For HTTPS, the difference nearly vanishes
When you request an HTTPS URL through an HTTP proxy, your client issues CONNECT and the proxy becomes a dumb tunnel. It sees the hostname in the CONNECT line and nothing else. Functionally that is SOCKS5 with a different handshake, which is why for ordinary web scraping the choice rarely matters.
When to pick SOCKS5
- Non-HTTP traffic: SMTP, IRC, game protocols, database connections.
- Clients whose CONNECT support is unreliable — some older libraries and a lot of desktop software.
- Tools that only accept a SOCKS proxy setting, which is common in the peer-to-peer and privacy tooling world.
Otherwise use HTTP on port 8000. It is the better-supported path, the error messages are more informative, and the performance difference is inside the noise floor of a residential network's latency.