SOCKS5 vs proxies HTTP: a diferença que importa

Proxies HTTP entendem requisições web. SOCKS5 é um túnel TCP genérico. Escolha o protocolo que o cliente realmente fala e depois verifique.

SOCKS5 vs proxies HTTP: a diferença que importa

Protocolo não é origem. Um IP residencial pode ser vendido como HTTP. O mesmo pool pode ser vendido como SOCKS5. IPs de datacenter existem nos dois formatos. Compradores tratam “SOCKS5” como um grau de qualidade. É um transporte.

A diferença que importa é o que o cliente consegue enviar pelo túnel e o quanto o proxy entende da requisição.

01O que um proxy HTTP carrega#

Um proxy HTTP fala o protocolo de proxy HTTP. Para HTTPS, em geral usa CONNECT. O cliente pede ao proxy que abra um túnel para um host e uma porta. Depois disso, o TLS roda entre você e o destino. O proxy vê o host com o qual você conectou. Ele não vê a página descriptografada se o TLS estiver certo.

HTTP puro é diferente. O proxy consegue ler a requisição. Consegue injetar cabeçalhos. Consegue fazer cache. A maioria dos sites públicos agora redireciona para HTTPS, então CONNECT é o caminho que você realmente usa.

Proxies HTTP bastam para navegadores, para muitos scrapers e para qualquer coisa que já saiba configurar https_proxy. São uma escolha ruim para TCP arbitrário. Um cliente de e-mail, um jogo ou um binário próprio não fala CONNECT a menos que alguém tenha ensinado.

Alguns fornecedores acrescentam cabeçalhos extras em produtos HTTP. Esses cabeçalhos podem identificar você como usuário de proxy. Cheque uma requisição bruta se o alvo for sensível a isso.

02O que o SOCKS5 carrega#

SOCKS5 é um túnel genérico para TCP e, opcionalmente, para UDP. Ele não se importa se o payload é HTTP. O cliente diz “conecte a este host e porta”. O proxy faz isso. O DNS pode ser resolvido localmente ou de forma remota, conforme a configuração do cliente.

DNS remoto via SOCKS5 é o jeito usual de evitar vazamento de DNS em apps que suportam isso. DNS local é o jeito usual de vazar, porque a consulta de nome ainda bate no seu ISP. Teste isso. Os passos em como checar se o proxy funciona cobrem DNS e WebRTC.

A autenticação SOCKS5 é em geral usuário e senha. Alguns clientes ainda esperam SOCKS4 sem auth. Esses clientes falham contra um gateway moderno. Leia a documentação do cliente antes de culpar o fornecedor.

UDP sobre SOCKS5 importa para parte do tráfego de voz e de jogos. Não importa para scraping comum. Se o anúncio do fornecedor menciona UDP e você só busca páginas HTTPS, ignore o extra.

03O que navegadores e scrapers devem usar#

Um navegador que só carrega sites funciona com HTTP CONNECT. SOCKS5 também funciona se a configuração de proxy do navegador suportar. Escolha o que o perfil já conhece. Misturar os dois no mesmo perfil é como surgem vazamentos divididos.

Um scraper em Python ou Node deve usar a configuração de biblioteca já testada nesse stack. Proxies HTTP são o padrão em muitos clientes HTTP. SOCKS5 costuma precisar de um pacote extra. Pacotes extras falham de formas surpreendentes. Prefira o padrão, a menos que você precise de TCP que não seja HTTP.

Navegadores anti-detect e alguns apps no celular preferem SOCKS5 porque o resto do app não é um cliente HTTP. A mesma regra vale em qualquer lugar em que o cliente oficial exponha um campo SOCKS e não um campo HTTP.

A origem datacenter ou residencial ainda manda no sucesso em um site que pontua o tráfego. Trocar de HTTP para SOCKS5 não transforma um ASN de hosting em um ASN doméstico. Troque a origem. Veja proxies residenciais vs datacenter.

04Como verificar o protocolo#

Não confie no número da porta. 8080, 3128, 1080 e 60000 já foram reutilizados para os dois protocolos. Confie em um teste ao vivo.

Aponte o checador de proxy para o host, a porta, o usuário e a senha. Selecione o protocolo que você acha que comprou. Sucesso em HTTP e falha em SOCKS5 significa que você comprou HTTP. O inverso também acontece. Alguns gateways falam os dois. Os dois devem ser testados se você puder trocar de cliente depois.

Observe o DNS no mesmo teste. Um cliente SOCKS5 com DNS local ainda expõe o seu resolvedor. Force DNS remoto se o cliente oferecer.

Observe IPv6. Um túnel SOCKS5 em IPv4 não carrega um destino v6 a menos que o gateway suporte. Anúncios dual-stack precisam de um teste dual-stack.

Protocolo é uma escolha de compatibilidade do cliente. Origem é uma escolha de acesso. Modo de sessão é uma escolha de fluxo. Compre nessa ordem e você não paga por SOCKS5 como se fosse um IP mais limpo.