Visual RFC.
ALL RFCs / RFC 1928
Read the RFC ↗

RFC 1928 / START HERE

SOCKS version 5, before the details

SOCKS is the protocol name; RFC1928 does not expand it as an acronym. Version5 defines a way for an application to use a proxy, an intermediary that relays traffic.

The application negotiates a method with the proxy, then requests a target connection, an incoming listener or a UDP relay. Addresses, status replies and lifetimes keep these operations distinct.

Start the guide See the 5 chapters ↓

The idea in one picture

  1. Client application

  2. SOCKS proxy

  3. Target service

A simplified picture of the idea; the chapters explain the actual mechanisms.

Why it exists

Applications sometimes need controlled access through a firewall. SOCKS5 adds generalized method negotiation, UDP and domain/IPv6 addressing to the earlier SOCKS model; it is not a general network-layer gateway.

A familiar example

A configured app can ask the proxy to connect to a service and wait for success before sending data. A UDP relay also needs a live TCP association. SOCKS alone does not guarantee encryption, anonymity or permission to reach every destination.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

TCPRFC 9293 · beginner overview ↗UDPRFC 768 · beginner overview ↗IPv6RFC 8200 · beginner overview ↗

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. Negotiate a method before requesting a relayThe application connects to a SOCKS server and offers methods. The server chooses a method before the application requests any target.
  2. Encode the target and its address typeA request names a command and target address. ATYP tells the receiver how many address bytes to read.
  3. Wait for CONNECT success before relaying dataThe proxy opens its own target connection and reports an outcome. A successful reply describes its bound endpoint, not an echo of the target.
  4. Separate the two BIND repliesBIND asks the proxy to listen for an incoming secondary connection. Listening and accepting the peer are distinct events.
  5. Keep UDP headers and TCP association lifetime distinctUDP ASSOCIATE uses a TCP control connection, then separate header-wrapped UDP datagrams travel through its relay endpoint.
Start with chapter one →

This introduction explains RFC 1928 (1996). Read the original RFC ↗