SOCKS4 vs SOCKS5: Protocol Differences and Which Version to Use

Think of SOCKS5 as SOCKS4 plus everything today's software expects: real logins with passwords, a UDP relay, IPv6 targets and the option to hand a domain name to the proxy instead of an IP. SOCKS4 can do one thing, open TCP sessions toward IPv4 hosts, and it recognises clients by a free-text user ID that nobody verifies. A small unofficial add-on called SOCKS4a let it accept hostnames, and the old branch never grew beyond that.

By 2026 you will find SOCKS4 mainly inside aging utilities and on free proxy lists. Comparing the versions down to individual bytes is still worthwhile, since that level explains everyday headaches: leaking DNS lookups, refused credentials, voice apps that never connect. Below you get both handshakes decoded, a feature matrix, the meaning of the letter "h" in socks5h and a short decision guide.

A Bit of History

SOCKS was born in the early nineties as a way to let hosts sitting behind a corporate firewall reach outside through one supervised gateway; David Koblas presented the idea in a 1992 paper. Ying-Da Lee at NEC wrote down SOCKS4 in a brief memo that never turned into an RFC, and he later sketched SOCKS4a as a tiny extension.

SOCKS5 took the formal IETF route and appeared as RFC 1928 in March 1996. Two sister documents handle sign-in: RFC 1929 describes the username-and-password exchange, and RFC 1961 describes GSSAPI, a Kerberos-flavoured option aimed at enterprise networks. Readers who want the big picture first can start with our explainer on what a SOCKS5 proxy is.

Anatomy of a SOCKS4 Request

There is no negotiation whatsoever in SOCKS4. One packet goes out, one comes back:

04 01 01 BB CB 00 71 0A 00

Read left to right: 04 is the protocol version; 01 picks CONNECT (a 02 would mean BIND); 01 BB encodes port 443; CB 00 71 0A spells 203.0.113.10; the trailing 00 closes an empty user ID. The server replies with eight bytes, and the second byte holds the verdict: 90 allows the request, 91 refuses it, while 92 and 93 signal trouble with identd, a long-forgotten service that confirmed user names on the client host.

Those four values are the entire diagnostic vocabulary. An unreachable address, a closed port and a policy ban all produce the same terse 91.

SOCKS4a and Hostnames

Vanilla SOCKS4 insists on an IPv4 address, so name lookups stay on the client. SOCKS4a sidesteps that with a hack: the client puts a deliberately bogus address of the form 0.0.0.x (x being non-zero) into the packet and tacks the hostname on after the user ID. A server aware of 4a resolves the name itself; a server that predates it just fails.

How SOCKS5 Opens a Session

SOCKS5 replaces the single packet with a short dialogue:

1. Offer. The client announces which sign-in methods it can handle. The bytes 05 02 00 02 mean version 5, two options on the table: anonymous access and login with password.
2. Pick. The server answers with its choice, for instance 05 02. A reply of FF tells the client none of its offers is acceptable.
3. Credentials. If method 02 was chosen, the client transmits its login and password in the RFC 1929 format and learns whether they passed.
4. Command. Next comes the actual instruction: 01 for CONNECT, 02 for BIND, 03 for UDP ASSOCIATE, plus a target written as an IPv4 address, a domain name or an IPv6 address.
5. Outcome. A zero byte signals success. Eight further codes pin down failures precisely, from a ruleset ban through an unreachable host to a refused connection.

The extra exchanges add a few milliseconds while the session is being set up. Once data starts moving, the two protocols behave identically and simply copy bytes between a pair of TCP sockets.

Feature Matrix

DNS: socks4, socks4a, socks5 and socks5h

Whether names are resolved locally or remotely depends on the protocol and on the client's own choice. curl makes the distinction explicit with four URL schemes:

• with socks4:// your machine looks up the name and passes an address;
• with socks4a:// the name travels to the proxy;
• with socks5:// curl still does the lookup itself, despite SOCKS5 being able to forward names;
• with socks5h:// the hostname goes to the proxy; the "h" stands for exactly that.

Local lookups cause two separate problems. First, every query lands at your ISP's resolver, which therefore keeps a list of the domains you visit. Second, CDNs choose an edge node near that resolver instead of near the proxy, so you may be served content meant for your real region. Firefox offers the same switch as a checkbox called "Proxy DNS when using SOCKS v5", and the Python requests library likewise recognises socks5h://.

UDP Outside the Spec Sheet

UDP is the headline argument for SOCKS5 and also the most overestimated one. Under UDP ASSOCIATE the client requests a relay over its TCP connection, receives an address and port for datagrams, and from then on wraps each packet in a compact SOCKS header. The relay disappears as soon as that controlling TCP session closes.

The practical snag: both ends have to implement it. Browsers never push UDP through SOCKS, many desktop programs skip the feature, and a good number of providers keep it disabled. If calls, multiplayer games or UDP-based DNS are the reason you want SOCKS5, ask the provider directly and go through our guide on UDP proxies beforehand.

Sign-In and Security

A SOCKS4 user ID is just a tag; a client may present any string it likes. That is why providers still selling SOCKS4 gate it by source IP, an arrangement that gets clumsy on cellular networks where your public address shifts all the time.

SOCKS5 brings genuine credentials, with one caveat: RFC 1929 ships the login and password in readable form. Neither generation encrypts the payload either. Secure websites remain protected by their own TLS, yet unencrypted protocols inside the tunnel can be read on their way to the proxy. On untrusted networks, put SOCKS inside SSH or a VPN. The same logic counts against random free proxies, whose lists teem with open SOCKS4 servers run by unknown people.

SOCKS5 vs SOCKS4: Which One to Choose

Default to SOCKS5. Browsers, Telegram, antidetect tools, scrapers and system-wide clients all understand it, and you get passwords, remote DNS, IPv6 and meaningful error codes. Our SOCKS5 proxies authenticate with a login and password, so they keep working on devices whose IP changes.

Fall back to SOCKS4 or SOCKS4a only when forced to: a legacy application, an embedded box or a library that predates SOCKS5. In that case pick 4a so lookups happen on the proxy, and whitelist your IP in the provider's dashboard.

Look at an HTTP proxy instead if the workload is pure web browsing and header control matters; that pairing is weighed in SOCKS5 vs HTTP proxies.