Página de vendas de proxy é toda parecida. Os testes abaixo revelam o que está por trás — e podem ser feitos em poucos minutos, com um único IP contratado, antes de comprometer orçamento.
1. Confirme que o tráfego realmente passa pelo proxy
Parece óbvio, mas é o teste que mais gente pula. Um proxy "configurado" que não está roteando o tráfego é a causa mais frequente de diagnóstico errado.
# Seu IP real
curl https://api.ipify.org
# Através do proxy
curl -x http://usuario:senha@host:porta https://api.ipify.org
Os dois resultados devem ser diferentes, e o segundo deve ser o endereço contratado.
Se em vez do IP voltar um erro 407, o tráfego chegou ao proxy mas a credencial não foi aceita — o que costuma ser senha com caractere especial ou usuário no formato errado, e não defeito do produto. As causas e a correção estão em erro 407 Proxy Authentication Required.
2. Verifique a classificação do ASN
Este é o teste que revela se o produto é o que foi vendido. Um proxy anunciado como "residencial" mas com ASN de datacenter não é residencial.
curl -x http://usuario:senha@host:porta https://ipinfo.io/json
O campo org na resposta traz o ASN e o nome da organização que anuncia o bloco. Interprete assim:
- Nome de provedor de banda larga conhecido → ISP residencial legítimo
- Nome de operadora celular → mobile
- Nome de empresa de hospedagem ou cloud → datacenter
Se você pagou por ISP e o campo mostra um provedor de nuvem, o produto não corresponde à descrição. Por que o ASN importa tanto está em residencial vs datacenter.
3. Cheque a geolocalização em mais de uma fonte
Bases de geolocalização discordam entre si com frequência. Consulte pelo menos duas antes de concluir que a localização está errada.
curl -x http://usuario:senha@host:porta https://ipinfo.io/json
curl -x http://usuario:senha@host:porta https://ipapi.co/json
Divergência de cidade é normal e irrelevante. Divergência de país é problema real — significa que parte dos serviços vai enxergar você em outro lugar.
4. Meça a latência
curl -o /dev/null -s -w "conexão: %{time_connect}s | total: %{time_total}s\n" \
-x http://usuario:senha@host:porta https://www.google.com
Referências para proxy brasileiro acessado do Brasil: conexão abaixo de 0,3s, total abaixo de 1,5s.
Valores muito acima podem indicar: proxy fisicamente fora do Brasil apesar da geolocalização, rota ruim, ou uso simultâneo acima do contratado.
Repita o teste algumas vezes em horários diferentes. Latência que varia muito é mais preocupante que latência consistentemente média.
Se a latência estiver alta depois da compra, antes de trocar de IP siga o roteiro de proxy lento ou caindo, que separa rede, destino e configuração com o curl.
5. Procure indícios de compartilhamento
Não existe um teste definitivo, mas há indícios claros:
Limite de taxa atingido sem volume seu. Se um serviço reclama de excesso de requisições e você fez cinco, alguém mais está usando aquele endereço.
Verificação imediata em serviço comum. Um IP realmente novo e dedicado não deveria gerar desafio na primeira visita a um site comum.
Cookies ou sessões inesperadas. Sinal de que outro usuário passou por ali recentemente.
A pergunta direta ao fornecedor continua sendo o melhor teste: quantos clientes usam esse endereço simultaneamente? Uma resposta que não é um número é, em si, uma resposta. O impacto disso na reputação está em dedicado vs compartilhado.
6. Verifique vazamento de DNS e WebRTC
Um proxy pode estar roteando o tráfego HTTP corretamente e ainda assim vazar informação por outros caminhos.
DNS — se a resolução de nomes acontece na sua máquina, o seu resolvedor local vê todos os domínios que você acessa. Em SOCKS5, use socks5h:// em vez de socks5:// para resolver no proxy.
WebRTC — no navegador, a API de comunicação em tempo real pode expor o IP real da sua conexão mesmo com proxy ativo. Navegadores antidetecção têm configuração específica para isso. Em SOCKS5 versus HTTP, as diferenças estão no guia de protocolos.
Teste os dois em qualquer serviço de verificação de vazamento, com o proxy ativo.
7. Teste o suporte antes de precisar
Este não é um teste técnico, mas é o que mais diferencia fornecedores.
Mande uma pergunta técnica real pelo canal de suporte — algo como "qual a porta do SOCKS5 e vocês suportam resolução de DNS remota?" — e observe:
- Tempo de resposta
- Se a resposta foi técnica ou script de vendas
- Se foi em português, por alguém que entende de proxy
Suporte que não responde bem antes da compra não vai melhorar depois.
Como interpretar os resultados
| Resultado | O que significa |
|---|---|
| IP igual ao seu | O tráfego não está no proxy — configuração errada |
| ASN diferente do prometido | Produto não corresponde à descrição |
| País divergente entre fontes | Parte dos serviços vai localizar você errado |
| Latência muito alta | Proxy longe, rota ruim ou uso acima do contratado |
| Limite de taxa sem volume seu | Endereço provavelmente compartilhado |
| DNS na sua operadora | Vazamento — ajuste a resolução remota |
| WebRTC expondo seu IP | Configuração do navegador, não do proxy |
O protocolo recomendado antes de escalar
- Compre um IP, não dez
- Rode os sete testes acima
- Use em produção por uma semana no cenário real
- Teste o suporte com uma dúvida real
- Só então escale a quantidade ou considere plano longo
Fornecedor que não permite começar com um IP, ou que exige gasto mínimo alto, está pedindo confiança antes de demonstrar competência.
Se quiser os comandos completos de teste, com interpretação de cada saída, veja o guia de como testar se o proxy funciona. Para avaliar o fornecedor antes do teste, veja as 12 perguntas antes de pagar.
Dois testes deste roteiro têm um artigo só para eles, porque a saída exige interpretação: o vazamento de DNS, com a diferença entre os dois modos de SOCKS5, está em socks5 ou socks5h; e a compatibilidade do destino com IPv6, que decide se o lote barato serve para o seu caso, está em testar IPv6 antes de comprar. Se o proxy passa nos testes mas oscila depois, o roteiro de diagnóstico é proxy lento ou caindo.