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 é:
- 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çalhoProxy-Authorization. - O proxy se conecta ao destino e retorna
200 Connection Establishedao cliente. - 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.
- 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ério | Proxy HTTP(S) | Proxy SOCKS5 |
|---|---|---|
| Camada em que atua | Camada de aplicação (HTTP) | Camada de sessão, independente de protocolo |
| Tráfego transportado | Requisições web | Qualquer tráfego TCP e UDP |
| Suporte a UDP | Não | Sim |
| Acesso aos cabeçalhos da requisição | Sim, em HTTP sem criptografia | Não |
| Cache e filtragem de conteúdo | Possível em HTTP sem criptografia | Não é possível |
| Autenticação | Sim (Proxy-Authorization) | Sim (usuário/senha) |
| Resolução de DNS | Em HTTPS, o domínio de destino é enviado ao proxy | Pode ser feita no cliente ou no proxy |
| Sobrecarga do handshake | Cabeçalhos HTTP | Poucos bytes |
| Suporte de software | Navegadores, bibliotecas HTTP, quase todas as ferramentas | Navegadores, cURL, aplicativos de desktop, clientes de jogos; algumas bibliotecas exigem pacote adicional |
| Uso típico | Extração de dados web, SEO, monitoramento de preços | Jogos, 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:443envia 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?
| Ferramenta | Proxy HTTP(S) | Proxy SOCKS5 |
|---|---|---|
| Chrome, Firefox, Edge | Sim | Sim (no Chrome, sem autenticação por senha) |
| cURL | Sim | Sim (socks5://, socks5h://) |
| wget | Sim | Não |
| Python Requests | Nativo | Com requests[socks] |
| Python HTTPX | Nativo | Com httpx[socks] |
| Node.js undici / fetch | ProxyAgent | Com pacote adicional, como socks-proxy-agent |
| Puppeteer / Playwright | Sim | Sim (autenticação por senha limitada) |
| Proxifier | Sim | Sim |
| Clientes SSH | Com ProxyCommand | Com ProxyCommand, suporte nativo |
| Clientes de jogos | Geralmente não | Com 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:
# 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/ipOs 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:
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 necessidade | Recomendação |
|---|---|
| Extração de dados web com Python ou Node.js | HTTP(S) |
| Automação de navegador com autenticação por senha | HTTP(S) |
| Ferramentas de SEO, monitoramento de preço, verificação de anúncios | HTTP(S) |
| Cliente de jogos, tráfego UDP | SOCKS5 |
| SSH, FTP, e-mail, serviço TCP personalizado | SOCKS5 |
| Aplicativo de desktop sem configuração de proxy | SOCKS5 + Proxifier |
| Manter as consultas DNS do lado do proxy | SOCKS5 (resolução remota) ou HTTP(S) |
| Download com wget | HTTP(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.




