No — SOCKS5 is a transport protocol, not an encryption protocol. The authentication and the data both travel in plaintext between you and the proxy unless you wrap the whole thing in TLS or run it through an SSH tunnel. Don't use SOCKS over hostile networks without an outer layer of encryption.

What port does SOCKS use?

By convention, 1080. It's not a hard requirement and many deployments use other ports — Tor's bundled SOCKS5 listener is on 9050 — but 1080 is the IANA-assigned default.

Why does Tor use SOCKS5 instead of HTTP?

SOCKS5 can tunnel any TCP protocol, not just HTTP. Tor users want to onion-route IRC, email, custom apps, and more — not just web traffic. SOCKS5 also passes domain names to the proxy, which lets Tor resolve them inside the network rather than leaking the lookup locally.

Can SOCKS handle UDP?

SOCKS5 added a UDP-associate command that lets the client tunnel UDP datagrams through the proxy. Support is uneven — many SOCKS server implementations only do TCP — but the spec is there, and it's how Tor and Shadowsocks handle UDP-based DNS.

Should I prefer SOCKS5 or a VPN?

For whole-device privacy, a VPN — it tunnels everything and encrypts the link. For tunneling one specific application or for chaining with Tor, SOCKS5 is the right tool. The two are complementary, not competing.

SOCKS Proxies Explained: How SOCKS4, SOCKS5, and SOCKS Over TLS Work

SOCKS is the protocol-agnostic proxy. Where HTTP proxies only understand web traffic, a SOCKS proxy will tunnel any TCP (and in SOCKS5, UDP) connection, no questions asked. That generality is why SSH ships SOCKS support out of the box, why Tor exposes a SOCKS5 listener, and why almost every privacy tool that wants to forward arbitrary application traffic ends up using it.

SOCKS ("Socket Secure") was designed at MIPS Computer Systems in the early 1990s to give firewalled hosts a clean way to reach the outside world. Rather than parsing every application protocol the way an HTTP proxy does, a SOCKS server just opens TCP connections on the client's behalf and shuffles bytes back and forth. Whatever protocol is layered on top — HTTP, SMTP, IRC, custom binary — works unchanged.

SOCKS4 vs SOCKS5

SOCKS4, standardized in 1992, only supports IPv4 and TCP, and has no authentication. It is essentially obsolete today but still widely seen in legacy software.

SOCKS5, defined in RFC 1928 (1996), is the version in active use. It adds:

IPv6 destination addresses
Domain-name destinations (the proxy resolves them, not the client — important for privacy)
Authentication methods (username/password being the common one)
UDP associate — a control channel that lets the client tunnel UDP datagrams, useful for DNS, VoIP, and game protocols

The connection flow

A SOCKS5 conversation looks like this:

Client connects to the SOCKS server on its listening port (typically 1080).
Client sends a greeting listing supported auth methods.
Server picks one and replies.
If auth was negotiated, client and server perform it.
Client sends a CONNECT request naming the destination host and port.
Server opens that TCP connection, replies with success and the bound address, and from then on everything the client writes is forwarded to the destination and vice versa.

Five round-trips before the first application byte moves. SOCKS isn't latency-friendly, but it is simple.

SOCKS and DNS: where leaks come from

One subtle SOCKS5 feature is how the destination is named. The CONNECT request can name it by IPv4, IPv6, or domain name. If the client sends an IP, the client did the DNS lookup locally — and if you were trying to hide behind the proxy, your local resolver just saw the name. If the client sends the domain, the proxy resolves it, which is what Tor users want.

This is the root cause of countless DNS leaks: applications configured for SOCKS5 that still resolve hostnames locally. Curl needs --socks5-hostname instead of --socks5. Firefox needs network.proxy.socks_remote_dns = true. Our DNS leak test catches the failure mode.

SSH dynamic forwarding

One of the most practical uses of SOCKS is ssh -D 1080 user@server. SSH spawns a local SOCKS5 listener; any application pointed at it has its TCP traffic tunneled over the SSH session to server, which then makes the outbound connection. Free of cost, encrypted end-to-end between you and the SSH server, and it routes around almost any local network restriction that allows port 22.

SOCKS vs HTTP CONNECT

HTTP CONNECT, the tunneling verb used by HTTP proxies for HTTPS, is functionally similar to SOCKS — both establish a raw TCP tunnel. The differences:

HTTP CONNECT runs over HTTP, so it inherits HTTP authentication and is firewall-friendly on port 80 or 443.
SOCKS is a dedicated protocol on a dedicated port, with cleaner UDP support and richer auth.
HTTP CONNECT can be intercepted and inspected by HTTPS-aware filters; SOCKS is more opaque to them.

SOCKS over TLS

SOCKS itself is not encrypted — the client/proxy link is plaintext, including the authentication exchange. To protect the link, modern deployments wrap SOCKS in TLS or run it inside an SSH tunnel. Shadowsocks took a different approach: it kept the SOCKS5 idea but added per-connection encryption and obfuscation to defeat deep packet inspection.

Where SOCKS sits next to VPNs

A VPN routes all traffic from your device through a tunnel. A SOCKS proxy only routes the applications you point at it. That makes SOCKS great for selective tunneling (route only your browser through Tor, leave games on the local link) and less great for whole-device protection. Some commercial VPN providers (Mullvad, IVPN) also expose SOCKS5 endpoints inside their networks so you can route a single app without bringing the full VPN up.

Frequently asked questions

Is SOCKS5 encrypted?: No — SOCKS5 is a transport protocol, not an encryption protocol. The authentication and the data both travel in plaintext between you and the proxy unless you wrap the whole thing in TLS or run it through an SSH tunnel. Don't use SOCKS over hostile networks without an outer layer of encryption.
What port does SOCKS use?: By convention, 1080. It's not a hard requirement and many deployments use other ports — Tor's bundled SOCKS5 listener is on 9050 — but 1080 is the IANA-assigned default.
Why does Tor use SOCKS5 instead of HTTP?: SOCKS5 can tunnel any TCP protocol, not just HTTP. Tor users want to onion-route IRC, email, custom apps, and more — not just web traffic. SOCKS5 also passes domain names to the proxy, which lets Tor resolve them inside the network rather than leaking the lookup locally.
Can SOCKS handle UDP?: SOCKS5 added a UDP-associate command that lets the client tunnel UDP datagrams through the proxy. Support is uneven — many SOCKS server implementations only do TCP — but the spec is there, and it's how Tor and Shadowsocks handle UDP-based DNS.
Should I prefer SOCKS5 or a VPN?: For whole-device privacy, a VPN — it tunnels everything and encrypts the link. For tunneling one specific application or for chaining with Tor, SOCKS5 is the right tool. The two are complementary, not competing.