Cómo un solo puerto de proxy puede aceptar HTTP y SOCKS a la vez
Explica cómo un oyente deliberadamente mixto puede distinguir HTTP de SOCKS, mientras que un oyente normal de un solo protocolo no puede.
Un oyente de proxy mixto puede aceptar HTTP y SOCKS en un solo puerto TCP porque el servidor inspecciona los bytes iniciales del protocolo. El número de puerto no realiza esa detección.
Una solicitud de proxy HTTP comienza con un método HTTP, como GET o CONNECT. Un saludo SOCKS comienza con campos binarios del protocolo. El software diseñado para estas entradas puede enviar la conexión al controlador adecuado.
Esta es una característica explícita de la implementación. Un oyente HTTP normal de Squid no se vuelve mixto porque se cambie su puerto a 1080, y un oyente solo de SOCKS no aprende HTTP a partir de la configuración de un navegador.
TLS añade otra frontera: una conexión de proxy cifrada comienza con TLS, no con un método HTTP visible. Admitirlo en el mismo extremo requiere un manejo deliberado adicional; reconocer HTTP en texto plano y SOCKS no establece esa capacidad.
Utilice el protocolo de cliente documentado para el extremo. Si ambos funcionan, eso es evidencia sobre el oyente mixto de ese servidor, no un motivo para dejar el protocolo sin especificar en todos los clientes.
El oyente mixto de Glider ofrece un ejemplo concreto: examina un byte sin consumirlo, envía 0x05 a su controlador SOCKS5 y, de lo contrario, invoca su analizador HTTP. Ese analizador sigue validando la solicitud entrante; la elección de envío no convierte una entrada arbitraria en HTTP válido.
Compartir el oyente TCP no proporciona por sí mismo la asociación UDP de SOCKS5. Glider inicia su oyente UDP por separado. La selección del protocolo TCP y la posterior retransmisión de datagramas son capacidades separadas.