Um socket .NET precisa de um handshake SOCKS

Apontar Socket.Connect() para um servidor SOCKS abre uma conexão TCP com esse servidor. Os próximos bytes ainda precisam falar SOCKS. Enviar o protocolo da sua aplicação imediatamente deixa o servidor à espera de outra conversa.

Com SOCKS5, o estabelecimento da conexão inclui negociação de método, qualquer troca de autenticação selecionada e uma solicitação que nomeia o destino. Apenas uma resposta bem-sucedida abre o caminho para os bytes da aplicação. Esses estágios são definidos na RFC 1928.

Mantenha a negociação na camada de conexão

Uma aplicação com seu próprio protocolo TCP pode usar um conector ciente de proxy que retorna um fluxo estabelecido. O restante da aplicação então lê e escreve através desse fluxo. Um conector deve considerar leituras parciais, endereços de comprimento variável, falhas de autenticação e um prazo para a negociação.

Uma implementação escrita à mão que lê um buffer de tamanho fixo e assume sucesso é frágil. O TCP não preserva os limites das mensagens SOCKS. Leia a resposta completa descrita pelo seu tipo de endereço antes de iniciar o protocolo da aplicação. Um leitor de resposta CONNECT do .NET 7+ ilustra essa etapa.

Se uma biblioteca mantida já fornece essa camada de conexão, verifique suas versões SOCKS suportadas, métodos de autenticação e framework de destino. Um link de fórum de uma década é um ponto de partida para investigação, não evidência de compatibilidade atual.

A configuração do cliente HTTP tem um escopo separado

A configuração de proxy de um cliente HTTP configura esse cliente HTTP. Ela não modifica cada socket bruto no processo. A API Socket aceita um endpoint de rede e deixa a negociação de nível superior para o chamador.

Para um protocolo de aplicação criptografado, execute seu handshake TLS após o túnel de proxy ser estabelecido. Valide a identidade do destino pretendido nesse estágio. A autenticação de proxy e a autenticação de destino permanecem separadas, embora usem o mesmo fluxo subjacente.