Em um plano de proxy residencial por GB, a banda é a unidade que você compra, então escolher o plano certo se resume a uma pergunta: quantos gigabytes você vai realmente usar em um mês? Estimar por baixo demais e você atinge excedente ou limitação no meio do mês; estimar por cima demais e você paga a mais por uma folga que nunca usa. A boa notícia é que a banda é estimável, não um mistério. Com uma fórmula, alguns tamanhos de página realistas e uma medição de cinco minutos, você consegue dimensionar um plano com confiança.
Este guia é para equipes que planejam o uso de proxy. Vamos construir a estimativa passo a passo, fundamentá-la em uma medição real e percorrer exemplos práticos para cargas de trabalho comuns.
A fórmula
Tudo se reduz a isto:
GB mensais ≈ (requisições por mês × tamanho médio da resposta × fator de overhead) / bytes por GBQuatro entradas, e uma delas domina. Vamos analisá-las em ordem de impacto.
Passo 1: tamanho médio da resposta (o grande fator)
Quantos bytes retornam por requisição é onde as estimativas se sustentam ou desmoronam, e isso varia mais de 10x dependendo de como você faz a busca. Faixas típicas:
| O que você busca | Tamanho típico por requisição |
|---|---|
| Resposta de API JSON enxuta | 5 a 50 KB |
| Apenas página HTML (sem recursos) | 100 a 500 KB |
| Página completa em navegador headless (imagens, CSS, JS, fontes) | 1 a 5 MB+ |
O maior fator isolado na sua conta é se você renderiza um navegador completo ou busca HTML/JSON diretamente. Um navegador baixa tudo que está na página; uma requisição HTTP simples puxa uma fração disso. Se você conseguir obter seus dados a partir do HTML ou de uma API, o tamanho por requisição, e sua banda, cai em uma ordem de grandeza. (Isso, mais o bloqueio de recursos, é o núcleo de como reduzir custos de banda de proxy.)
Não chute esse número se você pode medi-lo, veja o Passo 4.
Passo 2: requisições por mês
Isso costuma ser páginas (ou registros) vezes frequência:
requisições por mês = itens × verificações por dia × 30Um monitor de preços rastreando 10.000 produtos uma vez por dia gera 10.000 × 1 × 30 = 300.000 requisições por mês. A construção de um conjunto de dados único é apenas o total de páginas, sem multiplicador de frequência. Inclua a paginação: se cada “item” abrange três páginas de resultados, multiplique de acordo.
Passo 3: o fator de overhead
Rastreamentos reais não são 100% eficientes. Retentativas, redirecionamentos e tentativas falhas atravessam o proxy e todos custam banda, uma requisição bloqueada ou que expirou ainda gastou bytes. Adicione um fator de overhead em cima da sua estimativa limpa:
- Alvos fáceis e abertos: ~1,1 (10% de overhead)
- Sites típicos: ~1,2 (20%)
- Alvos bem defendidos (bloqueios/retentativas frequentes): ~1,3 ou mais
Quanto mais difícil o alvo, mais retentativas, logo maior o fator. Reduzir sua taxa de bloqueio (melhor qualidade de IP, ritmo sensato) diminui isso diretamente, veja como evitar ser bloqueado.
Passo 4: meça o tamanho real da sua página (não chute)
O caminho mais rápido para uma estimativa confiável é buscar uma amostra representativa do seu alvo real através do proxy e medir os bytes. O tamanho da resposta em bytes é len(response.content):
import os, requests, statistics
USER, PASS = os.environ["SHIFTER_USER"], os.environ["SHIFTER_PASS"]proxy_url = f"http://{USER}-country-us:{PASS}@p.shifter.io:443"proxies = {"http": proxy_url, "https": proxy_url}
sample_urls = [ ... ] # 20-50 URLs de alvo representativassizes_kb = []for url in sample_urls: r = requests.get(url, proxies=proxies, timeout=30) sizes_kb.append(len(r.content) / 1024)
avg_kb = statistics.mean(sizes_kb)print(f"avg {avg_kb:.0f} KB/request (n={len(sizes_kb)})")Execute contra 20 a 50 URLs reais e você terá um tamanho médio fundamentado em vez de um chute. Observe que isso mede os bytes comprimidos que realmente atravessam o proxy (mantenha Accept-Encoding ativado), que é o que é cobrado. A configuração completa do cliente está em proxies residenciais com Python.
Exemplos práticos
Usando GB mensais = requisições × tamanho médio × overhead / 1.000.000 (KB para GB, decimal):
Monitoramento de preços, apenas HTML. 10.000 produtos, diariamente, ~200 KB/página, overhead 1,15.
300.000 × 200 KB × 1,15 = 69.000.000 KB ≈ 69 GB/mês.
Mesmo trabalho, mas com renderização completa em navegador. ~2 MB/página em vez de 200 KB.
300.000 × 2.000 KB × 1,15 = 690.000.000 KB ≈ 690 GB/mês.
Mesmos dados, 10x a banda, esse é o custo de renderizar quando você não precisava (veja com Playwright para bloquear recursos se você precisar renderizar).
Monitoramento de busca/ranqueamento, respostas enxutas. 500 consultas, 4x/dia, ~30 KB cada, overhead 1,2.
500 × 4 × 30 × 30 KB × 1,2 = 2.160.000 KB ≈ 2,2 GB/mês. Pequeno e barato.
Construção de um conjunto de dados único. 2.000.000 páginas, ~300 KB HTML, overhead 1,2.
2.000.000 × 300 KB × 1,2 = 720.000.000 KB ≈ 720 GB, uma única vez, não mensal.
O padrão é claro: tamanho da resposta e escolha de renderização dominam; a contagem de requisições escala linearmente; o overhead é um multiplicador modesto.
Da estimativa ao plano
Transforme o número em um plano com um pouco de disciplina:
- Adicione uma margem. Dimensione o plano para sua estimativa mais 20 a 30%, para crescimento dentro do mês e erro de estimativa. Ficar sem banda no meio do ciclo é mais disruptivo do que uma pequena folga.
- Conheça os termos de excedente. Verifique como seu provedor lida com ultrapassagens, extra por GB, limitação, ou uma parada total, para que um mês agitado não seja uma surpresa.
- Reconcilie semanalmente. Compare o uso real com sua estimativa no início do ciclo e ajuste. O uso real ensina seu verdadeiro tamanho por página e taxa de bloqueio mais rápido do que qualquer chute.
- Reduza o número antes de comprar mais. Muitas vezes o gigabyte mais barato é aquele que você não gasta, evite a renderização, bloqueie recursos e não busque novamente páginas inalteradas (reduzir custos de banda de proxy) antes de aumentar o plano. Esse é o modelo por GB que faz a eficiência compensar (a era do per-port acabou).
Perguntas frequentes
Como estimo a banda se nunca executei o trabalho antes? Meça uma amostra representativa das páginas do seu alvo através do proxy (Passo 4) para obter um tamanho real por requisição, depois insira na fórmula com sua contagem de requisições e um fator de overhead. Uma amostra medida supera qualquer estimativa genérica.
O que usa mais banda? A renderização completa em navegador, de longe, ela baixa cada imagem, fonte e script. Buscar HTML ou uma API JSON diretamente pode reduzir o tamanho por requisição em 10x. A escolha de renderização é a maior alavanca na sua conta.
Requisições falhas e repetidas contam para minha banda? Sim. Qualquer requisição que atravessa o proxy usa banda, incluindo bloqueios, redirecionamentos e retentativas. É por isso que a estimativa inclui um fator de overhead, e por isso que reduzir sua taxa de bloqueio diminui o custo.
1 GB é 1.000 MB ou 1.024 MB? Depende da definição de cobrança do provedor, decimal (1.000) ou binário (1.024). A diferença é de cerca de 7%, aceitável para estimativa, mas confirme qual seu provedor usa ao dimensionar próximo de um limite de plano.
Quanta margem devo adicionar? Planeje para sua estimativa mais 20 a 30%, para absorver crescimento e erro de estimativa dentro do mês. Depois reconcilie com o uso real e ajuste, em vez de comprar demais antecipadamente.
Resumo final
Estimar a banda de proxy residencial não é chute: multiplique as requisições por um tamanho médio de resposta medido e um fator de overhead, converta para GB e adicione uma margem. As duas coisas que mais movem o número são como você faz a busca (HTML/JSON supera o navegador completo em aproximadamente 10x) e com que frequência você faz retentativas (melhor qualidade de IP significa menos bytes desperdiçados), então meça uma amostra real antes de se comprometer, e reduza o número antes de comprar mais.
Depois de ter uma estimativa, a página de preços apresenta os planos por GB para que você possa combinar um nível com seu número mais margem, e direcione um scraper bem ajustado para o gateway residencial para manter o uso real próximo do planejado.