Wait for CONNECT success before relaying data
03The proxy opens its own target connection and reports an outcome. A successful reply describes its bound endpoint, not an echo of the target.
Separate failed attempt: target connection is refused. The proxy sends REP05 toward the client, then closes within the specified bound. No data path reaches the target.
Source for this drawing: RFC 1928 · Read RFC section 6 ↗
New to this? Start hereA quick picture + helpful background
A request starts a conversation.
A client asks for a resource. A server sends a response. The method, address, headers, and status explain what that conversation means.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Success joins two connection legs; failure stops them.
- For CONNECT, the proxy uses DST.ADDR/DST.PORT to connect to the target. The reply fields are VER, REP, RSV, ATYP, BND.ADDR and BND.PORT.
- REP00 means success. CONNECT BND.ADDR/BND.PORT describe the proxy endpoint used for the target connection; that address can differ from the client-facing proxy address.
- A failure REP other than00 requires the SOCKS server to terminate TCP shortly after replying, no more than10 seconds after detecting the failure condition. Data and replies use method-dependent protection when applicable.
The worked request targets203.0.113.20:443; the chosen proxy outgoing endpoint is198.51.100.9:40000, distinct from its client-facing address192.0.2.10. REP02 is policy refusal;03 network unreachable;04 host unreachable;05 connection refused;06 TTL expired;07 unsupported command;08 unsupported address type;01 general failure. The failure scene is an alternative, not a failure after the pictured successful transfer. SOCKS is not itself a TLS or VPN guarantee.
Read the RFC section ↗