Como testar proxies: 6 métodos práticos

Um proxy defeituoso raramente passa despercebido. Ele manifesta-se como scrapes falhados, contas banidas, geolocalização misteriosamente errada ou páginas que parecem CAPTCHAs em vez de produtos. Mesmo os proxies premium beneficiam de uma verificação prévia rápida, porque erros de configuração (porta errada, protocolo errado, credenciais expiradas) são responsáveis por uma percentagem surpreendente das falhas no mundo real. Encare o teste de proxies como um seguro barato: alguns segundos curl agora poupa horas de depuração de uma recolha de 30 000 páginas mais tarde, independentemente de o conjunto de proxies ser gratuito ou pago.

A maioria dos guias sobre como testar proxies apresenta-lhe uma lista simples de ferramentas. Um modelo mais útil são os cinco sinais de integridade que todos os proxies devem passar:

1. Conectividade. O host do proxy aceita uma ligação TCP na porta anunciada.
2. IP de saída e localização geográfica. O tráfego sai do IP, país e ISP que esperas.
3. Velocidade e latência. O tempo de ida e volta está dentro da sua tolerância para o site de destino.
4. Nível de anonimato. O proxy oculta o seu IP real e não se anuncia.
5. Tipo e reputação do IP. O IP é do tipo correto e não está na lista negra.

Comece com a verificação mais simples. A partir do seu terminal:

ping pr.example-proxy.com
curl -x http://proxy.example.com:8000 https://httpbin.org/ip --connect-timeout 10

Um ping retorna métricas de tempo de resposta, indicando que o host está ativo. O curl chamada vai um passo além: encaminha efetivamente um pedido através do proxy e apresenta o IP de saída que httpbin.org/ip foi visto. Se obtiver um IP diferente do seu IP real, o proxy HTTP está a encaminhar o tráfego.

O ping por si só não é suficiente. Ele apenas confirma a acessibilidade do host, não se o proxy aceitará tráfego HTTP ou SOCKS, se o autenticará ou se renderizará o destino sem um CAPTCHA.

Configure o seu navegador ou shell para usar o proxy e carregue qualquer página genérica de verificação de IP. A página revela o IP público de onde a sua solicitação sai, além do país, cidade e ISP.

Três aspetos a verificar: o país corresponde ao que o seu fornecedor lhe indicou, o ISP é plausível para o tipo de proxy (ASN residencial para planos residenciais, não um ASN de centro de dados) e a página ainda não sinaliza o IP como um proxy conhecido. Os verificadores online são limitados, por isso combine este teste de verificação com as verificações na base de dados do Método 3.

Dois tipos diferentes de bases de dados são importantes aqui, e confundir os dois é um erro comum.

Bases de dados de localização e tipo de IP, como IP2Location e MaxMind, indicam como é um IP: país, ASN e se parece pertencer a um centro de dados ou a uma ligação residencial. Se comprou proxies residenciais e o MaxMind classifica o IP como pertencente a um centro de dados, o site de destino recebe o mesmo sinal e irá bloquear mais rapidamente.

Bases de dados de reputação de IP, como a AbuseIPDB, indicam se o IP teve um comportamento inadequado: relatórios de spam, abuso de scraping, tentativas de força bruta ou histórico de DDoS. Um IP residencial pode parecer impecável na MaxMind e, mesmo assim, ter uma pilha de relatórios de abuso recentes. Uma má reputação desencadeia bloqueios automáticos em muitos WAFs, por isso, trate a reputação como um teste de proxy de primeira classe.

Os testadores baseados na web vão além de uma simples página de IP. Ferramentas como o FOGLDN Proxy Tester e o hidemy.name informam a velocidade e o anonimato. Com base na documentação atual, espere suporte para HTTP, HTTPS e, em alguns casos, SOCKS, além de uma leitura de anonimato em quatro níveis:

• Sem anonimato: o destino vê o seu IP real e o proxy.
• Baixo anonimato: o proxy é detetado, mas o seu IP real fica oculto.
• Anonimato médio: o destino recebe um IP falso, mas ainda deteta o proxy.
• Anonimato elevado (de elite): nem o seu IP real nem o proxy são detetados.

Uma regra inegociável: nunca cole credenciais autenticadas numa ferramenta web de terceiros. Use o Método 5 para qualquer proxy que precise de um nome de utilizador e palavra-passe.

Para proxies autenticados, a linha de comando é o único local sensato. As credenciais permanecem na sua máquina e acede à URL exata que pretende rastrear, não httpbin.org.

Proxy HTTP / HTTPS:

curl -x http://YOUR_USERNAME:YOUR_PASSWORD@proxy.your-provider.com:PORT \
     -L https://target-website.com \
     --connect-timeout 10 --head

proxy SOCKS5 (note o --socks5-hostname sinalizador, que força a resolução de DNS através do proxy):

curl --socks5-hostname YOUR_USERNAME:YOUR_PASSWORD@proxy.your-provider.com:PORT \
     -L https://target-website.com \
     --connect-timeout 10 --head

O manual oficial do curl documenta ambas as flags. -L segue redirecionamentos, --head mantém as respostas leves, --connect-timeout 10 elimina hosts inativos. É assim que se testam proxies com autenticação sem revelar credenciais: HTTP/2 200 OK é o sinal verde; 407, 403 ou um tempo limite é um sinal real, não ruído para tentar novamente.

Para mais do que um punhado de proxies, a criação de scripts é a melhor opção. A forma mais fiável de testar proxies em escala é o seu próprio verificador: aceda a um URL conhecido, valide o estado e o corpo, registe a latência e grave em CSV.

import csv, time, requests
PROXIES = ["http://user:pass@p1.example.com:8000"]
TARGET, EXPECT = "https://target.example.com/page", "expected text"
w = csv.writer(open("report.csv", "w", newline=""))
for p in PROXIES:
    t0 = time.perf_counter()
    try:
        r = requests.get(TARGET, proxies={"http": p, "https": p}, timeout=30)
        ok = r.status_code == 200 and EXPECT in r.text.lower()
        w.writerow([p, r.status_code, int((time.perf_counter()-t0)*1000), ok])
    except Exception as e:
        w.writerow([p, "ERR", "", False, str(e)[:80]])

Use um tempo limite de cerca de 10 segundos para proxies de centros de dados e até 30 segundos para proxies residenciais. A validação do corpo é a parte que a maioria dos testadores ignora: é a lacuna entre fazer ping em IPs e saber realmente como testar proxies contra o alvo real.

Cenários diferentes merecem testes diferentes. Esta matriz substitui a habitual tabela plana de prós e contras por uma visão centrada na decisão.

Diferentes modos de falha requerem soluções diferentes. Identifique a causa e, em seguida, tome medidas.

• Timeout: o proxy está inativo, sobrecarregado ou bloqueado na camada de rede.
• HTTP 407: a autenticação está errada, expirada ou formatada incorretamente.
• HTTP 403 ou 429: o destino está a bloquear ou a limitar a taxa desse IP.
• CAPTCHA HTML no corpo: o proxy foi identificado; substitua-o.
• País errado no IP de saída: a configuração de segmentação geográfica ou de sessão persistente está desativada.

O nosso guia de erros de estado do proxy associa cada código HTTP a uma solução concreta.

A qualidade do proxy não é estática. Listas gratuitas podem passar numa verificação e falhar dez minutos depois, e mesmo a rotação de gateways residenciais faz com que os IPs fiquem obsoletos. Agende o script Python do Método 6 num cron, integre-o na CI do seu scraper e recorra a um fluxo de trabalho de gestão de proxies para que os novos testes, a rotação e a retirada ocorram automaticamente.

• Qualquer pessoa que esteja a aprender a testar proxies deve verificar cinco aspetos, e não apenas um: conectividade, IP de saída, velocidade, anonimato e reputação do IP.
• ping e um teste básico curl -x confirmar que um proxy está acessível, mas não diz nada sobre se o site de destino o aceitará.
• Utilize bases de dados de IP como a MaxMind para o tipo e serviços do estilo AbuseIPDB para a reputação; um IP residencial sinalizado como um centro de dados está efetivamente queimado.
• Teste proxies autenticados localmente com curl (HTTP e --socks5-hostname para SOCKS5) para que as credenciais nunca saiam da sua máquina.
• Para qualquer coisa além de um punhado de proxies, um pequeno script em Python com validação do corpo, tempos de espera e registo em CSV terá um desempenho superior a qualquer ferramenta de interface de utilizador.

Refaça o teste passivamente em cada pedido e ativamente de acordo com um calendário. Trate qualquer 407, 403, 429, tempo limite ou corpo inesperado como um sinal de integridade em tempo real e coloque o IP problemático em quarentena. Além disso, execute uma verificação completa do conjunto a cada 15 a 60 minutos para listas gratuitas ou partilhadas, e pelo menos uma vez por dia para planos residenciais ou de centro de dados pagos.

Os verificadores online acedem a um URL de teste genérico, não ao seu destino. O proxy pode estar acessível e ser anónimo em geral, mas ainda assim estar na lista de bloqueios do destino, ter sido identificado pela sua pilha anti-bot ou estar sujeito a limites de tráfego para esse domínio. Confirme sempre se um proxy funciona no site real que pretende rastrear, idealmente numa página representativa em vez da página inicial.

Os proxies transparentes encaminham o seu IP real em cabeçalhos como X-Forwarded-For, pelo que o destino vê tanto o utilizador como o proxy. Os proxies anónimos ocultam o IP do utilizador, mas continuam a expor cabeçalhos relacionados com o proxy, pelo que o destino sabe que está a ser utilizado um proxy. Os proxies de elite (de elevado anonimato) eliminam esses sinais: o servidor de destino não deteta nem o IP real do utilizador nem qualquer indicação de que esteja envolvido um proxy.

Não. Colar user:pass@host:port num formulário web de terceiros envia essas credenciais para um servidor que não controla, e muitas dessas ferramentas registam os pedidos para fins de análise. Para proxies autenticados, utilize a linha de comandos com curl ou execute um script Python local. Reserve os verificadores baseados na web para proxies abertos não autenticados, onde o vazamento de credenciais não é uma preocupação.

Use curl --socks5-hostname user:pass@host:port -L https://target.example.com --connect-timeout 10 --head. O --socks5-hostname sinalizador força a resolução de DNS através do proxy, o que impede que o seu resolvedor local divulgue o nome do host. Adicione -v se precisar de ver o handshake SOCKS. Uma HTTP/2 200 OK resposta significa que o túnel SOCKS5 e a autenticação estão a funcionar.

Saber como testar proxies consiste principalmente em substituir o pensamento positivo por cinco verificações concretas. Confirme se o host está acessível, confirme o IP de saída e a localização geográfica, meça a velocidade, verifique o nível de anonimato e audite o tipo e a reputação do IP. Use ping e curl para verificações pontuais, bases de dados de IP para tipo e reputação, testadores baseados na web (com cuidado) para leituras de velocidade e anonimato não autenticadas, linha de comando curl para proxies HTTP e SOCKS5 autenticados e um pequeno script Python para tudo o que precise de ser escalado. Interprete os sinais de falha em vez de tentar novamente às cegas e incorpore novos testes na CI do seu scraper para que a integridade do proxy seja monitorizada, e não apenas assumida.

Se preferir evitar completamente a sobrecarga de testes e rotação, a rede de proxies residenciais da WebScrapingAPI lida com a rotação de IP, a segmentação geográfica e a higiene de reputação por trás de um único ponto de extremidade, para que o seu scraper veja saídas limpas em vez de um CSV de hosts inativos. Seja como for, crie o hábito de testar proxies antes de os colocar em produção. O seu eu futuro de plantão vai agradecer-lhe.