Testar antes de usar economiza horas de diagnóstico. Um proxy que "parece configurado" mas não está roteando o tráfego é a causa mais frequente de problema em operação nova.
O que exatamente testar
Quatro coisas, em ordem de importância:
- O IP de saída é o que você contratou
- O país é o Brasil (ou a região esperada)
- Não há vazamento de DNS ou WebRTC expondo sua conexão real
- A latência está dentro do razoável
Teste 1 — Terminal com curl (o mais confiável)
Este é o teste que isola o proxy de tudo mais. Se ele passa, o proxy está bom.
# Descubra seu IP real, sem proxy
curl https://api.ipify.org
# Agora através do proxy
curl -x http://usuario:[email protected]:8000 https://api.ipify.org
# Via SOCKS5
curl -x socks5h://usuario:[email protected]:8000 https://api.ipify.org
Os dois comandos devem retornar endereços diferentes. O segundo deve ser o IP que você contratou.
Note o socks5h em vez de socks5: o h faz a resolução de DNS acontecer no proxy, e não na sua máquina. Sem isso, o seu resolvedor de DNS local vê os domínios que você está acessando — que é uma forma de vazamento.
Para ver detalhes da conexão quando algo falha:
curl -v -x http://usuario:[email protected]:8000 https://api.ipify.org
A saída verbosa mostra em que etapa a conexão parou: resolução de nome, conexão TCP, autenticação ou requisição.
Teste 2 — Localização e detalhes do IP
curl -x http://usuario:[email protected]:8000 https://ipinfo.io/json
O retorno em JSON traz país, região, cidade e a organização responsável pelo bloco. Esse último campo é útil: ele indica se o endereço é anunciado por um provedor de internet ou por um datacenter — a diferença entre um ISP residencial e um IPv4 comum.
Teste 3 — Latência
curl -o /dev/null -s -w "conexão: %{time_connect}s | total: %{time_total}s\n" \
-x http://usuario:[email protected]:8000 https://www.google.com
Referência prática para um proxy brasileiro acessado do Brasil: tempo de conexão abaixo de 0,3s e total abaixo de 1,5s. Valores muito acima disso pedem investigação.
Teste 4 — Dentro do navegador antidetecção
Depois de configurar o perfil, abra e verifique, na primeira aba:
- IP e país — em qualquer serviço de consulta de IP
- Vazamento de WebRTC — o IP exibido pela verificação de WebRTC deve ser o do proxy, não o seu
- Vazamento de DNS — os servidores de DNS listados não devem apontar para a sua operadora
- Fuso horário — coerente com a localização do IP
Um perfil que passa nos quatro está tecnicamente bem configurado.
Interpretando os resultados
IP diferente do contratado — o tráfego não está passando pelo proxy. Revise a configuração da ferramenta.
IP correto, país errado — improvável em IP brasileiro, mas pode acontecer quando a base de geolocalização do serviço de consulta está desatualizada. Confira em um segundo serviço antes de concluir.
WebRTC expondo seu IP real — problema de configuração do navegador, não do proxy. Ajuste o WebRTC para modo alterado nas opções do perfil.
DNS apontando para sua operadora — use socks5h em vez de socks5, ou configure a ferramenta para resolver nomes no proxy.
Latência alta — verifique, nesta ordem: VPN ativa na máquina, uso simultâneo acima do contratado, e rota da sua operadora até o proxy.
Funciona no curl mas não na ferramenta — o proxy está bom. O problema é formato de credencial ou configuração dentro da ferramenta.
Quando abrir ticket
Se o teste por curl falha, vale abrir ticket. Inclua:
- O comando que você executou (troque a senha por
***) - A saída completa, incluindo o modo verboso
- Se o mesmo proxy já funcionou antes e quando parou
Com essas três informações, o diagnóstico costuma sair na primeira resposta. Sem elas, a conversa vira uma sequência de perguntas.
Para os erros mais frequentes com sintoma e correção, veja o guia de erros comuns de configuração.