Erro 429 ao fazer parsing: 6 razões além do proxy.

Você troca de proxy, compra um novo pool de endereços IP, mas o parser ainda falha com o erro 429 Too Many Requests? Esta é uma situação clássica: 70% dos casos de bloqueio não estão relacionados ao endereço IP, mas à forma como a solicitação é feita. Vamos analisar seis razões reais pelas quais o site continua a bloquear você mesmo após a troca de proxy — e o que fazer em cada caso.

O que significa o erro 429 e por que o proxy não é uma panaceia

O código HTTP 429 Too Many Requests significa formalmente "limite de solicitações excedido". Mas, na prática, sites — especialmente Wildberries, Ozon, Avito, Yandex.Market — usam esse código como um sinal universal de "achamos que você é um bot". A razão pode estar na frequência das solicitações, mas com a mesma probabilidade pode estar nos cabeçalhos, impressão do navegador, ausência de sessão de cookies ou em limites vinculados não ao IP, mas à sua conta.

É por isso que trocar de proxy muitas vezes não ajuda: se o sistema bloqueia não o IP, mas o padrão da solicitação (fingerprint, cabeçalhos, velocidade de cliques), então do novo endereço IP você receberá o mesmo 429 em poucos minutos. Vamos analisar cada razão em detalhes e mostrar como verificá-las e resolvê-las sem comprar um novo pool de proxies.

Importante: proxies continuam sendo uma ferramenta necessária — mas apenas como parte de um sistema, e não como a única solução. IPs residenciais e móveis reduzem a probabilidade de serem colocados em listas negras por reputação de IP, mas não salvam de bloqueios por comportamento ou cabeçalhos.

Razão 1: Frequência de solicitações muito alta

A razão mais óbvia, mas também a mais frequentemente diagnosticada incorretamente. Muitos pensam: "já que troco de proxy a cada solicitação — a frequência não importa". Isso está errado. Sistemas modernos de anti-bots (por exemplo, Wildberries e Ozon usam soluções de nível Cloudflare ou seus próprios WAF) analisam não apenas a frequência de um único IP, mas também a carga total em um endpoint API específico ou página de produto em um determinado período de tempo de todas as fontes em conjunto com sinais comportamentais.

Se seu parser faz 50-100 solicitações por segundo para a mesma seção do catálogo, o sistema vê um pico anômalo de tráfego, independentemente de quantos IPs diferentes você está usando. A solução não é trocar de proxy, mas implementar atrasos artificiais (throttling) entre as solicitações: 1-3 segundos de atraso aleatório em vez de um intervalo fixo, além de um backoff exponencial ao receber 429 (aumentar a pausa em dobro após cada bloqueio).

import time, random

def safe_request(session, url):
    for attempt in range(5):
        response = session.get(url)
        if response.status_code == 429:
            wait = (2 ** attempt) + random.uniform(0, 1)
            time.sleep(wait)
            continue
        return response
    return None

Se você está usando um parser pronto sem código (por exemplo, um serviço de monitoramento de preços na nuvem), verifique as configurações do intervalo entre solicitações — na maioria dessas ferramentas há um controle deslizante "velocidade de varredura". Reduzir a velocidade em 30-40% muitas vezes elimina completamente o 429, mesmo sem mudar o proxy.

Razão 2: Cabeçalhos incorretos ou ausentes

Muitos parsers enviam solicitações com um conjunto mínimo de cabeçalhos ou usam a User-Agent da biblioteca por padrão (por exemplo, "python-requests/2.28.1"). Esse cabeçalho imediatamente revela um bot — um navegador real envia dezenas de cabeçalhos: Accept, Accept-Language, Accept-Encoding, Sec-Fetch-*, Referer e outros em uma ordem estritamente definida.

Wildberries e Ozon comparam o conjunto de cabeçalhos com a "impressão" esperada de um navegador real como Chrome ou Safari. Se houver muitos poucos cabeçalhos, eles não estiverem na ordem correta ou a User-Agent não corresponder aos outros parâmetros (por exemplo, declarado Chrome no Windows, mas a impressão TLS se assemelhar ao Python) — a solicitação é bloqueada com 429 independentemente do IP.

Cabeçalho	Erro típico	Solução
User-Agent	Versão desatualizada ou string claramente da biblioteca	UA atual de um Chrome/Safari real, rotação do pool
Accept-Language	Ausente ou não coincide com a geolocalização do IP	ru-RU para marketplaces russos
Referer	Vazio, embora a transição real sempre venha com Referer	Indicar a página anterior do catálogo
Sec-Fetch-*	Totalmente ausente (não é um cliente de navegador)	Copiar o conjunto completo do DevTools de um navegador real

A maneira mais fácil é copiar o conjunto completo de cabeçalhos da aba Network no DevTools de um navegador real, abrindo a página necessária manualmente, e usar exatamente esse conjunto no parser — levando em conta a ordem dos cabeçalhos, se a biblioteca permitir (por exemplo, curl_cffi ou httpx com ordem explícita).

Razão 3: Falta de rotação de sessões e cookies

Um erro que frequentemente é negligenciado: o parser muda de IP a cada solicitação, mas usa a mesma sessão de cookies ou não salva cookies de forma alguma. Um usuário real recebe, na primeira visita, um conjunto de cookies (tokens de sessão, identificadores de dispositivo, etiquetas de proteção antibot como Cloudflare __cf_bm ou similares em Ozon/WB) e os utiliza em todas as solicitações subsequentes dentro da sessão.

Se você enviar uma solicitação sem cookies obtidos na página "aquecida", o sistema anti-bot vê uma sessão "nula" — e isso é imediatamente suspeito, especialmente ao acessar endpoints API diretamente, ignorando a página principal. A solução é emular o cenário completo: primeiro carregar a página principal ou a página da categoria, obter cookies, esperar 1-2 segundos e só então acessar a API desejada ou a ficha do produto, mantendo os cookies na mesma sessão ao longo da cadeia de solicitações.

import requests

session = requests.Session()
session.headers.update({
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)...",
    "Accept-Language": "ru-RU,ru;q=0.9"
})

# Aquecendo a sessão
session.get("https://www.wildberries.ru/catalog/0/search.aspx")
time.sleep(1.5)

# Solicitação principal já com cookies
response = session.get(target_url)

Se você está usando um navegador anti-detect como Dolphin Anty ou AdsPower para monitorar fichas de produtos manualmente ou através de automação embutida, certifique-se de que o perfil salva cookies entre sessões e não é iniciado sempre "do zero" — isso também aciona a suspeita do sistema.

Razão 4: Comportamento semelhante ao de um bot

Mesmo com cabeçalhos e cookies ideais, o parser pode se revelar através de padrões comportamentais: ordem estritamente linear ao acessar produtos (em ordem crescente de ID), intervalo idêntico entre solicitações até milissegundos, ausência de solicitações "desperdício" para estáticos (imagens, CSS, JS), que um navegador comum carrega automaticamente.

Sistemas de proteção avançados da Wildberries e Ozon analisam não apenas as solicitações HTTP, mas também se o JavaScript foi executado na página (através da detecção headless), se o "mouse" se moveu, se houve rolagem. Se você faz solicitações HTTP puras sem renderização de JS, e o site espera a execução de um script para obter um token (por exemplo, desafio de JavaScript anti-bot), a solicitação sem a execução desse script automaticamente recebe 429 ou 403.

A solução depende da escala: para volumes pequenos, o uso de um navegador headless (Playwright, Puppeteer) com emulação de movimentos do mouse e atrasos aleatórios é adequado. Para scraping em larga escala — aleatorização da ordem de navegação dos produtos, adição de "ruído" na forma de solicitações para recursos secundários, variabilidade dos intervalos de tempo com distribuição normal, e não em um passo fixo.

Razão 5: Impressão TLS/JA3 e HTTP/2

Esta é a razão técnica mais "invisível", da qual 90% das pessoas envolvidas em scraping sem formação técnica profunda não têm conhecimento. Cada cliente TLS (biblioteca requests, curl, urllib) deixa uma impressão única ao estabelecer uma conexão HTTPS — um conjunto de cifras suportadas, versões do protocolo, extensões TLS. Essa impressão é chamada de impressão JA3/JA4.

Sistemas anti-bot de nível Cloudflare, Akamai e soluções próprias de grandes marketplaces comparam a impressão JA3 com um banco de dados de bots e bibliotecas conhecidas. O padrão Python requests ou o módulo https do Node.js têm uma impressão facilmente detectável, completamente diferente da impressão de um Chrome real. Mesmo com cabeçalhos e cookies ideais, a solicitação é bloqueada exatamente no nível do handshake TLS, antes que o servidor veja os cabeçalhos HTTP.

Além disso, muitos marketplaces exigem HTTP/2 com parâmetros específicos (ordem dos frames SETTINGS, priorização de streams) — bibliotecas baseadas em HTTP/1.1 se destacam automaticamente nesse contexto. A solução é usar bibliotecas que emulam a impressão de um navegador real: curl_cffi (emula a impressão TLS do Chrome), tls-client, ou navegadores headless completos baseados em Chromium, que fornecem uma impressão "real" por definição.

pip install curl_cffi

Exemplo: curl_cffi.requests.get(url, impersonate="chrome120") — a biblioteca automaticamente insere a impressão TLS idêntica ao Chrome 120 real.

Razão 6: Limite no nível da conta ou chave API

Se você está trabalhando através da API oficial ou semi-oficial do marketplace (por exemplo, API do vendedor Wildberries ou Ozon Seller API), o 429 pode estar vinculado não ao IP, mas à própria conta do vendedor ou ao token API. Nesse caso, trocar de proxy é completamente inútil — o limite é armazenado no lado do servidor vinculado ao seu identificador de conta, e qualquer IP dessa conta receberá a mesma limitação.

Essa situação é típica para vendedores que monitoram simultaneamente os preços dos concorrentes através do painel e acessam a API para extrair estoques — ambos os fluxos de solicitações se somam ao limite geral da conta. A solução é distribuir a carga ao longo do tempo, usar as cotas oficiais da API de forma mais econômica (armazenar em cache dados que não mudam a cada minuto), e para monitoramento puro de preços dos concorrentes, usar um fluxo de solicitações não autenticado separado, não vinculado à conta do vendedor.

Verificar isso é simples: se o 429 continuar mesmo ao acessar de um novo IP limpo e sem um único cookie de sessões anteriores, mas você estiver logado no painel em uma aba ao lado — provavelmente, o limite é realmente da conta.

Como diagnosticar a verdadeira razão

Antes de mudar a infraestrutura, faça um diagnóstico seguindo o algoritmo a seguir. Primeiro, abra a página manualmente em um navegador comum e verifique se o 429 não ocorre com um comportamento real — isso confirmará que o problema está do lado do parser, e não um bloqueio global da região.

Em seguida, compare os cabeçalhos do seu parser com os cabeçalhos de um navegador real através do DevTools (aba Network → Copy as cURL). Se a diferença for mínima, verifique a impressão TLS através de serviços como tls.peet.ws — envie uma solicitação com sua biblioteca e compare o hash JA3 com o do navegador de referência. Se a solicitação falhar na etapa do handshake TLS (a conexão é interrompida antes de receber a resposta HTTP) — a razão está no fingerprint, e não na frequência ou cabeçalhos.

Em seguida, verifique se o limite está vinculado ao IP ou à conta: faça uma solicitação de um novo IP limpo sem autenticação. Se o 429 desaparecer — o problema estava na reputação do IP anterior ou na frequência desse endereço. Se o 429 persistir — procure a razão nos cabeçalhos, TLS ou comportamento, e não no proxy.

Checklist para resolver o 429 sem trocar de proxy

Adicione atrasos aleatórios de 1-4 segundos entre as solicitações em vez de um intervalo fixo.
Copie o conjunto completo de cabeçalhos de um navegador real, incluindo Sec-Fetch-* e Accept-Language.
Mantenha e passe cookies dentro de uma única sessão, começando com o aquecimento da página principal.
Verifique a impressão TLS da sua biblioteca — use curl_cffi ou um navegador headless em vez de um cliente HTTP puro.
Randomize a ordem de navegação das páginas e adicione solicitações "ruidosas" para recursos estáticos.
Divida a carga da conta API e do monitoramento anônimo de preços em diferentes fluxos.
Implemente um backoff exponencial ao receber 429, em vez de uma repetição imediata da solicitação.
Apenas após verificar todos os itens acima — troque de proxy ou amplie o pool de IPs.

Quando o proxy ainda é necessário e quais escolher

Após resolver todas as seis razões, o proxy continua sendo um elemento importante da infraestrutura — mas agora como um meio de escalonamento, e não como a única maneira de combater bloqueios. Se sua tarefa é monitorar paralelamente milhares de fichas da Wildberries e Ozon de diferentes "usuários virtuais", você precisará de um pool de IPs com boa reputação, para não acumular um histórico de bloqueios em um único endereço.

Para monitoramento em massa de preços e catálogos de marketplaces, os proxies residenciais são os mais adequados — eles usam IPs reais de provedores domésticos, portanto, os sistemas anti-bot percebem as solicitações como tráfego de compradores comuns, e não de data centers. Isso é crítico, pois a Wildberries e a Ozon há muito mantêm listas negras de faixas de IPs de data centers.

Se a tarefa está relacionada à verificação da versão móvel do site, ao trabalho através do aplicativo do marketplace ou ao teste de anúncios no TikTok Ads e Facebook Ads com precisão geográfica até a cidade, os proxies móveis são relevantes — eles têm o nível máximo de confiança na maioria dos sistemas de proteção, pois os IPs pertencem a operadores de telefonia móvel reais.

Para tarefas menos sensíveis — por exemplo, scraping de catálogos abertos sem autenticação em volumes pequenos — você pode usar proxies de data center: eles são significativamente mais baratos e rápidos, mas exigem uma configuração mais cuidadosa dos cabeçalhos e da impressão TLS, pois, por si só, apresentam um risco maior de serem considerados suspeitos.

Tipo de proxy	Quando resolve o 429	Quando não ajuda
Residenciais	IP já na lista negra por reputação	Bloqueio por impressão TLS ou cabeçalhos
Móveis	Necessária a máxima confiabilidade do IP para cenários sensíveis	Limite vinculado à conta, e não ao IP
Data Center	Scraping simples de páginas abertas sem autenticação	Sistemas anti-bot rigorosos com verificação de reputação de faixas

Conclusão

O erro 429 ao fazer parsing raramente é resolvido com um único botão "trocar proxy". Na maioria dos casos, o problema reside na frequência das solicitações, cabeçalhos incompletos, ausência de sessão de cookies, impressão TLS detectável, padrões comportamentais ou limites vinculados à conta, e não ao endereço IP. Realize o diagnóstico de cada um dos seis pontos deste artigo antes de gastar o orçamento para expandir o pool de proxies.

Quando a parte técnica está configurada corretamente — os cabeçalhos correspondem a um navegador real, a impressão TLS não revela a biblioteca, e as solicitações imitam o comportamento natural do usuário — os proxies se tornam uma ferramenta realmente eficaz de escalonamento. Para monitoramento de preços na Wildberries e Ozon em grandes volumes, recomendamos começar com proxies residenciais: eles oferecem o melhor equilíbrio entre custo e nível de confiança dos sistemas anti-bot.