Where SOCKS5 came from
SOCKS (short for "SOCKet Secure") dates back to 1990, originally developed by David Koblas and later maintained by NEC. The version still in use today, SOCKS5, was formalized by the IETF in RFC 1928, published in March 1996 — making it one of the oldest proxy standards still in active, widespread use, older than HTTPS itself in its modern form.
SOCKS5's original goal was narrow: earlier firewalls could only really reason about specific applications (an FTP proxy, an HTTP proxy, and so on), and SOCKS was meant to be a generic circuit-level proxy that any application could use, without the firewall needing to understand the specifics of that application's protocol.
How it actually works
Unlike an HTTP proxy, which operates at the application layer and understands HTTP requests specifically, SOCKS5 works at a lower level — it simply relays TCP (and, with UDP ASSOCIATE, UDP) connections between a client and a destination without inspecting or modifying the traffic inside them. This is what makes it application-agnostic: a single SOCKS5 proxy can carry web browsing, email, torrenting, or any other TCP-based traffic without any protocol-specific logic.
The RFC 1928 handshake is short: the client connects and offers a list of supported authentication methods, the server picks one, authentication happens if required, and then the client sends a connection request specifying the destination address and port. From that point on, the proxy simply relays bytes in both directions.
Plain SOCKS5 has no encryption of its own — RFC 1928 defines an authentication negotiation, not a confidentiality guarantee. On an open network, a SOCKS5 connection's contents are visible to anyone positioned to observe it. This is precisely the gap Shadowsocks was built to close in 2012: take the proven, minimal SOCKS5 model and wrap it in strong encryption from the very first packet.
SOCKS5 vs. HTTP proxy
| Property | HTTP Proxy | SOCKS5 |
|---|---|---|
| OSI layer | Application | Session / transport |
| Protocol awareness | Understands HTTP specifically | Protocol-agnostic |
| UDP support | No | Yes (UDP ASSOCIATE) |
| Encryption | None natively | None natively |
| Standard | Various | RFC 1928 (1996) |
Where you'll encounter it
SOCKS5 shows up almost everywhere in modern networking tooling: as the local interface many VPN and Tor clients expose to applications, as the transport model underneath Shadowsocks, and as a lightweight way to route a single application's traffic without installing a full VPN client. Its longevity comes from doing one job — relaying connections — and staying out of the way of everything built on top of it.
MiTiVPN exposes a local SOCKS5 interface for advanced users who want to route individual applications through the tunnel selectively, rather than sending all system traffic through the VPN.