A lista de preços do provedor de proxy é estruturada de tal forma que comparar fornecedores parece uma tarefa simples: um gigabyte custa $1, enquanto outro custa $8 — considere, a diferença é de oito vezes. Na prática, a equipe que comprou um gigabyte por um dólar paga regularmente mais pelos dados coletados do que aquela que pagou oito. A razão não está no marketing e nem em taxas ocultas: o preço por gigabyte simplesmente não é a unidade em que sua tarefa é medida. Você não está comprando tráfego — você está comprando registros extraídos com sucesso, e entre essas duas grandezas existe uma cadeia de multiplicadores, que varia para cada projeto.
A conta não vem pelo que você calculou
Cena típica: planejou coletar um milhão de cartões de produtos, estimou 200 KB por página, obteve os 200 GB calculados e um orçamento em torno de mil e quinhentos dólares. Após um mês, no painel pessoal — 900 GB e uma conta três vezes maior que a estimativa. Ninguém enganou: três coisas mudaram que não estavam no cálculo.
A discrepância entre o preço e a conta sempre se desdobra nas mesmas componentes. Vale a pena analisá-las separadamente — então a fórmula se montará sozinha.
Três multiplicadores entre o preço e a conta
1. Quanto pesa realmente a página
A estimativa de "200 KB" vem da cabeça e se refere ao HTML cru. O peso real depende de como você obtém a página. A resposta HTML bruta de uma loja moderna geralmente é de centenas de kilobytes. Mas uma página completamente renderizada em um navegador headless, com todos os scripts, fontes, imagens e análises, pesa entre 2 e 5 MB. A diferença entre as duas maneiras de obter os mesmos dados é uma ordem de magnitude, e isso recai inteiramente sobre o seu tráfego.
Os cálculos do setor geralmente operam com uma faixa de 1 a 3 MB para coleta não otimizada e 100 a 300 KB para otimizada. Entre esses dois modos — não é uma "pequena economia", mas uma diferença de dez vezes no mesmo projeto.
2. Qual a proporção de respostas que realmente serve
O segundo multiplicador é a taxa de sucesso, a proporção de solicitações que retornaram conteúdo utilizável. Captcha em vez de página, 403, estrutura vazia sem dados, redirecionamento para uma página de erro — tudo isso é tráfego pago que não gerou nenhum registro.
A aritmética é simples e implacável: número de solicitações = registros necessários ÷ taxa de sucesso. Com 95% de sucesso, para um milhão de registros, são necessários 1,05 milhão de solicitações. Com 70% — já são 1,43 milhão. Com 60% — 1,67 milhão. Ou seja, a queda na taxa de sucesso de 95% para 60% por si só adiciona quase 60% à conta, com o preço do gigabyte absolutamente inalterado.
3. Retries, timeouts e tráfego adicional
Além disso, há o tráfego adicional da própria infraestrutura. Aqui, a diferença entre uma pilha madura e uma montada às pressas é enorme: plataformas gerenciadas bem ajustadas consomem cerca de 0,1 a 3% a mais, enquanto um pipeline Scrapy feito sob medida consome de 5 a 15%, e essa proporção cresce com a escala. Uma lógica de retry agressiva, que tenta um domínio bloqueado cinco vezes seguidas, facilmente transforma esses porcentuais em dezenas.
Métrica que não mente
Vamos juntar tudo em uma única medida. O que deve ser contado não são dólares por gigabyte, mas custo por mil registros extraídos com sucesso:
- Preço por 1000 registros = (peso médio da resposta em GB ÷ taxa de sucesso) × (1 + proporção de retries) × preço por GB × 1000
O valor dessa fórmula é que ela torna ofertas incomparáveis comparáveis. Um pool barato com uma taxa de banimento de 40% e um caro com uma taxa de banimento de 5% finalmente se encontram no mesmo eixo. É notável que, no último ano, os próprios provedores chegaram a essa métrica: em materiais do setor, a expressão "preço dividido pela taxa de sucesso" tem sido cada vez mais utilizada, em vez do preço bruto por gigabyte.
Como isso se traduz em dinheiro
Vamos considerar um milhão de registros, uma página média de 500 KB e tráfego residencial a $8/GB — uma típica média de mercado. Mudamos apenas a taxa de sucesso:
- 95% de sucesso — 1,05 milhão de solicitações, cerca de 525 GB, aproximadamente $4.200
- 70% de sucesso — 1,43 milhão de solicitações, cerca de 715 GB, aproximadamente $5.720
- 60% de sucesso — 1,67 milhão de solicitações, cerca de 835 GB, aproximadamente $6.680
A variação é de quase $2.500 no mesmo preço. Agora, vamos comparar duas ofertas que na lista de preços parecem céu e terra. Provedor A: $2/GB, mas mantém 55% de sucesso na sua meta. Provedor B: $6/GB e 92% de sucesso. Com os mesmos 500 KB e um milhão de registros, A resulta em cerca de 910 GB e $1.820, enquanto B resulta em cerca de 545 GB e $3.270. Aqui, A realmente é mais barato, e esse é um resultado honesto: com uma grande diferença de preço, uma baixa taxa de sucesso nem sempre consome o benefício.
Mas adicione a A retries de 15% contra 3% de B, adicione a renderização headless, que é ativada exatamente porque o pool barato frequentemente retorna uma página de erro em vez de conteúdo — e o peso da página em A sobe para 1,5 MB contra 500 KB em B. Recalculando: A — cerca de 3,1 TB e $6.200, B — cerca de 560 GB e $3.370. A situação se inverteu. É por isso que a questão "quem tem o gigabyte mais barato" não faz sentido por si só: a resposta depende do seu objetivo, da sua pilha e da sua taxa de banimento.
Por que APIs de scraping são consideradas de forma diferente — e como compará-las
Uma dificuldade adicional é que parte do mercado não vende gigabytes. APIs de scraping e desbloqueadores de sites cobram por solicitações, tarifando-as de acordo com a complexidade. A faixa de preços de 2026 para 1000 páginas é a seguinte:
- HTML simples: ScrapeOps cerca de $0,19, ScraperAPI cerca de $0,49, Scrape.do cerca de $0,58, ScrapingBee cerca de $0,66, Bright Data cerca de $1,00
- Com renderização JS (geralmente 5 créditos em vez de um): ScrapeOps cerca de $0,95, Scrape.do cerca de $2,90, ScrapingBee cerca de $3,30, ScraperAPI cerca de $4,90, Bright Data cerca de $5,00
- Sites sob proteção anti-bot (10–25 créditos): ScrapeOps cerca de $1,90, Scrape.do cerca de $4,45, ScraperAPI cerca de $5,96, ScrapingBee cerca de $6,60, Bright Data na faixa de $8–15
Note a discrepância dentro de um mesmo provedor: uma página simples e uma página sob proteção no ScraperAPI diferem em doze vezes. A tarifa "por solicitação" parece mais previsível do que gigabytes até o momento em que o objetivo muda da primeira categoria para a terceira — e isso acontece sem sua participação, por decisão do proprietário do site.
Isso se resume a uma fórmula comum: custo por solicitação ÷ taxa de sucesso × 1000. Depois disso, a oferta " $3,30 por 1000 páginas JS" e a oferta "$6 por gigabyte de tráfego residencial" finalmente podem ser colocadas lado a lado. Uma análise mais ampla das abordagens em si — API oficial, dataset pronto ou seu próprio parser — foi discutida separadamente; aqui, o que importa é apenas sua comparabilidade em termos financeiros.
Medida em uma noite
A fórmula é inútil sem seus próprios números, e a boa notícia é que obtê-los é um trabalho de algumas horas. Um teste com 1000 solicitações em seus URLs reais fornece tudo o que você precisa.
- Pegue uma amostra representativa de objetivos — não a página principal, mas aqueles cartões, categorias e resultados que você irá coletar em produção. A taxa de sucesso na página principal não prevê nada.
- Registre separadamente quatro contadores: respostas válidas com dados, erros HTTP, captchas e desafios, "duzentos vazios" — código 200 sem o conteúdo necessário. A última categoria é a mais traiçoeira: formalmente é um sucesso, mas na prática — lixo pago.
- Capture o volume real de tráfego a partir das estatísticas do provedor, e não de suas estimativas. A discrepância entre o peso calculado e o peso real da página é geralmente a primeira descoberta desse teste.
- Conte os retries como uma linha separada, e não os misture no número total de solicitações.
- Repita com o segundo provedor no mesmo dia. A taxa de sucesso varia com o humor dos sistemas anti-bot, e medições espaçadas em uma semana não podem ser comparadas.
Se o teste mostrou uma baixa taxa de sucesso, não se apresse em mudar de fornecedor: primeiro, é importante entender a razão. A análise das fontes típicas do problema está reunida no material sobre como diagnosticar uma baixa taxa de sucesso em proxies, e o controle regular das mesmas métricas deve ser estabelecido como um fluxo contínuo. Muitas vezes, o problema está nos cabeçalhos, no tempo ou na impressão TLS do cliente, e não na qualidade do IP.
Quatro alavancas que movem os números mais do que um desconto
Quando a métrica é calculada, fica claro onde ela é mais sensível. Um desconto de 10% no preço é a alavanca mais fraca disponível.
Peso da resposta. O ganho mais rápido. Coletar apenas o que é necessário reduz o tráfego em 2 a 10 vezes. Se um navegador headless é obrigatório, bloqueie no nível de interceptação de solicitações imagens, fontes, mídias e scripts de terceiros — o conteúdo não é afetado, mas o volume diminui drasticamente. Ative a compressão e solicitações condicionais por ETag: uma página que não mudou desde a última varredura deve custar uma resposta 304, e não megabytes.
Taxa de sucesso. Cada dez pontos percentuais de sucesso na faixa de 60 a 95% representam dezenas de porcentagens na conta. Aqui, não se trata de dinheiro, mas de engenharia: uma impressão correta do cliente, um ritmo razoável, o tipo certo de IP para o objetivo específico.
Mix de tipos de proxy. Direcionar todo o tráfego através de um pool residencial é o erro mais comum e mais caro. Uma parte significativa dos objetivos é perfeitamente atendida por proxies de datacenter, que são muito mais baratos; endereços residenciais devem ser usados apenas para o que realmente os requer. Roteamento por objetivo, e não por hábito, reduz os custos com proxies em 60 a 70%.
Disciplina de retries. Atraso exponencial, limite de tentativas, recusa de repetições em códigos que não são resolvidos por tentativas. A diferença entre 3% e 15% de tráfego adicional é a diferença entre uma infraestrutura bem ajustada e a ausência dela. O aspecto prático da questão é discutido no material sobre otimização do uso de tráfego através de proxies.
O que fica de fora do tráfego
A imagem completa dos custos é mais ampla do que a conta de proxies, e isso deve ser lembrado ao escolher entre "coletar por conta própria" e "comprar pronto". Para um projeto de um milhão de páginas por mês, as estimativas do setor para uma solução self-hosted são as seguintes: tráfego residencial $500–1500, tempo de engenharia $1000–2000, infraestrutura $300–500. Totalizando $2000–4400 por mês — e isso antes de escrever a lógica de negócios propriamente dita. Com a taxa de um engenheiro em cerca de $100 por hora, alguns dias gastos consertando seletores quebrados custam mais do que a conta mensal de proxies.
Isso não é um argumento contra a coleta autônoma — é um argumento a favor de considerar as horas de engenharia como uma linha de orçamento, assim como gigabytes. O modelo de tarifação também deve ser escolhido de forma consciente: para sessões longas e estáveis, o pagamento por IP dedicado muitas vezes se mostra mais vantajoso do que por megabyte.
Resumindo
O preço por gigabyte não é o preço dos dados, mas o preço de um dos quatro multiplicadores. Comparar provedores por ele é o mesmo que escolher um carro pelo preço do litro de gasolina, sem perguntar sobre o consumo. A unidade de comparação é uma: quanto custa mil registros extraídos com sucesso em seus objetivos, com seu peso de resposta, sua taxa de sucesso e seus retries.
Calcule isso em um teste de mil solicitações antes de assinar um plano anual. Muitas vezes, descobre-se que a oferta mais barata na lista de preços acaba custando mais do que todas as outras — e que a maior reserva de economia não está nas negociações sobre descontos, mas em duas dezenas de linhas de código que desativam o carregamento de imagens.
```