Os quatro protocolos chamados de "proxy" têm pouco em comum além do nome. Proxies HTTP analisam a Camada 7 e reescrevem cabeçalhos; proxies SOCKS não leem o tráfego. Essa distinção determina qual proxy é adequado para navegação, scraping e tunelamento bruto.
Proxy HTTP
Um proxy HTTP espera semântica HTTP. Ele abre a requisição, lê a URL, pode anexar cabeçalhos como Via ou X-Forwarded-For e recusa qualquer coisa que não seja uma requisição HTTP válida. Navegadores, curl e a maioria das bibliotecas de scraping usam proxies HTTP por padrão, pois a configuração é praticamente gratuita — basta definir uma variável de ambiente ou passar uma flag.
O custo dessa simplicidade é a visibilidade. O proxy vê a URL completa, incluindo o caminho e a string de consulta, e em HTTP não criptografado também vê o corpo. Proxies de cache podem reescrever respostas; proxies transparentes podem remover cookies. Trate qualquer proxy HTTP como um intermediário com privilégios totais e nunca envie credenciais em texto puro.
Proxy HTTPS e o Método CONNECT
"Proxy HTTPS" é um rótulo um pouco enganoso. Refere-se a um proxy HTTP que também implementa o método CONNECT. CONNECT instrui o proxy a abrir um túnel TCP bruto para um host de destino e transportar bytes em ambas as direções; o cliente e o destino então negociam TLS como se o proxy não estivesse lá. O proxy vê o host e a porta de destino, e o volume de bytes, mas não o payload.
Um proxy "com suporte a HTTPS" é, portanto, um proxy que suporta tunelamento TLS, não um proxy que roda sobre TLS. O link entre sua máquina e o proxy pode ser texto puro ou criptografado de forma independente. Se você se preocupa com a proteção desse link, use uma implementação SOCKS5 sobre TLS ou um proxy comercial pago que publique seu endpoint TLS.
SOCKS4
SOCKS4 é o mínimo de 1994: apenas TCP, apenas IPv4, sem UDP, sem IPv6, sem autenticação, sem resolução de nomes no proxy. O handshake tem seis bytes mais um byte de código de resposta. Ele sobrevive na natureza porque o protocolo é tão pequeno que quase qualquer ferramenta que entenda TCP pode implementá-lo corretamente. Se uma lista anuncia SOCKS4, espere encaminhamento TCP bruto para um endereço IPv4 — e nada mais.
SOCKS5
SOCKS5, definido na RFC 1928 (1996), é a versão que a maioria das ferramentas modernas utiliza. Ele adiciona encaminhamento UDP, endereços IPv6, autenticação GSSAPI e a opção de resolver nomes de host no proxy em vez do cliente. Como o SOCKS5 não faz suposições sobre a camada de aplicação que roda sobre ele, é a escolha mais flexível para cargas de trabalho não HTTP: SSH, IRC, BitTorrent, RPC personalizado.
Desempenho e Sobrecarga
Proxies SOCKS têm menor sobrecarga por requisição porque não analisam nada. Proxies HTTP e HTTPS pagam pela análise completa da requisição em cada conexão. Para uma única sessão TLS de longa duração dentro de CONNECT, a diferença é insignificante. Para milhares de requisições curtas onde o proxy abre uma nova conexão a cada vez, o SOCKS5 vence de forma mensurável — tipicamente 2–5 ms por requisição devido ao caminho de análise.
Anonimato, na Prática
Um proxy HTTP que não remove seus cabeçalhos pode vazar seu IP de cliente via Via, X-Forwarded-For ou Forwarded. Proxies SOCKS não possuem tais cabeçalhos porque não têm o conceito de cabeçalhos. Isso não é um recurso de anonimato, mas sim a ausência de uma superfície de vazamento. Dentro de HTTPS tunelado por CONNECT, o destino vê apenas o handshake TLS, portanto qualquer vazamento em nível HTTP no proxy é irrelevante.
Convenções de Porta
Você verá estas neste diretório: 80, 8080, 3128, 8888 para HTTP; 443 para endpoints que suportam explicitamente CONNECT; 1080 para SOCKS. Muitos provedores expõem portas altas não padrão (acima de 10.000) para evitar varreduras casuais de portas. O número da porta não diz nada sobre qualidade — apenas sinaliza o que o operador escolheu expor.