SOCKS5 proxy
A proxy speaking the SOCKS5 protocol, which forwards any kind of TCP or UDP traffic without inspecting it, not just web requests.
SOCKS5 is a protocol, not a network. Where an HTTP proxy reads your request, understands it as a web request and can rewrite its headers, a SOCKS5 proxy is a blind relay: it opens a tunnel and moves whatever bytes you hand it without caring what they mean. HTTP, email, a database connection, a game protocol, a torrent. That indifference to content is the whole design, standardised in RFC 1928.
The blindness has a consequence people rarely connect. Because a SOCKS5 proxy never parses HTTP, it cannot add the headers that give HTTP proxies away. There is no Via and no X-Forwarded-For to strip, because nothing in the protocol was ever going to write them. That is not the same as being anonymous, though: your client can still leak your identity above the tunnel, and the operator still sees every byte passing through.
Over SOCKS4 it added three things that matter in practice. Authentication, so an endpoint can require a username and password (RFC 1929) instead of being open to anyone who finds it. UDP, through the UDP ASSOCIATE command, which is what lets it carry DNS lookups and real-time traffic instead of TCP alone. And IPv6 plus domain-name targets, so the proxy can resolve a hostname on your behalf.
That last one is the quiet reason to prefer it. If your client resolves the hostname locally and then asks the proxy for an IP, your DNS server has already watched you look up the destination, and the tunnel protected nothing. Handing SOCKS5 the hostname instead moves resolution to the proxy side. Most tools expose this as a separate setting, and it is off more often than people expect.
SOCKS5 also says nothing about the address behind it. Residential, datacenter, ISP, mobile: all of those can speak SOCKS5, and the protocol is silent on which you have. It describes how your client and the proxy talk to each other, not whose network the traffic appears to come from. Conflating the two is the most common mistake made with this term.
One practical note: 1080 is the conventional SOCKS port, but it is a convention rather than a rule, and providers routinely serve SOCKS on whatever port they like.
How it works
- 1.Your client opens a TCP connection to the proxy and offers the authentication methods it supports.
- 2.The proxy picks one, either no authentication or username and password, and says so.
- 3.If credentials are required, the client sends them and waits for an accept.
- 4.The client sends a CONNECT request naming the destination as an IPv4 address, an IPv6 address or a domain name, plus a port.
- 5.The proxy opens its own connection to that destination and replies with a success code.
- 6.From that point the proxy copies bytes in both directions and does not look at them again.
Frequently asked questions
Is SOCKS5 more anonymous than an HTTP proxy?
It cannot leak your address through HTTP headers, because it never parses HTTP and was never going to write one. That removes an entire category of leak the anonymity grades exist to measure. It does not make you anonymous: the operator still sees every byte that is not encrypted, and your client can still expose you above the tunnel.
Does SOCKS5 encrypt my traffic?
No. It is a tunnel, not an encrypted one. Whatever you send through it arrives in the state you sent it, so HTTPS traffic remains encrypted because it already was and plain HTTP remains readable to the operator. If you need encryption, that comes from the protocol you are speaking, not from SOCKS5.
Why do people say SOCKS5 is better for torrents and games?
Because it relays anything rather than only web requests, and because it supports UDP through the UDP ASSOCIATE command. An HTTP proxy understands one protocol and cannot carry traffic that is not that protocol, while SOCKS5 is indifferent to what the bytes mean.
What port does SOCKS5 use?
1080 by convention, though it is only a convention and providers frequently choose otherwise. Take the port from your provider's documentation rather than assuming, and never infer the protocol from the port number, since the same host commonly serves different protocols on different ports.
Do I need to change anything to avoid DNS leaks with SOCKS5?
Usually yes, and it is the setting most people miss. SOCKS5 can resolve hostnames at the exit, but only if your client sends a hostname rather than resolving locally first and handing over an address. Most clients expose this separately, often labelled remote DNS, and it is frequently off by default.
Back to the full glossary.