SOCKS4 vs SOCKS5 Proxies: Key Differences

Use SOCKS5. It's the current standard, defined in RFC 1928 (1996), and it's what nearly every commercial proxy service ships today. It supports username/password authentication, UDP traffic, IPv6 destinations, and hostname resolution at the proxy.

Use SOCKS4 only when something in your stack cannot speak SOCKS5: an old client library, a legacy appliance, or a piece of software that hardcodes the SOCKS4 handshake. SOCKS4 carries IPv4 TCP connections and nothing else. No auth, no UDP, no IPv6.

For a broader look at where SOCKS fits next to HTTP proxies, see What Is a SOCKS Proxy? and SOCKS5 vs HTTP Proxies. This post stays focused on the version-to-version differences.

Every row where they differ favors SOCKS5. The one thing SOCKS4 has going for it is simplicity, and that only matters if you're implementing the protocol by hand.

SOCKS4 is a minimal relay. The client opens a TCP connection to the proxy and sends a single request describing where it wants to go:

VN=0x04  CD=0x01  DSTPORT(2 bytes)  DSTIP(4 bytes)  USERID...  NULL(0x00)

CD=0x01 is CONNECT, CD=0x02 is BIND. DSTIP is a raw 4-byte IPv4 address, which is the first hard limit: the client has to resolve the hostname to an IPv4 address itself before it can even build the request. The proxy replies with a version byte of 0x00 (not 0x04, a common parsing gotcha) and a result code, where 0x5A (90) means granted and 0x5B (91) means rejected.

The USERID field looks like authentication but isn't. There's no password, and no password exchange happens. Historically a server could cross-check that string against an ident response (RFC 1413) from the client machine, but that mechanism is effectively dead on the modern internet. In practice most SOCKS4 servers ignore USERID entirely. So when you read "SOCKS4 has no authentication," this is why: the protocol has no field for a secret and no step to verify one.

What you get with SOCKS4: outbound IPv4 TCP connections through a relay. What you don't get: any password, any UDP, any IPv6, and any way to hand the proxy a hostname to resolve.

SOCKS5 keeps the relay model and layers on the pieces SOCKS4 was missing. The handshake gains an authentication negotiation step up front, and the connect request gains an address-type field so the destination can be an IPv4 address, an IPv6 address, or a domain name.

The connect request carries an ATYP byte:

• 0x01, IPv4 address
• 0x03, domain name (the proxy resolves it)
• 0x04, IPv6 address

And a command byte:

• 0x01, CONNECT (TCP stream)
• 0x02, BIND (accept an incoming connection)
• 0x03, UDP ASSOCIATE (relay UDP datagrams)

Those two fields alone account for most of the SOCKS5 advantage. ATYP=0x03 enables remote DNS. ATYP=0x04 enables IPv6. CMD=0x03 enables UDP. None of that exists in SOCKS4. The full byte-level handshake is walked through in the SOCKS proxy explainer if you want the connection flow in detail.

This is the difference people feel first. SOCKS4 relays TCP only. SOCKS5 can relay UDP through its UDP ASSOCIATE command, which opens a side channel the proxy uses to forward datagrams.

UDP matters for a specific set of workloads:

• Online gaming, which leans on UDP for low-latency updates.
• Real-time voice and video (RTP-style media).
• DNS queries you want to send through the proxy.
• BitTorrent's DHT and peer exchange, which use UDP alongside TCP.

If any of those are in scope, SOCKS4 is disqualified before you compare anything else. One caveat worth knowing: UDP ASSOCIATE is part of the SOCKS5 spec, but plenty of commercial proxy providers only enable TCP CONNECT on their endpoints. Having SOCKS5 does not guarantee UDP is turned on. If you need UDP relay, confirm it with the provider explicitly rather than assuming the protocol version implies it.

For most buyers, socks5 authentication is the deciding difference. SOCKS4 has no authentication method, so access control has to come from somewhere else, almost always an IP allowlist. If your source IP changes or you're on a shared network, that gets fragile fast.

SOCKS5 negotiates an auth method in the opening handshake, before any application data flows. RFC 1928 defines the negotiation, and the individual methods are:

Username/password (0x02) is what commercial proxy services use almost universally. It's why a SOCKS5 provider hands you a user:pass@host:port credential set and a SOCKS4 provider can only offer IP allowlisting. One security detail: RFC 1929 sends the username and password in cleartext over the SOCKS connection, so the transport underneath has to be trusted. Your HTTPS payload is still protected by its own TLS, but the proxy credentials themselves are not encrypted by the protocol. Providers typically expose SOCKS5 on port 1080, and sometimes on 443 to slip past firewalls; the proxy ports guide breaks down those assignments.

SOCKS4 forces the client to resolve hostnames locally, because the request can only carry a 4-byte IPv4 address. That means your machine sends the DNS query, so your local resolver and ISP see every hostname you connect to, even though the connection itself goes through the proxy. That's a DNS leak by design.

SOCKS5 fixes this with ATYP=0x03: the client sends the hostname as a string and the proxy resolves it. In client tooling this is the difference between two schemes that look almost identical:

# socks5:  client resolves DNS locally (can leak the hostname)
curl --socks5 user:pass@HOST:1080 https://example.com/

# socks5h: proxy resolves DNS (recommended)
curl --socks5-hostname user:pass@HOST:1080 https://example.com/

In Python's requests, the same distinction is the h:

import requests

# socks5h:// -> hostname resolved at the proxy
proxies = {
    "http":  "socks5h://user:pass@HOST:1080",
    "https": "socks5h://user:pass@HOST:1080",
}
r = requests.get("https://example.com/ip", proxies=proxies, timeout=15)
r.raise_for_status()

Remote DNS does two useful things: it keeps your lookups off your local network, and it makes geo-targeting accurate, since the resolution happens from the proxy's location rather than yours. SOCKS4 cannot do this at all. SOCKS4a can, which is the next section.

SOCKS4's address field is exactly four bytes, so it can only express an IPv4 destination. There is no room in the protocol for an IPv6 address. If the target is IPv6-only, SOCKS4 simply cannot reach it.

SOCKS5 added ATYP=0x04 for 16-byte IPv6 destination addresses, so it connects to IPv4 and IPv6 targets alike. As more services go IPv6-first, this quietly becomes a reason SOCKS4 ages out. For the wider tradeoffs between the two address families in a proxy context, the proxy protocols overview covers where each shows up.

SOCKS4a is an informal extension to SOCKS4, not a separate RFC. It solves exactly one SOCKS4 limitation: remote DNS. The client sets the destination IP to an invalid 0.0.0.x value as a signal, then appends the hostname after the USERID field. The proxy sees the sentinel address, reads the hostname, and resolves it server-side.

That's the whole feature. SOCKS4a still has no authentication, no UDP, and no IPv6. It closes the DNS-leak gap and nothing else. It's worth recognizing because some older clients advertise "SOCKS4a" support and people assume it's close to SOCKS5. It isn't. On the socks4 vs socks5 axis, SOCKS4a is SOCKS4 with one borrowed feature.

Reach for SOCKS5 when:

• You need password authentication rather than IP allowlisting.
• You're moving UDP traffic (gaming, real-time media, DNS, torrent DHT).
• The destination is IPv6, or you want proxy-side DNS to prevent leaks.
• You want one modern protocol your tooling already speaks by default.

Reach for SOCKS4 (or SOCKS4a) only when:

• A legacy client or appliance hardcodes SOCKS4 and can't be updated.
• You're maintaining old software whose SOCKS stack predates SOCKS5.
• Access is IP-allowlisted anyway and the traffic is plain IPv4 TCP.

For web scraping specifically, note that the SOCKS version is rarely the thing that decides success. The IP type behind the proxy (datacenter, residential, or mobile) and its reputation matter far more than SOCKS4 versus SOCKS5. Pick SOCKS5 for the auth and DNS behavior, then focus on IP quality.

SparkProxy proxies speak SOCKS5, so you get authentication, IPv6 destinations, and remote DNS out of the box. There's no reason to run SOCKS4 against a modern pool. Use the socks5h:// scheme so hostnames resolve at the proxy:

curl --socks5-hostname "USER:PASS@HOST:PORT" https://example.com/

import requests

proxies = {
    "http":  "socks5h://USER:PASS@HOST:PORT",
    "https": "socks5h://USER:PASS@HOST:PORT",
}
r = requests.get("https://example.com/", proxies=proxies, timeout=30)
r.raise_for_status()

requests needs the SOCKS extra for this: pip install "requests[socks]".

If you'd rather not manage proxy protocols, rotation, and retries yourself, the SparkProxy Scraping API handles the transport for you. You send a target URL and it returns the rendered page, no SOCKS handshake on your side:

import requests

r = requests.get(
    "https://scrape.sparkproxy.io/api/v1",
    headers={"X-API-Key": "YOUR_API_KEY"},
    params={"url": "https://example.com", "render_js": "true", "country_code": "US"},
)
print(r.text)

Either path gives you SOCKS5-grade behavior. The direct proxy route keeps you in control of the connection; the Scraping API trades that control for a managed pipeline that also handles JavaScript rendering and geo-targeting.