SOCKS5 vs proxy HTTP: comparação completa

Proxy HTTP e SOCKS5 resolvem a mesma tarefa — substituir seu endereço diante do servidor —, mas o fazem em camadas diferentes da pilha de rede, e disso decorre todo o resto: que tráfego eles deixam passar, o que veem e podem alterar, como se comportam com DNS e UDP e com quais programas são compatíveis. A velocidade, ao contrário do que se pensa, quase não tem relação com isso. A seguir, uma análise dos dois protocolos, uma tabela de diferenças e uma regra de escolha que resolve nove de cada dez casos.

Resumindo

• Proxy HTTP entende HTTP. Ele lê a requisição, sabe para onde você vai, pode adicionar cabeçalhos, armazenar a resposta em cache ou bloquear um endereço. HTTPS ele deixa passar às cegas pelo comando CONNECT. Tráfego que não é HTTP não é problema dele.
• SOCKS5 não entende nada e não quer entender. Após um breve handshake, ele simplesmente repassa bytes nos dois sentidos: TCP de qualquer protocolo e, se necessário, UDP. Dentro pode haver qualquer coisa — site, e-mail, Telegram, jogo, torrent.
• Nem um nem outro criptografa o tráfego por si só. A proteção dos dados é responsabilidade do protocolo interno (HTTPS, TLS), não do proxy.

Em que camada cada um opera

O proxy HTTP vive na camada de aplicação. O cliente envia a ele uma requisição HTTP comum, apenas com o endereço completo na primeira linha (GET http://example.com/page HTTP/1.1), o proxy mesmo abre a conexão com o servidor, recebe a resposta e a entrega ao cliente. Todo o conteúdo passa por ele em texto claro, e ele tem o direito de alterá-lo.

Para HTTPS o esquema é outro: o cliente pede ao proxy para estabelecer um túnel com o comando CONNECT example.com:443, o proxy conecta os dois sockets e daí em diante apenas repassa os bytes criptografados. Ele vê o nome do host e a porta, mas não o caminho, nem os cabeçalhos, nem o corpo da requisição.

O SOCKS5 (RFC 1928) fica mais abaixo — entre o transporte e a aplicação. O cliente negocia com o proxy o método de autenticação, informa o endereço de destino (IPv4, IPv6 ou nome de domínio) e a porta, o proxy abre a conexão e a partir desse momento se torna um tubo transparente. Ele não sabe qual protocolo há dentro e, por isso, funciona com qualquer um. Se você precisar relembrar os fundamentos, comece pelo artigo sobre o que é um servidor proxy.

Como funciona um proxy HTTP

O que ele consegue fazer porque entende o protocolo

• Cache. Requisições repetidas ao mesmo recurso podem nem chegar ao servidor — é assim que funcionam os proxies corporativos e de provedores.
• Filtragem por URL. O proxy vê o endereço e pode bloqueá-lo, remover rastreadores ou redirecionar.
• Alteração de cabeçalhos. Ele pode adicionar Via, X-Forwarded-For ou Forwarded (RFC 7239) — e com isso revelar seu endereço real. Também pode remover o que for desnecessário.
• Autenticação. Login e senha são transmitidos pelo cabeçalho Proxy-Authorization, na maioria das vezes no esquema Basic — ou seja, em codificação Base64, sem criptografia. Em canal não protegido, eles ficam visíveis.

O que ele não consegue fazer

Tudo o que não é HTTP. Protocolos de e-mail, SSH, servidores de jogos, clientes de torrent, VoIP ou não funcionam de jeito nenhum através de um proxy HTTP, ou exigem que o programa saiba encapsular a conexão em CONNECT e que o proxy permita tais túneis para portas arbitrárias. Muitos proxies permitem CONNECT apenas para a porta 443.

Três graus de anonimato

Por causa dos cabeçalhos, os proxies HTTP são tradicionalmente divididos em três classes. O transparente transmite seu IP real em X-Forwarded-For e informa honestamente sobre si mesmo em Via. O anônimo oculta o endereço, mas mantém os cabeçalhos sobre o proxy — o servidor entende que há um intermediário à frente. O elite não adiciona nada e se parece com um cliente comum. O SOCKS5 não tem essa classificação: ele não tem acesso aos cabeçalhos e não adiciona nada por definição.

Como funciona o SOCKS5

Handshake

A conexão começa com o cliente listando os métodos de autenticação suportados, e o servidor escolhe um: sem autenticação, por login e senha (RFC 1929) ou GSS-API. Em seguida o cliente envia uma requisição com o comando, o tipo de endereço e a porta. São três comandos: CONNECT — conexão TCP de saída comum, BIND — aceitar uma conexão de entrada (necessário, por exemplo, para FTP ativo), UDP ASSOCIATE — abrir retransmissão de datagramas UDP.

DNS remoto

A diferença fundamental em relação ao SOCKS4: o endereço de destino pode ser passado como nome de domínio, e então o nome é resolvido pelo proxy, não pelo seu computador. No curl e no Python essa distinção é exposta no esquema da URL: socks5:// resolve o nome localmente, socks5h:// — do lado do proxy. A primeira opção deixa as consultas DNS com o seu provedor, a segunda as leva junto com o tráfego. Para tarefas em que é importante não expor o endereço, é preciso usar socks5h.

UDP

Pelo UDP ASSOCIATE passa o que o TCP não atende bem: voz e vídeo em mensageiros, DNS, parte dos protocolos de jogos, QUIC. Na prática, UDP através do SOCKS5 não é suportado por todos os servidores nem por todos os clientes, então antes de comprar um proxy para essa finalidade é preciso verificar isso separadamente.

Senha sem criptografia

Login e senha no SOCKS5 (método RFC 1929) são transmitidos em texto claro, assim como no HTTP Basic. O canal até o proxy não é protegido em nenhum dos dois casos; o que torna o tráfego protegido é apenas o TLS dentro da conexão. Se o provedor oferece autenticação por IP, isso é igualmente confiável e não deixa a senha nos logs dos programas.

Principais diferenças em uma tabela

Critério	Proxy HTTP	SOCKS5
Camada	Aplicação (entende HTTP)	Sessão (transmite bytes)
Tráfego	HTTP, HTTPS via CONNECT	Qualquer TCP, opcionalmente UDP
Vê o conteúdo	Sim para HTTP, apenas o host para HTTPS	Apenas o endereço de destino
Pode alterar a requisição	Sim (cabeçalhos, cache, filtros)	Não
Resolução de DNS	No proxy	No proxy (socks5h) ou localmente (socks5)
Criptografia	Não (apenas no HTTPS interno)	Não (apenas no protocolo interno)
Autenticação	Proxy-Authorization, Basic	Login e senha (RFC 1929), GSS-API, sem autenticação
Suporte nos programas	Quase em todos	Amplo, mas não universal
Overhead	Análise de cabeçalhos	Mínimo

Velocidade: por que a diferença não está onde se procura

O SOCKS5 não analisa cabeçalhos nem faz buffer das respostas, então teoricamente economiza microssegundos em cada requisição. Diante da latência de rede até o proxy e do proxy até o servidor, isso é imperceptível. A velocidade real é determinada por quatro coisas: a distância até o servidor proxy e dele até o destino, o tipo de endereço IP (canais móveis e residenciais são mais lentos que os de datacenter — mais detalhes no artigo sobre tipos de proxy), a carga do servidor específico e o número de conexões que você abre em paralelo. O protocolo não está nessa lista.

O único caso em que o proxy HTTP é visivelmente mais rápido é o de proxy com cache em conteúdo repetitivo. O único caso em que o SOCKS5 é visivelmente mais rápido é o de tráfego que por um proxy HTTP simplesmente não passaria.

Anonimato e vazamentos

O vazamento de endereço através de um proxy não acontece "por causa do protocolo", mas por mecanismos concretos, e cada um tem sua própria causa.

• Cabeçalhos. Um proxy HTTP transparente entrega seu IP em X-Forwarded-For. Resolve-se escolhendo um proxy de elite. No SOCKS5 esse canal de vazamento não existe.
• DNS. Se o nome é resolvido localmente, seu provedor vê para onde você vai. Proxy HTTP e socks5h resolvem do lado deles; socks5 — não.
• WebRTC. O navegador pode revelar o endereço local e o externo via STUN, contornando qualquer proxy. Isso é uma característica do navegador, não do proxy; fecha-se com configurações ou extensão.
• Tráfego fora do proxy. O proxy é configurado por aplicativo. Tudo o que você não configurou — atualizações do sistema, outro navegador, mensageiro — sai direto. Se for preciso cobrir o dispositivo inteiro, isso é tarefa de VPN, veja proxy versus VPN e Tor.

Compatibilidade com programas

• Navegadores. Chrome e Edge pegam o proxy das configurações do sistema e entendem os dois tipos; o Firefox tem configurações próprias e sabe "proxear DNS no SOCKS5" com uma opção separada.
• curl. curl -x http://user:pass@host:port para HTTP, curl -x socks5h://user:pass@host:port para SOCKS5 com DNS remoto.
• Python. Em requests e httpx, proxies HTTP funcionam de imediato; SOCKS5 — após instalar um pacote adicional; o esquema socks5h:// também transfere a resolução para o proxy.
• Telegram, Discord, clientes de torrent, jogos. Em geral, apenas SOCKS5: o tráfego deles não é HTTP.
• Navegadores antidetect e parsers. Suportam ambos; provedores de proxies móveis e residenciais costumam entregar a mesma porta nos dois protocolos.
• SSH. ssh -D 1080 user@server levanta um proxy SOCKS5 local através de qualquer servidor ao qual você tenha acesso — uma forma prática de testar como um programa se comporta com SOCKS5.

Quando escolher cada um

Tarefa	Escolha	Por quê
Navegador, uso de sites	Qualquer um; HTTP com mais frequência	Todo o tráfego é HTTP(S), suporte em todo lugar
Parsing via biblioteca HTTP	HTTP ou socks5h	O principal é resolver o DNS no proxy e não enviar cabeçalhos desnecessários
Mensageiros, jogos, torrents, e-mail	SOCKS5	Tráfego não HTTP, às vezes UDP
Muitas contas em navegador antidetect	Qualquer um; olhar o IP, não o protocolo	O antifraude avalia o endereço e o fingerprint, não a forma de conexão
Rede corporativa, controle e cache	HTTP	São necessários filtragem e registro por URL
Privacidade total do dispositivo	Nenhum dos dois	Isso é tarefa de VPN ou Tor

Regra: se o programa tem um campo "proxy HTTP" e só trafega por HTTP(S) — use HTTP. Se o programa não é web ou só tem "SOCKS5" — use SOCKS5 com DNS remoto. Não faz sentido discutir velocidade.

Erros típicos

1. Esperar criptografia do proxy. Nem HTTP nem SOCKS5 protegem o tráfego até o proxy; só o TLS interno protege.
2. Usar socks5:// em vez de socks5h:// e depois procurar de onde o DNS "vaza".
3. Configurar um proxy HTTP em um programa que não trafega por HTTP e atribuir o silêncio dele a um "proxy ruim".
4. Escolher o protocolo pela velocidade. A velocidade é determinada pelo endereço e pela rota, e dá para verificá-los em um minuto — veja como testar um proxy quanto a anonimato, vazamentos e velocidade.
5. Considerar um proxy HTTP de elite "mais anônimo" que o SOCKS5. Ambos não revelam o endereço; a diferença é apenas que o SOCKS5 não tem sequer a possibilidade técnica de adicioná-lo.

Perguntas e respostas

O que é mais rápido — SOCKS5 ou proxy HTTP?

No mesmo servidor, a diferença é imensurável diante da latência de rede. A velocidade é definida pelo tipo de IP, pela distância e pela carga no servidor, não pelo protocolo.

O SOCKS5 criptografa o tráfego?

Não. O SOCKS5 transmite os bytes como estão; o login e a senha também vão em texto claro. O que torna o tráfego protegido é o TLS dentro da conexão, por exemplo HTTPS.

É possível usar um proxy HTTP para Telegram ou torrents?

Em geral, não: o tráfego deles não é HTTP, e o túnel via CONNECT para portas arbitrárias é proibido pela maioria dos proxies HTTP. Para esses programas é preciso SOCKS5.

Qual a diferença entre socks5h e socks5?

A letra h significa que o nome de domínio é resolvido pelo servidor proxy. Sem ela, a consulta DNS sai do seu computador através do seu provedor, e o endereço de destino fica visível para ele.

Qual protocolo é mais anônimo?

Um proxy HTTP de elite e o SOCKS5 igualmente não revelam seu endereço. Um proxy HTTP transparente o revela pelos cabeçalhos; o SOCKS5 não tem esse mecanismo. Os demais vazamentos — DNS, WebRTC, tráfego fora do proxy — não dependem do protocolo.