Como Medir a Velocidade e o Uptime de um Proxy: Método Repetível

A velocidade de um proxy não é um número único: é latência (quanto tempo até o primeiro byte), throughput (a velocidade com que os bytes chegam) e taxa de sucesso (com que frequência você obtém uma resposta utilizável) — cada um varia por hora, por alvo e por IP de saída. Um único teste em um momento específico diz quase nada, por isso os números de marketing dos provedores e as avaliações pontuais são tão fáceis de produzir e tão difíceis de usar. Este é o método que usamos para nossos próprios rankings: o que medir, como, com que frequência e como resumir para que o resultado signifique algo.

Os quatro números

Métrica	O que responde	Como obter	Valor bom típico
Latência (TTFB)	Quanto tempo cada requisição espera antes que os dados comecem	`curl -w %{time_starttransfer}` em um recurso pequeno	Datacenter: +10–50 ms sobre o direto; residencial/móvel: +80–300 ms
Throughput	Quão rápido os dados em massa se movem	Cronometrar um download de tamanho fixo (1–10 MB)	Datacenter: próximo à velocidade da linha; residencial: 5–50 Mbit/s; móvel: 5–30 Mbit/s
Taxa de sucesso	Com que frequência uma requisição é concluída com um 2xx real	Contar os resultados em muitas requisições	>98% em alvos neutros; menor em alvos protegidos é culpa do alvo
Uptime	Com que frequência o proxy está acessível	Probe de conectividade periódico ao longo de dias	>99.5% para datacenter/ISP; pools rotativos mascaram falhas individuais

Relatórios que dão um único número de “velocidade” geralmente relatam throughput em um download grande de um proxy de datacenter em uma hora tranquila — a combinação mais lisonjeira possível.

Princípios antes dos comandos

Meça a diferença, não o absoluto. Sempre execute a mesma requisição direta e através do proxy, consecutivamente, e relate o delta. A variabilidade da sua própria conexão é misturada com a do proxy.
Mesmo alvo, sempre. Use um endpoint pequeno, rápido e estável que não limite a taxa — um arquivo estático em um CDN importante, ou seu próprio servidor. Nunca faça benchmark contra o site que você pretende raspar; a resposta anti-bot dele é uma medição diferente.
Muitas amostras, distribuídas ao longo do tempo. Pelo menos 20 requisições por execução; execuções em várias horas do dia e ao longo de uma semana. Proxies são infraestrutura compartilhada e a carga segue o horário comercial nas regiões do provedor e dos IPs de saída.
Relate percentis, não médias. Um timeout de 30 segundos destrói uma média. A mediana (p50) conta a experiência típica; o p95 conta a experiência em dia ruim; ambos importam mais que a média.
Aqueça. Descarte a primeira requisição de cada execução — a configuração de DNS e sessão TLS a torna mais lenta que as demais.
Mude uma coisa de cada vez. Comparar o datacenter do provedor A com o residencial do provedor B compara tipos, não provedores.

Latência com curl

# direto
curl -o /dev/null -s -w "dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
     https://cdn.example.com/1kb.txt

# via proxy
curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s \
     -w "connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
     https://cdn.example.com/1kb.txt

Através de um proxy, time_connect é o tempo para alcançar o proxy; o connect e o TLS do destino acontecem dentro do túnel e aparecem em time_appconnect/time_starttransfer. O número a comparar é ttfb: o valor via proxy menos o direto é a latência adicionada pelo proxy. Faça um loop:

for i in $(seq 1 20); do
  curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s -w "%{time_starttransfer}\n" https://cdn.example.com/1kb.txt
done | sort -n | awk '{a[NR]=$1} END{print "p50", a[int(NR*0.5)], "p95", a[int(NR*0.95)]}'

Throughput

curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s -w "%{speed_download} bytes/s  %{size_download} bytes  %{time_total}s\n" \
     https://cdn.example.com/5mb.bin

Use um arquivo grande o suficiente para que a configuração da conexão seja uma fração pequena (5–10 MB), pequeno o suficiente para não queimar a cota por GB em planos residenciais em muitas execuções. Em pools rotativos, o throughput varia com a conexão do host de saída; execute amostras suficientes para ver a distribuição, e lembre-se de que em planos por GB o throughput também determina a velocidade com que você gasta dinheiro.

Taxa de sucesso

Cada requisição termina em: um 2xx com corpo do tamanho esperado; um 4xx/5xx do alvo; um erro de proxy (407, conexão recusada, timeout); ou uma página de desafio (CAPTCHA/intersticial) com status 200 — esta última é a que contadores ingênuos perdem, então verifique o corpo, não apenas o código. Em Python:

import requests, time, statistics as st

PROXY = {"https": "http://user:pass@proxy.example.com:8080"}
URL, N = "https://cdn.example.com/1kb.txt", 50
lat, outcomes = [], {"ok": 0, "http_err": 0, "proxy_err": 0, "timeout": 0, "challenge": 0}

for i in range(N):
    t = time.perf_counter()
    try:
        r = requests.get(URL, proxies=PROXY, timeout=15)
        dt = time.perf_counter() - t
        if r.status_code == 200 and len(r.content) > 500 and b"captcha" not in r.content.lower():
            outcomes["ok"] += 1; lat.append(dt)
        elif r.status_code == 200:
            outcomes["challenge"] += 1
        else:
            outcomes["http_err"] += 1
    except requests.exceptions.ProxyError:
        outcomes["proxy_err"] += 1
    except requests.exceptions.Timeout:
        outcomes["timeout"] += 1
    time.sleep(0.5)

lat.sort()
print(outcomes, "success %.1f%%" % (100 * outcomes["ok"] / N))
if lat: print("p50 %.3fs  p95 %.3fs" % (lat[len(lat)//2], lat[int(len(lat)*0.95)]))

Separe as falhas do proxy (407, erros de conexão, timeouts para o proxy) das falhas do alvo (403, 429, desafios). As primeiras são problema do provedor; as segundas são sobre a reputação do IP naquele alvo e pertencem a um teste diferente — veja como os sistemas anti-bot pontuam requisições.

Uptime

Uptime é a taxa de sucesso ao longo do tempo calendário. Agende um probe leve — o comando de latência acima, ou um CONNECT simples — a cada 5–15 minutos por pelo menos uma semana, registre o resultado com um timestamp e calcule a fração de probes que tiveram sucesso. Duas sutilezas:

Pools rotativos escondem falhas. Se um IP de saída morre, você recebe outro; o gateway é o que tem uptime. Probe o gateway e, separadamente, rastreie com que frequência o IP atribuído muda quando você pediu uma sessão sticky — uma mudança inesperada é uma falha suave.
IPs estáticos (datacenter, ISP) são para os quais “99.9%” é geralmente reivindicado. 99.9% é 43 minutos de indisponibilidade por mês; 99.5% é 3,6 horas. Ambos são fáceis de distinguir com uma semana de probes de 15 minutos.

Agendando as execuções

Um cronograma mínimo mas significativo: latência + sucesso (20–50 requisições) às 03:00, 09:00, 14:00 e 20:00 no horário local dos IPs de saída, todos os dias por sete dias; throughput uma vez por execução; um probe de conectividade a cada 15 minutos ao longo do período. Isso é algumas centenas de kilobytes por dia por proxy para latência e algumas dezenas de megabytes para throughput — acessível mesmo em planos por GB se você usar um arquivo pequeno. Execute a partir de uma máquina que fique ligada (um VPS pequeno é ideal) com cron e escreva uma linha CSV por requisição. Nossos rankings publicados — por exemplo, o ranking de velocidade e o ranking de confiabilidade — são construídos exatamente com esse tipo de série de uma semana, não de uma única tarde.

Interpretando os resultados

Latência p50 próxima da norma do tipo e p95 dentro de ~3× p50: saudável. Um p95 muitas vezes maior que o p50 significa congestionamento intermitente — o provedor está sobrecarregado no pico.
Taxa de sucesso abaixo de ~97% em um alvo neutro devido a erros do lado do proxy: problema de infraestrutura, não seu.
Muito pior durante o dia do que à noite: capacidade compartilhada; pergunte sobre opções dedicadas ou aceite isso no agendamento.
Números ótimos no datacenter, ruins no residencial do mesmo provedor: normal — produtos diferentes; compare residencial com residencial.
Uptime abaixo do reivindicado: agora você tem um log para mostrar ao suporte, o que vale mais que uma reclamação.

Finalmente, mantenha o tipo em mente. Proxies residenciais e móveis são mais lentos por construção — o tráfego realmente atravessa uma linha doméstica ou uma torre de celular — e comprá-los por velocidade é um erro de categoria; veja a comparação de tipos de proxy. Meça-os contra sua própria classe e contra o que sua tarefa realmente precisa. Note também que uma conexão via proxy usa HTTP/2, não HTTP/3, então compare como com como quando a linha de base direta está em um site habilitado para QUIC (detalhes).

Perguntas frequentes

Como testo a velocidade de um proxy?

Solicite o mesmo recurso pequeno diretamente e através do proxy, muitas vezes, em vários horários do dia; compare o tempo até o primeiro byte (latência) e, separadamente, cronometre um download de tamanho fixo (throughput). Relate medianas e percentis 95, não médias.

Qual é uma boa latência de proxy?

Em relação a uma conexão direta: proxies de datacenter adicionam dezenas de milissegundos; residenciais e móveis adicionam cerca de 80–300 ms porque o tráfego passa por uma conexão de consumo. Julgue cada tipo contra sua própria norma.

Como verifico o uptime de um proxy?

Faça um probe em um cronograma (a cada 5–15 minutos) por pelo menos uma semana, registre cada resultado e calcule a fração de probes bem-sucedidos. Para pools rotativos, probe o gateway; para IPs estáticos, probe o próprio IP.

Por que meus resultados diferem das alegações do provedor?

As alegações geralmente são o melhor caso: produto de datacenter, hora tranquila, download grande, amostra única. Sua medição inclui horários de pico, os IPs de saída específicos que você recebe e percentis. O seu é o número que prevê sua experiência.

Devo fazer benchmark contra o site que quero raspar?

Não para velocidade. A camada anti-bot dele adicionará desafios e bloqueios que medem a reputação do IP, não o desempenho do proxy. Use um recurso estático neutro para velocidade e execute testes de reputação separadamente.

Quantas amostras preciso?

Pelo menos 20 por execução para obter uma mediana estável, várias execuções por dia ao longo de uma semana para ver efeitos de hora do dia e dia da semana. O uptime precisa da semana independentemente.

Como Medir a Velocidade e o Uptime de um Proxy Você Mesmo: Um Método Repetível