Un socket .NET necesita un handshake SOCKS
Explica qué debe hacer un socket TCP .NET sin procesar antes de que los bytes de la aplicación viajen a través de un proxy SOCKS.
Apuntar Socket.Connect() a un servidor SOCKS abre una conexión TCP con ese servidor. Los siguientes bytes todavía tienen que hablar SOCKS. Enviar el protocolo de la aplicación de inmediato deja al servidor esperando otra conversación.
Con SOCKS5, el establecimiento de la conexión incluye la negociación del método, cualquier intercambio de autenticación seleccionado y una solicitud que nombra el destino. Solo una respuesta correcta abre el camino para los bytes de la aplicación. Estas etapas se definen en RFC 1928.
Mantén la negociación en la capa de conexión
Una aplicación con su propio protocolo TCP puede usar un conector consciente del proxy que devuelva un flujo ya establecido. El resto de la aplicación lee y escribe a través de ese flujo. Un conector debe tener en cuenta lecturas parciales, direcciones de longitud variable, fallos de autenticación y un plazo para la negociación.
Una implementación escrita a mano que lee un búfer de tamaño fijo y supone el éxito es frágil. TCP no conserva los límites de los mensajes SOCKS. Lee la respuesta completa descrita por su tipo de dirección antes de iniciar el protocolo de la aplicación. Un lector de respuestas CONNECT para .NET 7+ ilustra ese paso.
Si una biblioteca mantenida ya proporciona esta capa de conexión, comprueba sus versiones de SOCKS compatibles, sus métodos de autenticación y su framework de destino. Un enlace de foro de hace una década es un punto de partida para investigar, no una prueba de compatibilidad actual.
La configuración del cliente HTTP tiene un alcance aparte
La configuración de proxy de un cliente HTTP configura ese cliente HTTP. No modifica todos los sockets sin procesar del proceso. La API de Socket acepta un extremo de red y deja la negociación de nivel superior a quien llama.
Para un protocolo de aplicación cifrado, realiza su handshake TLS después de establecer el túnel del proxy. Valida la identidad del destino previsto en esa etapa. La autenticación del proxy y la del destino siguen siendo distintas aunque usen el mismo flujo subyacente.