“Quão rápido é isso?” é a pergunta errada a se fazer primeiro sobre um proxy residencial. Um proxy que responde em 200ms mas é bloqueado metade das vezes é inútil; um pouco mais lento, mas que retorna a página real todas as vezes, é exatamente o que você quer. Antes de confiar em um provedor, ou depurar por que seu scraper está com desempenho abaixo do esperado, você precisa medir três coisas objetivamente: taxa de sucesso, distribuição de latência e precisão de localização. Este guia traz testes prontos para copiar e colar para cada um deles e, tão importante quanto isso, como ler os números sem se enganar.
Tudo abaixo é executado contra o gateway residencial da Shifter (um único endpoint, p.shifter.io:443, com a segmentação codificada no nome de usuário), mas os testes são independentes de provedor, troque o host e as credenciais e eles funcionam em qualquer lugar. Os exemplos são em Python; a configuração do cliente segue proxies residenciais com Python.
As três métricas que realmente importam
A velocidade bruta é a métrica em que as pessoas se fixam e a menos útil isoladamente. IPs residenciais são roteados por dispositivos reais de consumidores, então são inerentemente um pouco mais lentos que os de datacenter, isso é esperado, e não um defeito. O que realmente determina se um proxy é bom para o seu trabalho:
- Taxa de sucesso — das solicitações que você envia, quantas retornam a página real (não um bloqueio, CAPTCHA ou erro). Esse é o número que decide se seu pipeline de dados está completo.
- Distribuição de latência — não a média, a dispersão. O p95 e a cauda dizem o quão ruim ficam suas requisições mais lentas, o que é o que prejudica em escala.
- Precisão de localização — quando você segmenta um país ou cidade, o IP de saída realmente resolve para lá? Para qualquer caso de uso de segmentação geográfica, dados de localização errada são dados silenciosamente errados.
Meça as três. Um único número, especialmente a velocidade média, esconde os problemas que importam.
Configuração
Mantenha as credenciais em variáveis de ambiente e defina um auxiliar que constrói uma URL de proxy segmentada:
import os, time, statistics, requests
USER = os.environ["SHIFTER_USER"]PASS = os.environ["SHIFTER_PASS"]GATEWAY = "p.shifter.io:443"
def proxy(country="us", city=None, sid=None, ttl=600): parts = [USER, "country", country] if city: parts += ["city", city] if sid: parts += ["sid", sid, "ttl", str(ttl)] url = f"http://{'-'.join(parts)}:{PASS}@{GATEWAY}" return {"http": url, "https": url}Primeiro, confira se você realmente está passando pelo proxy, um número surpreendente de relatos de “o proxy está lento” na verdade é tráfego que nunca saiu da máquina local:
r = requests.get("https://api.ipify.org?format=json", proxies=proxy("us"), timeout=30)print(r.json()) # deve ser um IP residencial, não o seu próprioTeste 1: Precisão de localização
Segmente um país (e opcionalmente uma cidade), consulte um endpoint de geo-IP para saber onde está o IP de saída e meça a taxa de acerto em muitas amostras. Alterne cada requisição (sem sid) para amostrar o pool, não um único IP:
def test_geo(country="us", n=50): hits = 0 for _ in range(n): try: r = requests.get("http://ip-api.com/json", proxies=proxy(country), timeout=30) data = r.json() if data.get("countryCode", "").lower() == country.lower(): hits += 1 except requests.RequestException: pass print(f"{country}: {hits}/{n} = {hits/n:.0%} country-accurate")
test_geo("us")test_geo("de")Como interpretar. A precisão de país deve ser muito alta (pense em algo na casa dos 90% altos). A precisão de cidade é inerentemente mais imprecisa, bancos de dados de geo-IP divergem sobre a qual cidade um IP pertence, então um “erro” pode ser uma divergência de banco de dados, não o proxy te enviando para o lugar errado. Duas ressalvas que evitam conclusões falsas: teste a precisão de cidade contra a mesma fonte de geo-IP que o seu site alvo usa, se possível, e nunca confie em um único provedor de consulta como verdade absoluta.
Teste 2: Latência, medida como distribuição
Meça o tempo total de requisição em muitas amostras e reporte percentis, não a média. Uma média suaviza exatamente a cauda lenta que prejudica você em escala:
def test_latency(country="us", n=50, url="https://api.ipify.org"): times = [] for _ in range(n): start = time.perf_counter() try: requests.get(url, proxies=proxy(country), timeout=30).raise_for_status() times.append((time.perf_counter() - start) * 1000) # ms except requests.RequestException: pass times.sort() p = lambda q: times[min(len(times)-1, int(q*len(times)))] print(f"n={len(times)} p50={p(0.5):.0f}ms p95={p(0.95):.0f}ms max={times[-1]:.0f}ms")
test_latency("us")Como interpretar. Observe o p50 em comparação ao p95: uma dispersão estreita (p95 próximo do p50) significa desempenho previsível; um p95 muitas vezes maior que o p50 significa uma cauda pesada que vai travar workers concorrentes. Para separar a sobrecarga do proxy da lentidão do alvo, execute o mesmo teste contra um endpoint neutro e rápido (como um eco de IP) e contra seu alvo real, a diferença é aproximadamente a latência própria do alvo. E não compare o p50 residencial com o p50 de datacenter como se fossem o mesmo produto; o residencial adiciona um salto real de dispositivo por design (veja proxies residenciais vs. de datacenter).
Teste 3: Taxa de sucesso, a que mais importa
Execute requisições contra seu alvo real (o sucesso é específico do alvo) e classifique cada resultado. A armadilha aqui é confiar no status HTTP: um 200 OK ainda pode ser um bloqueio suave, um CAPTCHA ou uma página de “por favor, verifique” servida com um 200. Então valide o conteúdo, não apenas o código:
def looks_like_real_page(html): # Ajuste isso ao seu alvo: presença da marcação esperada, ausência de marcadores de bloqueio. block_markers = ("captcha", "are you a robot", "access denied", "unusual traffic") low = html.lower() return len(html) > 1000 and not any(m in low for m in block_markers)
def test_success(url, country="us", n=100): ok, soft_block, errors = 0, 0, 0 for _ in range(n): try: r = requests.get(url, proxies=proxy(country), timeout=30) if r.status_code == 200 and looks_like_real_page(r.text): ok += 1 else: soft_block += 1 # 200-com-bloqueio, 403/429/503, etc. except requests.RequestException: errors += 1 # timeouts, falhas de conexão print(f"success={ok/n:.0%} blocked={soft_block/n:.0%} errors={errors/n:.0%}")
test_success("https://your-target.example/page", country="us")Como interpretar. A taxa de sucesso é a métrica principal para scraping, é a fração das requisições que retornaram dados utilizáveis. Divida as falhas entre bloqueadas (o alvo te recusou) e erros (rede/timeout), porque têm correções diferentes: bloqueios consistentes apontam para a qualidade do IP ou o comportamento da requisição (por que scrapers são bloqueados), enquanto erros apontam para timeouts ou filtros geográficos rígidos demais. Note que a rotação por requisição e um loop de nova tentativa aumentam sua taxa de sucesso efetiva, então meça tanto o valor bruto (tentativa única) quanto com nova tentativa, se for assim que você vai rodar em produção.
Juntando tudo
Um arcabouço mínimo executa os três testes e imprime um relatório único:
if __name__ == "__main__": for cc in ("us", "de", "gb"): print(f"\n== {cc.upper()} ==") test_geo(cc, n=50) test_latency(cc, n=50) test_success("https://your-target.example/page", country=cc, n=100)Leia nesta ordem: taxa de sucesso primeiro (os dados sequer estão voltando?), depois a cauda de latência (isso vai aguentar sob concorrência?), depois a precisão geográfica (são os dados corretos?). Um provedor que vence no p50 mas perde na taxa de sucesso é a escolha errada para scraping.
Armadilhas comuns que produzem números enganosos
- Reportar a latência média. Use percentis, a cauda é o que quebra jobs concorrentes.
- Confiar no status 200. Bloqueios suaves retornam 200 com uma página de CAPTCHA. Valide o conteúdo.
- Amostras pequenas demais. 5 requisições não dizem nada; use o suficiente (50 a 100+) para ver a distribuição e a cauda.
- Verdade geográfica errada. Bancos de dados de geo-IP diferentes divergem, especialmente no nível de cidade. Teste contra a fonte que seu alvo usa, e trate a precisão de cidade como inerentemente mais imprecisa que a de país.
- Comparar residencial com datacenter em velocidade bruta. São produtos diferentes; o residencial troca um pouco de latência por confiança de usuário real e uma taxa de sucesso maior em alvos defendidos (quais proxies são melhores para scraping).
- Não confirmar que você está usando o proxy. Verifique se o IP de saída mudou antes de fazer qualquer benchmark.
Uma nota sobre fazer isso de forma responsável
Faça benchmark contra endpoints que você tem permissão para acessar, serviços públicos de eco de IP para velocidade e geolocalização, e seus próprios alvos autorizados para taxa de sucesso. Mantenha os tamanhos de amostra razoáveis, não sobrecarregue um site para medi-lo, e respeite os limites de taxa. Nossa política de uso aceitável é a fonte da verdade sobre o que é permitido na Shifter.
Perguntas frequentes
Qual é uma boa taxa de sucesso para proxies residenciais? Depende inteiramente do alvo, um site bem defendido bloqueará mais do que um aberto. O que importa é medi-la contra o seu alvo e comparar provedores no mesmo alvo. Divida as falhas entre bloqueios e erros para saber o que corrigir.
Por que meu proxy residencial é mais lento que um de datacenter? Porque ele passa por um dispositivo real de consumidor, esse salto adiciona latência por design. Essa é a troca por confiança de usuário real e taxas de sucesso maiores em sites que bloqueiam IPs de datacenter. Avalie o residencial pela taxa de sucesso e pela distribuição de latência, não pelo p50 bruto comparado ao de datacenter.
Como eu testo a precisão de localização no nível de cidade? Segmente a cidade e verifique o IP de saída contra uma fonte de geo-IP, idealmente a mesma que seu alvo usa. Espere que a precisão de país seja muito alta e a de cidade seja mais imprecisa, já que os bancos de dados de geo-IP divergem nos limites das cidades. Veja quando a segmentação em nível de cidade importa.
Por que uma resposta 200 ainda conta como falha? Porque sites servem bloqueios suaves, CAPTCHA ou páginas de “verifique que você é humano”, com status 200. Se você só checar o código de status, vai registrar bloqueios como sucessos. Valide se o conteúdo corresponde ao de uma página real.
Devo testar com sessões rotativas ou fixas?
As duas, dependendo da sua carga de trabalho. A rotativa (sem sid) amostra o pool e é adequada para scraping amplo; a fixa (fixa vs. rotativa) testa fluxos de múltiplas etapas. Meça o modo que você realmente vai usar em produção.
Conclusão
Testar bem um proxy residencial significa se recusar a reduzi-lo a um único número de velocidade. Meça a taxa de sucesso contra seu alvo real com validação de conteúdo, a latência como uma distribuição observando a cauda do p95, e a precisão de localização com uma verdade de geo-IP sensata, e você vai saber se um provedor realmente se encaixa no seu trabalho em vez de adivinhar a partir de um número de marketing. A qualidade do pool é o que move os três, então entender a reputação de IP ajuda você a interpretar os resultados.
Se você está fazendo benchmark de provedores ou depurando sua própria taxa de sucesso, execute esses testes contra o gateway residencial e o alvo de sua escolha. A página de preços tem planos por GB para testar contra os mercados e sites que importam para você.