Glossary

SOCKS4 vs SOCKS5

SOCKS4 and SOCKS5 are proxy protocols; SOCKS5 adds authentication, UDP support, IPv6, and remote DNS resolution over the older SOCKS4.

SOCKS4 and SOCKS5 are versions of the SOCKS proxy protocol, which forwards raw TCP (and, for SOCKS5, UDP) traffic without understanding the application layer. This makes SOCKS proxies protocol-agnostic - they can carry HTTP, email, torrents, game traffic, and more, unlike HTTP proxies which only handle web requests.

SOCKS5 is the newer, more capable version. Its key additions over SOCKS4 are: username/password authentication (SOCKS4 has none), UDP support (SOCKS4 is TCP-only), IPv6 addressing, and remote DNS resolution - the proxy resolves hostnames, which prevents DNS leaks that would otherwise expose your activity.

For proxy users, SOCKS5 is effectively the standard; SOCKS4 is legacy and rarely offered by commercial providers. When a service advertises "SOCKS proxies," it means SOCKS5. The authentication and remote-DNS features alone make SOCKS5 the only sensible choice for privacy-sensitive work.

Choose SOCKS5 over an HTTP proxy when you need to proxy non-web traffic or want remote DNS resolution. Choose an HTTP/HTTPS proxy for standard web scraping - it is universally supported and slightly simpler. Many providers offer the same IP pool over both HTTP and SOCKS5 ports.

One is a museum piece

SOCKS4 dates from the early nineties and does three things: it opens outbound TCP connections, it supports a rudimentary user identifier, and it works only with IPv4 addresses. It cannot resolve hostnames, cannot carry UDP and has no real authentication.

SOCKS4a added remote hostname resolution as a patch. SOCKS5, standardised in 1996, added proper authentication methods, IPv6 support, UDP forwarding and hostname resolution as a first-class feature.

There is no scenario in current practice where SOCKS4 is the right choice. If a provider offers it, the interesting question is what else in their stack is that old.

What we speak

SOCKS5 on every product, with authentication as part of the handshake:

SOCKS5 endpoints

Residential   socks5h://login_c_US:password@proxy.sotaproxy.com:10000
Static        socks5h://login:password@your-ip:50101

# The h matters: it means we resolve the hostname, not your machine.

Use socks5h rather than socks5 so DNS lookups happen on our side. This is the most common leak in scraping stacks.
SOCKS5 authentication happens during the handshake, which is why clients ask for a username and password separately from the URL.
Targeting suffixes work identically under SOCKS5 and HTTP. Only the scheme changes.
Python needs the socks extra, Node needs socks-proxy-agent, and some tools need a SOCKS-capable downloader.

Where the comparison matters

SOCKS4 is not simpler in a useful way

It lacks authentication, IPv6 and remote DNS. Simplicity here means missing features.

SOCKS5 is not more anonymous than HTTP

Both send no forwarding headers when the provider is elite. The exit address is what counts.

SOCKS5 is not automatically faster

It skips header parsing, which is negligible next to the exit device's latency.

UDP support is rarely the reason

Most proxy work is TCP. UDP matters for specific protocols and almost nothing in scraping.

See this in practice

web scraping →

Ready to use socks4 vs socks5?

SotaProxy gives you access to rotating residential, mobile, datacenter, and ISP proxies. No minimum commitment.

Get started