SOCKS4 vs SOCKS5: What Changed and Which Should You Use?

A brief history

SOCKS was created in the early 1990s to let machines inside corporate firewalls reach the internet through a controlled gateway. SOCKS4 became the de facto standard, and SOCKS4a later added the ability to pass hostnames. In 1996 the IETF published SOCKS5 as RFC 1928, adding features the modern internet needed. Today, SOCKS5 is what almost every provider means when they say "SOCKS proxy".

The differences at a glance

Authentication

SOCKS4 has a "user ID" field but no password, so it offers no real authentication. Access is usually controlled by IP. SOCKS5 negotiates an authentication method at the start of each connection, and username/password authentication is universally supported by SOCKS5 clients and servers (with the notable exception of Chromium-based browsers on the client side).

For commercial proxies, which almost all require credentials or IP whitelisting, this alone makes SOCKS5 the practical choice. See proxy authentication methods.

DNS resolution

With SOCKS4, the client must resolve the hostname to an IPv4 address itself and send the IP to the proxy. That means your local DNS resolver sees every domain you visit, a classic DNS leak. SOCKS4a and SOCKS5 can send the hostname for the proxy to resolve. In tools like curl, this is the difference between socks5:// (local DNS) and socks5h:// (proxy DNS).

UDP

Only SOCKS5 can relay UDP. That matters for online games, voice and video calls, QUIC-based traffic and DNS queries. Note that many commercial proxy providers advertise SOCKS5 but only relay TCP; check before buying if UDP matters to you.

IPv6

SOCKS4 can only address IPv4 destinations. SOCKS5 supports IPv6 destinations, which matters as more sites become reachable over IPv6 and if you're using IPv6 proxies.

Where you'll still see SOCKS4

• Old free proxy lists, which are full of SOCKS4 servers (another reason to avoid them; see free proxies risks).
• Legacy software that predates SOCKS5.
• Internal corporate setups that have never been updated.

Most modern clients that support SOCKS4 also support SOCKS5, so there's rarely a reason to choose SOCKS4.

Which should you use?

Use SOCKS5. It's a strict superset of what SOCKS4 can do, it supports authentication, and every reputable provider offers it. If you're choosing between SOCKS5 and HTTP proxies rather than between SOCKS versions, read SOCKS5 proxies and HTTP vs HTTPS proxies. For shopping, see best SOCKS5 proxies.

How the handshakes differ

Understanding the handshakes helps when you're debugging a proxy that "connects but doesn't work".

SOCKS4 uses a single request: the client sends the version, a CONNECT command, the destination port, the destination IPv4 address and a user ID, terminated by a null byte. The server replies with a status byte, granted or rejected. There's no negotiation.

SOCKS5 uses two or three stages:

1. Greeting: the client lists the authentication methods it supports (for example "no auth" and "username/password").
2. Method selection: the server picks one.
3. Authentication (if required): the client sends username and password.
4. Request: the client asks to CONNECT, BIND or UDP ASSOCIATE, giving the destination as an IPv4 address, IPv6 address or domain name.
5. Reply: the server confirms and reports the bound address.

If a client speaks SOCKS4 to a SOCKS5-only server (or vice versa), the connection usually fails immediately with a cryptic error. When troubleshooting, check which version your client is configured for.

Choosing in practice: a decision table

SOCKS in common tools

The Chrome limitation is the one that catches most people. See Puppeteer SOCKS5 proxy for workarounds, and proxy chains for proxychains configuration.

Migrating an old SOCKS4 setup

If you've inherited scripts or apps that still point at SOCKS4, moving to SOCKS5 is usually an afternoon's work:

1. Find every SOCKS reference. Search configuration files and code for socks4://, socks4a:// and SOCKS4, plus proxychains lines such as socks4 203.0.113.10 1080.
2. Confirm the server speaks SOCKS5. curl --proxy socks5h://host:1080 https://api.ipify.org should print the proxy's IP. If that fails while socks4a:// works, the server is SOCKS4-only and needs replacing.
3. Add real authentication. SOCKS4 relied on IP-based access control. Switch to username and password (RFC 1929) or keep a strict IP allowlist, but never leave the port open.
4. Move DNS to the proxy. Use socks5h in curl and Python, proxy_dns in proxychains, and "Proxy DNS when using SOCKS v5" in Firefox, so lookups don't leak. See DNS leaks and proxies.
5. Retest IPv6 targets, which SOCKS4 could never reach. See IPv4 vs IPv6 proxies.

Keep the old configuration for a week before deleting it, in case a forgotten client turns out to support only SOCKS4. For those, a small local converter such as gost can accept SOCKS4 from the old client and forward over authenticated SOCKS5 to your provider. The forwarding pattern is explained in proxy chains, and proxy ports explained helps if your provider runs SOCKS5 on a different port from its HTTP gateway.

FAQ

Is SOCKS5 backwards compatible with SOCKS4?

Not on the wire. They use different handshakes, although many servers accept both on the same port.

Is SOCKS4 faster?

Its handshake is slightly shorter, but the difference is negligible.

Does SOCKS5 encrypt traffic?

No. Neither version encrypts data. Use HTTPS, SSH or another encrypted protocol inside the tunnel.