Como uma única porta de proxy pode aceitar HTTP e SOCKS
Explica como um ouvinte deliberadamente misto pode distinguir HTTP de SOCKS, enquanto um ouvinte normal de um único protocolo não consegue.
Um ouvinte de proxy misto pode aceitar HTTP e SOCKS numa única porta TCP porque o servidor inspeciona os bytes iniciais do protocolo. O número da porta não realiza essa deteção.
Um pedido de proxy HTTP começa com um método HTTP, como GET ou CONNECT. Uma saudação SOCKS começa com campos binários do protocolo. O software concebido para estas entradas pode encaminhar a ligação para o manipulador adequado.
Esta é uma característica explícita da implementação. Um ouvinte HTTP normal do Squid não se torna misto por a sua porta ser alterada para 1080, e um ouvinte apenas SOCKS não aprende HTTP a partir de uma definição do navegador.
O TLS acrescenta outra fronteira: uma ligação de proxy cifrada começa com TLS, não com um método HTTP visível. Suportá-lo no mesmo endpoint exige um tratamento deliberado adicional; reconhecer HTTP em texto simples e SOCKS não estabelece essa capacidade.
Utilize o protocolo de cliente documentado para o endpoint. Se ambos funcionarem, isso é evidência sobre o ouvinte misto desse servidor, não um motivo para deixar o protocolo por especificar em todos os clientes.
O ouvinte misto do Glider dá um exemplo concreto: espreita um byte sem o consumir, envia 0x05 para o seu manipulador SOCKS5 e, caso contrário, invoca o seu analisador HTTP. Esse analisador continua a validar o pedido recebido; a escolha de envio não torna uma entrada arbitrária em HTTP válido.
Partilhar o ouvinte TCP não fornece por si só a associação UDP do SOCKS5. O Glider inicia o seu ouvinte UDP separadamente. A seleção do protocolo TCP e o posterior encaminhamento de datagramas são capacidades separadas.