Sumário do artigo

O mesmo servidor proxy é frequentemente entregue ao cliente em dois modos: como proxy HTTP e como SOCKS5. Muitos acham que isso é truque de marketing. Não é. Por trás dessas duas siglas estão dois protocolos de intermediação completamente diferentes, operando em camadas distintas da pilha de rede. Entender a diferença entre eles economiza horas de depuração, reduz latência e ajuda a escolher a ferramenta certa para cada tarefa de engenharia.

Neste guia, vamos destrinchar a mecânica dos dois protocolos, do primeiro byte do handshake até o último cabeçalho. Vamos ver exatamente o que o intermediário enxerga em cada modo, por que o SOCKS5 deliberadamente não inspeciona o conteúdo do tráfego e como o método CONNECT transforma um proxy HTTP comum em um túnel TCP transparente. No final, você encontra uma tabela de correspondência tarefa-protocolo e um FAQ detalhado. O tom é de engenharia: pouca enrolação, muita precisão e código.

Introdução: por que um único proxy é entregue em dois modos

Imagine uma agência dos correios. No primeiro modo, o funcionário lê o endereço no envelope, pode colocá-lo em outro envelope, carimbar e até avisar que aquela carta já chegou ontem, entregando uma cópia do arquivo. Esse é o proxy HTTP: ele entende a linguagem em que a requisição foi escrita e trabalha com o conteúdo como dados significativos.

No segundo modo, o mesmo funcionário recebe um contêiner lacrado e uma instrução: entregar no endereço tal, na porta tal, e o que tem dentro não é problema dele. Ele simplesmente constrói um tubo do remetente ao destinatário e bombeia bytes nos dois sentidos. Esse é o SOCKS5: um protocolo de camada de sessão que não se importa com o conteúdo do túnel.

Por que um provedor, como a Proxeon, oferece os dois modos na mesma infraestrutura? Porque as tarefas dos clientes são diferentes. Um precisa de cache e filtragem no nível HTTP, outro precisa de transporte transparente para um protocolo TCP qualquer. Um único servidor pode escutar portas diferentes e atender aos dois cenários. É uma decisão técnica, não jogo de palavras.

A ideia-chave para guardar desde já: o proxy HTTP opera na camada de aplicação (L7), enquanto o SOCKS5 fica mais próximo da camada de sessão (L5, informalmente). Daí decorrem todas as outras diferenças: o que o proxy enxerga, o que consegue modificar, quais protocolos suporta e qual overhead introduz.

Fundamentos: dois níveis de intermediação

Antes de aprofundar, vamos fixar os conceitos básicos. Proxy é um intermediário entre cliente e servidor de destino. O cliente envia a requisição não diretamente, mas ao proxy, que a encaminha adiante. A diferença entre os tipos de proxy está em qual nível eles compreendem o que transmitem.

Camada de aplicação versus camada de sessão

O proxy HTTP interpreta a mensagem HTTP por completo. Ele vê o método (GET, POST), o caminho, todos os cabeçalhos e, em caso não criptografado, também o corpo. Isso o torna inteligente e ao mesmo tempo limitado: só consegue trabalhar com o protocolo que entende.

O SOCKS5 não interpreta o protocolo de aplicação de forma alguma. Ele recebe do cliente um comando do tipo estabeleça uma conexão TCP com o host X na porta Y e simplesmente repassa bytes. É essa neutralidade que faz do SOCKS5 um transporte universal para qualquer protocolo TCP: HTTP, HTTPS, SMTP, IMAP e muitos protocolos proprietários do seu software.

O que significa "o proxy vê o conteúdo"

Quando dizemos que o proxy HTTP vê o conteúdo, falamos de HTTP não criptografado. Se o tráfego vai por HTTPS pelo método CONNECT (detalhado abaixo), até o proxy HTTP enxerga apenas o fluxo criptografado e o nome do host. Esse esclarecimento é importante: a web moderna é quase toda TLS, então a profundidade de visão do proxy HTTP na prática fica limitada à fase de estabelecimento do túnel.

Portas e esquemas de endereçamento

No lado do cliente, a diferença aparece em como você configura o proxy. Para proxy HTTP, o esquema é http://user:pass@host:port. Para SOCKS5, socks5://user:pass@host:port. As portas dos modos geralmente são diferentes, porque nelas escutam handlers distintos. O mesmo servidor físico da Proxeon pode entregar proxy HTTP em uma porta e SOCKS5 em outra.

Proxy HTTP: requisição com URI absoluta

Começamos pelo proxy HTTP clássico e sua característica mais marcante: a URI absoluta na linha de requisição. É isso que visualmente distingue uma requisição a proxy de uma requisição direta ao servidor.

Forma absoluta da requisição

Quando o navegador acessa um site diretamente, envia um caminho relativo. A linha de requisição fica assim:

GET /index.html HTTP/1.1
Host: example.com

Mas quando o mesmo navegador está configurado para um proxy HTTP, ele envia ao servidor proxy a forma absoluta da URI. O proxy precisa saber exatamente para onde encaminhar a requisição, então o endereço completo vai na primeira linha:

GET http://example.com/index.html HTTP/1.1
Host: example.com
Proxy-Connection: keep-alive

Essa é a diferença fundamental. O proxy lê http://example.com/index.html, extrai o host, estabelece conexão com o servidor de destino e encaminha a requisição já na forma relativa comum. A RFC 7230 determina que clientes usem absolute-form ao falar com proxies e origin-form ao falar diretamente com o servidor.

O que o proxy vê e pode modificar

No modo HTTP não criptografado, o proxy vê muita coisa. Vamos listar:

  • URL completa, incluindo caminho e parâmetros de query.
  • Todos os cabeçalhos de requisição: User-Agent, Accept, Cookie, Referer.
  • O corpo da requisição em POST ou PUT.
  • A resposta do servidor por inteiro: status, cabeçalhos e corpo.

Além disso, o proxy pode legitimamente e de forma útil modificar o tráfego. Operações típicas de proxies HTTP corporativos ou de serviço:

  • Adição de cabeçalhos de serviço, como X-Forwarded-For ou Via.
  • Remoção de cabeçalhos hop-by-hop, que não devem seguir adiante (Connection, Proxy-Authorization).
  • Cache de respostas para requisições repetidas.
  • Compressão ou transformação de conteúdo quando configurado.

Cabeçalhos específicos de proxy

Existem cabeçalhos que só fazem sentido no diálogo cliente-proxy e não devem vazar para o servidor de destino. O principal é o Proxy-Authorization, que carrega as credenciais de acesso ao próprio proxy. Não confunda com Authorization, destinado ao servidor de destino. Há também a distinção de status: 407 Proxy Authentication Required indica que o proxy exige autenticação, ao contrário do 401 vindo do servidor de destino.

Exemplo prático: proxy HTTP explícito com curl

Vamos ver como acessar o proxy HTTP da Proxeon com curl. A flag -x define o proxy, e -v mostra o diálogo:

curl -v -x http://user:pass@proxy.proxeon.net:8080 http://example.com/

Na saída, você verá a linha de requisição em forma absoluta e o cabeçalho Proxy-Authorization com as credenciais em Base64. Isso demonstra claramente que o curl fala com o proxy, e não diretamente com o servidor de destino.

Limitação: apenas semântica HTTP

O proxy HTTP clássico, em sua forma primária, só consegue encaminhar requisições HTTP. Ele não sabe o que fazer com um fluxo TCP qualquer de SMTP ou com um protocolo binário da sua aplicação. Para HTTP não criptografado, isso funciona muito bem. Mas assim que aparece HTTPS ou outro protocolo, é preciso um mecanismo de tunelamento. É aí que entra o método CONNECT.

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

O método CONNECT é o que permite ao proxy HTTP atender HTTPS e qualquer fluxo TCP. Ele transforma o intermediário inteligente de camada de aplicação em um tubo transparente. Vamos entender a mecânica passo a passo.

Por que o CONNECT foi necessário

HTTPS criptografa toda a mensagem, cabeçalhos e caminho incluídos. Se o proxy tentasse ler a URI absoluta, encontraria bytes criptografados. O handshake TLS precisa acontecer diretamente entre cliente e servidor de destino, senão a criptografia ponta a ponta se perde. Ou seja, o proxy não precisa ler nada, apenas conectar os dois pontos e sair de cena.

Como é uma requisição CONNECT

O cliente envia ao proxy uma requisição especial, em que, no lugar da URL, informa o par host-porta no formato authority:

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dХNlcjpwYXNz

O proxy estabelece conexão TCP com example.com:443 e, se tudo der certo, responde:

HTTP/1.1 200 Connection Established

A partir dessa linha, acontece algo fundamental: o proxy deixa de ser um parser HTTP. Torna-se um retransmissor bidirecional de bytes. Tudo o que o cliente enviar dali em diante é copiado para o servidor, e vice-versa. É sobre esse túnel que o navegador inicia o handshake TLS com o servidor de destino, diretamente.

O que o intermediário vê após o estabelecimento do túnel

Esse é o ponto crucial de privacidade e segurança. Depois do 200 Connection Established, o proxy HTTP vê:

  • O nome do host e a porta do próprio comando CONNECT — antes do estabelecimento do túnel.
  • O fluxo de bytes criptografado — e nada mais.
  • O SNI (Server Name Indication) dentro do ClientHello TLS, se não houver criptografia de SNI — tecnicamente isso também revela o nome do host.
  • Metadados da conexão: volume de dados transmitidos, duração, tempos.

O que o proxy NÃO vê após o túnel: caminho da URL, parâmetros de query, cabeçalhos, cookies, corpo de requisições e respostas. Tudo isso é protegido por TLS. Assim, para tráfego HTTPS, o proxy HTTP em modo CONNECT se comporta quase como SOCKS5: é só transporte. A diferença está em como o cliente negocia o túnel.

Na prática: CONNECT em ação

Quando você faz uma requisição HTTPS via proxy HTTP, o curl usa CONNECT automaticamente. Observe o diálogo:

curl -v -x http://user:pass@proxy.proxeon.net:8080 https://example.com/

Na saída verbosa, você verá primeiro a linha CONNECT example.com:443 HTTP/1.1, depois a resposta 200 Connection Established e, em seguida, as linhas do handshake TLS e a requisição GET propriamente dita, dentro do túnel criptografado. O proxy só viu a primeira parte.

CONNECT não se limita à porta 443

Apesar de o CONNECT quase sempre levar à porta 443, a especificação não o vincula ao HTTPS. Tecnicamente, é possível tunelar qualquer protocolo TCP em qualquer porta via CONNECT, se o proxy permitir. Na prática, administradores costumam limitar a lista de portas permitidas por segurança, deixando 443 e, às vezes, 22 ou outras. Portanto, tentar passar SMTP via CONNECT pode esbarrar na política do proxy.

SOCKS5: handshake, autenticação e ATYP

Agora vamos ao SOCKS5, definido na RFC 1928. É um protocolo de filosofia totalmente diferente. Ele não sabe — nem quer saber — o que você transmite. A tarefa dele é estabelecer a conexão e virar um tubo.

Lógica geral do handshake

O diálogo SOCKS5 é binário, não textual como no HTTP. Consiste em alguns intercâmbios curtos de mensagens. Em linhas gerais:

  1. O cliente envia a lista de métodos de autenticação suportados.
  2. O servidor escolhe um método e comunica a escolha.
  3. Se necessário, ocorre a autenticação.
  4. O cliente envia a requisição de conexão: comando, tipo de endereço, endereço, porta.
  5. O servidor responde com o resultado.
  6. Começa a transmissão transparente de dados.

Saudação e escolha do método

A primeira mensagem do cliente é bem compacta. Contém a versão (0x05), a quantidade de métodos oferecidos e os métodos em si. Os mais usados são dois: 0x00 — sem autenticação — e 0x02 — autenticação por usuário e senha (username/password, RFC 1929). O servidor responde com dois bytes: versão e método escolhido. Se a resposta for 0xFF, nenhum dos métodos oferecidos serviu, e a conexão é encerrada.

Autenticação por login e senha

Se o método escolhido for 0x02, o cliente envia uma mensagem separada com a versão do subprotocolo, o comprimento e o valor do nome de usuário, depois o comprimento e o valor da senha. O servidor responde com o status. Detalhe importante de engenharia: no SOCKS5 clássico, esses dados são transmitidos sem criptografia embutida, então só se deve confiar nesse tipo de proxy por canais protegidos ou em ambiente controlado. Em proxies de serviço como os da Proxeon, a autenticação pode ser complementada por vinculação de IP, o que reduz riscos de vazamento de credenciais.

Comandos: CONNECT, BIND e UDP ASSOCIATE

O SOCKS5 suporta três comandos. O mais comum é o CONNECT (0x01), que estabelece uma conexão TCP de saída. Há o BIND (0x02) para conexões de entrada em protocolos como o antigo FTP. E há o UDP ASSOCIATE (0x03) para proxiar datagramas UDP. A mecânica do UDP ASSOCIATE e as diferenças entre os esquemas socks5 e socks5h não são abordadas aqui de propósito — são temas grandes, com material específico. Aqui, focamos no ponto mais essencial para a comparação com o proxy HTTP: o campo ATYP.

ATYP: domínio versus IP e por que isso é crítico para a resolução

Na requisição de conexão do SOCKS5 existe o campo ATYP (address type), que define como interpretar o endereço seguinte. São três valores possíveis:

  • 0x01 — endereço IPv4, quatro bytes.
  • 0x03 — nome de domínio: primeiro byte é o comprimento, seguido da string.
  • 0x04 — endereço IPv6, dezesseis bytes.

Aqui está uma das diferenças práticas mais importantes. Quando o cliente envia um nome de domínio (ATYP 0x03), a resolução DNS é feita pelo servidor proxy, e não pelo cliente. Quando o cliente envia um endereço IP já resolvido, a resolução ocorreu no lado do cliente. Isso afeta qual DNS é usado, qual IP o servidor de destino verá e quão bem funciona o roteamento geodependente.

Para o engenheiro, isso significa: se é importante que o nome seja resolvido na rede do proxy, envie o domínio, não o IP. Muitas bibliotecas, por padrão, resolvem o nome localmente e só depois vão ao proxy — o que muda o comportamento. A análise detalhada das diferenças entre resolução local e remota, e entre os esquemas socks5 e socks5h, está em um artigo separado, então aqui apenas registramos a existência do campo ATYP como alavanca-chave de controle.

Na prática: SOCKS5 com curl

Acessar um proxy SOCKS5 no curl é simétrico à variante HTTP, só muda o esquema:

curl -v --socks5 user:pass@proxy.proxeon.net:1080 https://example.com/

Nesse caso, o curl não envia nenhuma linha CONNECT em texto — em vez disso, faz o handshake binário do SOCKS5 e depois bombeia o tráfego TLS pelo túnel estabelecido. Para a aplicação, a diferença é quase imperceptível, mas no nível do protocolo acontece uma conversa totalmente diferente.

Por que o SOCKS5 não inspeciona o conteúdo — e isso é sua força

A filosofia do SOCKS5 é minimalista. Ele não tenta entender se lá dentro tem HTTP, SMTP ou seu próprio protocolo. Isso o torna:

  • Universal: qualquer protocolo TCP passa sem suporte especial.
  • Leve: o handshake é curto e não há parsing de camada de aplicação.
  • Transparente: o proxy não interfere nos dados, não altera nada e não faz cache.

O outro lado da moeda: o SOCKS5 não consegue cachear, filtrar por URL nem adicionar cabeçalhos — porque simplesmente não os vê. A universalidade tem como preço a ausência de inteligência de aplicação.

Comparação por critérios: o que importa na prática

Vamos reunir as diferenças em uma comparação estruturada pelos parâmetros que realmente influenciam a escolha em tarefas de engenharia.

Suporte a protocolos não-HTTP

O SOCKS5 funciona com qualquer protocolo TCP: IMAP e SMTP de e-mail, bancos de dados, protocolos de jogos, seus próprios intercâmbios binários. O proxy HTTP clássico entende nativamente apenas HTTP. Via CONNECT, ele pode tunelar outros protocolos TCP, mas somente se o proxy permitir a porta correspondente. Na prática, isso costuma ficar limitado à 443. Conclusão: para protocolos arbitrários, o SOCKS5 é preferível.

UDP

O proxy HTTP simplesmente não trabalha com UDP — seu modelo gira em torno de requisições TCP. O SOCKS5 tem o comando UDP ASSOCIATE e é capaz de proxiar datagramas. Não detalhamos aqui sua mecânica, mas o fato em si é importante: se a tarefa exige UDP, o proxy HTTP está fora de cogitação.

Overhead

O handshake SOCKS5 é composto por algumas mensagens binárias curtas. Para uma nova conexão, isso é muito barato. O proxy HTTP em modo CONNECT gasta um round-trip adicional com o par requisição CONNECT e resposta 200 antes do início do TLS. Em cenários com muitas conexões curtas, a diferença de latência pode se acumular. Por outro lado, com keep-alive persistente e reutilização de conexões, a diferença se dilui. Para tráfego HTTP, o proxy HTTP pode levar vantagem com cache e pool de conexões.

Cache

Aqui o proxy HTTP é imbatível. Como entende a semântica HTTP, pode cachear respostas, respeitar cabeçalhos como Cache-Control e ETag e devolver 304 Not Modified. Para requisições repetidas a conteúdo estático, isso reduz sensivelmente tráfego e latência. O SOCKS5 não consegue cachear fisicamente — ele não vê o conteúdo. Se sua tarefa é acelerar requisições HTTP massivas a recursos repetidos, um proxy HTTP com cache entrega ganho real.

Logging e observabilidade

O proxy HTTP consegue manter um access log detalhado: método, URL, código de resposta, tamanho, User-Agent. Isso é valioso para auditoria, depuração e analytics — ao trabalhar com HTTP não criptografado. Para HTTPS via CONNECT, o detalhamento cai ao nível host-porta-volume. O SOCKS5 registra apenas metadados da conexão: endereço de destino, tempo, volume de tráfego. Se você precisa de observabilidade de aplicação sobre HTTP, escolha o proxy HTTP; se bastam métricas de transporte, o SOCKS5 resolve.

Modificação de tráfego

O proxy HTTP pode legitimamente adicionar e remover cabeçalhos, o que é útil para finalidades de serviço. O SOCKS5 não toca nos dados. Para cenários em que qualquer interferência é inadmissível, a transparência do SOCKS5 é uma vantagem.

Tabela-resumo das diferenças

  • Camada do modelo: proxy HTTP — aplicação L7; SOCKS5 — sessão L5.
  • Formato do diálogo: HTTP — texto; SOCKS5 — binário.
  • Protocolos não-HTTP: HTTP — apenas via CONNECT e com restrições; SOCKS5 — nativamente.
  • UDP: HTTP — não; SOCKS5 — sim.
  • Cache: HTTP — sim; SOCKS5 — não.
  • Logging de aplicação: HTTP — sim, para tráfego não criptografado; SOCKS5 — apenas metadados.
  • Modificação de cabeçalhos: HTTP — sim; SOCKS5 — não.
  • Overhead de conexão: HTTP CONNECT — round-trip adicional; SOCKS5 — mínimo.

O que escolher por tarefa: framework prático

A teoria vale quando vira solução. Abaixo, um framework de escolha e a tabela principal de correspondências. Começamos com três perguntas que você deve se fazer antes de escolher.

Três perguntas antes de escolher

  1. Qual protocolo estou transmitindo? Apenas HTTP e HTTPS — os dois servem, mas o proxy HTTP traz bônus de cache e logs. TCP ou UDP arbitrário — só SOCKS5.
  2. Preciso de observabilidade de aplicação ou cache? Se sim — proxy HTTP. Se quero um tubo transparente — SOCKS5.
  3. Onde deve ocorrer a resolução DNS? Se for importante resolver nomes no lado do proxy, considere o comportamento do ATYP e as configurações do cliente.

Tabela principal: tarefa — protocolo — por quê

  • Navegador, uso comum — proxy HTTP ou SOCKS5 — os dois funcionam; o proxy HTTP adiciona cache e compatibilidade com políticas corporativas, o SOCKS5 é mais simples para portas não padrão.
  • Cliente HTTP para integrações de API — proxy HTTP — suporte nativo, configuração fácil por variáveis de ambiente, logs detalhados para depuração.
  • Coleta massiva de dados via HTTPS — SOCKS5 ou proxy HTTP — sob HTTPS, os dois são apenas transporte; o SOCKS5 economiza um round-trip em conexões curtas, o proxy HTTP é prático com pool de conexões.
  • Cliente de e-mail (SMTP, IMAP, POP3) — SOCKS5 — protocolos de e-mail não são HTTP; o proxy HTTP via CONNECT costuma ser bloqueado por porta.
  • Software próprio com protocolo TCP binário — SOCKS5 — transporte universal para qualquer TCP, sem suporte especial.
  • Aplicação que requer UDP — SOCKS5 — única opção via UDP ASSOCIATE; o proxy HTTP não faz UDP.
  • Acelerar acesso a conteúdo estático repetido — proxy HTTP com cache — consegue devolver respostas em cache e economizar tráfego.
  • Auditoria e log detalhado de requisições HTTP — proxy HTTP — vê métodos, URLs e códigos quando o HTTP não é criptografado.
  • Trabalhar com vários protocolos ao mesmo tempo em uma aplicação — SOCKS5 — um único transporte cobre todos os intercâmbios TCP.

Checklist de escolha

  • Defina o protocolo da aplicação: HTTP, outro TCP ou UDP.
  • Decida se precisa de cache e log de aplicação.
  • Verifique se seu cliente suporta o esquema de proxy necessário.
  • Confirme com o provedor quais portas estão abertas para CONNECT, caso planeje tunelar algo fora da 443.
  • Pense em onde deve ocorrer a resolução DNS.
  • Planeje a autenticação: login-senha ou por IP.

Compatibilidade em clientes e bibliotecas populares

Escolher o protocolo não faz sentido sem saber configurá-lo nas ferramentas concretas. Vamos passar pelas típicas.

curl

O curl suporta os dois protocolos. Para proxy HTTP use -x http://...; para SOCKS5 use --socks5 ou -x socks5://.... Há também a variante com resolução remota do nome no lado do proxy SOCKS5, definida por um esquema específico; os detalhes ficam em material especializado. Exemplo:

curl -x socks5://user:pass@proxy.proxeon.net:1080 https://api.example.com/v1/status

Variáveis de ambiente

Muitos utilitários de linha de comando e bibliotecas respeitam as variáveis http_proxy, https_proxy e all_proxy. A última costuma aceitar o esquema SOCKS5. Isso é prático para configuração global sem mexer no código:

export https_proxy=http://user:pass@proxy.proxeon.net:8080
export all_proxy=socks5://user:pass@proxy.proxeon.net:1080

Python: requests e httpx

A biblioteca requests se configura com um dicionário proxies. Para SOCKS5, é necessário um pacote adicional com suporte a SOCKS:

import requests
proxies = {"http": "http://user:pass@proxy.proxeon.net:8080", "https": "http://user:pass@proxy.proxeon.net:8080"}
r = requests.get("https://example.com/", proxies=proxies, timeout=10)
print(r.status_code)

Para SOCKS5, o esquema muda para socks5, e para resolução remota aplica-se um esquema específico. A biblioteca httpx funciona de modo parecido e suporta requisições assíncronas, o que é prático em operações massivas.

Node.js

No ecossistema Node, o proxy é definido por agentes específicos. Para proxy HTTP, usa-se https-proxy-agent; para SOCKS, socks-proxy-agent. Em linhas gerais:

const { SocksProxyAgent } = require('socks-proxy-agent');
const agent = new SocksProxyAgent('socks5://user:pass@proxy.proxeon.net:1080');
fetch('https://example.com/', { agent }).then(r => console.log(r.status));

Navegadores

Navegadores suportam os dois tipos via configurações do sistema ou arquivos PAC. A família Chromium aceita a flag de inicialização com o servidor proxy, e o Firefox tem configurações próprias, incluindo a opção de proxiar DNS ao usar SOCKS. É justamente nos navegadores que surge com mais frequência a questão de quem resolve o nome — detalhes em um artigo separado sobre os esquemas SOCKS.

Clientes de e-mail

Clientes de e-mail clássicos geralmente suportam SOCKS5 como transporte para SMTP e IMAP. Proxy HTTP para e-mail raramente se aplica, e só via CONNECT, o que costuma esbarrar nas restrições de porta. Conclusão prática: para e-mail, considere SOCKS5 por padrão.

Software próprio

Se você escreve a aplicação, o SOCKS5 se implementa com uma biblioteca de transporte ou um wrapper sobre sockets. Para um cliente HTTP interno, o mais simples é usar o suporte nativo a proxy HTTP da biblioteca HTTP escolhida. Conselho essencial: não invente o parser do handshake SOCKS na mão; use bibliotecas confiáveis — protocolos binários são fáceis de errar em casos-limite.

Equívocos comuns

Há muitos mitos sobre o tema. Vamos desmontá-los em lista para você não perder tempo com premissas falsas.

  • "SOCKS5 é sempre mais rápido que proxy HTTP". Nem sempre. Em conexões curtas, o SOCKS5 economiza um round-trip, mas um proxy HTTP com cache e pool pode superá-lo em requisições HTTP repetidas.
  • "SOCKS5 criptografa o tráfego". Não. O SOCKS5 não adiciona criptografia. A privacidade vem do TLS dentro do túnel, não do SOCKS5 em si. Até as credenciais do SOCKS5 clássico trafegam sem criptografia embutida.
  • "O proxy HTTP vê tudo, inclusive HTTPS". Não. Para HTTPS via CONNECT, o proxy só vê nome de host, porta e volume. O conteúdo é protegido por TLS.
  • "Proxy HTTP e SOCKS5 são a mesma coisa em portas diferentes". Não. São protocolos distintos. Coincidir o endereço do servidor não os torna idênticos.
  • "SOCKS5 não suporta autenticação". Suporta — pelo método username/password da RFC 1929, e também pode haver vinculação por IP.
  • "Não dá para usar protocolos não-HTTP via proxy HTTP". Dá, via CONNECT, desde que o proxy permita a porta necessária.
  • "Se o navegador está configurado para SOCKS5, o DNS sempre resolve no proxy". Nem sempre. Depende das configurações do cliente e de se é enviado o domínio ou o IP pronto no campo ATYP.
  • "CONNECT só funciona para 443". Tecnicamente não, mas administradores costumam restringir portas por política.
  • "SOCKS5 sabe cachear". Não. Ele não vê o conteúdo e fisicamente não consegue fazer cache.

Ferramentas e recursos para trabalhar

Para trabalhar com segurança nos dois protocolos, é útil ter à mão um conjunto de ferramentas de diagnóstico e verificação.

Diagnóstico de conexões

  • curl com a flag -v — a melhor forma de ver o diálogo real: a linha CONNECT, a resposta do proxy, o handshake TLS.
  • Analisador de tráfego — mostra o handshake binário do SOCKS5 e a diferença para o diálogo HTTP textual no nível de pacotes.
  • Utilitários de verificação de portas — ajudam a entender quais portas estão disponíveis para CONNECT no seu proxy.

Bibliotecas

  • Python — requests e httpx com extensão de suporte a SOCKS.
  • Node.js — agentes https-proxy-agent e socks-proxy-agent.
  • Integração sistêmica — variáveis de ambiente http_proxy, https_proxy, all_proxy.

O que verificar ao conectar à Proxeon

  • O esquema correto: http para proxy HTTP, socks5 para SOCKS5.
  • A porta correta para cada modo — elas são diferentes.
  • O método de autenticação: login-senha ou vinculação por IP.
  • A lista de portas permitidas para CONNECT, se você planeja tunelar algo fora da 443.
  • O comportamento do DNS: onde exatamente você quer resolver os nomes.

Mini-framework de depuração

  1. Repita a requisição diretamente, sem proxy — confirme que o destino está acessível.
  2. Repita com proxy e a flag -v — estude o diálogo.
  3. Se o HTTPS não estabelece — verifique se a porta está liberada para CONNECT.
  4. Se o nome não resolve — verifique se domínio ou IP está sendo enviado ao proxy.
  5. Se vier 407 — confira as credenciais e o cabeçalho Proxy-Authorization.

Casos e resultados de aplicação

Vamos ver alguns cenários típicos de engenharia e como a escolha do protocolo afeta o resultado. Os números são ilustrativos e servem para mostrar dependências, não como promessa de marketing.

Caso 1: integração de API com serviço externo

Uma equipe integrou seu backend a uma API REST externa via proxy da Proxeon para controlar o endereço de saída. Inicialmente escolheram SOCKS5, mas esbarraram no fato de que a biblioteca HTTP padrão se configurava mais facilmente com proxy HTTP via variáveis de ambiente. A migração para proxy HTTP simplificou a configuração, e o access log detalhado das chamadas de serviço não criptografadas ajudou a encontrar rapidamente causas de erros 5xx do parceiro. Conclusão: para API HTTP pura, o proxy HTTP é mais conveniente.

Caso 2: gateway de e-mail

Um serviço enviava notificações por SMTP através de um endereço de saída fixo. A tentativa de usar proxy HTTP via CONNECT falhou: o proxy só permitia a 443. A migração para SOCKS5 resolveu na hora, porque o SOCKS5 é neutro em relação ao protocolo e conectou na 587 sem restrições no nível de entendimento da camada de aplicação. Conclusão: para protocolos não-HTTP, o SOCKS5 é a escolha natural.

Caso 3: coleta massiva de dados públicos via HTTPS

Ao coletar um grande número de páginas por HTTPS, engenheiros compararam os dois modos. Em muitas conexões curtas, o SOCKS5 apresentou uma latência média de estabelecimento ligeiramente menor, pela ausência do round-trip extra do CONNECT. Quando ativaram a reutilização de conexões e keep-alive pelo proxy HTTP, a diferença praticamente desapareceu. Conclusão: em conexões curtas, o SOCKS5 economiza no handshake; em conexões longas, a diferença é irrelevante.

Caso 4: protocolo binário próprio de telemetria

Uma empresa transmitia telemetria por um protocolo TCP próprio. O proxy HTTP não servia conceitualmente — o protocolo não era HTTP. O SOCKS5 virou o único transporte razoável: a aplicação abria um socket comum via agente SOCKS5, e o protocolo funcionava sem alterações. Conclusão: para TCP arbitrário, o SOCKS5 é insubstituível.

Caso 5: acelerar acesso a conteúdo estático

Um serviço interno acessava com frequência o mesmo conjunto de recursos estáticos via HTTP. Um proxy HTTP com cache reduziu bastante o tráfego de saída e o tempo de resposta, graças à entrega de representações em cache e ao tratamento correto de requisições condicionais. O SOCKS5 não conseguiria oferecer essa otimização de forma alguma. Conclusão: onde há repetição de requisições HTTP, o proxy HTTP com cache traz ganho mensurável.

FAQ: perguntas frequentes

Posso usar a mesma conta Proxeon para HTTP e SOCKS5?

Em geral, sim — só mudam o esquema e a porta de conexão. Verifique no seu painel quais portas correspondem a cada modo e qual método de autenticação está configurado. Tecnicamente, é o mesmo recurso entregue em dois modos.

O que escolher se não tenho certeza de qual protocolo preciso?

Se sua aplicação trabalha exclusivamente com HTTP e HTTPS, comece com proxy HTTP: é mais simples de configurar e dá logs com cache. Se aparecer pelo menos um protocolo não-HTTP ou UDP, escolha SOCKS5, que é um transporte mais universal.

Por que, em HTTPS, a diferença entre proxy HTTP e SOCKS5 é quase imperceptível?

Porque, em HTTPS, o conteúdo é protegido por TLS, e os dois tipos de proxy atuam apenas como transporte. O proxy HTTP, nesse caso, via CONNECT vira o mesmo tubo que o SOCKS5. A única diferença é a forma de negociar o túnel: CONNECT textual versus handshake binário.

A escolha do protocolo influencia quem faz a resolução DNS?

Sim, indiretamente. No SOCKS5, isso é regulado pelo campo ATYP: se é enviado um domínio, o proxy resolve; se é IP, o cliente resolve. No proxy HTTP, o nome da URL ou da linha CONNECT também pode ser resolvido no lado do proxy. O comportamento exato depende do cliente e de suas configurações — e a análise detalhada está em material separado.

É seguro transmitir login e senha no SOCKS5?

O SOCKS5 clássico não criptografa credenciais de forma embutida. Use-o em ambiente confiável ou com medidas adicionais de proteção. Para proxies de serviço, costuma haver vinculação por IP, o que reduz a dependência de enviar a senha em cada conexão.

Posso tunelar qualquer porta via CONNECT?

Tecnicamente, a especificação não proíbe, mas na prática o administrador do proxy costuma restringir a lista de portas por segurança. Na maioria dos casos, só a 443 é liberada. Se você precisa de uma porta não padrão, consulte a política ou considere o SOCKS5, que é neutro em relação a portas.

O SOCKS5 oferece mais anonimato que o proxy HTTP?

Por si só, não. O anonimato é definido não pelo tipo de protocolo, mas pelos metadados transmitidos e registrados, e pela proteção TLS do tráfego. O proxy HTTP pode adicionar cabeçalhos de serviço que revelam o cliente, mas isso pode ser evitado com configuração correta. O SOCKS5 não adiciona cabeçalhos de aplicação simplesmente porque não os vê.

O que acontece se o servidor de destino atrás do proxy estiver indisponível?

O proxy HTTP retorna um código de erro HTTP, como 502 ou 504. O SOCKS5 retorna um código de erro na resposta ao comando de conexão — por exemplo, host inalcançável ou conexão recusada. Nos dois casos, o cliente recebe um sinal claro, mas em formatos diferentes: texto no HTTP e binário no SOCKS5.

Preciso de um proxy separado para UDP?

Só o SOCKS5 suporta UDP, via comando UDP ASSOCIATE. O proxy HTTP não trabalha com UDP. A mecânica desse comando é detalhada em um artigo separado; aqui basta lembrar do fato: se precisa de UDP, é território do SOCKS5.

Como saber se o proxy está realmente funcionando no modo certo?

O jeito mais confiável é executar uma requisição via curl com a flag -v e observar o diálogo. Para proxy HTTP, você verá a URI absoluta ou a linha CONNECT; para SOCKS5, a ausência de diálogo HTTP textual até a requisição em si e o código de resposta correto. Também vale verificar o endereço de saída em um serviço que mostra seu IP.

Conclusão: como tomar a decisão certa

Percorremos o caminho da filosofia dos dois protocolos até linhas concretas de código. Vamos resumir de modo técnico e direto.

O proxy HTTP é um intermediário inteligente de camada de aplicação. Entende HTTP, vê e pode modificar requisições não criptografadas, sabe cachear e manter logs detalhados. Seu método CONNECT o transforma em um túnel TCP para HTTPS e outros protocolos, com a ressalva das portas permitidas. Escolha-o quando trabalhar predominantemente com HTTP e HTTPS e valorizar observabilidade e cache.

O SOCKS5

Sobre o autor

Andrey Kokh

Andrey Kokh

Leading Expert and Business Consultant

Experiência profissional: Leading expert with 12 years of experience. Consults Forbes-listed companies, author of 3 books. Teaches at HSE and SKOLKOVO. His methodologies are used by hundreds of companies across Russia. RBC and Forbes expert on strategic development and digital transformation.
Formação: Higher School of Economics. Faculty of Economics, Master's Program
Especialização:
Strategic Consulting Digital Transformation Change Management Business Strategy Innovation Management Organizational Development Lean Management Agile Transformation

Compartilhe este artigo: