429 too many requests: soluções para web scraping e APIs de IA

Imagine um scraper coletando páginas públicas de produtos através de proxies do CyberYozh App, depois enviando o texto extraído para uma API de IA para análise. No meio do trabalho, ele para com "429 too many requests". A resposta tentadora é tentar novamente, mas primeiro você precisa descobrir onde a requisição falhou.

Foi o website, um serviço intermediário ou a API de IA que retornou o erro? Cada um pode impor limites diferentes, então alterar a configuração errada pode deixar o problema sem solução.

Durante a coleta, verifique o ritmo das requisições, conexões concorrentes e se o limite se aplica a um IP ou sessão. CyberYozh App permite que você controle as mudanças de IP do proxy e o comportamento da sessão nesta etapa. Durante o processamento de IA, verifique as permissões de requisição e token do provedor. Este guia percorre ambas as etapas para que você possa identificar a restrição, aplicar a correção certa e evitar repetir trabalho que já foi bem-sucedido.

TL;DR

• 429 too many requests significa que um serviço está impondo um limite de taxa ou uso. Isso não significa automaticamente que seu proxy está defeituoso ou permanentemente banido.

• Encontre a origem primeiro: o website de destino, um serviço intermediário ou a API de IA. Inspecione o corpo da resposta e os cabeçalhos.

• Desacelere e tente novamente com cuidado. Respeite o Retry-After, coordene os workers, reduza a concorrência e use backoff com jitter e uma contagem máxima de tentativas.

• Salve o trabalho concluído. Tente novamente a etapa de coleta ou análise que falhou sem reiniciar todo o fluxo de trabalho.

• Verifique os limites de requisição de IA, permissões de token e quotas separadamente. Mudar IPs não aumenta as permissões da conta.

• Combine a infraestrutura de proxy aos requisitos de coleta. CyberYozh App fornece geotargeting, sticky sessions de até 24 horas e tráfego ilimitado.

O que significa 429 too many requests?

Um erro 429 too many requests significa que um serviço está limitando requisições adicionais porque você atingiu um de seus limites de uso. Normalmente, isso envolve enviar muitas requisições dentro de uma janela de tempo específica. A resposta sozinha não informa qual limite foi atingido ou quanto tempo a restrição durará.

Para entender o que "429 too many requests" significa para seu fluxo de trabalho, verifique como o serviço conta a atividade. Como a documentação 429 do MDN explica, os limites podem se aplicar a um servidor, a um recurso específico ou de acordo com um endereço IP, usuário autenticado ou aplicação. Vários workers podem, portanto, compartilhar uma permissão mesmo quando cada um envia relativamente poucas requisições.

Um 429 não estabelece, por si só, um banimento permanente ou prova que seu proxy está defeituoso. A conexão pode estar funcionando enquanto o destino recusa requisições adicionais. Mudar IPs não redefinirá um limite vinculado à mesma conta autenticada.

Inspecione o corpo e os cabeçalhos da resposta para obter detalhes sobre a restrição, incluindo qualquer instrução Retry-After, antes de escolher sua próxima ação.

Descubra qual serviço está retornando o erro

Retorne ao exemplo da página de produto: a coleta falhou antes de o texto chegar à API de IA, ou a análise parou depois que as páginas foram salvas?

Em um navegador, abra as ferramentas de desenvolvedor, selecione o painel Network e inspecione a solicitação com status 429. No Postman, revise o status da resposta, os cabeçalhos e o corpo. Nos logs da aplicação, relacione a falha ao seu timestamp e à etapa do fluxo de trabalho.

Registre o hostname, o corpo da resposta, os cabeçalhos relevantes, o timestamp e o ID da solicitação quando disponível. Remova senhas, chaves de API, valores de autorização e cookies de sessão antes de compartilhar registros de diagnóstico.

Como corrigir o erro 429 too many requests

Depois de identificar o serviço que está retornando 429, deixe os detalhes da resposta guiarem a correção. Trabalhe nestas etapas antes de reiniciar o trabalho completo.

1. Pausar tentativas repetidas
   Pause o trabalho afetado e, em seguida, verifique workers em segundo plano, tarefas agendadas e execuções duplicadas. Se eles compartilham a mesma cota, coordene a pausa também; interromper um script pode deixar a maior parte do tráfego inalterada.

2. Respeitar o cabeçalho Retry-After
   Retry-After: 60 significa aguardar pelo menos 60 segundos. Uma data HTTP especifica quando tentar novamente. A documentação Retry-After da MDN explica ambos os formatos. Quando o cabeçalho está ausente, consulte os limites documentados do serviço e use atrasos de tentativa crescentes em vez de presumir um período de espera universal.

3. Reduzir a frequência de requisições e a concorrência
   Frequência significa requisições enviadas ao longo do tempo; concorrência significa requisições executadas simultaneamente. Controle ambas. Workers que compartilham uma cota precisam de ritmo coordenado, como uma fila compartilhada com um limitador de taxa, porque atrasos individuais não controlam o tráfego combinado.

4. Usar backoff exponencial com jitter
   Aumente os atrasos após falhas repetidas e adicione jitter, uma pequena variação aleatória que ajuda os workers a evitar tentar novamente juntos. Defina um número máximo de tentativas e verifique o comportamento de tentativa existente do cliente ou SDK antes de adicionar outro loop. Nunca reduza o tempo de espera solicitado pelo servidor.

5. Remover requisições desnecessárias
   Elimine URLs duplicadas na fila, armazene em cache respostas bem-sucedidas quando permitido e reduza a consulta quando dados atualizados não forem necessários. Salve as páginas concluídas para que uma requisição com falha não reinicie todo o trabalho de coleta.

Este exemplo GET em Python lida com ambos os formatos de cabeçalho, recorre ao backoff para valores ausentes ou malformados e para após cinco tentativas malsucedidas:

import random
import time
from datetime import timezone
from email.utils import parsedate_to_datetime

import requests


def get_with_backoff(url):
    for attempt in range(5):
        response = requests.get(url, timeout=30)
        if response.status_code != 429:
            response.raise_for_status()
            return response
        if attempt == 4:
            response.raise_for_status()

        value = response.headers.get("Retry-After", "").strip()
        delay = 2 ** attempt
        try:
            if value.isascii() and value.isdigit():
                delay = max(delay, int(value))
            elif value:
                retry_at = parsedate_to_datetime(value)
                if retry_at.tzinfo is None:
                    retry_at = retry_at.replace(tzinfo=timezone.utc)
                delay = max(delay, retry_at.timestamp() - time.time())
        except (ValueError, TypeError, OverflowError):
            pass  # Invalid header: keep the backoff delay.

        response.close()
        time.sleep(delay + random.uniform(0, 1))

Corrigir erros 429 recorrentes em web scraping

Erros 429 recorrentes exigem uma revisão do cronograma geral do trabalho de coleta. Conte as requisições em todos os workers direcionados ao mesmo site, especialmente quando eles compartilham um endereço IP, conta ou credencial de API. Coordene workers que compartilham um limite por meio de um limitador de taxa comum e aplique cooldowns em todo o grupo afetado quando ocorrer throttling.

A automação de navegador pode gerar mais tráfego do que seu script sugere. Abrir uma página de produto pode acionar requisições para imagens, scripts, recomendações e atualizações em segundo plano. Inspecione o painel Network do navegador para ver o que realmente chega ao destino. Ignore recursos desnecessários apenas quando isso preservar o comportamento da página e os dados de que você precisa.

Elimine URLs duplicadas na fila preservando diferenças intencionais, como vitrines regionais ou variantes de produtos. Salve respostas bem-sucedidas e registre quais itens foram concluídos. No exemplo da página de produto de abertura, se a coleta parar no meio do catálogo, retome a partir do item com falha após a espera necessária. As páginas já coletadas devem permanecer disponíveis para processamento de IA sem serem baixadas novamente.

Preserve a continuidade da sessão quando requisições relacionadas dependem dos mesmos cookies, conta ou endereço IP. Baseie a rotação de proxy nos requisitos de conexão da tarefa e no limite identificado; um 429 sozinho não é motivo para alterar endereços. Agende a coleta em torno das cotas documentadas do destino e reduza a consulta quando as informações do produto não precisarem de atualizações frequentes.

Corrigir erros 429 em APIs de IA e fluxos de trabalho de agentes

Seu scraper pode coletar todas as páginas de produtos com sucesso e, em seguida, encontrar um 429 quando envia os resultados para análise. Concluir um lote de coleta pode acionar uma explosão de chamadas de modelo, cada uma consumindo parte da cota de requisições ou tokens do provedor de IA.

Verifique qual cota você atingiu. A documentação de limite de taxa do Claude distingue requisições por minuto, tokens de entrada por minuto e tokens de saída por minuto. Tokens são as unidades que o modelo usa para processar texto. Algumas entradas grandes podem, portanto, atingir um limite de tokens mesmo quando o número de requisições parece modesto. Verifique os limites aplicáveis à sua conta e modelo.

Coloque os trabalhos de análise na fila e libere-os em um ritmo controlado. Se vários agentes compartilham uma cota de organização ou projeto, coordene o uso combinado. Reduzir entradas desnecessárias e solicitar saídas concisas também pode reduzir o consumo de tokens, enquanto o ritmo impede que lotes de scraping concluídos sobrecarreguem o estágio de processamento.

Uma entrada de log como last status: 429 too many requests registra o status HTTP final; o diagnóstico ainda depende da resposta subjacente. Inspecione o tipo de erro, mensagem, ID da requisição e cabeçalhos de limite do provedor e, em seguida, compare-os com informações de uso e faturamento. Um limite de taxa temporário e uma cota esgotada exigem ações diferentes. O Claude, por exemplo, documenta uma resposta de limite de gastos de nível mensal que continua falhando até que o acesso seja retomado.

Mantenha as páginas coletadas salvas independentemente do trabalho de análise. Quando uma requisição de IA falha, tente novamente apenas essa etapa de processamento após resolver a restrição. Verifique o comportamento de tentativa existente do SDK para que um fluxo de trabalho externo não reinicie repetidamente chamadas que o cliente já está tentando novamente.

Se a resposta entrar em conflito com o uso observado, verifique a página de status do serviço do provedor e investigue outras cargas de trabalho que compartilham a cota. Retenha o timestamp e o ID da requisição para suporte. Alterar o IP do proxy do scraper não aumentará os limites de requisições ou tokens da conta de IA.

Onde o CyberYozh App se encaixa no fluxo de trabalho de scraping

Uma vez que o diagnóstico identifica a necessidade de acesso regional, continuidade de sessão ou melhor controle sobre as conexões de coleta, o CyberYozh App oferece várias opções de infraestrutura. Combine a conexão com a tarefa, incluindo por quanto tempo as requisições relacionadas precisam manter o mesmo IP.

• Proxies móveis: Tráfego ilimitado em planos LTE/4G/5G reais mantém os custos de largura de banda previsíveis para coleta contínua. Planos dedicados reservam o canal móvel para sua carga de trabalho, enquanto planos compartilhados usam um canal junto com outros clientes. Conexões dedicadas oferecem mudanças de IP manuais e baseadas em API, permitindo agendar mudanças em torno dos limites de tarefas. 

• Proxies residenciais rotativos: Use segmentação regional para coletar listagens ou preços dependentes de localização. Escolha rotação para tarefas de coleta independentes ou sessões fixas de até 24 horas quando solicitações relacionadas precisarem de consistência temporária de IP. O tráfego é cobrado por uso, com tráfego não utilizado sendo transferido para o próximo mês de faturamento.

• Proxies ISP estáticos: Um endereço fixo durante o período de aluguel é adequado para sessões de coleta recorrentes que exigem o mesmo IP. Isso proporciona continuidade entre execuções separadas sem depender de uma sessão fixa temporária.

• Proxies de datacenter dedicados: Estes fornecem uma conexão fixa de datacenter para cargas de trabalho onde o destino aceita esse tipo de rede. Podem ser adequados para trabalhos de coleta rotineiros que não exigem uma conexão residencial ou móvel.

O CyberYozh App oferece suporte a conexões proxy no Scrapy, Postman, Playwright, Puppeteere Selenium. O acesso completo à API permite que scripts gerenciem operações de proxy suportadas junto com seu código de coleta existente.