HTTP proxy e SOCKS5 no nível do protocolo: CONNECT, ATYP, o que o intermediário vê e como escolher

Se você já abriu o painel de um serviço de proxy, já viu essa cena: o mesmo endereço, o mesmo login e, do lado, duas portas. Uma marcada como HTTP, a outra como SOCKS5. Muita gente escolhe no chute ou por hábito. No entanto, por trás dessas duas linhas existem dois protocolos diferentes, com arquiteturas distintas no nível dos bytes, formas diferentes de enxergar seu tráfego e comportamentos distintos nos clientes reais. Este guia desmonta a diferença byte a byte e termina com tabelas práticas de escolha.

Introdução: por que um mesmo proxy é oferecido em dois modos e isso não é marketing

Vamos começar com uma resposta honesta à pergunta do título. Quando a Proxeon entrega um endereço com duas portas, por trás delas está a mesma máquina, o mesmo IP de saída e a mesma conta. A diferença não está em para onde o tráfego vai. A diferença está em qual idioma seu cliente fala com o servidor proxy no primeiro trecho do caminho: da sua aplicação até o intermediário.

HTTP proxy fala a língua do HTTP. Ele recebe requisições HTTP, lê essas requisições, entende o que você quer buscar e ele mesmo vai atrás do recurso. Sabe fazer cache, adicionar cabeçalhos, responder com códigos de status. Para tudo que não é HTTP, ele tem um truque universal: o método CONNECT, que o transforma em um simples cano.

SOCKS5 não faz ideia do que seja HTTP. É um protocolo de camada de sessão: o cliente diz “conecte-me a este host e esta porta”, o proxy abre uma conexão TCP e, a partir daí, apenas repassa bytes de um lado para o outro. Ele não se importa com o que vai dentro: TLS, IMAP, SSH, protocolo de banco de dados ou seu próprio formato binário.

Por que não deixar só um modo? Porque a compatibilidade é diferente. Metade do software corporativo e de desktop só entende HTTP proxy pelas configurações do sistema. Boa parte das bibliotecas de rede e praticamente todo o tráfego que não é web se sente mais confortável em SOCKS5. Oferecer os dois modos no mesmo IP significa que você escolhe a ferramenta conforme o cliente, em vez de forçar o cliente a se adaptar à ferramenta.

O que você vai aprender neste artigo:

• como é uma requisição a um HTTP proxy no nível do texto e em que ela difere de uma requisição comum a um site;
• o que exatamente o proxy vê e pode alterar no modo HTTP transparente;
• como funciona o método CONNECT e o que permanece visível ao intermediário depois de estabelecido o túnel;
• o handshake em bytes do SOCKS5, os esquemas de autenticação e os três tipos de endereço ATYP;
• por que a escolha entre domínio e IP na requisição SOCKS5 afeta geolocalização e privacidade do DNS;
• comparação por protocolos não-HTTP, UDP, overhead, cache e logging;
• tabela “tarefa, protocolo, por quê” e análise de compatibilidade em clientes e bibliotecas populares.

A mecânica do comando UDP ASSOCIATE e a diferença entre os esquemas socks5 e socks5h em curl e Python não serão detalhadas aqui: esses temas têm materiais próprios no blog da Proxeon, e haverá links nos pontos certos.

Fundamentos: onde o proxy vive na pilha de rede

Para que a conversa sobre protocolos faça sentido, vamos combinar os termos. São poucos.

Três participantes e duas conexões

Em qualquer esquema com proxy existem três lados: o cliente (seu navegador, script, programa de email), o servidor proxy (o intermediário) e o servidor de destino (origin). Entre eles há duas conexões TCP independentes. A primeira: do cliente ao proxy. A segunda: do proxy ao servidor de destino. O servidor de destino enxerga apenas a segunda conexão e, portanto, apenas o IP do proxy.

Tudo o que discutimos neste artigo diz respeito exclusivamente à primeira conexão. É ali que mora a diferença entre HTTP e SOCKS5. A segunda conexão é igual nos dois casos: um TCP comum do proxy até o host de destino.

Camadas do modelo e por que isso importa

Uma analogia útil: imagine um serviço de entregas. O HTTP proxy no modo transparente é como um entregador que abre seu pacote, lê o endereço e o conteúdo, reembala se necessário e pode até responder sozinho, se tiver uma cópia guardada no estoque. O SOCKS5 é como um entregador a quem você informa apenas o endereço e entrega o pacote lacrado. Ele não sabe nem quer saber o que tem dentro.

Em termos de modelo de rede, o HTTP proxy atua na camada de aplicação: ele entende a semântica da requisição. O SOCKS5 atua na camada de sessão: opera com os conceitos de “host”, “porta” e “conexão” e não sobe mais do que isso.

Onde acontece a resolução de nomes

Um conceito à parte, que atravessa todo o material: a resolução DNS. Quando você acessa example.com, alguém precisa transformar o nome em endereço IP. Isso pode ser feito localmente pelo seu cliente ou pelo proxy, do lado dele. Disso depende de qual infraestrutura DNS você usa, qual resposta regional você recebe do CDN e se a informação sobre os domínios visitados vaza na rede local. Guarde esse ponto: ele reaparece tanto na seção sobre HTTP quanto na seção sobre SOCKS5.

Autenticação

Tanto o HTTP proxy quanto o SOCKS5 sabem verificar login e senha, mas fazem isso de formas diferentes. O HTTP usa o cabeçalho Proxy-Authorization e o código de resposta 407. O SOCKS5 usa um subprotocolo separado com o número de método 0x02. Existe também uma alternativa independente de protocolo: a autorização por endereço IP do cliente, em que o proxy libera todos que chegam de um endereço previamente autorizado. Na Proxeon as duas opções estão disponíveis, e a escolha entre elas influencia o quão fácil é conectar clientes que não sabem transmitir credenciais.

HTTP proxy: requisição com URI absoluto, o que o proxy vê e pode alterar

Uma requisição HTTP comum a um site tem esta cara:

GET /catalog/items?page=2 HTTP/1.1
Host: shop.example

Repare: na linha de requisição está apenas o caminho. O host vai em um cabeçalho separado. Esse formato se chama origin-form. Quando o cliente sabe que está falando não com o site, mas com o proxy, ele muda o formato para absolute-form: a URI completa vai na linha de requisição.

GET http://shop.example/catalog/items?page=2 HTTP/1.1
Host: shop.example
Proxy-Authorization: Basic dXNlcjpwYXNz
User-Agent: my-parser/1.0
Accept: text/html

Por que duplicar o host? Historicamente, a forma absoluta surgiu antes do cabeçalho Host e era a única maneira de dizer ao proxy para onde ir. O padrão HTTP/1.1 moderno exige que o proxy saiba aceitar a forma absoluta e que os clientes que se comunicam com o proxy usem exatamente essa forma. O cabeçalho Host é mantido para compatibilidade e para o servidor de destino, a quem o proxy reencaminhará a requisição já em origin-form.

O que o HTTP proxy vê

No modo transparente (sem criptografia entre o cliente e o site de destino), o proxy vê absolutamente tudo o que existe na requisição e na resposta:

• método, URL completo, incluindo parâmetros de query;
• todos os cabeçalhos da requisição: User-Agent, Cookie, Authorization, Referer;
• o corpo inteiro da requisição: formulários, JSON, arquivos enviados;
• status da resposta, cabeçalhos da resposta e corpo da resposta.

Isso não é efeito colateral. É característica fundamental da arquitetura: para encaminhar a requisição, o proxy é obrigado a interpretá-la. E, como ele a interpretou, pode fazer com ela o que quiser.

O que o HTTP proxy pode alterar

O padrão divide os cabeçalhos em end-to-end (ponta a ponta) e hop-by-hop (salto a salto). Os cabeçalhos hop-by-hop pertencem a uma conexão específica e devem ser removidos pelo proxy antes do encaminhamento. Entre eles estão Connection, Keep-Alive, Proxy-Authorization, Proxy-Authenticate, TE, Trailer, Transfer-Encoding, Upgrade. É por isso que seu login e senha do proxy não voam para o site de destino: o cabeçalho Proxy-Authorization é removido no proxy por padrão.

Além da limpeza obrigatória, o proxy pode:

• adicionar o cabeçalho Via com o nome e a versão do protocolo; o padrão exige isso, mas, na prática, proxies anônimos o omitem;
• adicionar X-Forwarded-For com o IP real do cliente; é o que fazem proxies corporativos e o que nunca deveria fazer um proxy comprado para trabalhar com recursos externos;
• entregar a resposta do seu próprio cache, sem consultar o servidor de destino, se a resposta estiver marcada como cacheável;
• alterar a codificação do corpo, adicionar ou remover compactação, reescrever links no HTML;
• rejeitar a requisição com uma resposta própria, como 403 ou 407.

A resposta 407 Proxy Authentication Required merece menção à parte. Se o proxy exige autenticação e o cliente não a enviou, o proxy responde com o nome 407 e o cabeçalho Proxy-Authenticate, em que lista os esquemas suportados. Bons clientes repetem a requisição com Proxy-Authorization. Clientes ruins mostram ao usuário um erro incompreensível. Daí o problema típico de configuração: a aplicação “não vê o proxy”, quando na verdade ela simplesmente não sabe tratar 407.

Na prática

A forma mais simples de ver tudo isso com os próprios olhos: curl com a flag -v.

curl -v -x http://user:pass@gate.proxeon.net:8080 http://httpbin.org/get

Na saída você verá uma linha do tipo GET http://httpbin.org/get HTTP/1.1 e o cabeçalho Proxy-Authorization. Essa é a forma absoluta.

A mesma requisição feita na mão, via socket, em Python, para que não reste magia:

import socket, base64

creds = base64.b64encode(b"user:pass").decode()
req = (
"GET http://httpbin.org/get HTTP/1.1\r\n"
"Host: httpbin.org\r\n"
f"Proxy-Authorization: Basic {creds}\r\n"
"Connection: close\r\n\r\n"
)
s = socket.create_connection(("gate.proxeon.net", 8080))
s.sendall(req.encode())
print(s.recv(65535).decode(errors="replace"))

Aqui não há nenhuma biblioteca de proxy. Apenas um socket e uma string bem montada. O HTTP proxy no modo transparente é tão simples que dá para escrever um em uma noite, e nisso está ao mesmo tempo sua força e sua fraqueza.

Onde o nome é resolvido no modo HTTP

Na forma absoluta, o cliente entrega ao proxy o nome do host como está. A resolução é feita pelo proxy. O cliente não precisa saber o IP do servidor de destino e nenhuma consulta DNS local é realizada. Isso é prático, mas nos leva à principal limitação: o esquema descrito só funciona para HTTP não criptografado. Para HTTPS, a forma absoluta é inútil, porque a conexão TLS precisa ser estabelecida entre o cliente e o servidor de destino, e o proxy não pode entrar no meio sem quebrar o certificado. Foi para isso que se criou o CONNECT.

Método CONNECT: transformar o HTTP proxy em túnel TCP

CONNECT é um método HTTP que pede ao proxy para não encaminhar a requisição, mas estabelecer uma conexão TCP com o host e a porta indicados e, em seguida, virar um cano transparente. A requisição tem esta cara:

CONNECT shop.example:443 HTTP/1.1
Host: shop.example:443
Proxy-Authorization: Basic dXNlcjpwYXNz
Proxy-Connection: Keep-Alive

Repare no formato do destino: apenas host e porta, sem esquema e sem caminho. É o authority-form da requisição, o terceiro formato depois de origin-form e absolute-form.

Se o proxy concorda, ele responde:

HTTP/1.1 200 Connection established

O texto depois do código pode ser qualquer coisa: os clientes se orientam apenas pelo 2xx. A partir daí, o HTTP acaba. Tudo o que o cliente escreve no socket o proxy repassa byte a byte ao servidor de destino, e vice-versa. O cliente inicia o handshake TLS diretamente nesse socket, como se estivesse conectado ao servidor diretamente.

O que o intermediário vê depois do CONNECT

Aqui começa a parte mais interessante. O proxy, que até agora era onisciente, fica subitamente cego. Depois de um CONNECT bem-sucedido, o proxy sabe:

• nome do host e porta informados na linha CONNECT; essa é a única informação semântica que ele recebeu;
• o horário de abertura e fechamento da conexão;
• o volume de bytes transmitidos nos dois sentidos;
• o conteúdo do TLS ClientHello, se houver TLS dentro do túnel: ali vão em texto claro o SNI (nome do servidor), a lista de cifras suportadas e as extensões; a extensão moderna Encrypted Client Hello oculta até o SNI, mas seu suporte ainda não é generalizado;
• nada do nível HTTP: nem URL, nem cabeçalhos, nem cookies, nem corpo.

Ou seja, depois do CONNECT o HTTP proxy vê exatamente o mesmo que o SOCKS5. Host, porta, tempos, volumes. A diferença de visibilidade entre os dois protocolos só existe para o tráfego HTTP não criptografado, e em 2026 ele é muito pouco em tarefas reais.

CONNECT não precisa levar a HTTPS

Um erro de raciocínio comum: o CONNECT só serve para HTTPS. Na verdade, o padrão não restringe o conteúdo do túnel. Pelo CONNECT dá para estabelecer conexão com um servidor IMAP na porta 993, com SSH na porta 22, com qualquer serviço TCP. A questão é se a configuração do proxy permite isso. Muitos proxies HTTP públicos e corporativos só permitem CONNECT para as portas 443 e, às vezes, 80, para evitar abusos. A Proxeon permite CONNECT para portas arbitrárias, mas, se o seu software entende SOCKS5, para protocolos não-HTTP ele continua sendo a escolha mais natural, como veremos abaixo.

Exemplo: TLS via CONNECT na mão

A ferramenta openssl consegue atravessar um HTTP proxy sozinha:

openssl s_client -proxy gate.proxeon.net:8080 -connect shop.example:443 -servername shop.example

E aqui está como isso fica em Python com a biblioteca padrão, sem dependências externas:

import http.client, ssl

conn = http.client.HTTPSConnection("gate.proxeon.net", 8080,
 context=ssl.create_default_context())
conn.set_tunnel("shop.example", 443,
headers={"Proxy-Authorization": "Basic dXNlcjpwYXNz"})
conn.request("GET", "/")
resp = conn.getresponse()
print(resp.status, resp.getheader("server"))

O método set_tunnel faz exatamente o que descrevemos: envia o CONNECT, espera o 200 e então envolve o socket em TLS. Note que o contexto TLS valida o certificado de shop.example, não o do proxy. O proxy, nesse esquema, não pode substituir o certificado sem provocar erro no cliente.

CONNECT em HTTP/2 e HTTP/3

Em HTTP/2 o método CONNECT foi mantido, mas funciona dentro de uma única conexão multiplexada: cada túnel é um stream separado. Isso permite manter dezenas de túneis em uma só conexão TCP com o proxy e economizar nos handshakes. O CONNECT estendido (com o pseudo-cabeçalho :protocol) é usado para WebSocket sobre HTTP/2. Em HTTP/3, baseado em QUIC, surgiu a especificação CONNECT-UDP, que formalmente permite tunelar UDP por um HTTP proxy. No entanto, nas bibliotecas de cliente isso ainda é exotismo e, na prática, se você precisa de UDP através de proxy, vai olhar para o SOCKS5.

O que o CONNECT não faz

• Cache: o conteúdo do túnel é opaco.
• Modificar cabeçalhos: eles simplesmente não aparecem.
• Multiplexar vários hosts de destino por um só túnel em HTTP/1.1: um CONNECT equivale a uma conexão TCP.
• Transportar UDP em HTTP/1.1 e HTTP/2.

SOCKS5: handshake, autenticação e ATYP

O SOCKS5 está descrito na RFC 1928, e seu esquema de autenticação por login e senha, na RFC 1929. As duas especificações cabem em poucas páginas, e essa é uma das vantagens do protocolo: implementá-lo do zero não é difícil, o que significa que há muitas implementações e elas raramente divergem na interpretação.

O SOCKS5 é um protocolo binário. Sem texto, apenas bytes de estrutura fixa. Vejamos a troca completa para o comando CONNECT.

Passo 1: saudação e escolha do método de autenticação

O cliente envia a versão e a lista de métodos de autenticação que suporta:

05 02 00 02
VER=5 NMETHODS=2 METHODS: 00 (sem autenticação), 02 (login/senha)

O servidor escolhe um método e responde com dois bytes:

05 02
VER=5 METHOD=02 (servidor exige login/senha)

Se o servidor responder 05 FF, isso significa “nenhum dos métodos oferecidos serve”, e o cliente é obrigado a fechar a conexão. É exatamente assim, no nível dos bytes, que se parece a situação em que você esqueceu de informar a senha e o proxy Proxeon está configurado para autenticação por login.

Passo 2: autenticação conforme a RFC 1929

Se o método escolhido for 02, o cliente envia:

01 04 75 73 65 72 04 70 61 73 73
VER=1 ULEN=4 UNAME="user" PLEN=4 PASSWD="pass"

Repare: a versão do subprotocolo aqui é 01, não 05. Esse é um erro frequente em clientes feitos à mão. O servidor responde:

01 00
VER=1 STATUS=00 (sucesso; qualquer outro valor indica recusa)

Login e senha são transmitidos em texto claro. Se entre você e o proxy houver uma rede não confiável, vale lembrar disso. Na prática, a conexão com o proxy costuma passar por um canal próprio do provedor, e a questão se resolve no nível do transporte ou com a substituição pela autorização por IP.

Passo 3: requisição de conexão

Agora a mensagem mais importante:

05 01 00 03 0C 73 68 6F 70 2E 65 78 61 6D 70 6C 65 01 BB
VER=5 CMD=01 (CONNECT) RSV=00 ATYP=03 (domínio)
LEN=12 ADDR="shop.example" PORT=0x01BB (443)

O campo CMD aceita três valores: 01 CONNECT (conexão TCP de saída), 02 BIND (espera por conexão de entrada, praticamente não usado), 03 UDP ASSOCIATE (criação de um retransmissor UDP). A mecânica do UDP ASSOCIATE e suas armadilhas estão em um artigo separado sobre UDP no SOCKS5, aqui só registramos: é o único dos dois protocolos que tem UDP de forma nativa.

ATYP: domínio vs IP

O campo ATYP determina em que forma o cliente transmitiu o endereço de destino:

• 0x01 IPv4: os próximos 4 bytes são o endereço;
• 0x03 nome de domínio: um byte de comprimento e, em seguida, o nome sem terminador nulo;
• 0x04 IPv6: os próximos 16 bytes são o endereço.

Parece um detalhe técnico. Na verdade, é uma das decisões mais importantes que o cliente toma, e veja por quê.

Se o cliente usa ATYP=0x01 ou 0x04, significa que ele mesmo fez a resolução DNS antes de enviar a requisição. Sua máquina consultou seu servidor DNS, obteve o endereço e passou ao proxy um IP já pronto. Consequências:

• a consulta DNS saiu pela sua rede local e é visível ao seu provedor ou administrador;
• você recebeu o IP que o DNS entregou para a sua região; em sites atrás de CDN, isso significa que o proxy, estando em outro país, vai acessar um edge server “errado”, o que atrasa a conexão e pode parecer anômalo;
• se sua máquina não tem IPv6, você nunca receberá o registro AAAA e não usará a rota IPv6 do proxy, mesmo que ela exista;
• se o DNS da sua rede se comporta de forma não padrão, o proxy receberá um endereço incorreto, e você perderá um bom tempo procurando a causa.

Se o cliente usa ATYP=0x03, a resolução é feita pelo proxy. Ele usa sua própria infraestrutura DNS, recebe o endereço relevante para sua localização, e sua rede local não vê a quais domínios você acessa. Para tarefas com georreferência isso é crítico: o sentido do proxy em um determinado país se perde em parte se o servidor de destino for escolhido pelo DNS da sua rede doméstica.

Como fazer o cliente enviar o domínio? Depende do cliente. Em curl e nas bibliotecas Python, isso é decidido pela escolha entre os esquemas socks5 e socks5h, e esse é o tema de um artigo separado. Aqui é importante entender a razão: a letra h significa “hostname” e ativa o ATYP=0x03. Sem ela, a biblioteca resolve o nome localmente.

Passo 4: resposta do servidor

05 00 00 01 C0 A8 01 0A 1F 90
VER=5 REP=00 (sucesso) RSV=00 ATYP=01 BND.ADDR=192.168.1.10 BND.PORT=8080

O campo REP contém o código de resultado. Vale a pena conhecê-los de cor na hora de depurar:

• 00 sucesso;
• 01 erro geral do servidor;
• 02 conexão proibida por regras;
• 03 rede inacessível;
• 04 host inacessível;
• 05 conexão recusada pelo servidor de destino;
• 06 TTL expirado;
• 07 comando não suportado;
• 08 tipo de endereço não suportado.

O código 08 aparece em implementações antigas ou simplificadas que não suportam ATYP=0x03 ou IPv6. A Proxeon suporta os três tipos de endereço.

Por que o SOCKS5 não inspeciona o conteúdo

Depois da resposta REP=00, o protocolo SOCKS5 terminou. Tudo o que o cliente escrever em seguida o proxy repassa à conexão de destino sem análise. Isso não é limitação de implementação, é propriedade do design. O SOCKS5 não tem noção de “requisição” nem de “cabeçalho”. Ele não sabe o que é HTTP, IMAP ou TLS. Passaram a ele um endereço e uma porta, ele conectou dois canos.

Disso decorrem várias consequências práticas:

• o SOCKS5 não pode fazer cache: ele não entende onde termina uma resposta e começa outra;
• o SOCKS5 não pode adicionar cabeçalhos nem substituir conteúdo; no máximo, pode fechar a conexão;
• o SOCKS5 não pode filtrar por URL, apenas por host e porta;
• o SOCKS5 funciona igualmente bem com qualquer protocolo TCP, inclusive aquele que você inventou ontem.

Handshake SOCKS5 completo em Python

import socket, struct

def socks5_connect(proxy, user, pwd, host, port):
s = socket.create_connection(proxy)
s.sendall(b"\x05\x02\x00\x02")
ver, method = s.recv(2)
if method == 0x02:
u, p = user.encode(), pwd.encode()
s.sendall(b"\x01" + bytes([len(u)]) + u + bytes([len(p)]) + p)
if s.recv(2)[1] != 0:
raise RuntimeError("auth failed")
elif method != 0x00:
raise RuntimeError("no acceptable auth method")
h = host.encode()
s.sendall(b"\x05\x01\x00\x03" + bytes([len(h)]) + h + struct.pack("!H", port))
reply = s.recv(4)
if reply[1] != 0:
raise RuntimeError(f"connect failed, REP={reply[1]}")
atyp = reply[3]
s.recv({1: 4, 4: 16}.get(atyp, 0) if atyp != 3 else s.recv(1)[0])
s.recv(2)
return s

sock = socks5_connect(("gate.proxeon.net", 1080), "user", "pass", "shop.example", 443)
# depois, sock pode ser envolvido em ssl.wrap_socket ou entregue a qualquer protocolo

Trinta linhas, e você tem um cliente SOCKS5 funcional, que envia o domínio (ATYP=0x03) e deixa a resolução para o servidor proxy. É justamente essa simplicidade que faz do SOCKS5 o padrão de fato para acesso programável.

Comparação por critérios: onde cada um ganha

Agora que a mecânica dos dois protocolos foi desmontada até os bytes, a comparação deixa de ser uma discussão de gosto e passa a ser uma lista de diferenças mensuráveis.

Protocolos não-HTTP

O SOCKS5 funciona com qualquer protocolo TCP de forma nativa: comando CONNECT, host, porta, pronto. O HTTP proxy também consegue via CONNECT, mas com ressalvas: o cliente precisa saber enviar CONNECT para tráfego não-HTTP (clientes de email sabem, a maioria das ferramentas de linha de comando não), e o proxy precisa permitir a porta necessária. Vencedor: SOCKS5.

UDP

O SOCKS5 tem o UDP ASSOCIATE. O HTTP proxy nas versões 1.1 e 2 não tem nada, e o CONNECT-UDP do HTTP/3 praticamente não é suportado pelos clientes. Se a tarefa inclui consultas DNS diretas, QUIC, protocolos de voz ou tráfego de jogos, não há escolha. Vencedor: SOCKS5, com a ressalva de que nem todo servidor SOCKS5 habilita UDP; verifique na documentação do seu plano.

Overhead no estabelecimento de conexão

Vamos contar em round-trips (RTT) entre o cliente e o proxy, além do próprio handshake TCP:

• HTTP proxy, modo transparente, sem autenticação: 0 RTT adicionais, a requisição sai imediatamente;
• HTTP CONNECT com autenticação na primeira requisição: 1 RTT (CONNECT, resposta 200);
• SOCKS5 sem autenticação: 2 RTT (saudação, requisição);
• SOCKS5 com login e senha: 3 RTT (saudação, autenticação, requisição).

Em bytes, a diferença se inverte: o handshake completo do SOCKS5 com autenticação cabe em cerca de 40 bytes, enquanto um CONNECT com cabeçalhos Host, Proxy-Authorization e User-Agent facilmente ocupa 150 ou mais. Mas, em tarefas reais, o que decide é o RTT, não os bytes. Com latência até o proxy de 50 ms, o SOCKS5 com autenticação adiciona 150 ms a cada nova conexão, contra 50 ms do CONNECT. Se o cliente reusa conexões (keep-alive, pools), esse é um custo único. Se cada requisição abre um novo socket, a diferença se acumula. Vencedor em RTT: HTTP. Como reduzir a distância no SOCKS5: autorização por IP, que elimina um RTT.

Cache

Só o HTTP proxy no modo transparente. Nem CONNECT, nem SOCKS5. E ele só consegue cachear tráfego não criptografado, que hoje é pouco, então esse critério deixou de ser decisivo e virou nicho. Ele é relevante para sistemas internos de build, espelhos de pacotes e requisições repetidas a APIs sem TLS dentro de um perímetro confiável. Vencedor: HTTP, mas com escopo estreito.

Logging

Esse ponto costuma ser mal compreendido. O que o proxy consegue registrar em cada modo?

• HTTP transparente: URL completo, método, cabeçalhos e, se quiser, corpo; status da resposta; volumes.
• HTTP CONNECT: host e porta da linha CONNECT; horário; volumes; e, se quiser, o SNI do ClientHello.
• SOCKS5 com ATYP=0x03: nome de domínio e porta; horário; volumes; e, se quiser, o SNI.
• SOCKS5 com ATYP=0x01/0x04: apenas IP e porta; o proxy não conhece o domínio; horário; volumes; SNI.

Para tráfego criptografado, CONNECT e SOCKS5 dão ao intermediário a mesma visibilidade. A diferença aparece só onde o cliente SOCKS5 envia IP em vez de domínio, e aí o proxy sabe ainda menos. Mas o servidor de destino, nesse caso, recebe a requisição da “região errada”; ver a seção sobre ATYP. Empate com nuances.

Diagnóstico de erros

O HTTP proxy responde com códigos legíveis por humanos: 407 indica autenticação, 403 indica proibição, 502 indica destino inacessível, 504 indica timeout. Algumas implementações acrescentam um corpo com explicação. O SOCKS5 responde com um único byte REP, e nem toda biblioteca traduz isso em uma mensagem clara. Ao depurar em ambiente desconhecido, o HTTP proxy é mais fácil de diagnosticar. Vencedor: HTTP.

Multiplexação

Um proxy HTTP/2 permite conduzir vários túneis CONNECT por uma única conexão. O SOCKS5 exige uma conexão TCP separada para cada destino. Para clientes com centenas de conexões paralelas, isso reduz sensivelmente a carga na pilha de rede e no proxy. Mas o suporte a HTTP/2 no lado do cliente ainda é fragmentado. Vencedor potencial: HTTP; empate na prática.

Possibilidade de intervenção no tráfego

O HTTP proxy no modo transparente pode alterar tudo. No modo CONNECT e no SOCKS5, ele só pode encerrar a conexão. Para o cliente que quer garantias de imutabilidade do tráfego, o melhor é SOCKS5 ou CONNECT com TLS dentro. Vencedor em previsibilidade: SOCKS5.

Autenticação

Os dois sabem login e senha. O HTTP ainda suporta os esquemas Digest, NTLM e Negotiate, o que importa em ambientes corporativos. O SOCKS5 tem formalmente o método GSSAPI, mas em proxies comerciais ele praticamente não aparece. Para trabalhar com um serviço como a Proxeon, isso não faz diferença: usa-se Basic ou lista de IPs permitidos.

O que escolher para cada tarefa: tabela

Vamos reunir as conclusões em uma ferramenta de trabalho. A tabela parte do princípio de que os dois modos estão disponíveis no mesmo IP, como na Proxeon, e a questão é apenas qual porta indicar.

Algoritmo de escolha em quatro passos

1. Determine o protocolo interno. Se não for HTTP nem HTTPS, vá de SOCKS5 e não pense duas vezes.
2. Verifique o que o cliente sabe fazer. Abra a documentação dele e procure por socks5, proxy, CONNECT. Se não houver SOCKS5 ou se ele for sem autenticação, a escolha foi feita por você.
3. Decida onde o domínio deve ser resolvido. Se a região importa (CDN, conteúdo geodependente, monitoramento), vá de SOCKS5 com envio de domínio ou HTTP CONNECT: nos dois casos, quem resolve é o proxy.
4. Avalie o perfil das conexões. Muitas conexões curtas sem pool: olhe para o RTT do handshake, escolha HTTP CONNECT ou ative a autorização por IP.

Compatibilidade em clientes e bibliotecas populares

A teoria acaba onde começam os clientes reais. Abaixo está uma análise do comportamento das ferramentas mais difundidas, conforme o estado em 2026. Verifique as versões atuais: o comportamento muda a cada release.

curl

Suporta tudo. Esquemas no parâmetro -x ou em variáveis de ambiente: http://, https:// (TLS até o próprio proxy), socks4://, socks4a://, socks5://, socks5h://. A diferença entre socks5 e socks5h está em um artigo separado; aqui, guarde: para resolução no proxy, é preciso usar socks5h.

curl -x socks5h://user:pass@gate.proxeon.net:1080 https://shop.example/
curl -x http://user:pass@gate.proxeon.net:8080 https://shop.example/

As variáveis de ambiente http_proxy, https_proxy e all_proxy são lidas automaticamente; all_proxy aceita também esquemas SOCKS.

wget

Apenas HTTP proxy. SOCKS não é suportado de forma alguma. Se precisar de wget via SOCKS5, será necessário um proxyficador de sistema.

Python: requests

HTTP proxy de fábrica. Para SOCKS5, é preciso o pacote PySocks (instalado como requests[socks]).

import requests

proxies = {
"http": "socks5h://user:pass@gate.proxeon.net:1080",
"https": "socks5h://user:pass@gate.proxeon.net:1080",
}
r = requests.get("https://shop.example/api/items", proxies=proxies, timeout=15)
print(r.status_code, r.headers.get("cf-ray"))

Para HTTPS através de HTTP proxy, o requests usa CONNECT automaticamente. Para HTTP através de HTTP proxy, usa a forma absoluta.

Python: httpx

HTTP proxy de fábrica; SOCKS5 via pacote socksio (httpx[socks]). O esquema socks5:// no httpx envia o domínio ao servidor proxy. Suporta async, o que o torna prático para tarefas paralelas.

import httpx, asyncio

async def main():
async with httpx.AsyncClient(proxy="socks5://user:pass@gate.proxeon.net:1080") as c:
r = await c.get("https://shop.example/")
print(r.status_code)

asyncio.run(main())

Python: aiohttp

HTTP proxy nativo. SOCKS5 via pacote aiohttp-socks com a classe ProxyConnector, cujo parâmetro rdns controla onde acontece a resolução.

Node.js: fetch e undici

O fetch nativo do Node.js usa o undici, que tem o ProxyAgent para HTTP proxy. Para SOCKS5, usa-se um agente separado do ecossistema, como o socks-proxy-agent para os módulos http/https.

import { ProxyAgent, fetch } from "undici";

const agent = new ProxyAgent({
 uri: "http://gate.proxeon.net:8080",
 token: "Basic " + Buffer.from("user:pass").toString("base64"),
});
const res = await fetch("https://shop.example/", { dispatcher: agent });
console.log(res.status);

Go

O net/http padrão suporta HTTP proxy via Transport.Proxy e variáveis de ambiente. Desde o Go 1.13, o esquema socks5:// em HTTP_PROXY também é aceito pela biblioteca padrão. Para controle fino, usa-se o pacote golang.org/x/net/proxy.

package main

import (
"fmt"
"net/http"
"net/url"
)

func main() {
u, _ := url.Parse("socks5://user:pass@gate.proxeon.net:1080")
tr := &http.Transport{Proxy: http.ProxyURL(u)}
client := &http.Client{Transport: tr}
resp, err := client.Get("https://shop.example/")
if err != nil {
panic(err)
}
fmt.Println(resp.Status)
}

Em Go, o esquema socks5 envia o domínio ao proxy: nenhuma resolução local é realizada.

Java

HTTP proxy via propriedades de sistema http.proxyHost, https.proxyHost ou via objeto Proxy com Type.HTTP. SOCKS via socksProxyHost e Proxy.Type.SOCKS. A autenticação se faz pela classe Authenticator. A partir do JDK 8u111, o esquema Basic para HTTPS via CONNECT vem desabilitado por padrão na propriedade jdk.http.auth.tunneling.disabledSchemes, e é preciso limpá-la, senão você recebe 407 sem explicação. Essa é uma das causas mais frequentes de chamados ao suporte.

.NET

O HttpClient com SocketsHttpHandler suporta HTTP proxy via WebProxy. O suporte a SOCKS4, SOCKS4a e SOCKS5 apareceu no .NET 6 e é ativado pela mesma construção WebProxy, com endereço no formato socks5://host:port.

Navegadores

Navegadores Chromium usam as configurações de proxy do sistema ou a flag --proxy-server. HTTP proxy com autenticação funciona: o navegador exibe um diálogo de login. SOCKS5 via configurações do sistema funciona sem autenticação; não dá para informar login e senha. Para SOCKS5 com senha, é preciso uma extensão com API de proxy ou autorização por IP. O Firefox tem configurações próprias de proxy, suporta SOCKS5 e a opção “Proxy DNS when using SOCKS v5”, que ativa o ATYP=0x03. A autenticação para SOCKS5 no Firefox também não existe nativamente.

Clientes de email

O Thunderbird usa configurações de proxy semelhantes às do Firefox e sabe usar SOCKS5 para IMAP e SMTP. Muitos outros clientes de email de desktop têm uma seção própria de proxy SOCKS5 nas configurações da conta. Via HTTP proxy, o email só funciona se o cliente souber enviar CONNECT para as portas 993 e 465, o que é raro.

Proxyficadores de sistema

Para aplicações sem configurações próprias de proxy, existem programas que interceptam chamadas de rede no nível do sistema e as redirecionam para SOCKS5 ou HTTP proxy. Praticamente todos preferem SOCKS5 como transporte justamente porque ele não depende do protocolo interno. Se sua tarefa inclui esse tipo de ferramenta, deixe a porta SOCKS5 pronta.

Checklist de compatibilidade

• O cliente suporta SOCKS5? Ele sabe enviar login e senha em SOCKS5?
• O cliente resolve o domínio sozinho ou o entrega ao proxy? Existe alguma configuração de remote DNS?
• O cliente trata corretamente o 407 e repete a requisição com autenticação?
• O cliente usa CONNECT para HTTPS ou tenta enviar URI absoluto com esquema https (algumas bibliotecas antigas fazem isso, e não funciona)?
• O cliente reutiliza conexões com o proxy ou abre uma nova a cada requisição?

Casos da prática de engenharia

Os números abaixo são típicos dos cenários descritos e servem para entender a ordem de grandeza do efeito, não como resultado garantido.

Caso 1: monitoramento de vitrines em diferentes regiões

Uma equipe acompanhava disponibilidade e preços em suas próprias vitrines regionais através de proxies de vários países. Usavam Python e requests com o esquema socks5://. De vez em quando as métricas mostravam o preço “errado” para a região, embora a vitrine funcionasse corretamente. A causa: a biblioteca resolvia o domínio localmente, no país do escritório, e entregava ao proxy um IP já pronto do edge server do CDN. O proxy do outro país se conectava honestamente a esse endereço, e o CDN entregava o conteúdo tendo determinado a região pelo seu próprio nó, não pelo IP do cliente. Trocar o esquema para socks5h transferiu a resolução para o proxy. A proporção de medições anômalas caiu a praticamente zero, e o tempo mediano de resposta diminuiu cerca de um terço, porque o proxy passou a acessar o nó do CDN mais próximo dele.

Caso 2: frota de coletores com conexões curtas

Um serviço de agregação de preços públicos fazia até centenas de milhares de requisições por dia via SOCKS5 com login e senha, abrindo uma nova conexão a cada requisição. O profiling mostrou que os três RTT do handshake por conexão, com latência até o proxy de cerca de 40 ms, geravam 120 ms de overhead por requisição, cerca de um quarto do tempo total. Duas mudanças: ativaram um pool de conexões no cliente HTTP e migraram para autorização por IP, eliminando um RTT. O tempo total de varredura da lista caiu cerca de 30%, sem alterar a quantidade de proxies. O protocolo foi mantido em SOCKS5, porque trocar para HTTP CONNECT daria menos ganho do que o pool.

Caso 3: caixas de email e IMAP

O time de suporte implantava um cliente de email de desktop para várias representações regionais, em que cada caixa deveria se conectar ao servidor de email através do IP de uma região específica. A primeira tentativa com HTTP proxy falhou: o cliente não sabia usar CONNECT para IMAP. A migração para a porta SOCKS5 da Proxeon resolveu a tarefa em minutos, porque o cliente tinha configuração nativa de SOCKS5 para cada conta. Sem software adicional.

Caso 4: aplicação Java e o misterioso 407

Um integrador corporativo conectava um serviço Java a uma API externa através de HTTP proxy com autenticação Basic. O proxy retornava 407 de forma consistente, embora as credenciais estivessem corretas e o curl com os mesmos parâmetros funcionasse. A causa: a partir de certa atualização do JDK, a autenticação Basic para túneis CONNECT vem desabilitada por padrão. Uma flag da JVM limpando jdk.http.auth.tunneling.disabledSchemes resolveu o problema. Aqui foi útil justamente o fato de o HTTP proxy responder com código legível: o 407 apontou imediatamente a direção da busca, enquanto o SOCKS5, em situação análoga, retornaria 05 FF, e sem conhecer o protocolo seria mais difícil entender.

Equívocos comuns

• “SOCKS5 é mais seguro que HTTP proxy.” Para tráfego criptografado, os dois protocolos dão ao intermediário a mesma visibilidade: host, porta, tempos, volumes, SNI. A segurança do conteúdo é garantida pelo TLS, não pelo protocolo de proxy. A diferença existe apenas para HTTP não criptografado, onde o HTTP proxy transparente vê tudo.
• “HTTP proxy não funciona com HTTPS.” Funciona via CONNECT. Esse é o mecanismo padrão e onipresente: é assim que todos os navegadores acessam sites HTTPS através de proxies corporativos.
• “SOCKS5 é mais rápido porque é binário.” No estabelecimento da conexão, o SOCKS5 com autenticação gasta mais RTT que o HTTP CONNECT. Na transferência de dados, nenhum dos dois adiciona nada: depois do handshake, nos dois casos é um cano TCP limpo. A velocidade é determinada pelo canal do proxy, não pelo protocolo.
• “CONNECT só serve para a porta 443.” O padrão não restringe a porta. Quem restringe é a configuração de cada proxy.
• “SOCKS5 sempre resolve o domínio no proxy.” Só se o cliente enviar ATYP=0x03. Muitas bibliotecas, por padrão, resolvem localmente e enviam o IP.
• “HTTP proxy sempre adiciona X-Forwarded-For e revela meu IP.” Esse é o comportamento de configurações corporativas específicas, não uma propriedade do protocolo. Proxies comerciais não adicionam esses cabeçalhos, e no modo CONNECT seria fisicamente impossível adicioná-los.
• “O proxy vê minha senha do proxy em texto claro, então a do site também.” A senha do proxy é transmitida ao proxy e, por padrão, não é reencaminhada. A senha do site, dentro do túnel TLS, o proxy não vê.
• “Como o SOCKS5 não inspeciona o conteúdo, não dá para limitá-lo.” O proxy pode limitar por host de destino, porta, volume, velocidade e número de conexões. Só não por URL.
• “As portas HTTP e SOCKS5 de um mesmo provedor são servidores diferentes.” Em geral, é o mesmo servidor e o mesmo IP de saída; muda apenas o protocolo na entrada. Na Proxeon é exatamente assim.
• “No navegador, SOCKS5 com senha se configura igual ao HTTP.” Não. As configurações de sistema do Chromium e do Firefox não transmitem credenciais em SOCKS5. É preciso autorização por IP ou extensão.

FAQ

O site de destino consegue identificar se eu vim por HTTP proxy ou por SOCKS5?

Não. O servidor de destino vê apenas a segunda conexão, do proxy até ele, e ela é, nos dois casos, um TCP comum a partir do IP do proxy. A única exceção: o HTTP proxy transparente, que adiciona cabeçalhos Via ou X-Forwarded-For. No modo CONNECT e no SOCKS5 isso é impossível.

Se eu usar HTTP proxy para HTTPS, o proxy pode espiar ou substituir o conteúdo?

Só se ele fizer interceptação TLS com troca de certificado, e aí seu cliente vai acusar erro de validação de certificado, a menos que você tenha instalado manualmente o certificado raiz confiável desse proxy. Em operação normal, depois do CONNECT o proxy vê um fluxo criptografado e não consegue ler nem alterar seu conteúdo.

Por que SOCKS5 com senha não funciona no Chrome, mas HTTP proxy com senha funciona?

A implementação da pilha de rede do Chromium suporta diálogo de autenticação para HTTP proxy pelo mecanismo 407, mas não implementa o método 0x02 da RFC 1929 para SOCKS5. É uma decisão dos desenvolvedores do navegador, não uma limitação do protocolo. Solução: autorização por endereço IP no painel da Proxeon ou uma extensão que gerencie o proxy pela API.

O que fazer se o proxy retornar REP=05 em SOCKS5?

O código 05 significa que o servidor de destino recusou a conexão TCP: porta fechada, serviço não iniciado ou firewall do destino bloqueando o IP do proxy. Verifique se você informou a porta correta e tente outro endereço de proxy. O proxy em si está funcionando; o problema está na segunda metade do caminho.

Qual a diferença entre REP=02 no SOCKS5 e 403 no HTTP proxy?

Semanticamente, é a mesma coisa: o proxy recusou estabelecer a conexão segundo suas regras. Normalmente isso significa que a porta ou o host de destino é proibido pela política do proxy. No HTTP proxy, o corpo da resposta 403 às vezes traz uma explicação; no SOCKS5, apenas o byte.

Posso usar o mesmo login e senha para a porta HTTP e a porta SOCKS5?

Na Proxeon, sim: a conta é compartilhada, muda apenas a porta e o protocolo. Ao trocar de protocolo, não é preciso mudar as credenciais.

Como saber se meu cliente resolve o domínio localmente ou no proxy?

A forma mais confiável: capturar o tráfego na sua interface e verificar se uma consulta DNS para o domínio de destino sai antes da conexão com o proxy. Uma forma mais simples: colocar temporariamente no arquivo hosts um endereço claramente errado para o domínio de destino. Se a requisição via proxy continuar funcionando, quem resolve é o proxy. Se quebrar, quem resolve é o cliente.

Vale a pena usar HTTP/2 até o proxy, se a biblioteca suportar?

Se você tem muitas conexões paralelas para destinos diferentes e o cliente realmente multiplexa streams CONNECT, o ganho será perceptível: menos conexões TCP, menos handshakes. Mas o suporte a esse recurso em clientes e servidores proxy ainda é irregular. Consulte a documentação do seu cliente e confirme se o seu plano suporta HTTP/2 na entrada.

Por que no HTTP proxy existe URI absoluto, se há o cabeçalho Host?

O padrão HTTP/1.1 exige que o cliente use a forma absoluta ao se comunicar com o proxy, para que o proxy entenda sem ambiguidade que a requisição deve ser encaminhada, e não processada localmente. O cabeçalho Host é mantido porque o proxy reencaminhará a requisição ao servidor de destino já em origin-form, e lá o Host é obrigatório. A duplicação é o preço da compatibilidade.

O que importa mais para scraping: HTTP ou SOCKS5?

Para alvos HTTPS, não há diferença de visibilidade; a diferença está no comportamento da biblioteca. Se a biblioteca funciona bem com SOCKS5 e envia o domínio, vá de SOCKS5: ele não corre o risco de mexer nos cabeçalhos e garante a resolução regional correta. Se a biblioteca é caprichosa com SOCKS5 ou você tem muitas conexões curtas sem pool, o HTTP CONNECT não fica atrás. O principal conselho: não abra uma nova conexão com o proxy a cada requisição; isso custa mais caro do que qualquer escolha de protocolo.

Conclusão

Duas portas no painel não são um par de marketing do tipo “simples e avançado”. São duas línguas diferentes para falar com a mesma máquina. O HTTP proxy fala a língua das requisições e respostas, entende semântica, sabe fazer cache e explica erros com códigos legíveis, e, para tudo o que não entende, tem o CONNECT, que o transforma em túnel TCP. O SOCKS5 fala a língua do “host e porta”, não inspeciona o conteúdo, suporta qualquer protocolo TCP e UDP, e permite controlar explicitamente onde o domínio é resolvido.

Para tráfego criptografado, os dois protocolos dão ao intermediário a mesma visibilidade. A escolha entre eles não é determinada pela segurança, mas por três coisas práticas: o que seu cliente sabe fazer, qual protocolo está dentro e onde você quer resolver os nomes.

O que fazer agora

1. Determine o protocolo interno da sua tarefa. Não é HTTP: vá de SOCKS5 imediatamente.
2. Verifique na documentação do cliente o suporte a SOCKS5 com autenticação e a opção de resolução remota.
3. Se você trabalha com recursos geodependentes, garanta que o domínio vá para o proxy: socks5h, remote DNS, ATYP=0x03 ou HTTP CONNECT.
4. Ative um pool de conexões ou keep-alive até o proxy. Isso dará mais resultado do que qualquer troca de protocolo.
5. Se o cliente não sabe enviar login em SOCKS5, configure a autorização por IP no painel da Proxeon.
6. Ao depurar, comece por curl -v: ele mostra todo o diálogo com o proxy e separa imediatamente o problema do cliente do problema da rede.

E, por fim. Os dois protocolos são mais velhos que a maioria dos engenheiros que os usam, e ambos continuam funcionando sem mudanças estruturais. É um caso raro em que a simplicidade do design venceu. Entendendo o que acontece exatamente nos primeiros quarenta bytes da conexão, você deixa de escolher a porta no chute e passa a escolher a ferramenta.