Diferença entre SOCKS e HTTP proxy: qual escolher?

Publicado:

12 min de leitura

Acar Diveroli
Autor: Acar Diveroli
Comparação entre proxy HTTP e SOCKS: ícone de envelope e túnel de várias faixas

Ao comprar um proxy, a primeira escolha técnica que costuma aparecer é o protocolo: HTTP(S) ou SOCKS5? Os dois roteiam o seu tráfego por outro IP, mas fazem isso em camadas diferentes e com capacidades diferentes. O proxy HTTP reconhece requisições web e trabalha com elas. Já o proxy SOCKS transporta os bytes de uma ponta a outra sem se importar com o que o aplicativo está enviando.

Neste artigo explicamos passo a passo como os dois protocolos funcionam, as diferenças na prática, os detalhes de DNS e criptografia, o suporte de software e qual escolher em cada trabalho. Se você quiser se aprofundar nos detalhes técnicos do SOCKS5, o artigo O que são proxies SOCKS5? é um bom complemento.

Como o proxy HTTP funciona?

Como o nome já diz, o proxy HTTP fala o protocolo HTTP. Ele se comporta de forma diferente em duas situações:

  • Em requisições HTTP sem criptografia, o cliente envia toda a requisição ao proxy. O proxy lê a requisição, encaminha ao destino e devolve a resposta. Nesse processo, ele consegue ver, colocar em cache ou até alterar os cabeçalhos.
  • Em requisições HTTPS, o cliente primeiro envia ao proxy uma requisição CONNECT destino.com:443. O proxy abre uma conexão TCP com o destino e, a partir daí, apenas transporta os bytes criptografados. Ele não consegue ver o conteúdo. Esse método é definido na RFC 9110.

Ou seja, na web de hoje, dominada por HTTPS, um proxy HTTP tem acesso não ao conteúdo do site, mas apenas ao domínio e à porta a que ele se conecta.

O caminho de uma requisição HTTPS via proxy é:

  1. O cliente se conecta ao proxy via TCP e envia CONNECT destino.com:443 HTTP/1.1; se necessário, autentica sua identidade com o cabeçalho Proxy-Authorization.
  2. O proxy se conecta ao destino e retorna 200 Connection Established ao cliente.
  3. Dentro dessa conexão, o cliente faz o handshake TLS com o destino. A validação do certificado ocorre entre o cliente e o destino.
  4. O tráfego HTTP criptografado flui pelo túnel; o proxy só transporta bytes.

A expressão "proxy HTTPS" costuma se referir a essa capacidade de tunelamento; a conexão com o próprio proxy geralmente é HTTP sem criptografia. Por isso, os endereços de proxy começam com http:// mesmo para sites HTTPS.

Como o proxy SOCKS funciona?

O SOCKS funciona de forma independente do protocolo do aplicativo. O cliente diz ao proxy "conecte-se a tal endereço, tal porta"; o servidor SOCKS estabelece a conexão e transporta o tráfego entre as duas pontas tal como está. Se o tráfego do outro lado é web, jogo, e-mail ou banco de dados, isso não importa para ele.

A versão atual, SOCKS5, é definida pela RFC 1928 e adiciona três recursos importantes em relação ao antigo SOCKS4:

  • Autenticação (usuário e senha, RFC 1929),
  • Suporte a UDP (para tráfego baseado em UDP, como jogos, chamadas de voz e DNS),
  • Conexão por nome de domínio, ou seja, a resolução de DNS pode ser feita do lado do proxy; além de suporte a endereço IPv6.

Uma conexão SOCKS5 também é estabelecida em algumas etapas: o cliente informa os métodos de autenticação que suporta, o servidor escolhe um, a identidade é autenticada, e então o cliente envia o endereço e a porta de destino. Depois que o servidor estabelece a conexão, dados brutos fluem nos dois sentidos. Esse handshake tem apenas alguns bytes; é menor que os cabeçalhos HTTP.

As diferenças principais

CritérioProxy HTTP(S)Proxy SOCKS5
Camada em que atuaCamada de aplicação (HTTP)Camada de sessão, independente de protocolo
Tráfego transportadoRequisições webQualquer tráfego TCP e UDP
Suporte a UDPNãoSim
Acesso aos cabeçalhos da requisiçãoSim, em HTTP sem criptografiaNão
Cache e filtragem de conteúdoPossível em HTTP sem criptografiaNão é possível
AutenticaçãoSim (Proxy-Authorization)Sim (usuário/senha)
Resolução de DNSEm HTTPS, o domínio de destino é enviado ao proxyPode ser feita no cliente ou no proxy
Sobrecarga do handshakeCabeçalhos HTTPPoucos bytes
Suporte de softwareNavegadores, bibliotecas HTTP, quase todas as ferramentasNavegadores, cURL, aplicativos de desktop, clientes de jogos; algumas bibliotecas exigem pacote adicional
Uso típicoExtração de dados web, SEO, monitoramento de preçosJogos, aplicativos de desktop, protocolos fora da web

Por que a resolução de DNS é importante?

Uma das diferenças menos conhecidas, mas mais importantes, entre os dois protocolos é onde o nome de domínio é convertido em IP.

  • No proxy HTTP, a requisição CONNECT destino.com:443 envia o nome de domínio ao proxy; a resolução é feita pelo proxy. Nenhuma consulta chega ao servidor DNS do próprio cliente.
  • No SOCKS5, existem duas opções. O cliente pode resolver o nome de domínio ele mesmo e enviar o IP (no cURL, socks5://), ou deixar a resolução para o proxy (no cURL, socks5h://). Na primeira opção, a consulta DNS sai da sua própria rede; isso significa que os sites a que você se conecta podem ser vistos pela rede local, e o site de destino pode entregar ao proxy um servidor distante em vez do mais próximo de você.

Regra prática: ao usar SOCKS5, prefira a resolução remota. Nas bibliotecas, isso costuma ser configurado com o esquema socks5h ou uma opção de "resolução DNS remota"; algumas ferramentas fazem resolução local por padrão, e essa diferença passa despercebida.

Qual é mais rápido?

De modo geral, o SOCKS5 tem menos sobrecarga, porque faz menos trabalho: não interpreta as requisições, apenas as transporta. Já em tráfego HTTPS, o proxy HTTP também transporta apenas bytes depois do túnel CONNECT, então a diferença praticamente desaparece.

Na prática, a velocidade é determinada muito mais pela localização do servidor proxy, o tipo de IP e a qualidade do link do que pelo protocolo. Escolher um ponto de saída próximo ao servidor de destino faz muito mais diferença do que trocar de protocolo. Explicamos como essa diferença é medida em jogos no artigo Solução para ping e perda de pacotes em jogos; e o efeito do tipo de IP na velocidade no artigo Diferença entre proxy residencial e datacenter.

Existe diferença em segurança e privacidade?

Nenhum dos dois protocolos criptografa o tráfego. A criptografia vem do protocolo usado pelo serviço de destino: HTTPS na web, SSH em shell remoto, TLS em e-mail. Nesse sentido, dizer que "o SOCKS5 é mais seguro" ou "o proxy HTTP é mais seguro" está errado; os dois são igualmente meros transportadores.

Dois pontos os diferenciam:

  • Visibilidade em HTTP sem criptografia. Se você se conecta a um site HTTP sem criptografia via proxy HTTP, o proxy pode ler toda a requisição; o SOCKS5 transporta os mesmos bytes, só não os interpreta. Ou seja, em termos de privacidade não há diferença: em ambos os casos, o tráfego está sem criptografia.
  • Vazamento de DNS. Como explicado acima, se você faz resolução local no SOCKS5, os sites que você acessa podem ser vistos pela rede local. No proxy HTTP esse risco não existe, porque o domínio sempre é enviado ao proxy.

Se você quer entender a diferença de criptografia entre proxy e VPN, veja nosso artigo Diferença entre proxy e VPN.

Em que situação escolher proxy HTTP?

  • Extração de dados web e automação. Bibliotecas Python como Requests, HTTPX e AIOHTTP suportam proxy HTTP sem exigir pacote adicional. Tratamos as diferenças entre essas bibliotecas na nossa comparação entre HTTPX, Requests e AIOHTTP; mostramos o lado Node.js no artigo cURL em JavaScript.
  • Se você só está roteando tráfego web. Em navegador, ferramentas de SEO ou software de monitoramento de preços, o proxy HTTP oferece a maior compatibilidade.
  • Ferramentas de linha de comando. Para testes rápidos com cURL e wget, o proxy HTTP funciona diretamente. Vale lembrar que o wget não tem suporte nativo a SOCKS; os detalhes estão no artigo Uso de proxy com o wget.
  • Automação de navegador. Puppeteer, Playwright e Selenium suportam autenticação por usuário e senha com proxy HTTP; no SOCKS5, o Chrome não suporta essa autenticação.
  • Rede corporativa e cache. Colocar em cache ou filtrar tráfego HTTP sem criptografia só é possível com proxy HTTP.

A opção adequada para tráfego web são os pacotes de Proxies HTTPS.

Em que situação escolher proxy SOCKS5?

  • Jogos e aplicativos de desktop. Clientes de jogos não são navegadores web; comunicam-se com protocolos próprios e, muitas vezes, via UDP. Esse tráfego só pode ser transportado pelo SOCKS5. Explicamos as configurações do lado dos jogos nos nossos guias de Knight Online e Silkroad Online.
  • Protocolos fora da web. SSH, FTP, e-mail ou serviços TCP personalizados.
  • Forçar um aplicativo a usar proxy. Programas que não oferecem configuração de proxy podem ser roteados via SOCKS5 com ferramentas como o Proxifier. Você encontra a configuração no nosso guia do Proxifier.
  • Evitar vazamento de DNS. Quando você quer que a resolução de nome de domínio seja feita do lado do proxy (como no esquema socks5h:// do cURL).
  • Sobrecarga baixa. Em aplicativos que abrem muitas conexões curtas, o handshake pequeno do SOCKS5 pode fazer uma diferença mensurável.

Para esses cenários, vale conferir os pacotes de Proxies SOCKS5.

Suporte de software: o que cada ferramenta suporta?

FerramentaProxy HTTP(S)Proxy SOCKS5
Chrome, Firefox, EdgeSimSim (no Chrome, sem autenticação por senha)
cURLSimSim (socks5://, socks5h://)
wgetSimNão
Python RequestsNativoCom requests[socks]
Python HTTPXNativoCom httpx[socks]
Node.js undici / fetchProxyAgentCom pacote adicional, como socks-proxy-agent
Puppeteer / PlaywrightSimSim (autenticação por senha limitada)
ProxifierSimSim
Clientes SSHCom ProxyCommandCom ProxyCommand, suporte nativo
Clientes de jogosGeralmente nãoCom ferramenta de redirecionamento

Como a tabela mostra, o suporte ao proxy HTTP é mais difundido; já o SOCKS5, onde é suportado, transporta uma gama mais ampla de tráfego.

O mesmo proxy pode suportar os dois protocolos?

Sim. Muitos provedores oferecem o mesmo IP tanto pela porta HTTP quanto pela porta SOCKS5; o esquema no endereço de conexão determina o protocolo. Testar o mesmo proxy das duas formas com o cURL é a maneira mais rápida de ver a diferença:

bash
# Via proxy HTTP
curl -x "http://kullanici:parola@pr.proxynet.io:8000" https://httpbin.org/ip

# Via SOCKS5, com resolução de DNS do lado do proxy
curl -x "socks5h://kullanici:parola@pr.proxynet.io:1080" https://httpbin.org/ip

Os dois comandos devem retornar o mesmo IP de saída. O endereço e a porta variam de acordo com o seu pacote; encontre os valores corretos no seu painel de cliente. Para outras opções de proxy no cURL, veja nosso artigo Como usar proxy com o cURL?.

Se quiser fazer o mesmo teste em Python com o Requests:

python
import requests

HTTP_PROXY = "http://kullanici:parola@pr.proxynet.io:8000"
SOCKS_PROXY = "socks5h://kullanici:parola@pr.proxynet.io:1080"  # pip install "requests[socks]"

for proxy in (HTTP_PROXY, SOCKS_PROXY):
    r = requests.get("https://httpbin.org/ip", proxies={"http": proxy, "https": proxy}, timeout=20)
    print(proxy.split("://")[0], r.json()["origin"])

Guia de decisão

Sua necessidadeRecomendação
Extração de dados web com Python ou Node.jsHTTP(S)
Automação de navegador com autenticação por senhaHTTP(S)
Ferramentas de SEO, monitoramento de preço, verificação de anúnciosHTTP(S)
Cliente de jogos, tráfego UDPSOCKS5
SSH, FTP, e-mail, serviço TCP personalizadoSOCKS5
Aplicativo de desktop sem configuração de proxySOCKS5 + Proxifier
Manter as consultas DNS do lado do proxySOCKS5 (resolução remota) ou HTTP(S)
Download com wgetHTTP(S)

Perguntas frequentes

O SOCKS5 criptografa o tráfego?

Não. O SOCKS5 transporta o tráfego tal como está. O que garante a privacidade da conexão é a criptografia usada pelo serviço de destino (por exemplo, HTTPS ou SSH). O mesmo vale para o proxy HTTP.

Qual devo usar no navegador?

Se você só acessa sites, os dois funcionam. O proxy HTTP tem suporte mais difundido e todo navegador suporta autenticação por senha; o SOCKS5 traz vantagem quando você quer deixar a resolução de DNS a cargo do proxy. Para gestão de perfil por navegador, veja nossos guias de SwitchyOmega e configuração de proxy no Firefox.

Posso usar SOCKS5 em Python?

Pode, mas depende de pacote adicional conforme a biblioteca. Para o Requests, instale requests[socks]; para o HTTPX, httpx[socks]; depois use o esquema socks5:// ou socks5h:// no endereço do proxy.

O SOCKS4 ainda é usado?

Algumas ferramentas antigas o suportam, mas, por não ter autenticação, UDP nem suporte a nome de domínio, não é indicado em instalações novas. Se um provedor diz "SOCKS", hoje isso costuma significar SOCKS5.

Proxy HTTP e proxy HTTPS são a mesma coisa?

No uso do dia a dia, sim: "proxy HTTPS" significa um proxy HTTP capaz de acessar sites HTTPS via túnel CONNECT. Tecnicamente também existe uma forma em que se fala com o próprio proxy via TLS, mas não é comum e a maioria dos clientes não a suporta.

Como sei qual protocolo o meu proxy suporta?

O painel do provedor geralmente informa a porta de acordo com o protocolo; HTTP e SOCKS5 costumam ter portas diferentes. Se não tiver certeza, teste os dois comandos cURL acima: tentar conectar com o protocolo errado gera erro de conexão ou resposta sem sentido, e o protocolo correto retorna o IP.

Em resumo

Se você está roteando tráfego web, o proxy HTTP(S) oferece a maior compatibilidade e funciona logo de cara na maioria das ferramentas de extração de dados. Para jogos, aplicativos de desktop, tráfego UDP ou protocolos fora da web, o SOCKS5 é a única opção correta; nesse caso, não esqueça de deixar a resolução de DNS do lado do proxy. A diferença de velocidade é determinada mais pela localização e pelo tipo de IP do proxy do que pelo protocolo. Confira nossas soluções de proxy para pacotes que suportam os dois protocolos.