A .NET Socket Needs a SOCKS Handshake

Pointing Socket.Connect() at a SOCKS server opens a TCP connection to that server. The next bytes still have to speak SOCKS. Sending your application's protocol immediately leaves the server waiting for a different conversation.

With SOCKS5, connection establishment includes method negotiation, any selected authentication exchange, and a request naming the destination. Only a successful reply opens the path for the application's bytes. These stages are defined in RFC 1928.

Keep negotiation in the connection layer

An application with its own TCP protocol can use a proxy-aware connector that returns an established stream. The rest of the application then reads and writes through that stream. A connector must account for partial reads, variable-length addresses, authentication failures, and a deadline for the negotiation.

A hand-written implementation that reads one fixed-size buffer and assumes success is fragile. TCP does not preserve the boundaries of the SOCKS messages. Read the complete reply described by its address type before starting the application protocol. A .NET 7+ CONNECT reply reader illustrates that step.

If a maintained library already supplies this connection layer, check its supported SOCKS versions, authentication methods, and target framework. A decade-old forum link is a starting point for investigation rather than evidence of current compatibility.

HTTP client configuration has a separate scope

An HTTP client's proxy setting configures that HTTP client. It does not modify every raw socket in the process. The Socket API accepts a network endpoint and leaves higher-level negotiation to the caller.

For an encrypted application protocol, perform its TLS handshake after the proxy tunnel is established. Validate the intended destination identity at that stage. Proxy authentication and destination authentication remain separate even though they use the same underlying stream.