Erro 429 Too Many Requests: Causas e Como Resolver

O Que É o Erro HTTP 429?

O erro HTTP 429 é um código de status de erro do cliente que significa Too Many Requests (muitas requisições). O servidor está informando que você enviou requisições demais em um determinado período e está temporariamente recusando processar mais até que você diminua o ritmo.

Esse erro é definido na RFC 6585 e faz parte do mecanismo de rate limiting (limitação de taxa) do HTTP. É um dos erros mais comuns encontrados por desenvolvedores que trabalham com APIs, mas usuários comuns também podem se deparar com ele ao navegar em sites.

O código de status 429 é diferente de outros erros 4xx. Um erro 403 significa que você não tem autorização. Um erro 401 significa que você não está autenticado. Já o erro 429 significa que suas credenciais estão corretas — você apenas está enviando requisições rápido demais.

Quando o servidor retorna uma resposta 429, ele pode incluir um header Retry-After que informa exatamente quanto tempo esperar antes de enviar a próxima requisição.

Como o Erro 429 Aparece?

O erro 429 aparece de formas diferentes dependendo do navegador, aplicação ou cliente de API que você está usando. Veja as variações mais comuns:

Diferente dos erros 500 que indicam um problema no servidor, o 429 é um erro do lado do cliente — o servidor está funcionando normalmente, mas está se protegendo contra excesso de requisições.

Como Funciona o Rate Limiting

Rate limiting é uma técnica que os servidores usam para controlar quantas requisições um cliente pode fazer dentro de uma janela de tempo específica. Quando o limite é excedido, o servidor responde com HTTP 429.

Existem vários algoritmos comuns de rate limiting:

• Janela Fixa (Fixed Window) — O servidor permite N requisições por janela de tempo (por exemplo, 100 requisições por minuto). O contador é zerado em intervalos fixos.

• Janela Deslizante (Sliding Window) — Similar à janela fixa, mas a janela de tempo desliza com cada requisição. Isso evita picos nas bordas da janela.

• Token Bucket — O servidor atribui tokens que são recarregados a uma taxa constante. Cada requisição consome um token. Quando os tokens acabam, as requisições são rejeitadas.

• Leaky Bucket — As requisições são processadas a uma taxa constante, independentemente do volume de pico. Requisições em excesso entram em fila ou são descartadas.

A maioria das APIs comunica seus limites de taxa através de headers na resposta. Os headers mais comuns incluem X-RateLimit-Limit (máximo de requisições permitidas), X-RateLimit-Remaining (requisições restantes na janela atual) e X-RateLimit-Reset (quando a janela é reiniciada).

Entender qual algoritmo um serviço usa ajuda você a projetar seu cliente para ficar dentro dos limites e evitar erros 429.

Causas Comuns do Erro HTTP 429

O erro 429 pode ser acionado por diversos cenários. Veja as causas mais comuns, agrupadas por quem normalmente as encontra:

Como Resolver o Erro 429 (Para Visitantes)

Se você está vendo o erro 429 ao navegar em um site, aqui estão as soluções que você pode tentar. Comece pela mais simples e vá avançando.

1. Espere e Tente Novamente

A solução mais simples é esperar. O erro 429 é temporário — o servidor está pedindo que você diminua o ritmo, não bloqueando você permanentemente.

Espere de 30 segundos a alguns minutos e tente novamente. A maioria dos limites de taxa é reiniciada entre 1 e 5 minutos. Se a página ainda mostrar o erro 429, espere mais — alguns serviços aplicam limites por hora ou por dia.

Não fique atualizando a página repetidamente. Cada atualização envia outra requisição e pode estender o período de bloqueio.

2. Limpe o Cache e os Cookies do Navegador

Às vezes, dados em cache ou cookies podem acionar o rate limiting. Limpá-los pode resolver o problema:

• Chrome: Pressione Ctrl+Shift+Delete (Windows) ou Cmd+Shift+Delete (Mac) → selecione "Cookies" e "Imagens em cache" → clique em "Limpar dados"

• Firefox: Pressione Ctrl+Shift+Delete → selecione "Cache" e "Cookies" → clique em "Limpar agora"

• Edge: Pressione Ctrl+Shift+Delete → marque "Cookies" e "Dados em cache" → clique em "Limpar agora"

• Safari: Vá em Safari → Configurações → Privacidade → Gerenciar Dados de Sites → Remover Todos

Após limpar, feche e reabra o navegador antes de acessar o site novamente.

3. Desconecte a VPN ou Proxy

Se você está usando VPN ou proxy, pode estar compartilhando um endereço IP com centenas de outros usuários. Quando as requisições combinadas deles excedem o limite do servidor, todos naquele IP são bloqueados.

Tente desconectar sua VPN e acessar o site pela sua conexão de internet normal. Se o erro 429 desaparecer, o IP da VPN era o problema.

Se você precisa da VPN, tente mudar para um servidor em outra localização para obter um novo endereço IP.

4. Desative Extensões do Navegador

Algumas extensões do navegador enviam requisições em segundo plano sem seu conhecimento. Bloqueadores de anúncios, ferramentas de comparação de preços, extensões de SEO e plugins de atualização automática podem gerar requisições extras que acionam o rate limiting.

Para testar, abra o site em uma janela anônima/privada (que desativa a maioria das extensões por padrão). Se o erro 429 desaparecer, uma das suas extensões é a culpada.

Desative as extensões uma por uma para encontrar a problemática. No Chrome, vá em chrome://extensions/ e desative-as individualmente.

5. Tente uma Rede Diferente

Se nada mais funcionar, o servidor pode estar limitando especificamente o seu endereço IP. Tente o seguinte:

Mude do Wi-Fi para os dados móveis (isso dá a você um IP diferente). Tente acessar o site a partir de outra rede. Se você está em uma rede corporativa ou escolar, tente de casa — redes grandes compartilham um único IP público.

Você pode verificar seu IP atual usando nossa ferramenta Qual é Meu IP para confirmar que ele mudou.

Como Resolver o Erro 429 (Para Desenvolvedores)

Se você está desenvolvendo uma aplicação que consome APIs, o erro 429 significa que seu código está enviando requisições rápido demais. Veja como lidar com isso corretamente.

1. Implemente Backoff Exponencial

Backoff exponencial é a estratégia padrão da indústria para retentativas. Em vez de tentar novamente imediatamente após um 429, você aumenta progressivamente o tempo de espera entre as retentativas:

Primeira retentativa: espere 1 segundo. Segunda retentativa: espere 2 segundos. Terceira retentativa: espere 4 segundos. Quarta retentativa: espere 8 segundos. E assim por diante.

Aqui está uma implementação básica em JavaScript:

async function fetchWithBackoff(url, options = {}, maxRetries = 5) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const response = await fetch(url, options);
    
    if (response.status !== 429) return response;
    
    // Check Retry-After header first
    const retryAfter = response.headers.get('Retry-After');
    const delay = retryAfter
      ? parseInt(retryAfter) * 1000
      : Math.pow(2, attempt) * 1000; // Exponential backoff
    
    console.log(`Rate limited. Retrying in ${delay / 1000}s...`);
    await new Promise(resolve => setTimeout(resolve, delay));
  }
  throw new Error('Max retries exceeded');
}

Adicione jitter (variação aleatória) ao delay para evitar que vários clientes façam retentativas exatamente ao mesmo tempo. Substitua o cálculo do delay por Math.pow(2, attempt) * 1000 + Math.random() * 1000.

2. Respeite o Header Retry-After

Quando o servidor retorna uma resposta 429, ele frequentemente inclui um header Retry-After que informa exatamente quanto tempo esperar. Esse header pode conter um número de segundos ou uma data HTTP:

Retry-After: 60 significa espere 60 segundos. Retry-After: Thu, 06 Mar 2026 12:00:00 GMT significa espere até aquele horário específico.

Sempre verifique esse header antes de aplicar sua própria lógica de backoff. O servidor sabe melhor que o seu código quanto tempo você deve esperar.

import requests
import time

def make_request(url):
    response = requests.get(url)
    
    if response.status_code == 429:
        retry_after = response.headers.get('Retry-After', '5')
        wait_time = int(retry_after)
        print(f"Rate limited. Waiting {wait_time} seconds...")
        time.sleep(wait_time)
        return make_request(url)  # Retry after waiting
    
    return response

3. Faça Cache das Respostas da API

Se sua aplicação faz a mesma chamada de API várias vezes, armazene a resposta em cache em vez de acessar a API toda vez. Isso reduz drasticamente a quantidade de requisições.

Use um cache em memória (como Redis ou um simples Map) para dados acessados frequentemente. Defina um TTL (time-to-live) razoável com base na frequência de atualização dos dados.

Por exemplo, se você está consultando registros DNS de um domínio, os resultados provavelmente não vão mudar nos próximos 5 minutos — faça cache deles.

const cache = new Map();
const CACHE_TTL = 5 * 60 * 1000; // 5 minutes

async function cachedFetch(url) {
  const cached = cache.get(url);
  if (cached && Date.now() - cached.time < CACHE_TTL) {
    return cached.data;
  }
  
  const response = await fetch(url);
  const data = await response.json();
  cache.set(url, { data, time: Date.now() });
  return data;
}

4. Use Webhooks em Vez de Polling

Se você está fazendo polling em uma API repetidamente para verificar mudanças (por exemplo, checando o status de um pedido a cada 10 segundos), mude para webhooks se o serviço oferecer suporte.

Com webhooks, o servidor envia atualizações para sua aplicação quando algo muda — sem necessidade de polling constante. Isso pode reduzir suas chamadas de API de milhares por hora para apenas algumas.

A maioria das APIs modernas (Stripe, GitHub, Twilio, Shopify) suporta webhooks. Consulte a documentação da API para configuração de webhooks.

5. Solicite Limites Maiores

Se você legitimamente precisa de mais chamadas de API, entre em contato com o provedor do serviço. Muitas APIs oferecem limites mais altos para planos pagos ou aplicações verificadas.

Ao solicitar limites maiores, explique seu caso de uso e forneça estimativas do volume esperado de requisições. Serviços como Google APIs, Twitter API e GitHub API possuem processos para solicitar limites elevados.

Algumas APIs também oferecem endpoints em lote que permitem buscar múltiplos recursos em uma única requisição, reduzindo a contagem total de chamadas.

Como Resolver o Erro 429 (Para Donos de Sites)

Se seus visitantes ou consumidores de API estão recebendo erros 429, o problema está na configuração do seu servidor. Veja como diagnosticar e resolver.

1. Ajuste Seus Rate Limits

Se usuários legítimos estão recebendo erros 429, seus limites de taxa podem estar restritivos demais. Revise e ajuste-os.

No Nginx, o módulo de rate limiting (ngx_http_limit_req_module) controla as taxas de requisição:

# Define rate limit zone: 10 requests per second per IP
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        # Allow bursts of 20, no delay for first 10
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

O parâmetro burst é fundamental — ele permite picos curtos de tráfego sem acionar o erro 429. Sem ele, até padrões normais de navegação podem atingir o limite.

No Apache, use mod_ratelimit ou mod_evasive. No Node.js, use pacotes como express-rate-limit.

2. Libere IPs Confiáveis

Se determinados clientes (serviços de monitoramento, processadores de pagamento, seus próprios microsserviços) estão sendo limitados, libere seus endereços IP no whitelist.

No Nginx, você pode usar um map para ignorar o rate limiting para IPs confiáveis:

geo $rate_limit {
    default        1;
    192.168.0.0/16 0;  # Internal network
    10.0.0.0/8     0;  # Internal network
    203.0.113.50   0;  # Payment processor
}

map $rate_limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}

limit_req_zone $limit_key zone=api:10m rate=10r/s;

Também libere os bots de mecanismos de busca (Googlebot, Bingbot) se eles estiverem sendo limitados — bloqueá-los prejudica seu SEO. Você pode verificar a identidade dos bots usando consultas de DNS reverso.

3. Verifique as Configurações do WAF e CDN

Se você usa Cloudflare, AWS WAF, Sucuri ou outro serviço de segurança, as regras de rate limiting deles podem ser a origem dos erros 429 — e não o seu servidor de origem.

No Cloudflare, verifique Security → WAF → Rate Limiting Rules. Você pode ver quais regras estão sendo acionadas e ajustar os limites. O modo "I'm Under Attack" do Cloudflare é particularmente agressivo.

No AWS WAF, verifique as regras do seu web ACL para regras baseadas em taxa. O limite mínimo é de 100 requisições por 5 minutos — certifique-se de que isso é adequado para o seu nível de tráfego.

Analise os dados de analytics do seu CDN para distinguir entre tráfego legítimo e tráfego de bots antes de ajustar os limites.

4. Otimize o Desempenho do Servidor

Às vezes, erros 429 aparecem porque o servidor não consegue lidar com a carga, e o rate limiting entra em ação como mecanismo de segurança. Melhorar o desempenho do servidor permite aumentar os limites de taxa com segurança.

As principais otimizações incluem: ativar o cache de respostas para reduzir a carga do backend, usar um CDN para assets estáticos, adicionar cache de consultas ao banco com Redis ou Memcached, implementar connection pooling para conexões com o banco de dados, e escalar horizontalmente com balanceamento de carga se o tráfego justificar.

Use nossa ferramenta HTTP Headers para verificar se seus headers de cache estão configurados corretamente.

429 vs Outros Erros HTTP

É fácil confundir o erro 429 com outros códigos de status HTTP. Veja como eles se diferenciam:

A distinção principal: o erro 429 é temporário e intencional. O servidor está saudável — ele está ativamente escolhendo rejeitar sua requisição para se proteger. Outros erros 5xx indicam que algo está realmente quebrado.

Como Prevenir Erros 429

Prevenir é melhor que remediar. Veja as melhores práticas para evitar erros 429 desde o início:

• Leia a documentação da API — Conheça os limites de taxa antes de escrever código. A maioria dos serviços publica seus limites de forma clara.

• Monitore seu uso — Acompanhe os headers X-RateLimit-Remaining para saber o quão perto você está do limite.

• Agrupe requisições — Use endpoints em lote quando disponíveis em vez de fazer chamadas individuais.

• Distribua as requisições — Espalhe as chamadas de API uniformemente ao longo do tempo em vez de enviar rajadas.

• Use chaves de API — Requisições autenticadas geralmente recebem limites de taxa mais altos do que as anônimas.

• Implemente circuit breakers — Se você receber erros 429 repetidos, pare de enviar requisições completamente por um período de espera.

• Teste com simuladores de rate limit — Simule respostas 429 no ambiente de desenvolvimento para garantir que seu tratamento de erros funcione.

• Registre respostas 429 — Monitore quando e onde o rate limiting ocorre para otimizar seus padrões de requisição.