O erro clássico ao escalar um scraper é comprar proxies "a olho": pegamos 100 IPs, iniciamos o scraper e recebemos bans em meia hora. O problema não está na quantidade de endereços, mas no fato de que ninguém calcula a carga real em cada IP. Vamos analisar a fórmula de cálculo do pool de proxies, baseada no RPS (requests per second), delays e limites do site alvo — com números concretos e código em Python.
Por que contar o pool pela quantidade de IPs é um erro
A abordagem típica de um novato em scraping: "preciso coletar 50.000 cartões de produtos, então vamos comprar 500 proxies e distribuir a carga". A lógica parece sensata, mas não leva em conta o principal — sites como Wildberries e Ozon banem não pelo número absoluto de requisições, mas pela intensidade de requisições de um único IP em um determinado tempo. Ou seja, 500 proxies, cada um fazendo 20 requisições por segundo, serão banidos instantaneamente — os sistemas anti-bot detectam um padrão semelhante a um DDoS.
Por outro lado, se você tiver 50 proxies, mas cada um faz 1 requisição a cada 5-10 segundos com pausas aleatórias, imitando o comportamento humano, você pode fazer scraping de forma estável por semanas sem um único ban. A quantidade de IPs não é a razão da estabilidade, mas a consequência de uma carga bem calculada. É por isso que a fórmula deve se basear não em "quantos IPs comprar", mas em "quanto RPS é necessário alcançar e qual é a carga segura em um único IP".
Outro detalhe: diferentes tipos de proxies têm diferentes "reservas de resistência" por IP. Proxies de data center são banidos mais rapidamente com alta frequência de requisições, pois suas sub-redes são facilmente reconhecidas como de hospedagem. Proxies residenciais e móveis se parecem com usuários comuns, e podem ter uma frequência um pouco mais alta sem risco de bloqueio — mas isso não significa que se pode ignorar os limites completamente.
Fórmula básica de cálculo do pool de proxies
A fórmula para calcular a quantidade de proxies no pool é a seguinte:
N = (RPS_target × Delay_per_ip) / Concurrency_per_ip
Onde:
- N — quantidade necessária de proxies no pool;
- RPS_target — velocidade alvo de scraping (requisições por segundo em todo o sistema);
- Delay_per_ip — pausa mínima segura entre requisições de um único IP (em segundos);
- Concurrency_per_ip — quantos fluxos paralelos você permite em um único IP (geralmente 1, no máximo 2 para proxies residenciais).
A lógica é simples: se você quer manter 10 requisições por segundo no total, e a pausa segura entre requisições de um único IP é de 8 segundos, então um IP fisicamente pode fazer apenas 1 requisição a cada 8 segundos, ou seja, 0.125 RPS. Para obter 10 RPS no total, você precisa de 10 / 0.125 = 80 proxies. Esse é o cálculo que substitui a adivinhação de "500 IPs por precaução".
Como calcular o RPS alvo para scraping
Antes de calcular o pool, é necessário determinar o RPS_target — quantas requisições por segundo você realmente precisa para coletar dados em um prazo razoável. A fórmula aqui é inversa:
RPS_target = Total_requests / Time_budget_seconds
Exemplo: você precisa coletar 100.000 cartões de produtos do Wildberries em 8 horas (28.800 segundos). Se cada cartão requer 1 requisição, RPS_target = 100.000 / 28.800 ≈ 3.47 requisições por segundo. Isso não é tanto quanto parece à primeira vista — muitos superestimam a velocidade necessária e compram uma quantidade excessiva de proxies.
Se a tarefa envolve vários tipos de requisições (por exemplo, primeiro obter a lista de categorias, depois os cartões, depois as avaliações), calcule o RPS para cada etapa separadamente — eles podem ocorrer paralelamente com diferentes pools de proxies, e a carga total no site será distribuída entre diferentes endpoints.
Limites por IP: quantas requisições por minuto são seguras
Delay_per_ip é o parâmetro mais importante na fórmula, e deve ser determinado empiricamente para cada site. Diretrizes gerais, baseadas na prática de scraping de marketplaces:
| Plataforma | Pausa segura entre requisições de 1 IP | Máximo de requisições/min com 1 IP |
|---|---|---|
| Wildberries (API de cartões) | 4-6 seg | 10-15 |
| Ozon (páginas de produtos) | 5-8 seg | 8-12 |
| Avito (anúncios) | 6-10 seg | 6-10 |
| Yandex.Market | 5-7 seg | 8-12 |
Esses números são um ponto de partida, não uma regra rígida. Comece com valores conservadores (limite superior da pausa), monitore a porcentagem de erros 429 e 403, e gradualmente diminua a pausa se os bans não aumentarem. Aumento repentino do RPS sem testes graduais é a maneira mais comum de queimar todo o pool de proxies em um dia.
Cálculos práticos: Wildberries, Ozon, Avito
Vamos analisar três cenários reais com cálculo completo pela fórmula.
Cenário 1: monitoramento de preços no Wildberries. É necessário atualizar os preços de 20.000 produtos a cada 2 horas. RPS_target = 20.000 / (2 × 3600) ≈ 2.78 RPS. Com uma pausa de 5 seg por 1 IP e Concurrency = 1: N = (2.78 × 5) / 1 ≈ 14 proxies. Para uma margem em caso de banimento de alguns IPs, recomenda-se ter um pool com um fator de 1.5-2x, ou seja, 21-28 proxies.
Cenário 2: coleta única do catálogo do Ozon. 500.000 cartões em 24 horas. RPS_target = 500.000 / 86.400 ≈ 5.79 RPS. Com uma pausa de 6 seg: N = (5.79 × 6) / 1 ≈ 35 proxies. Com margem — 50-60 proxies.
Cenário 3: monitoramento de concorrentes no Avito em tempo real. 5.000 anúncios, atualização a cada 15 minutos. RPS_target = 5.000 / 900 ≈ 5.56 RPS. Com uma pausa de 8 seg: N = (5.56 × 8) / 1 ≈ 45 proxies. Aqui é importante considerar que o Avito banem ativamente sub-redes de data center, portanto, para essa tarefa, é mais sensato usar IPs residenciais ou móveis desde o início.
Proxies residenciais, móveis e de data center na fórmula
O tipo de proxy influencia diretamente o Delay_per_ip e, consequentemente, o N final na fórmula. Proxies de data center são mais baratos e rápidos, mas requerem pausas mais longas entre requisições e são banidos mais frequentemente com alta frequência — de fato, para os mesmos 5 RPS, você pode precisar de 2-3 vezes mais IPs de data center do que residenciais.
| Tipo de proxy | Delay_per_ip médio | Quando usar |
|---|---|---|
| Proxies de data center | 8-15 seg | APIs abertas, sites sem anti-bot rigoroso |
| Proxies residenciais | 4-8 seg | Wildberries, Ozon, Avito e outros marketplaces com anti-bot |
| Proxies móveis | 3-6 seg | As proteções mais agressivas, redes sociais, APIs móveis |
Para scraping de marketplaces como Wildberries e Ozon, a escolha ideal geralmente são proxies residenciais — elas equilibram preço e estabilidade, permitindo manter pausas mais curtas sem um aumento brusco nos bans. Proxies de data center devem ser considerados apenas para plataformas sem anti-bot agressivo ou para tarefas pontuais com RPS baixo.
Implementação do pool em Python: código com rotação
Abaixo está uma implementação simplificada do pool de proxies com controle de frequência de requisições para cada IP. A lógica: cada proxy armazena o tempo da última utilização, e o planejador escolhe apenas aqueles IPs que tiveram tempo suficiente desde a última requisição.
import time
import random
from dataclasses import dataclass, field
from typing import List, Optional
@dataclass
class ProxyNode:
address: str
delay_per_ip: float # pausa segura em segundos
last_used: float = field(default=0.0)
class ProxyPool:
def __init__(self, proxies: List[str], delay_per_ip: float):
self.nodes = [ProxyNode(address=p, delay_per_ip=delay_per_ip) for p in proxies]
def get_available_proxy(self) -> Optional[ProxyNode]:
now = time.time()
available = [
node for node in self.nodes
if now - node.last_used >= node.delay_per_ip
]
if not available:
return None
# escolhe aleatoriamente entre os disponíveis, para evitar padrão de fila
node = random.choice(available)
node.last_used = now
return node
def size(self) -> int:
return len(self.nodes)
def calculate_pool_size(rps_target: float, delay_per_ip: float, concurrency: int = 1) -> int:
"""Fórmula: N = (RPS_target * Delay_per_ip) / Concurrency_per_ip"""
return max(1, int((rps_target * delay_per_ip) / concurrency))
# Exemplo de uso
rps_target = 5.79 # calculado a partir do volume da tarefa e do tempo
delay_per_ip = 6.0 # pausa segura para Ozon
n_proxies = calculate_pool_size(rps_target, delay_per_ip)
print(f"Proxies necessários no pool: {n_proxies}") # ~35, com margem 50-60
Em um scraper real, essa lógica deve ser complementada com uma fila de tarefas (por exemplo, através de asyncio ou multiprocessing), para que os workers aguardem a disponibilidade de um proxy livre, em vez de falharem com erro na ausência deles. Também é recomendável adicionar um backoff exponencial ao receber 429/403 — isso aumentará automaticamente a pausa para um IP específico ao sinalizar bloqueio.
Monitoramento e correção dinâmica do pool
O cálculo estático pela fórmula é um ponto de partida, não uma solução final. Na prática, é necessário monitorar três métricas-chave:
- Taxa de sucesso — porcentagem de requisições bem-sucedidas (código 200) em relação ao total. Uma queda abaixo de 90-95% sinaliza que o Delay_per_ip precisa ser aumentado ou que proxies devem ser adicionados ao pool;
- Taxa de banimento — proporção de proxies que mostraram sinais de bloqueio (captcha, 403, redirecionamento para formulário de verificação) na última hora;
- RPS real — velocidade real de processamento de requisições, que pode diferir da calculada devido a timeouts e tentativas de repetição.
Regra prática: se a taxa de banimento exceder 5-7% por hora, aumente o Delay_per_ip em 20-30% e recalcule N pela fórmula novamente. Se a taxa de sucesso permanecer acima de 98% por várias horas, você pode gradualmente diminuir a pausa e reduzir o tamanho do pool — isso representa uma economia direta no orçamento para proxies sem perda de estabilidade.
Uma boa prática é manter um log separado para cada IP: tempo da última requisição bem-sucedida, número de erros consecutivos, tempo médio de resposta. Isso permite excluir automaticamente proxies "danificados" da rotação por 30-60 minutos, em vez de continuar enviando requisições por meio deles e receber captcha a cada passo.
Erros comuns ao calcular o pool de proxies
Mesmo conhecendo a fórmula, é fácil cometer erros nos detalhes do cálculo. Aqui está uma lista de erros típicos:
- Ignorar a reserva para bans. Mesmo com um cálculo perfeito, 5-10% dos proxies estarão temporariamente indisponíveis devido a bloqueios ou problemas de rede. Sempre adicione um fator de 1.3-2x ao N base;
- Delay_per_ip igual para todos os endpoints. A página de categoria e a página do cartão de produto podem ter limites diferentes — calcule separadamente;
- Concurrency maior que 1 sem testes. Requisições paralelas de um único IP aumentam drasticamente o risco de banimento, especialmente em proxies residenciais — comece com Concurrency = 1;
- Ausência de rotação de User-Agent e cabeçalhos. Mesmo um pool de proxies bem calculado não ajudará se todas as requisições forem feitas com a mesma impressão de navegador;
- Pausa fixa sem jitter. Intervalo estritamente igual entre requisições (por exemplo, exatamente 5.0 seg) é um padrão facilmente reconhecido pelo anti-bot. Adicione uma variação aleatória de ±20-30%.
Conclusão
A fórmula N = (RPS_target × Delay_per_ip) / Concurrency_per_ip transforma o cálculo do pool de proxies de uma adivinhação em uma tarefa de engenharia com números concretos. Primeiro, determine a velocidade alvo de scraping com base no volume de dados e no tempo, em seguida, encontre empiricamente a pausa segura para a plataforma específica, e só então calcule a quantidade necessária de IPs — com uma reserva de 30-100% para bans e falhas.
Essa abordagem economiza orçamento: em vez de comprar uma quantidade excessiva de IPs "por precaução", você paga exatamente pelo volume de proxies necessário para alcançar o RPS alvo sem risco de bloqueios. Para scraping de marketplaces e outros sites protegidos, recomendamos começar com proxies residenciais — elas oferecem o melhor equilíbrio entre estabilidade e custo ao trabalhar com sistemas anti-bot do Wildberries, Ozon e Avito.