v1.9.4-99ab90b
← Back to Hex Proxies

SOCKS4 Proxy Protocol

SOCKS4 is a transport-layer proxy protocol that routes TCP connections through a proxy server without understanding the application-level protocol. It provides basic TCP proxying with IP-based authentication.

Technical Details

SOCKS4 operates at Layer 5 (Session Layer) of the OSI model, sitting between the transport and application layers. Unlike HTTP proxies, SOCKS4 is protocol-agnostic for TCP — it does not parse or understand the data being transmitted. SOCKS4 connection handshake: 1. Client connects to the SOCKS4 proxy on the designated port (typically 1080) 2. Client sends a connection request packet: - Version: 0x04 (SOCKS4) - Command: 0x01 (CONNECT) or 0x02 (BIND) - Destination port: 2 bytes - Destination IP: 4 bytes (IPv4 only) - User ID: null-terminated string 3. Proxy attempts to connect to the destination 4. Proxy responds with a status packet: - Version: 0x00 - Status: 0x5A (granted) or 0x5B (rejected/failed) - Reserved bytes 5. If granted, the proxy relays TCP data bidirectionally SOCKS4a extension: The original SOCKS4 requires the client to resolve the hostname to an IP before connecting. SOCKS4a adds DNS resolution at the proxy by setting the IP to 0.0.0.x (where x is non-zero) and appending the hostname after the user ID. This allows the proxy to perform DNS resolution, preventing DNS leaks. Protocol limitations: - IPv4 only — no IPv6 support - TCP only — no UDP support - No password authentication — only user ID (not a secure credential) - No encryption — traffic is transmitted in cleartext - No error reporting beyond grant/reject

Advantages

  • Protocol-agnostic — works with any TCP-based application protocol
  • Simpler than SOCKS5 — lower implementation overhead
  • No application-layer parsing — lower latency for raw TCP
  • Widely supported in legacy tools and applications
  • SOCKS4a extension enables proxy-side DNS resolution
  • Minimal handshake — fast connection establishment

Disadvantages

  • No UDP support — cannot proxy DNS, VoIP, or game traffic
  • IPv4 only — incompatible with IPv6 networks
  • No password authentication — user ID is not a secure credential
  • No encryption — traffic is vulnerable to interception
  • Limited error reporting — binary grant/reject only
  • Largely superseded by SOCKS5 in modern deployments

Use Cases

  • 1Legacy system integration where SOCKS5 is not supported
  • 2Simple TCP connection forwarding without protocol inspection
  • 3Basic IP masking for TCP applications
  • 4Connecting through older proxy infrastructure
  • 5Lightweight proxying where authentication security is not required
  • 6Internal network routing in controlled environments

Code Example

# Python — SOCKS4 proxy with PySocks
import socks
import socket

socks.set_default_proxy(socks.SOCKS4, "gate.hexproxies.com", 1080,
                        username="USER")
socket.socket = socks.socksocket

import requests
response = requests.get("http://httpbin.org/ip")
print(response.json())

# Python — SOCKS4 with requests[socks]
import requests

proxies = {
    "http": "socks4://USER@gate.hexproxies.com:1080",
    "https": "socks4://USER@gate.hexproxies.com:1080",
}

response = requests.get("http://httpbin.org/ip", proxies=proxies)
print(response.json())

# cURL — SOCKS4 proxy
curl --socks4 gate.hexproxies.com:1080 http://httpbin.org/ip

# cURL — SOCKS4a (proxy-side DNS resolution)
curl --socks4a gate.hexproxies.com:1080 http://httpbin.org/ip

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.

Ready to Get Started?

Use SOCKS4 Proxy Protocol with Hex Proxies for reliable, fast connections.

Cookie Preferences

We use cookies to ensure the best experience. You can customize your preferences below. Learn more