Erro HTTP 429 Too Many Requests: o que é e como resolver

O que é o erro HTTP 429?

HTTP 429 Too Many Requests significa que o servidor está limitando a sua taxa de acesso: você, o seu endereço IP ou o seu app enviou mais requisições do que ele permite em um período de tempo. É temporário. O servidor está funcionando; ele só escolheu não responder a você por enquanto.

O código foi adicionado na RFC 6585 (2012) justamente para esse caso, e a resposta pode trazer um header Retry-After que diz quanto tempo esperar. Você vai se deparar com ele ao navegar em sites movimentados, chamar APIs, baixar arquivos em massa ou usar uma VPN cujo endereço IP é compartilhado por muita gente.

Ele é diferente dos códigos vizinhos: um 401 significa que você não fez login, um 403 significa que você não tem permissão, e um 429 significa que você tem permissão, mas está indo rápido demais.

Como o erro 429 aparece?

A mensagem depende de quem responde. Estas são as que as pessoas pesquisam:

Ao contrário de um erro 500, que significa que algo quebrou no servidor, o 429 é um erro de cliente nos termos do HTTP: o servidor está se protegendo de requisições demais.

Como funciona o rate limiting

Rate limiting é uma técnica que os servidores usam para controlar quantas requisições um cliente pode fazer em uma janela de tempo. Quando o limite é excedido, o servidor normalmente responde 429 (alguns respondem 403 ou 503).

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.

Muitas APIs informam seus limites nos headers de resposta. No GitHub, por exemplo, são x-ratelimit-limit (requisições permitidas por hora), x-ratelimit-remaining, x-ratelimit-used e x-ratelimit-reset (quando a janela é reiniciada, em segundos Unix). Um rascunho da IETF propõe headers padrão RateLimit e RateLimit-Policy para a mesma função.

Saber qual algoritmo e qual janela um serviço usa ajuda a projetar seu cliente para ficar dentro do limite.

Causas comuns do erro HTTP 429

A causa depende de quem está vendo o erro:

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. Um 429 é temporário: o servidor está pedindo que você desacelere, não está banindo você.

Quanto tempo depende do limite do site: alguns reiniciam em menos de um minuto, outros são por hora ou por dia. Se a página ou a API enviar um header Retry-After, esse é o tempo exato de espera. Depois, carregue a página uma vez.

Não fique atualizando: cada atualização é mais uma requisição e conta para o mesmo limite.

2. Limpe os cookies do site

Isso raramente faz diferença, mas alguns sites contam requisições por cookie de sessão. Limpe os cookies só desse site para ter uma sessão nova, sem sair de todo o resto:

• Chrome / Edge: abra chrome://settings/content/all (Edge: edge://settings/content/all), procure o site e apague os dados dele
• Firefox: clique no cadeado na barra de endereços → Limpar cookies e dados de sites do domínio…
• Safari: Safari → Ajustes → Privacidade → Gerenciar Dados de Sites → encontre o site → Remover

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

3. Desconecte a VPN ou proxy

Se você usa uma VPN ou proxy, pode estar compartilhando o endereço IP com centenas de outros usuários. Quando as requisições somadas deles excedem o limite do servidor, todo mundo naquele IP é limitado.

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

Se você precisa da VPN, troque para outra localização de servidor: o endereço dela pode ser compartilhado por menos gente.

4. Desative extensões do navegador

Algumas extensões fazem requisições em segundo plano aos sites que você visita: rastreadores de preço, ferramentas de SEO e extensões de atualização automática podem somar até atingir um limite. (Bloqueadores de anúncios costumam fazer o contrário e reduzir as requisições.)

Para testar, abra o site em uma janela anônima/privada, onde a maioria das extensões fica desativada. A janela anônima também começa sem cookies, então, se o 429 sumir, há uma extensão ou um limite baseado em sessão envolvido.

Desative as extensões uma a uma para encontrar a que causa o problema. No Chrome, acesse chrome://extensions/ e desligue-as individualmente.

5. Verifique se seu endereço IP é compartilhado

Muitas pessoas podem compartilhar um único endereço IP público: uma rede de escritório ou escola, a rede de uma operadora móvel (CGNAT) ou um servidor de VPN. As requisições delas contam para o mesmo limite que as suas.

Se você está em uma rede assim, carregar o site pela sua conexão de casa ou pelos dados móveis mostra se o problema é o endereço compartilhado. Se o limite está no seu próprio endereço, espere ele reiniciar em vez de trocar de rede para contorná-lo. Você pode ver o seu IP público atual com o Qual é meu IP.

Como resolver o erro 429 (para desenvolvedores)

Se o seu código recebe 429, ele está enviando requisições mais rápido do que a API permite. Trate nesta ordem: leia o Retry-After, tente de novo com backoff e jitter e, por fim, reduza o número de requisições.

1. Implemente backoff exponencial

O backoff exponencial é a estratégia padrão de nova tentativa: em vez de tentar de novo imediatamente depois de um 429, você dobra a espera a cada vez (1 segundo, 2, 4, 8…) e adiciona jitter, um atraso aleatório extra, para que muitos clientes não tentem de novo no mesmo instante.

Esta versão usa o Retry-After quando o servidor envia um valor válido, em qualquer um dos dois formatos, recorre ao backoff com jitter caso contrário e desiste depois de algumas tentativas. (Em um navegador chamando a API de outro site, o Retry-After só pode ser lido se a API o expuser com Access-Control-Expose-Headers.)

async function fetchWithBackoff(url, options = {}, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url, options);
    if (response.status !== 429 || attempt === maxRetries) return response;

    // Retry-After is either a number of seconds or an HTTP date
    const header = response.headers.get('Retry-After');
    let delay = NaN;
    if (header) {
      const seconds = Number(header);
      delay = Number.isNaN(seconds) ? Date.parse(header) - Date.now() : seconds * 1000;
    }
    if (!Number.isFinite(delay)) delay = 2 ** attempt * 1000 + Math.random() * 1000; // backoff + jitter
    await new Promise((resolve) => setTimeout(resolve, Math.max(delay, 0)));
  }
}

2. Respeite o header Retry-After

Quando um servidor envia Retry-After com um 429, ele diz exatamente quanto tempo esperar. A RFC 9110 permite duas formas: um número de segundos ou uma data HTTP.

Retry-After: 60 significa esperar 60 segundos. Retry-After: Wed, 21 Oct 2026 07:28:00 GMT significa esperar até aquele horário. Verifique-o antes da sua própria lógica de backoff: o servidor sabe melhor que o seu código.

Em Python, trate as duas formas e pare depois de algumas tentativas em vez de recursar para sempre:

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

import requests


def get_with_retry(url, max_retries=5):
    for attempt in range(max_retries + 1):
        response = requests.get(url)
        if response.status_code != 429 or attempt == max_retries:
            return response
        retry_after = response.headers.get("Retry-After", "")
        try:
            if retry_after.isdigit():
                wait = int(retry_after)
            else:  # an HTTP date
                wait = (parsedate_to_datetime(retry_after) - datetime.now(timezone.utc)).total_seconds()
        except (TypeError, ValueError):  # missing or unparseable: back off with jitter
            wait = 2 ** attempt + random.random()
        time.sleep(max(wait, 0))

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);
  if (!response.ok) throw new Error(`HTTP ${response.status}`); // never cache errors (a 429 included)
  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ê realmente precisa de mais chamadas de API, entre em contato com o provedor do serviço. Muitas APIs oferecem limites maiores para planos pagos ou aplicações verificadas.

Ao pedir limites maiores, explique o seu caso de uso e informe uma estimativa do volume de requisições esperado. Muitas APIs, como as do Google, têm um formulário ou um plano pago para limites maiores.

Algumas APIs também oferecem endpoints em lote que permitem buscar vários recursos em uma única requisição, reduzindo o 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 reais recebem 429, descubra qual camada responde primeiro: seu CDN ou WAF, seu servidor web ou seu app. Depois ajuste os limites dessa camada.

No nginx, quem faz o trabalho é o limit_req. Note que ele responde 503 por padrão: adicione limit_req_status 429; para que os clientes saibam que devem desacelerar em vez de achar que o servidor caiu:

# 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/ {
        # Up to 20 extra requests pass at once (nodelay); more than that get 429
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

O parâmetro burst deixa passar picos curtos sem 429; sem ele, até um carregamento de página normal, com muitas requisições, pode atingir o limite.

O Apache não tem um limitador de taxa de requisições embutido: o mod_ratelimit limita a largura de banda, não a contagem de requisições, e o módulo de terceiros mod_evasive responde 403. Use um proxy reverso, um WAF ou o seu app para obter 429. No Node.js, o express-rate-limit responde 429 por padrão.

2. Libere IPs confiáveis

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

No nginx, geo e map dão uma chave vazia aos endereços confiáveis, e o nginx não conta requisições com chave vazia. Isto substitui a linha limit_req_zone do exemplo anterior:

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;

Não limite os rastreadores dos mecanismos de busca por engano: o Google trata um 429 como erro de servidor e reduz o ritmo de rastreamento (Google Search Central). Verifique as requisições reais do Googlebot e do Bingbot com uma consulta de DNS Reverso confirmada por uma consulta direta desse nome, ou libere as faixas de IP publicadas pelos rastreadores.

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 dele podem responder antes de o seu servidor sequer ver a requisição.

A Cloudflare mostra aos visitantes "Error 1015: You are being rate limited" quando uma regra de rate limiting é acionada. Encontre a regra nas regras de segurança do painel, confira os eventos dela e aumente o limite ou reduza o escopo.

As regras baseadas em taxa do AWS WAF contam requisições por IP (ou outra chave) em uma janela de 1, 2, 5 ou 10 minutos, com limite mínimo de 10. Uma requisição bloqueada recebe 403 por padrão; defina uma resposta personalizada 429 para que os clientes saibam que devem desacelerar.

Veja as análises do CDN para separar visitantes reais de bots antes de mudar qualquer coisa.

4. Otimize o desempenho do servidor

Alguns serviços limitam com mais rigor quando estão sob carga, como válvula de segurança. Melhorar o desempenho do servidor permite aumentar os limites com segurança.

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

Use o nosso Verificador de headers HTTP para verificar se os 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 429 é deliberado e temporário: o servidor está escolhendo recusar você por enquanto. A maioria dos códigos 5xx significa que algo falhou no servidor, embora um 503 também possa ser uma manutenção planejada ou, no nginx, um rate limit.

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.