Erro "Too Many Requests" 429: como contornar limites usando proxies e rotação de IP

Se você está fazendo scraping de marketplaces, monitorando preços de concorrentes ou automatizando o trabalho com redes sociais, certamente já se deparou com o erro 429 Too Many Requests. O site bloqueia suas solicitações, considerando-as suspeitas, e toda a automação para. Neste artigo, vamos analisar por que esse problema ocorre e como resolvê-lo através da configuração correta de proxies, rotação de IP e distribuição adequada de carga.

Vamos mostrar soluções específicas para diferentes tarefas: scraping de Wildberries e Ozon, monitoramento de concorrentes, trabalho com APIs de redes sociais, coleta de dados em massa. Todas as recomendações são baseadas em experiência prática e funcionam em projetos reais.

O que é o erro 429 Too Many Requests e por que ele ocorre

O erro 429 Too Many Requests é um código de resposta HTTP que o servidor retorna quando você excede o número permitido de solicitações em um determinado período de tempo. Este é um mecanismo de proteção dos sites contra sobrecarga e coleta automatizada de dados.

Situações típicas em que o 429 ocorre:

• Scraping de marketplaces — você coleta preços de Wildberries, Ozon ou Avito, fazendo centenas de solicitações por minuto. O site detecta atividade anômala de um único IP e o bloqueia.
• Monitoramento de concorrentes — coleta automatizada de dados sobre produtos, preços, disponibilidade. Com verificações frequentes, o limite é atingido.
• Trabalho com APIs — muitas APIs têm restrições rígidas: por exemplo, a API do Instagram permite 200 solicitações por hora, o Twitter — 300 solicitações a cada 15 minutos.
• Registro ou ações em massa — criação de contas, envio de mensagens, curtidas. As plataformas rapidamente identificam a automação e bloqueiam o IP.

É importante entender: o erro 429 não é apenas uma limitação técnica. É um sinal de que o site reconheceu sua atividade como suspeita. Se continuar atacando do mesmo IP, você pode receber um banimento permanente.

Como os sites determinam atividades suspeitas

Para contornar bloqueios de forma eficaz, é necessário entender como os sites o identificam. Sistemas de proteção modernos analisam uma série de parâmetros:

1. Endereço IP e frequência de solicitações

O parâmetro mais óbvio. Se de um único IP chegam 100 solicitações por minuto, enquanto um usuário comum faz 5-10 — isso é uma automação clara. Os sites estabelecem limites:

• Wildberries: cerca de 60 solicitações por minuto de um único IP
• Ozon: cerca de 30-40 solicitações por minuto
• Avito: limites rígidos, especialmente para consultas de busca
• API do Instagram: 200 solicitações por hora por aplicativo

2. User-Agent e cabeçalhos do navegador

Se você envia solicitações através de um script sem o User-Agent correto, o site imediatamente entende que não é um navegador real. Os cabeçalhos também são analisados: Accept, Accept-Language, Referer. A ausência desses cabeçalhos ou valores atípicos — um sinal vermelho.

3. Padrões comportamentais

Um usuário real não faz solicitações com uma periodicidade perfeita a cada 2 segundos. Ele rola, clica, faz pausas. Se seu scraper funciona como um metrônomo — isso é suspeito.

4. Tipo de endereço IP

Muitas plataformas mantêm listas negras de IPs de data centers. Se você usa proxies baratos da AWS ou Google Cloud, a probabilidade de bloqueio é maior. IPs residenciais de provedores reais levantam menos suspeitas.

Rotação de proxies: a principal forma de contornar limites

A principal solução para o problema 429 é a rotação de endereços IP. Em vez de fazer todas as solicitações de um único IP, você distribui a carga entre vários endereços. Cada IP faz um pequeno número de solicitações e não excede os limites.

Tipos de rotação de proxies

Exemplo prático: scraping de Wildberries

Suponha que você precise fazer scraping de preços de 10.000 produtos. O Wildberries bloqueia após 60 solicitações por minuto de um único IP. Como resolver:

1. Use rotação por solicitação — cada solicitação vem de um novo IP. Você precisaria de cerca de 167 IPs diferentes (10.000 solicitações / 60 por minuto = 167 minutos com um IP, mas com rotação você faz isso em 10-15 minutos).
2. Configure delays — mesmo com rotação, não é recomendável fazer 1000 solicitações por segundo. O ideal: 5-10 solicitações por segundo com diferentes IPs.
3. Adicione aleatoriedade — os delays devem ser aleatórios: de 0,5 a 2 segundos entre solicitações.

Para essas tarefas, proxies residenciais com rotação automática são ideais — eles têm pools de milhões de IPs e mudam os endereços a cada solicitação sem sua intervenção.

Configuração de delays entre solicitações

Mesmo com rotação de proxies, não se deve bombardear o site com solicitações na velocidade máxima. Sistemas de proteção modernos analisam a carga total no servidor e podem bloquear todo o intervalo de IPs se detectarem atividade semelhante a DDoS.

Regras para configuração de delays

Delay exponencial (exponential backoff)

Se você ainda receber o erro 429, não continue atacando o site. Use a estratégia de delay exponencial:

• Primeira tentativa falha → espera 1 segundo
• Segunda tentativa falha → espera 2 segundos
• Terceira tentativa falha → espera 4 segundos
• Quarta tentativa falha → espera 8 segundos
• E assim por diante, até um máximo (por exemplo, 60 segundos)

Essa estratégia dá ao servidor tempo para "esfriar" e reduz a probabilidade de banimento permanente. Muitas APIs (Google, Twitter) recomendam essa abordagem em sua documentação.

Exemplo de configuração para diferentes tarefas

User-Agent e cabeçalhos: imitando um navegador real

A rotação de proxies e delays resolvem o problema da frequência de solicitações, mas isso não é suficiente. Os sites analisam como exatamente você envia as solicitações. Se os cabeçalhos parecerem suspeitos — o bloqueio é inevitável.

Cabeçalhos obrigatórios para imitar um navegador

O conjunto mínimo de cabeçalhos que deve estar em cada solicitação:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Cache-Control: max-age=0

Rotação de User-Agent

Não use o mesmo User-Agent para todas as solicitações. Crie uma lista de 10-20 versões atuais de navegadores e altere-as aleatoriamente:

• Chrome (Windows, macOS, Linux)
• Firefox (várias versões)
• Safari (macOS, iOS)
• Edge (Windows)

Referer e Origin

Muitos sites verificam de onde a solicitação veio. Se você está fazendo scraping de uma página de produto, o cabeçalho Referer deve conter um link para o catálogo ou busca. Se você está fazendo scraping de uma API — o Origin deve ser correto.

Exemplo para scraping de Wildberries:

Referer: https://www.wildberries.ru/catalog/0/search.aspx?search=ноутбук
Origin: https://www.wildberries.ru

Quais proxies escolher para contornar o 429

A escolha do tipo de proxy é criticamente importante. Proxies baratos de data centers frequentemente já estão em listas negras, e você receberá 429 mesmo com baixa frequência de solicitações.

Comparação de tipos de proxies para contornar limites

Recomendações para escolha

Para scraping de marketplaces (Wildberries, Ozon, Avito): Use proxies residenciais com rotação por solicitação. O pool deve ser grande — no mínimo 10.000 IPs. Isso garante que cada IP faça poucas solicitações e não caia sob os limites.

Para trabalhar com APIs de redes sociais: Proxies móveis são a melhor escolha. Instagram e TikTok confiam mais em IPs de operadoras móveis do que em residenciais. Um IP móvel pode atender 5-10 contas sem problemas.

Para monitoramento de preços de concorrentes: Proxies residenciais com rotação por timer (a cada 10-15 minutos). Isso permite fazer uma série de solicitações de um único IP, mantendo a sessão, mas sem exceder os limites.

Para tarefas simples (scraping de notícias, blogs): Proxies de data centers podem ser adequados se o site não tiver proteção séria. Mas esteja preparado para bloqueios periódicos.

Casos reais: scraping de marketplaces e APIs

Caso 1: Monitoramento de preços no Wildberries (10.000 produtos diariamente)

Tarefa: Um vendedor de marketplace monitora os preços de concorrentes em 10.000 itens. É necessário coletar dados 2 vezes ao dia.

Problema: Ao usar um único IP, recebia banimento após 50-60 solicitações. O scraping de 10.000 produtos levava várias horas com bloqueios constantes.

Solução:

1. Conectei proxies residenciais com um pool de 50.000 IPs e rotação por solicitação
2. Configurei delays aleatórios de 0,5 a 2 segundos entre solicitações
3. Adicionei rotação de User-Agent (20 variantes de Chrome e Firefox)
4. Configurei os cabeçalhos Referer e Accept corretamente

Resultado: O scraping de 10.000 produtos leva 15-20 minutos sem um único bloqueio. Cada IP faz no máximo 1-2 solicitações, o que é impossível de detectar como automação.

Caso 2: Automação do Instagram (50 contas de clientes)

Tarefa: Uma agência de SMM gerencia 50 contas de clientes no Instagram. É necessário publicar conteúdo, responder a comentários, coletar estatísticas.

Problema: A API do Instagram tem um limite de 200 solicitações por hora por aplicativo. Ao trabalhar com 50 contas, os limites eram atingidos em 10 minutos.

Solução:

1. Criamos 10 aplicativos diferentes da API do Instagram (5 contas por aplicativo)
2. Cada aplicativo usa um proxy móvel separado
3. Configurei um delay de 18 segundos entre solicitações (200 solicitações/hora = 1 solicitação a cada 18 seg)
4. Adicionei delay exponencial ao receber 429

Resultado: Todas as 50 contas funcionam de forma estável. Erros 429 ocorrem raramente (1-2 vezes por semana) e são tratados automaticamente através de tentativas repetidas.

Caso 3: Scraping de Avito (anúncios de todo o Brasil)

Tarefa: Um agregador de imóveis coleta anúncios do Avito de todas as cidades do Brasil para seu banco de dados.

Problema: O Avito tem uma das proteções mais rígidas entre os sites brasileiros. Os bloqueios começavam após 10-15 solicitações, mesmo de diferentes IPs de data centers.

Solução:

1. Transição para proxies residenciais com geolocalização (IPs da mesma cidade que o scraping)
2. Aumento dos delays para 3-5 segundos entre solicitações
3. Uso de um navegador headless (Puppeteer) em vez de simples solicitações HTTP
4. Emulação de ações do usuário: rolagem, cliques, movimentos do mouse

Resultado: Scraping bem-sucedido de mais de 50.000 anúncios por dia. Os bloqueios diminuíram em 95%. Os 5% restantes são tratados através de tentativas repetidas com um novo IP.

Caso 4: Monitoramento da API de concorrentes (e-commerce)

Tarefa: Uma loja online monitora a disponibilidade de produtos e preços de 20 concorrentes através de suas APIs.

Problema: A maioria das APIs dos concorrentes tem limites públicos (100-500 solicitações por hora). Ao exceder, retorna 429.

Solução:

1. Criar uma fila de solicitações com prioridades (os produtos mais importantes são verificados com mais frequência)
2. Monitorar limites através dos cabeçalhos de resposta (X-RateLimit-Remaining)
3. Pausa automática ao atingir 80% do limite
4. Usar várias chaves de API para cada concorrente (onde possível)

Resultado: O sistema distribui automaticamente as solicitações de forma a nunca exceder os limites. Os dados são atualizados com a máxima frequência possível sem bloqueios.

Conclusão

O erro 429 Too Many Requests é um mecanismo de proteção dos sites que pode ser contornado com a abordagem correta. Os principais princípios para resolver o problema:

• Rotação de endereços IP — distribua a carga entre vários proxies para que cada endereço faça o mínimo de solicitações
• Delays corretos — imite um usuário real com pausas aleatórias de 1 a 5 segundos
• Cabeçalhos corretos — use User-Agent atual e um conjunto completo de cabeçalhos de navegador
• Escolha do tipo de proxy — para sites complexos (marketplaces, redes sociais), use proxies residenciais ou móveis
• Tratamento de erros — aplique delay exponencial ao receber 429, não ataque o site novamente

Lembre-se: o objetivo não é enganar a proteção a qualquer custo, mas fazer com que sua automação pareça o mais natural possível. Sistemas de proteção modernos estão se tornando cada vez mais inteligentes, e a força bruta deixa de funcionar.

Se você planeja trabalhar com scraping de marketplaces, monitoramento de concorrentes ou automação em redes sociais, recomendamos experimentar proxies residenciais — eles oferecem um grande pool de endereços IP, rotação automática e risco mínimo de bloqueios. Para trabalhar com Instagram, TikTok e outras plataformas móveis, proxies móveis com IPs de operadoras reais são a melhor opção.