Tipos de servidores proxy: como o HTTP difere do SOCKS5

As palavras "HTTP", "SOCKS4" e "SOCKS5" aparecem na descrição de todo serviço de proxy, e por elas você sabe se uma linha vai funcionar no seu software. A diferença entre protocolos se resume a três coisas: como o software diz ao proxy onde se conectar, quem transforma o domínio em endereço IP e o que o servidor faz depois com o tráfego. Vemos os quatro protocolos com tabelas e exemplos, e no fim mostramos como o protocolo combina com a origem dos endereços: dos pacotes MIX às linhas residenciais.

Como uma requisição passa pelo proxy

Qualquer proxy fica entre seu software e o site. O software abre uma conexão com o proxy, o proxy abre a dele com o site e depois transmite bytes nos dois sentidos, por isso o site vê o endereço do proxy e não o seu. Os protocolos diferem no primeiro passo: a forma como o software entrega a requisição ao servidor.

Proxy HTTP: a requisição é lida inteira

O software envia ao proxy HTTP uma requisição normal, só que com o endereço completo: GET http://site/page. O proxy a analisa, vai ao site por conta própria e devolve a resposta. Como o servidor vê a requisição inteira, pode acrescentar os cabeçalhos de serviço Via e X-Forwarded-For, e neste último está seu IP real.

Por esses cabeçalhos os proxies públicos se dividem em três níveis. O transparente envia seu endereço ao site. O anônimo o esconde, mas os cabeçalhos mostram que é um proxy. O elite não acrescenta nada, e para o site parece um visitante comum. A lista grátis indica o nível de cada endereço, e a coluna Tipo filtra elite e anônimos. Teste sua linha na página de verificação de anonimato: ela mostra os cabeçalhos e os vazamentos de WebRTC.

Em estado puro, o protocolo serve para sites sem criptografia, e quase não restam. Por isso, na prática, "proxy HTTP" significa uma combinação: texto aberto para endereços http e túnel CONNECT para todo o resto.

Proxy HTTPS: o túnel CONNECT

Para um site criptografado, o software pede ao proxy que abra um túnel com o comando CONNECT site:443. O proxy responde com o código 200 e passa um fluxo que não consegue olhar: o TLS vai do seu software ao site de ponta a ponta. Ao servidor restam o domínio, a hora e o volume de tráfego. Não existe um protocolo "proxy HTTPS" separado: é um proxy HTTP com o comando CONNECT permitido, e todas as nossas linhas HTTP o suportam.

SOCKS4 e SOCKS5: transmitir um fluxo

O SOCKS trabalha um nível abaixo e não olha dentro do HTTP: o software indica o endereço de destino, o proxy abre uma conexão TCP e transmite o fluxo como está. Para o protocolo tanto faz o que há dentro: página, e-mail ou tráfego de jogo. O SOCKS4 aceita só endereços IPv4 e vive sem senha, e a versão 4a aprendeu a usar domínios. As duas aparecem em software antigo, e nos projetos novos o SOCKS5 as substituiu.

O SOCKS5 acrescentou três coisas: autorização por login e senha, endereços IPv6 com domínios e transmissão UDP. Para o trabalho importa um detalhe que costuma ser esquecido: o domínio pode ser convertido em IP tanto pela sua máquina quanto pelo proxy. Se for sua máquina, a consulta DNS sai do seu endereço, e esse rastro anula o anonimato. No curl o esquema decide: socks5:// resolve no cliente, socks5h:// no proxy. Os dois comandos abaixo mostram o endereço de saída da linha, e o segundo ainda esconde o DNS:

curl -x "http://LOGIN:PASSWORD@HOST:PORT" https://ifconfig.me
curl --socks5-hostname "LOGIN:PASSWORD@HOST:PORT" https://ifconfig.me

O UDP por SOCKS5 é necessário para streaming, chamadas, jogos e QUIC. Dos nossos planos, o Resi Prime o suporta, e nos demais o proxy leva TCP.

Uma nota à parte sobre a web moderna. Cada vez mais sites falam HTTP/3, que roda sobre UDP. Por um proxy sem UDP o navegador volta sozinho ao HTTP/2 por TCP, e o site abre normalmente, só sem ganho de velocidade. Nada quebra aqui, mas se o console do navegador mostra h2 onde você esperava h3, a causa é essa.

Comparação de protocolos

A velocidade quase não depende do protocolo: a sobrecarga de todos cabe em uma troca de pacotes ao conectar. Decidem a origem do endereço e o canal de saída, e isso já é do pool. Como um mesmo protocolo se comporta em dois pools diferentes se vê nas nossas medições de endereços alemães: a resposta diferiu em quatro vezes e meia.

Protocolo e origem dos endereços: dois eixos diferentes

Compradores costumam perguntar o que é "mais confiável": HTTP ou SOCKS5. Para o site não há diferença: ele vê uma conexão de entrada do endereço do proxy e não sabe qual protocolo você usou com o servidor. A reputação da linha vem da origem do endereço: data center, provedor doméstico ou rede celular. O protocolo se escolhe pelo software, a origem pelo site com que você vai trabalhar.

Nos planos por gigabytes o protocolo é definido ao criar a lista no painel, e a linha já contém login, senha e porta. Se o software espera outro formato, passe a lista pelo conversor de proxy.

Formatos das linhas

O protocolo também aparece na própria linha. O software aceita um proxy de duas formas: endereço com porta ou link completo com esquema. No link o protocolo vem primeiro, e muitas vezes é confundido com o do site: o esquema http:// na linha indica como se conectar ao proxy e não significa que sites https não abrirão por ele.

O verificador SLP e nosso painel aceitam os três formatos, e se o software insiste em um só, o conversor de proxy reescreve a lista inteira: colar, escolher modelo, baixar. Para digitar uma linha à mão no Windows, macOS ou navegador, use o guia de configuração manual de proxy.

O que escolher por tarefa

• Scraping e verificadores. SOCKS5 com o esquema socks5h para o DNS passar pelo proxy, ou HTTP: os dois servem a um scraper. Para milhares de threads sem medidor de tráfego use pacotes MIX, e para localização precisa as linhas Resi Core.
• Navegadores e antidetecção. Use HTTP: o Chromium não passa login e senha para SOCKS5, e um perfil com essa linha fica sem rede. Escrevemos mais sobre a escolha de pool para contas no artigo sobre proxies backconnect.
• Streaming, chamadas, jogos. É preciso UDP, ou seja, SOCKS5 no Resi Prime.
• Software antigo sem campo de senha. Os pacotes MIX servem: o acesso abre pelo IP do seu servidor, então não há onde nem por que digitar um login.

Como verificar uma linha

O endereço de saída e o país aparecem na página meu IP, os cabeçalhos e o nível de anonimato na verificação de anonimato. Uma lista inteira é mais prática de rodar no verificador SLP ou no script para Linux da mesma página: ele entende ip:port e linhas com login, detecta sozinho o protocolo da porta e marca as linhas mortas. Testamos os comandos curl deste artigo em linhas vivas antes de publicar.

Todos os planos são pagos de um único saldo: pacotes por prazo, o resto por gigabytes, e o tráfego comprado dura três meses. Os preços de cada volume estão na página de comparação de planos.