SOCKS

SOCKS (Socket Secure) operates below the application layer. When an application connects to a SOCKS5 proxy, it sends the destination address and port; the proxy opens a connection to that destination and relays bytes in both directions. The proxy doesn't read or modify the payload — it's invisible to the application protocol. SOCKS5 (RFC 1928) added UDP support, IPv6 support, and username/password authentication over SOCKS4. It runs on port 1080 by default and is supported natively by most operating systems and applications.

SOCKS4 vs SOCKS5 vs HTTP proxy

How SOCKS proxy works vs HTTP proxy

An HTTP proxy operates at the application layer and understands HTTP. It reads the request line (GET http://example.com/ HTTP/1.1), makes its own request to the origin on behalf of the client, and returns the response. For HTTPS, it uses the CONNECT method to establish a TCP tunnel through which the TLS handshake happens end-to-end. An HTTP proxy only handles HTTP and HTTPS traffic — it cannot forward raw TCP connections for SSH, FTP data, gaming protocols, or email.

A SOCKS proxy operates at the session layer (OSI Layer 5), below the application layer. The client connects to the proxy and sends a short negotiation exchange: proxy version, authentication method, destination address, and destination port. The proxy opens a raw TCP (or UDP for SOCKS5) connection to the destination and relays bytes in both directions without reading them. Because SOCKS does not inspect the payload, it works identically for HTTP, SSH, SMTP, BitTorrent, VoIP, database connections, or any other TCP/UDP application. The tradeoff is that SOCKS cannot cache, filter, or modify content.

SOCKS5 authentication methods

SOCKS5 supports pluggable authentication via a method negotiation step at the start of each connection. The client proposes a list of acceptable methods; the server selects one. Defined methods include:

• No authentication (0x00): any client can use the proxy without credentials. Suitable only on trusted internal networks.
• Username/password (0x02, RFC 1929): the client sends a plaintext username and password. Simple and widely supported but credentials are exposed unless the connection is itself encrypted (e.g., inside an SSH tunnel).
• GSSAPI (0x01): Kerberos-based authentication, used in enterprise environments where a KDC is available. Rarely seen outside corporate settings.

SOCKS5 and DNS leak prevention

A critical difference between standard SOCKS5 and the SOCKS5h variant is where DNS resolution occurs. With plain SOCKS5, the client resolves the hostname to an IP address locally before connecting to the proxy, then sends the IP. This means DNS queries are visible to the local ISP — a DNS leak that reveals the sites you visit even when traffic is proxied. With SOCKS5h (the "h" stands for "host" resolution), the client sends the unresolved hostname to the proxy, and the proxy resolves it on its end. All DNS queries happen at the proxy's location, preventing DNS leaks. Tor's SOCKS5 interface always uses SOCKS5h-style remote resolution for this reason.

SSH SOCKS proxy: ssh -D

The most practical SOCKS5 setup for individuals requires nothing beyond an SSH server account. The command ssh -D 1080 user@remote-server opens a local SOCKS5 proxy on port 1080. All TCP traffic routed through this proxy travels inside an encrypted SSH tunnel to the remote server, then exits from there. Configure your browser's proxy settings to SOCKS5 at 127.0.0.1:1080 (with remote DNS enabled to prevent leaks) and your traffic appears to originate from the SSH server's IP. The tunnel is fully encrypted with SSH's cipher suite. No extra software, VPN client, or special server configuration is required — any standard SSH server works.

To make all OS traffic use the tunnel rather than just the browser, use ssh -D 1080 -N user@remote-server combined with OS-level SOCKS proxy settings in System Preferences (macOS) or Network Settings (Windows/Linux). The -N flag tells SSH not to execute a remote command, keeping the tunnel open without opening a shell session.

Use cases

• Tor network: Tor Browser and the Tor daemon expose a SOCKS5 interface at 127.0.0.1:9050. Any application configured to use this proxy routes its TCP connections through the Tor onion network with multi-hop anonymisation.
• Proxy chains: tools like proxychains allow routing TCP traffic through multiple sequential SOCKS5 (or HTTP) proxies, adding hops between the client and destination for additional indirection.
• Bypassing firewalls: corporate firewalls that block direct connections to certain ports or destinations often allow port 443 (HTTPS). SOCKS5 tunnelled over SSH on port 443 can bypass port-based filtering.
• Non-HTTP application proxying: game clients, email clients, IRC, and other non-HTTP applications can use SOCKS5 where HTTP proxies are inapplicable.
• Remote access without a VPN: a SOCKS5 proxy via SSH provides selective proxying — only applications explicitly configured to use it go through the tunnel, unlike a VPN that routes all OS traffic.

Configuring SOCKS proxy in OS and browsers

On macOS: System Settings → Network → select interface → Proxies → enable SOCKS Proxy, enter 127.0.0.1 and port 1080. On Windows: Settings → Network → Proxy → Manual proxy setup, or per-application in proxy settings. In Firefox: Settings → Network Settings → Manual proxy configuration → SOCKS Host field; enable "Proxy DNS when using SOCKS v5" to prevent DNS leaks. In Chrome: Chrome uses OS proxy settings by default, or can be launched with --proxy-server="socks5://127.0.0.1:1080" as a command-line flag.

Frequently Asked Questions

What is the difference between SOCKS5 and an HTTP proxy?

HTTP proxies understand HTTP and handle only web traffic. SOCKS5 operates at the session layer and relays raw TCP and UDP bytes for any protocol — email, torrents, SSH, gaming, databases. SOCKS5 cannot cache or filter content because it does not inspect payloads.

What is SOCKS5 used for?

Changing apparent IP for non-HTTP traffic, bypassing port-based firewalls, routing traffic through SSH tunnels (ssh -D), DNS leak prevention via remote resolution, and accessing the Tor network. Tor exposes a SOCKS5 interface at 127.0.0.1:9050 for application-level anonymous routing.

Does SOCKS5 encrypt traffic?

No — SOCKS5 itself forwards bytes without encryption. Encryption comes from the application layer (HTTPS, SSH) or the transport carrying the SOCKS connection. SSH dynamic forwarding wraps SOCKS5 inside an encrypted SSH tunnel, providing encryption end-to-end to the SSH server.