Como un só porto de proxy pode aceptar HTTP e SOCKS á vez
Explica como un oínte deliberadamente mixto pode distinguir HTTP de SOCKS, mentres que un oínte normal dun só protocolo non pode.
Un oínte de proxy mixto pode aceptar HTTP e SOCKS nun só porto TCP porque o servidor inspecciona os bytes iniciais do protocolo. O número de porto non realiza esa detección.
Unha solicitude de proxy HTTP comeza cun método HTTP, como GET ou CONNECT. Un saúdo SOCKS comeza con campos binarios do protocolo. O software deseñado para estas entradas pode enviar a conexión ao xestor axeitado.
Esta é unha característica explícita da implementación. Un oínte HTTP normal de Squid non se volve mixto porque se cambie o seu porto a 1080, e un oínte só de SOCKS non aprende HTTP a partir da configuración dun navegador.
TLS engade outra fronteira: unha conexión de proxy cifrada comeza con TLS, non cun método HTTP visible. Admitilo no mesmo punto final require un manexo deliberado adicional; recoñecer HTTP en texto plano e SOCKS non establece esa capacidade.
Use o protocolo de cliente documentado para o punto final. Se ambos funcionan, iso é evidencia sobre o oínte mixto dese servidor, non un motivo para deixar o protocolo sen especificar en cada cliente.
O oínte mixto de Glider ofrece un exemplo concreto: mira un byte sen consumilo, envía 0x05 ao seu xestor SOCKS5 e, se non, invoca o seu analizador HTTP. Ese analizador segue validando a solicitude entrante; a elección de envío non converte unha entrada arbitraria en HTTP válido.
Compartir o oínte TCP non proporciona por si mesmo a asociación UDP de SOCKS5. Glider inicia o seu oínte UDP por separado. A selección do protocolo TCP e a posterior retransmisión de datagramas son capacidades separadas.