1. What a SOCKS5 proxy actually is

A SOCKS5 proxy is a relay that forwards raw TCP and UDP traffic between you and a destination without understanding or caring what that traffic contains. It learns where you want to go during a short handshake, opens a connection there on your behalf, and then becomes a dumb pipe in both directions. SOCKS stands for “Socket Secure”, and version 5 is standardized in RFC 1928, published in 1996. The protocol has barely changed since, which is the first useful thing to know about it.

The defining property is that a SOCKS proxy sits below the application protocol. Compare it to an HTTP proxy. An HTTP proxy parses your requests: it knows about methods, headers, and the Host line, and it can cache responses, rewrite headers, or filter by URL. A SOCKS5 proxy sees none of that. It sees a byte stream and a destination address. Once the handshake is done, it has no idea whether you are speaking HTTP, SSH, SMTP, IMAP, a BitTorrent wire protocol, or a game’s custom UDP format. It just moves bytes.

That protocol-agnosticism is the whole appeal. An HTTP proxy can only carry HTTP. A SOCKS5 proxy carries anything that runs over TCP, and with one extension, anything over UDP. The cost of that generality is that the proxy gives you nothing application-specific in return: no caching, no content awareness and no encryption. More on that below.

In OSI terms, SOCKS sits around the session layer, layer 5, between transport and application. It is not a tunnel in the VPN sense. A VPN captures all of your machine’s IP traffic and wraps it. A SOCKS5 proxy handles one connection at a time, each negotiated explicitly by an application that knows it is talking to a proxy. Per-connection relay, not a system-wide redirect.

2. How the SOCKS5 handshake works

Every SOCKS5 connection begins with a short, fixed negotiation before any application data flows. There are three exchanges: method negotiation, optional authentication, and the connection request. All of it happens over a single TCP connection that the client opens to the proxy.

2.1. Method negotiation

The client opens a TCP connection to the proxy and immediately sends a greeting: a version byte (0x05 for SOCKS5), a count, and a list of authentication methods it is willing to use. The method numbers that matter in practice are 0x00 (no authentication), 0x02 (username/password), and 0x01 (GSSAPI, the Generic Security Services API, used mostly in Kerberos environments).

The proxy picks one method from the client’s list and replies with its number. If none of the offered methods is acceptable, the proxy replies with 0xFF (“no acceptable methods”) and closes the connection. It’s a negotiation, not a fixed scheme: the same proxy can serve an anonymous client and an authenticated client depending on what each one offers.

2.2. Authentication

If the chosen method is 0x00, this step is skipped entirely and the client moves straight to the connection request. If the method is 0x02, the client runs the username/password sub-negotiation defined in RFC 1929: it sends a username and password, and the proxy replies with success or failure.

This sub-negotiation is itself sent in the clear. Your proxy credentials cross the wire unencrypted unless something underneath, such as an SSH tunnel or a TLS-wrapped SOCKS endpoint, is protecting them. SOCKS5 has authentication, but it does not have confidentiality.

2.3. The connection request

With a method agreed and authentication passed, the client sends the request that actually does something. It carries four fields that matter: a command, an address type, the destination address, and the destination port.

The command (CMD) is one of three:

• CONNECT (0x01) is by far the most common. It asks the proxy to open a TCP connection to the destination. This is what happens when you route a browser, curl, or an SSH session through SOCKS5.
• BIND (0x02) asks the proxy to listen for an inbound connection on the client’s behalf, and report back the address it is listening on. It exists for protocols that need the server to connect back to the client, such as active-mode FTP. It is rarely used today.
• UDP ASSOCIATE (0x03) sets up a UDP relay. That gets its own section below.

The address type (ATYP) tells the proxy how to read the destination address: 0x01 for an IPv4 address, 0x04 for IPv6, and 0x03 for a domain name. The domain-name type is more important than it looks: when the client sends a hostname instead of a resolved IP, the proxy performs the DNS lookup. That single choice decides who sees your DNS queries, which section 6 returns to.

The proxy replies with a status code and the address and port it bound locally for the connection. After a success reply, the negotiation is over. From that point the proxy is a transparent relay: whatever the client writes goes to the destination, whatever the destination sends comes back, and the proxy inspects none of it.

3. UDP ASSOCIATE: forwarding more than TCP

SOCKS5 is the first version of SOCKS that can forward UDP, and it does so through the UDP ASSOCIATE command. This matters because a large and growing share of traffic is not TCP: DNS lookups, QUIC (and therefore HTTP/3), VoIP, WebRTC media, and most online games all ride on UDP. A proxy that only spoke TCP would be invisible to all of it.

The mechanism is slightly indirect. The client sends a UDP ASSOCIATE request over the existing TCP control connection. The proxy replies with an address and port where the client should send its UDP datagrams. For each datagram, the client prepends a small SOCKS UDP request header that names the real destination, then sends the wrapped datagram to that relay port. The proxy strips the header, forwards the payload to the destination, and relays replies back, wrapped the same way.

The TCP control connection does not carry the UDP data, but it is not idle either: it serves as the lifetime anchor for the association. When that TCP connection closes, the proxy tears down the UDP relay. This keeps UDP state, which has no connection of its own, tied to something the proxy can reliably observe ending.

The catch is implementation coverage. UDP ASSOCIATE is the least consistently implemented part of RFC 1928. Many public and commercial SOCKS5 proxies support only CONNECT and quietly reject UDP. Tor is the most prominent example: its SOCKS5 front end refuses UDP ASSOCIATE outright, because Tor circuits carry only TCP streams. So “SOCKS5 supports UDP” is a true statement about the protocol and an unreliable assumption about any specific proxy. If you need UDP, test for it instead of trusting the version number.

4. SOCKS5 vs SOCKS4

SOCKS4 and SOCKS5 share a name and not much else. SOCKS5 is a full redesign published as RFC 1928, not an incremental revision of SOCKS4. Knowing the difference is mostly useful for recognizing SOCKS4 when you trip over it in an old config or a legacy tool.

SOCKS4 supported only the CONNECT and BIND commands, both TCP-only, and only IPv4 addresses. It had no real authentication: the client sent a userid string that the proxy could match against an access list, but there was no challenge and no password. A later tweak, SOCKS4a, added exactly one capability: the client could send a hostname instead of a pre-resolved IP, letting the proxy do the DNS lookup.

SOCKS5 added four things that, together, are why it is the version everyone uses:

• Negotiated authentication. The negotiated method list means a proxy can require no-auth, username/password, or GSSAPI, and the scheme is extensible rather than fixed.
• UDP support via UDP ASSOCIATE, covered above.
• IPv6, through the 0x04 address type.
• Native domain-name addressing, built into the ATYP field rather than retrofitted the way SOCKS4a did it.

For practical purposes, SOCKS4 is legacy. When something today advertises a “SOCKS proxy”, it is almost always SOCKS5, and the rest of this post assumes that. The reason to know SOCKS4 still exists is so you recognize it as the problem when an old client cannot authenticate or cannot carry UDP.

5. SOCKS5 vs HTTP proxy vs VPN

The single most important fact about SOCKS5, and the one most often missed, is that it does not encrypt your traffic. SOCKS5 moves bytes; it does not protect them. If your connection is encrypted, that encryption came from the application (HTTPS, an SSH tunnel, a VPN underneath) and not from the proxy. Anyone who can observe the path between you and the proxy, and the proxy operator itself, sees exactly what they would see without the proxy, minus only the change of apparent source IP.

That fact decides most “should I use a SOCKS5 proxy or a VPN” questions on its own. The three tools occupy genuinely different layers:

The practical decision follows from the table:

• Reach for SOCKS5 when you want to route one application’s traffic through a different exit point without disturbing the rest of the system, and the app may speak something other than HTTP. The classic case is ssh -D into a server to reach an internal network, which section 6 walks through.
• Reach for an HTTP proxy when you specifically want application-layer behaviour: response caching, content filtering, request inspection, or header rewriting. Corporate egress proxies are the usual example. An HTTP proxy can do these things precisely because it understands HTTP; a SOCKS5 proxy cannot do them for the same reason it can carry anything.
• Reach for a VPN when you want confidentiality and integrity for all of your traffic, system-wide, and you are willing to trust the VPN operator with the whole of it.

This is also where SOCKS5’s marketing gets ahead of its design. “SOCKS5 proxy” services are often sold as a privacy tool. A SOCKS5 proxy changes your apparent IP address; it does not hide the contents of your traffic from anyone on the path to the proxy, and it certainly does not hide them from the proxy operator. Whatever is not already wrapped in TLS by the application is fully visible to whoever runs the proxy. Treat SOCKS5 as an IP-routing tool, not an anonymity tool. If you need the traffic itself protected that protection has to come from somewhere else in the stack.

6. Using SOCKS5 in practice

The most common real-world use of SOCKS5 today is not a commercial proxy subscription. It is ssh -D: dynamic port forwarding, which turns any SSH server you have shell access to into a personal SOCKS5 proxy. Most developers who use SOCKS5 use it this way without thinking of it as “using SOCKS5”.

6.1. ssh -D dynamic forwarding

ssh -D 1080 user@example-server.com

This opens a local SOCKS5 listener on port 1080. Any application you point at localhost:1080 has its TCP traffic carried through the SSH connection and out from example-server.com. The hop between your machine and the server is encrypted, but the encryption is SSH’s, not the SOCKS protocol’s. SOCKS5 here is just the local interface that applications use to hand SSH their connections.

This is the everyday use: reaching a database or internal service that only accepts connections from inside a network, or getting a clean exit point out of a hostile local network, using a server you already have.

6.2. curl, and the DNS-leak distinction

curl makes the most instructive SOCKS5 distinction easy to see. Compare these two commands:

curl --socks5 localhost:1080 https://example.com
curl --socks5-hostname localhost:1080 https://example.com

With --socks5, curl resolves example.com locally using your machine’s resolver, then sends the proxy a request with an IPv4 or IPv6 address type. With --socks5-hostname, curl sends the domain name as the address (the domain-name address type from the handshake) and the proxy does the DNS lookup.

The difference is who sees your DNS query. With --socks5, your local resolver, and whoever it reports to, sees every hostname you visit, even though the connection itself goes through the proxy. With --socks5-hostname, the lookup happens at the proxy. The same choice is available in URL form: socks5:// resolves locally, socks5h:// resolves at the proxy (the h is for hostname).

This is the single most common SOCKS5 misconfiguration: routing TCP through the proxy but leaking DNS locally. If the point of the proxy is to reach names your local DNS cannot resolve, or to keep your local network from seeing which hosts you visit, you need proxy-side resolution. Browsers expose the same switch: Firefox has a checkbox labelled “Proxy DNS when using SOCKS v5” for exactly this.

6.3. Tor’s SOCKS5 front end

Tor exposes a SOCKS5 interface, by default on port 9050, or 9150 when running inside the Tor Browser bundle. Applications send domain-name requests to it, Tor resolves them and routes the connection through a circuit. As noted earlier, this interface is TCP-only: UDP ASSOCIATE is refused, which is the underlying reason you cannot simply push arbitrary UDP traffic through Tor. Anything you route through Tor’s SOCKS5 port is carried over TCP streams or not at all.

6.4. Application-level routing

Plenty of software accepts a SOCKS5 endpoint directly in its configuration: package managers, IRC and chat clients, Telegram, BitTorrent clients, and proxychains for wrapping binaries that have no proxy setting of their own. The reason to do this instead of a VPN is precision. A SOCKS5 endpoint routes exactly one application, leaves every other connection on the machine untouched and needs no root, changing no system-wide routing table along the way.

That precision is the whole identity of the protocol. SOCKS5 is a small, stable design from 1996 that has survived nearly unchanged because it does one job, moving a single connection’s bytes to a different exit point, and deliberately refuses to do anything else. Learn the handshake and the encryption gap, and you have most of what “everything you need to know” actually amounts to.