SOCKS4 vs SOCKS5: Key Differences

SOCKS4 is an older relay protocol with no authentication standard and no UDP. SOCKS5 modernized the handshake, added optional username/password auth, domain-name resolution, and UDP associate. Most contemporary pools and client libraries default to SOCKS5 — but you will still see SOCKS4 in legacy lists.

SOCKS4 and SOCKS5 background

SOCKS4 supports TCP connect requests with IPv4 addresses only. SOCKS5 (RFC 1928) extended the protocol for IPv6, domain names, multiple auth methods, and UDP. If your provider offers both, prefer SOCKS5 unless a downstream tool explicitly requires SOCKS4.

Authentication differences

SOCKS4 has no standardized auth in the base spec — access control is often IP-based at the proxy firewall. SOCKS5 negotiates methods including 0x00 (no auth) and 0x02 (username/password). Production pools typically require credentials on SOCKS5 endpoints.

DNS and addressing

SOCKS4 clients must resolve hostnames locally before connecting — the proxy receives only an IPv4 address. SOCKS5 can accept a domain name in the request, letting the proxy perform DNS. That matters when local DNS is unreliable or when you want consistent resolution at the egress point.

UDP support

Only SOCKS5 supports UDP associate for datagram relay. Web scraping rarely needs this, but some monitoring and gaming workloads do. For HTTP-only automation, UDP is irrelevant.

Migrating from SOCKS4

• Update client agents from socks4:// to socks5:// URLs.
• Add username/password if the new pool requires auth.
• Re-run health and latency tests — SOCKS5 endpoints may differ from SOCKS4 lists.
• Compare with HTTP vs SOCKS5 if web-only.