Understanding the SOCKS4 Protocol
SOCKS4 was introduced in 1990 by David Koblas as a way to route TCP connections through a firewall transparently. Unlike HTTP proxies that understand and manipulate HTTP traffic, SOCKS4 operates below the application layer — it creates a TCP tunnel without knowing or caring what protocol is being used inside it.
How SOCKS4 Differs from HTTP Proxies
The fundamental difference is protocol awareness. An HTTP proxy reads HTTP requests, understands methods, headers, and URLs. A SOCKS4 proxy sees only TCP connection requests — it knows the destination IP and port, but nothing about the data flowing through the connection.
This means SOCKS4 can proxy any TCP-based protocol: HTTP, HTTPS, SMTP, FTP, SSH, database connections, and more. The trade-off is that SOCKS4 cannot perform HTTP-specific operations like caching, content filtering, or header modification.
The SOCKS4 Handshake
The SOCKS4 protocol uses a compact binary handshake, not text-based HTTP. Here is the exact byte-level flow:
**Client request (variable length):** | Byte | Field | Value | |------|-------|-------| | 0 | Version | 0x04 | | 1 | Command | 0x01 (CONNECT) or 0x02 (BIND) | | 2-3 | Dest Port | Network byte order (big-endian) | | 4-7 | Dest IP | IPv4 address | | 8+ | User ID | Null-terminated ASCII string |
**Proxy response (8 bytes):** | Byte | Field | Value | |------|-------|-------| | 0 | Version | 0x00 | | 1 | Status | 0x5A = granted, 0x5B = rejected | | 2-3 | Port | Ignored (set to 0) | | 4-7 | IP | Ignored (set to 0) |
After a successful handshake (status 0x5A), the proxy becomes a transparent TCP relay. Every byte sent by the client is forwarded to the server and vice versa.
SOCKS4a: DNS Resolution Fix
The original SOCKS4 specification requires the client to resolve hostnames before connecting. This creates a problem: DNS queries from the client can leak the target hostname to the local network, defeating the purpose of using a proxy for privacy.
SOCKS4a solves this by allowing the client to set the destination IP to an invalid address (0.0.0.x where x > 0) and append the hostname after the null-terminated user ID field. The proxy then performs DNS resolution on behalf of the client.
Authentication Model
SOCKS4's authentication is minimal. The client sends a "user ID" string, but this is not a password — it is transmitted in cleartext and there is no challenge-response mechanism. For any deployment requiring real authentication, SOCKS5 with username/password is the better choice.
When to Use SOCKS4 vs SOCKS5
SOCKS4 is largely a legacy protocol today. SOCKS5 supports everything SOCKS4 does, plus UDP, IPv6, proper authentication, and better error handling. The only reasons to use SOCKS4 are:
- Your client or application only supports SOCKS4 (increasingly rare)
- You need the absolute minimal protocol overhead
- You are working with legacy infrastructure that predates SOCKS5
For all new deployments, Hex Proxies recommends SOCKS5.
Using SOCKS4 with Hex Proxies
Hex Proxies supports SOCKS4 connections through the gateway at `gate.hexproxies.com`. While we recommend SOCKS5 for new integrations, SOCKS4 compatibility is maintained for clients with legacy requirements. All Hex Proxies proxy types — residential, ISP, datacenter, and premium residential — accept SOCKS4 connections.
Migration Path to SOCKS5
If you are currently using SOCKS4, migrating to SOCKS5 is straightforward. The handshake structure is similar, and most client libraries that support SOCKS4 also support SOCKS5. The main change is adding a proper authentication negotiation phase. Hex Proxies uses the same gateway and credentials for both SOCKS4 and SOCKS5, so switching is a one-line configuration change in most clients.
Protocol Comparison Summary
SOCKS4 is a lightweight, fast protocol for TCP proxying with minimal overhead. It lacks the security and feature completeness of SOCKS5 but remains useful for legacy integrations and low-overhead scenarios. For modern proxy workflows, especially those involving UDP traffic, IPv6, or authenticated access, SOCKS5 is the recommended alternative.