How a SOCKS4 proxy works
Your application opens a TCP connection to the proxy instead of connecting directly to the destination.
Application → SOCKS4 proxy → 198.51.100.20:443
During setup, the client sends the SOCKS version, command, destination port, destination IPv4 address and a USERID field. For the common CONNECT command, the proxy opens a connection to the destination and reports whether it succeeded. SOCKS4 also defines BIND, which listens for an incoming TCP connection.
After the connection is accepted, the proxy relays bytes in both directions without interpreting HTTP or other application data. The destination sees the proxy’s IP address as the connection source.
SOCKS4 vs SOCKS5
SOCKS5 is the newer protocol and supports more connection types.
| Feature | SOCKS4 | SOCKS5 |
|---|---|---|
| Traffic | TCP only | TCP and UDP association |
| Destination | IPv4; hostnames via SOCKS4a | IPv4, IPv6 or hostname |
| Authentication | No standardized negotiation; cleartext USERID | Negotiated methods available |
| DNS | Usually resolved by the client | Proxy can resolve hostnames |
Original SOCKS4 requests contain an IPv4 address, so the client must perform DNS resolution first. The SOCKS4a extension lets a client send a hostname for proxy-side resolution, but it doesn’t add SOCKS5’s other features.
When SOCKS4 fits
SOCKS4 is mainly useful when existing software supports it but not newer proxy protocols. Common cases include:
- Routing a legacy application’s outbound TCP connections.
- Carrying HTTP, HTTPS or other TCP-based protocols without interpreting them.
- Testing traffic through a known IPv4 proxy endpoint.
For new deployments, SOCKS5 is usually the better choice. Use an HTTP proxy when your tool only handles web requests and needs HTTP-specific behavior.
Limits and safe use
- No UDP support: DNS clients, games and real-time applications may require UDP.
- No IPv6 destinations: the original request format provides an IPv4 destination field.
- No encryption: SOCKS4 doesn’t protect data between you and the proxy. HTTPS can still encrypt web traffic end to end.
- No standardized authentication negotiation: SOCKS4 sends a cleartext USERID field for identification. A proxy implementation may choose to validate that value, but it isn’t a negotiated username-and-password method.
A proxy changes the connection’s source IP, not your headers, cookies or browser fingerprint. Follow site terms, respect rate limits and use SOCKS4 only with applications and proxy servers you trust.
FAQ
Does SOCKS4 support UDP?
No. SOCKS4 only relays TCP connections. Use SOCKS5 if your application needs a UDP association.
Can SOCKS4 proxy HTTPS traffic?
Yes. HTTPS runs over TCP, so SOCKS4 can relay its encrypted byte stream. The TLS connection provides the encryption; SOCKS4 itself doesn’t.
Does SOCKS4 prevent DNS leaks?
Not usually. Original SOCKS4 requires the client to resolve the hostname locally, which can expose DNS requests outside the proxy. SOCKS4a can send the hostname to the proxy for resolution.