Limite de tráfego para scraping Wildberries e Ozon: como não desperdiçar um pacote mensal de proxies durante a noite

O vendedor inicia o scraper de preços dos concorrentes à noite e, pela manhã, recebe uma notificação: o tráfego acabou, o pacote foi esgotado em 90%. Situação familiar? Na maioria das vezes, o culpado não é o scraper em si, mas a falta de limites no nível de proxies e do script. Neste artigo, vamos analisar como exatamente o tráfego "vaza" desnecessariamente e como implementar proteções para que o pacote mensal de proxies residenciais ou móveis dure até o final do período calculado.

Por que o tráfego acaba durante a noite

O scraping do Wildberries, Ozon ou Avito parece uma tarefa simples: envia-se uma solicitação — recebe-se um JSON com o preço. Mas na prática, o tráfego é consumido não apenas por dados úteis. As principais fontes de desperdício são:

• Carregamento de imagens e mídia. Se o scraper abre a página do produto completamente através do navegador (em vez de fazer uma solicitação direta à API), ele automaticamente carrega imagens, vídeos, banners — isso pode ser dezenas de megabytes por cartão.
• Solicitações repetidas devido a CAPTCHA e bloqueios. O marketplace reconhece o bot, exibe um CAPTCHA ou um bloqueio temporário de IP, o script faz uma nova solicitação — o tráfego é desperdiçado, e os dados não chegam.
• Falta de cache de solicitações. Sem a lógica de "já foi raspado nesta hora — não repetir", o script pode consultar os mesmos cartões várias vezes durante a noite.
• Fluxos paralelos sem limites. Executar 50-100 fluxos simultaneamente parece acelerar o trabalho, mas o tráfego é consumido muito mais rápido do que o planejado, e parte das solicitações simplesmente é bloqueada.
• Escolha incorreta do tipo de proxy. Proxies residenciais e móveis geralmente são cobrados pelo volume de tráfego (GB), ao contrário dos proxies de data center, onde o pagamento é mais frequentemente feito pelo número de IPs ou tempo de aluguel. Se o scraper estiver configurado para um pool residencial sem controle — o limite se esgota rapidamente.

A combinação desses fatores leva a que um script projetado para um mês de trabalho consuma um pacote de tráfego em uma única sessão noturna de scraping de 10-20 mil cartões de produtos.

Como o tráfego é contabilizado para diferentes tipos de proxies

Antes de definir limites, é importante entender pelo que exatamente você está pagando. Diferentes tipos de proxies contabilizam o consumo de maneiras diferentes, e isso afeta diretamente a estratégia de economia.

Tipo de Proxy	Cobrança	Risco de desperdício	Quando aplicar
Proxies residenciais	Por volume de tráfego (GB)	Alto sem limites	Scraping com contorno da proteção anti-bot dos marketplaces
Proxies móveis	Por volume de tráfego ou por tempo	Alto, tráfego mais caro	Scraping de versões móveis de sites, contornando bloqueios rígidos
Proxies de data center	Por número de IPs / tempo de aluguel	Baixo, tráfego geralmente ilimitado	Scraping em massa sem proteção anti-bot rigorosa

Se você está fazendo scraping do Wildberries ou Ozon, onde a proteção contra bots está ativamente em funcionamento, proxies residenciais ou móveis são quase sempre necessários — endereços de data center são bloqueados rapidamente. Mas é precisamente devido à cobrança por tráfego que aqui é especialmente importante definir limites com antecedência.

Quanto tráfego realmente é necessário para scraping

Para definir um limite adequado, é necessário basear-se em números reais, e não em sensações. As despesas aproximadas na prática são:

• Solicitação à API do cartão do produto (JSON, sem imagens): 5-30 KB por cartão. Para 10.000 cartões — cerca de 50-300 MB.
• Carregamento da página do produto através de um navegador headless com imagens: 1-3 MB por cartão. Para os mesmos 10.000 cartões — 10-30 GB.
• Monitoramento de preços uma vez por hora para 1000 SKU: com solicitações simplificadas — cerca de 1-5 GB por dia, com carregamento completo das páginas — 50-100 GB por dia.

A diferença entre scraping "leve" e "pesado" é de dezenas de vezes. Portanto, o primeiro passo para economizar tráfego é desativar o carregamento de imagens, vídeos e scripts de terceiros onde for possível e trabalhar diretamente com a API do marketplace ou a versão móvel do site, que pesa menos que a versão desktop.

Limites em navegadores anti-detect e gerenciadores de proxies

Para aqueles que fazem scraping através de um navegador anti-detect (por exemplo, Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) ou um gerenciador de proxies próprio, a maneira mais simples de limitar o consumo é configurar limites no nível do perfil e da conta do provedor de proxies.

1. Acesse o painel do provedor de proxies e encontre a seção de gerenciamento de tráfego ou limites para sub-usuários/portas.
2. Crie uma sub-conta ou porta separada para scraping — não use o mesmo pool de proxies que para farmar contas no Instagram ou TikTok. A separação por tarefas imediatamente mostra para onde o tráfego está indo.
3. Defina um limite diário ou horário de tráfego nesta sub-conta — por exemplo, 5 GB por dia em vez de consumir todo o pacote mensal em uma única sessão.
4. No navegador anti-detect, desative o carregamento automático de imagens para perfis que são usados exclusivamente para coleta de dados, e não para visualização visual das páginas.
5. Configure um cronograma de ativação de perfis para que o scraping ocorra não em uma única sessão longa, mas em intervalos curtos com pausas — isso reduz o risco de bloqueio e dá tempo para monitorar o consumo de tráfego entre as execuções.

Essa abordagem é especialmente importante para agências e freelancers que fazem scraping de vários marketplaces ao mesmo tempo: sem a separação por sub-contas, é difícil entender qual projeto específico "consumiu" o tráfego.

Limitação de tráfego no nível do script e API

Se o scraper foi escrito manualmente em Python ou Node.js, os limites podem e devem ser incorporados diretamente no código — isso proporciona um controle mais preciso do que as configurações da interface do provedor de proxies.

Exemplo de um contador simples de tráfego em Python usando requests:

import requests

MAX_BYTES_PER_DAY = 5 * 1024 * 1024 * 1024  # limite de 5 GB por dia
used_bytes = 0

proxies = {
    "http": "http://user:pass@proxy_host:port",
    "https": "http://user:pass@proxy_host:port",
}

def safe_get(url):
    global used_bytes
    if used_bytes >= MAX_BYTES_PER_DAY:
        raise RuntimeError("Limite diário de tráfego esgotado, scraping interrompido")

    response = requests.get(url, proxies=proxies, timeout=10)
    used_bytes += len(response.content)
    return response

# exemplo de chamada
resp = safe_get("https://card.wb.ru/cards/detail?nm=123456")
print("Tráfego utilizado:", round(used_bytes / 1024 / 1024, 2), "MB")

A lógica é simples: o script conta o volume de cada resposta em bytes e para assim que o limite definido é alcançado. Isso protege contra situações em que, devido a um erro em um loop ou repetições infinitas de solicitações, o script "consome" o pacote mensal de tráfego em poucas horas.

Além disso, é aconselhável adicionar:

• Atraso exponencial em caso de erros (retry com backoff) — em vez de repetir imediatamente a solicitação em caso de CAPTCHA ou bloqueio, o script aguarda um intervalo crescente (5 seg, 15 seg, 60 seg), o que reduz o número de solicitações inúteis.
• Limitação do número de fluxos paralelos — por exemplo, não mais que 10-20 conexões simultâneas através do pool de proxies, para não provocar bloqueios e não desperdiçar tráfego desnecessariamente.
• Desativação do carregamento de recursos no navegador headless — se o scraping estiver sendo feito através do Selenium ou Puppeteer, nas configurações do navegador é possível bloquear o carregamento de imagens, fontes e CSS, deixando apenas as respostas HTML/JSON.

Monitoramento de consumo em tempo real

Um limite sem monitoramento funciona pior, pois você só descobre sobre o problema após a interrupção do script. Para controlar o consumo em tempo real:

• Ative notificações no painel do provedor de proxies sobre o alcance de 50%, 80% e 100% do pacote mensal de tráfego — a maioria dos serviços suporta esses alertas por email ou Telegram.
• Mantenha um log simples no próprio script: registre em um arquivo ou banco de dados o volume de tráfego por horas, para ver os picos de consumo e rapidamente encontrar a fonte do problema.
• Separe o tráfego por tarefas através de sub-contas ou etiquetas — separadamente para scraping do Wildberries, separadamente para Ozon, separadamente para Avito. Isso simplifica a análise de qual projeto consome mais.
• Compare o consumo com o volume de dados esperado: se para 10.000 cartões foram utilizados 20 GB em vez dos 300 MB calculados, significa que recursos extras estão sendo carregados ou que há solicitações repetidas.

Checklist de controle do orçamento de tráfego

Erros comuns de iniciantes

Na prática, a maioria dos pacotes de tráfego "queimados" pode ser explicada por alguns erros típicos:

• Executar scraping "à noite sem supervisão" sem limites. O script funciona 8-10 horas sem parar, e se em algum lugar houver um loop de solicitações repetidas, o tráfego é consumido continuamente até a manhã.
• Um único pool de proxies para todas as tarefas. Farmar contas no Instagram, testar anúncios no Facebook Ads e fazer scraping do Ozon usam o mesmo tráfego — impossível entender o que exatamente está consumindo.
• Ignorar CAPTCHA. Em vez de reduzir a frequência das solicitações ao primeiro sinal de CAPTCHA, o script continua atacando o site com a mesma intensidade, desperdiçando tráfego em respostas inúteis com código de erro.
• Escolher proxies residenciais onde proxies de data center seriam suficientes. Se o marketplace não bloqueia IPs de data center rigorosamente, o pagamento excessivo por tráfego de um pool residencial não é justificado — para objetivos menos protegidos, proxies de data center com outro modelo de cobrança são adequados.
• Falta de um teste prévio. Antes de iniciar um scraping completo em milhares de cartões, é aconselhável executar o script em 50-100 cartões e medir o consumo real de tráfego, para extrapolar para todo o volume.

Conclusão

O tráfego para scraping "queima-se" não por causa do volume de dados, mas pela falta de controle: imagens desnecessárias, solicitações repetidas em bloqueios, fluxos paralelos sem limites e um pool geral de proxies para todas as tarefas. A solução é separar o tráfego por projetos, definir limites diários no nível da conta de proxy, incorporar um contador de consumo no próprio script e configurar monitoramento com notificações antes que o pacote realmente acabe.

Se você está fazendo scraping de marketplaces com proteção ativa contra bots, como Wildberries ou Ozon, recomendamos usar proxies residenciais para contornar bloqueios e, adicionalmente, IPs móveis para os cenários mais sensíveis à proteção anti-bot — mas em ambos os casos, é imprescindível definir limites de tráfego com antecedência, para que o pacote mensal não se esgote em uma única sessão noturna.