Asio Needs a SOCKS5 Exchange After Connecting to the Proxy
Treat SOCKS5 as a protocol state machine over the Asio socket, with complete reads, validated replies and destination TLS only after CONNECT succeeds.
Connecting an Asio TCP socket to a SOCKS5 listener completes one step: the TCP connection to that listener. It does not ask the proxy to connect to the final server. For a permitted public-target test, the SOCKS5 proxy list offers candidates for that first TCP endpoint; the connector still has to complete the exchange below.
A SOCKS5 connector must then run the protocol exchange:
- Send a version-5 greeting listing the authentication methods the client supports.
- Read the selected method and perform its authentication exchange when required.
- Send CONNECT with the destination address type, address and network-byte-order port.
- Read the reply, check its version and result code, and consume its complete variable-length bound address and port.
- Hand the established stream to the application's protocol.
A helper called socks5::async_proxy_connect belongs to the SOCKS implementation providing that helper. Naming it beside boost::asio does not make it part of Asio's TCP socket interface.
TCP reads can return only part of a reply. Compose reads for the required byte counts, then choose the remaining length from the address-type field. Do not assume every server reply has the fixed IPv4 layout.
For HTTPS, perform the destination TLS handshake after SOCKS CONNECT succeeds, preserving the destination's SNI and hostname verification. A successful proxy reply alone does not authenticate the website.
Keep cancellation and deadlines across the entire setup sequence. Timing out TCP connection establishment leaves the later greeting, authentication and CONNECT exchanges otherwise unbounded.