---
title: "429 Too Many Requests: o que é o erro de rate limit"
description: "429 Too Many Requests indica que você enviou mais solicitações do que um serviço permite em pouco tempo. Veja como o rate limit funciona e como resolver o erro."
url: https://proxynet.io/pt-br/blog/http-429-too-many-requests
date: 2026-09-19
author: "Acar Diveroli"
category: "Tutoriais, Web scraping"
lang: pt-BR
---

# 429 Too Many Requests: o que é o erro de rate limit

Você está olhando ofertas de troca em uma plataforma de jogos, escrevendo uma pergunta atrás da outra em um chat de inteligência artificial ou abrindo a mesma página várias vezes para ver se surgiu uma vaga de agendamento de visto. De repente a página muda e resta uma única linha na tela: "429 Too Many Requests". Às vezes a mensagem vem em português ("Muitas tentativas, tente novamente mais tarde"), às vezes aparece dentro de um aplicativo como "Request failed with status code 429" e às vezes diz "rate limit exceeded". Todas dizem a mesma coisa: o serviço do outro lado contou as solicitações que chegam de você, e a contagem passou do limite.

Neste artigo explicamos o que são o código 429 e o conceito de rate limit (limite de taxa), em relação a que o limite é contado, por que ele aparece para quem "não fez nada" e quanto tempo é preciso esperar. A primeira metade é para quem vê o erro na tela; a segunda, para desenvolvedores que usam uma API e para equipes que coletam dados.

> **Nota: Resposta rápida**
>
> 429 Too Many Requests é o código de status HTTP que informa que você enviou mais solicitações do que um serviço permite em determinado período. O nome desse mecanismo é rate limit, ou limite de taxa. O bloqueio é temporário: o contador depende do tempo e se abre sozinho quando você espera. Recarregar a página não zera o contador, conta como uma nova solicitação. O limite pode ser mantido por endereço IP, por conta, por sessão ou por chave de API; por isso trocar de IP não muda nada na maioria dos casos. A reação correta é esperar e reduzir o ritmo das solicitações.

## O que significa 429 Too Many Requests?

Sempre que o seu navegador ou um aplicativo se conecta a um servidor, o servidor coloca no início da resposta um código de status de três dígitos. `200` significa "tudo certo", `404` significa "essa página não existe". `429` significa "entendi a sua solicitação, mas não vou processá-la agora, porque você enviou solicitações demais em pouco tempo". O código é definido na [seção 4 da RFC 6585](https://www.rfc-editor.org/rfc/rfc6585#section-4). A mesma seção deixa duas coisas a cargo do servidor: como o usuário é identificado e como as solicitações são contadas. Ou seja, a regra por trás de um 429 é diferente em cada serviço; o que há em comum é só a mensagem.

O mesmo erro assume formas diferentes conforme a interface do serviço:

| O que você vê na tela | Onde aparece | O que significa |
|---|---|---|
| `429 Too Many Requests` | No navegador, quase sempre em uma página branca simples | O servidor mostra o código como ele é |
| `HTTP Error 429`, `Request failed with status code 429` | Em aplicativos e ferramentas de desenvolvedor | O aplicativo repassa a você o 429 que recebeu do servidor |
| "Muitas tentativas, tente novamente mais tarde", "Muitas solicitações" | Em contas de redes sociais, e-mail e jogos com interface em português | O mesmo limite, traduzido para a linguagem do usuário |
| `Rate limit exceeded`, `You are being rate limited` | Em respostas de API, plataformas de chat e de jogos | O limite de taxa foi excedido |
| `Error 1015` | Em sites que usam a Cloudflare | A página com a marca da Cloudflare para um 429 |

A última linha tem um artigo próprio: explicamos cada linha dessa tela, o código Ray ID e o que o dono do site pode fazer em [O que é Error 1015? Como resolver You are being rate limited](/pt-br/blog/cloudflare-error-1015).

## O que é rate limit e por que ele existe?

Rate limit é o teto de solicitações que um serviço aceita de um mesmo usuário em determinado período. É uma regra como "60 solicitações por minuto", "5 tentativas de login por hora" ou "1.000 buscas por dia". "Rate limit exceeded" diz que esse teto foi ultrapassado, e "rate limited" diz que você está sendo limitado por isso. Em português se fala em limite de taxa ou limite de solicitações.

Os serviços colocam esse limite por quatro motivos:

- **Proteger a capacidade.** O número de solicitações que um servidor consegue processar é finito. Um único usuário ou um programa com defeito não deve consumir toda a capacidade.
- **Segurança das contas.** Nas páginas de login o limite é mantido baixo de propósito. Quem tenta adivinhar uma senha quer fazer milhares de tentativas; uma regra de "espere depois de cinco tentativas erradas" desacelera esse ataque até ele perder o sentido.
- **Divisão justa.** Planos gratuitos e pagos têm cotas diferentes; o limite define a parte de cada um.
- **Custo.** Cada solicitação tem um preço em tempo de processador, largura de banda e, às vezes, tarifas de terceiros.

## Em relação a que o limite é contado?

A primeira pergunta ao receber um 429 é esta: em nome de quem o contador é mantido? [A página da MDN sobre o 429](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429) lista os métodos possíveis: para o servidor inteiro, para um único recurso, por endereço IP, por usuário ou por aplicação. O método em uso decide o que ajuda e o que não ajuda.

| A que o contador está ligado | Exemplo típico | O que isso significa para você |
|---|---|---|
| Endereço IP | Sites acessados sem login, chamadas de API sem chave | Todos que saem pelo mesmo endereço dividem um contador |
| Conta | Redes sociais, plataforma de jogos, e-mail | O mesmo contador enche pelo celular e pelo computador; trocar de rede ou de IP não muda nada |
| Sessão ou cookie | Painéis web com login feito | Trocar de navegador abre uma sessão nova, mas o contador da conta pode ser mantido à parte |
| Chave de API | APIs oficiais, serviços de inteligência artificial | Todos os seus programas que usam a chave gastam de uma única cota |
| Endpoint | Funções específicas como busca, login, envio de mensagem | Só essa função retorna 429 enquanto o resto do site carrega |

A maioria dos serviços mantém vários desses contadores ao mesmo tempo. O GitHub é um bom exemplo porque escreve a sua regra abertamente: segundo [a documentação de limites da API REST](https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api), solicitações sem autenticação são limitadas a 60 por hora, e esse contador não está ligado ao usuário, e sim ao endereço IP de onde a solicitação vem. O limite de um usuário autenticado é de 5.000 solicitações por hora e está ligado à conta.

## Como o rate limit funciona?

Os detalhes mudam de um serviço para outro, mas o fluxo é o mesmo:

1. **O serviço escreve uma regra.** A regra tem três partes: quem é contado (IP, conta, chave), o período e o limiar.
2. **Cada solicitação que chega é anotada em um contador.** Antes de processá-la, o servidor verifica a qual contador ela pertence e aumenta esse contador em um.
3. **Ultrapassado o limiar, a solicitação é rejeitada sem ser processada.** Em vez de preparar a página, o servidor envia uma resposta 429 curta.
4. **O servidor pode dizer quanto tempo você precisa esperar.** Ele faz isso com um cabeçalho de resposta chamado `Retry-After`. O cabeçalho não é obrigatório e nem todo site o envia.
5. **O contador esvazia com o passar do tempo.** A janela se fecha ou uma nova ficha cai no balde, e o acesso se abre sozinho.
6. **A punição pode crescer para quem insiste.** Alguns serviços bloqueiam por mais tempo, e com um código mais duro, o cliente que segue no mesmo ritmo apesar do 429. A documentação do GitHub diz isso com todas as letras: continuar enviando solicitações enquanto você está limitado pode resultar no banimento da sua integração.

Uma observação sobre o segundo passo: abrir uma página não é uma única solicitação. O navegador pede imagens, scripts e consultas em segundo plano separadamente; um único clique pode enviar dezenas de solicitações ao servidor.

## Não fiz nada, por que recebi um 429?

Nas sugestões de busca, os nomes que mais aparecem ao lado desse erro são Steam, Roblox, ChatGPT, Outlook e sites de agendamento de visto. O que eles têm em comum: são lugares onde o usuário gera muitas solicitações sem perceber.

- **Páginas de mercado e de troca em plataformas de jogos.** Listas de preços, inventário e páginas de ofertas enviam muitas consultas em segundo plano a cada abertura. Uma extensão de navegador que acompanha preços pode encher o limite em minutos. Ferramentas de terceiros que você conectou à sua conta também enviam solicitações em seu nome.
- **Chats de inteligência artificial.** Cada mensagem é uma operação cara, por isso o limite vale tanto para o total de mensagens quanto para a frequência delas. Várias pessoas dividindo a mesma conta ou gerar a resposta de novo repetidas vezes é o caminho mais rápido até o limite.
- **Contas de e-mail.** Tentativas de login com senha errada, um celular esquecido que ainda tenta se conectar com a senha antiga ou um programa de e-mail enchem o contador no seu lugar.
- **Sites de agendamento e de ingressos.** Aqui quem gera as solicitações é o próprio usuário: uma página recarregada a cada poucos segundos para ver se abriu uma vaga.

Se nada disso se aplica a você, sobra o endereço IP compartilhado. Se o contador está ligado ao IP, todos que saem para a internet pelo mesmo endereço (todos os computadores de um escritório, assinantes de dados móveis atrás do mesmo endereço público) contam como uma só pessoa: outra pessoa enche o contador e quem vê o 429 é você. Explicamos o mecanismo, e como reconhecê-lo na sua própria conexão, em [O que é CGNAT, como saber se você tem e como sair](/pt-br/blog/what-is-cgnat). Em serviços gratuitos de VPN e proxy, um grupo muito maior usa o mesmo endereço de saída; os detalhes estão em [Proxies gratuitos e sites de web proxy são seguros?](/pt-br/blog/are-free-proxies-safe).

## Quanto tempo dura um erro 429? Por que recarregar não adianta?

Não há uma resposta única, porque quem define a duração não é o padrão, e sim o próprio serviço. Uma janela de segundos se abre em alguns segundos, uma cota por hora dentro de uma hora, uma cota diária no dia seguinte. Na resposta de exemplo da MDN aparece `Retry-After: 3600`, ou seja, uma hora.

Recarregar não adianta porque, para o servidor, F5 é uma nova solicitação: ou ela é rejeitada de imediato ou entra no contador e pode aumentar a espera. Em um serviço que usa janela deslizante (explicamos mais abaixo), o contador de quem insiste sem parar nunca esvazia.

Em vez de adivinhar a duração, você pode lê-la: abra as ferramentas de desenvolvedor com F12, recarregue a página uma vez com a aba Rede (Network) aberta e clique na linha do 429. Se `Retry-After` estiver entre os cabeçalhos de resposta, o número ao lado é o tempo de espera em segundos.

## O que fazer se você é visitante?

1. **Pare.** Feche a aba, saia do aplicativo e não tente nada por alguns minutos.
2. **Feche o que envia solicitações em seu nome.** Outras abas abertas do mesmo site, extensões de recarga automática e de acompanhamento de preços, um aplicativo de desktop rodando em segundo plano, ferramentas de terceiros conectadas à sua conta.
3. **Se o erro está na tela de login, pare de tentar senhas.** Cada tentativa errada pode aumentar a espera. Se não tiver certeza, espere e depois use o caminho "esqueci minha senha". Se algum dispositivo continua tentando a senha antiga, atualize-o.
4. **Tente uma vez.** Se abriu, o problema acabou. Se não abriu, aumente a espera: dez minutos, meia hora, algumas horas.
5. **Meça a parte que cabe à conexão.** Se houver VPN ou proxy gratuito ativo, desative e depois tente pelos dados móveis do celular. Se lá abre e na rede do escritório ou de casa não, o contador pertence ao endereço que você compartilha. Se o mesmo erro aparece nas duas conexões, o contador está ligado à sua conta e não há o que fazer além de esperar.
6. **Se o erro aparece todo dia no uso normal, escreva para o suporte do serviço.** Diga o que você estava fazendo e qual mensagem apareceu.

Limpar cookies, trocar de navegador ou reiniciar o roteador não estão nesta lista, porque o contador costuma estar ligado a algo que isso não muda: a sua conta ou o endereço compartilhado. O aviso parecido que aparece nas buscas do Google tem causas próprias; tratamos dele em [nosso artigo sobre o erro de tráfego incomum do Google](/pt-br/blog/google-unusual-traffic-error).

## Algoritmos de rate limit: janela fixa, janela deslizante e token bucket

Daqui em diante o artigo é para desenvolvedores. A regra "10 solicitações por minuto" se comporta de três maneiras diferentes conforme o modo como o contador é mantido.

| Algoritmo | Como conta | Ponto forte | Ponto fraco |
|---|---|---|---|
| Janela fixa (fixed window) | Conta em trechos fixos, como cada hora ou minuto cheio; ao fim do trecho o contador é zerado | Simples, basta um contador | Solicitações acumuladas dos dois lados da borda da janela podem passar em até o dobro do limite |
| Janela deslizante (sliding window) | Olha "os últimos 60 segundos"; considera a contagem do trecho anterior na proporção da parte que resta dele | Pega o acúmulo na borda e ainda pede pouca memória | É um cálculo aproximado |
| Token bucket (balde de fichas) | Fichas caem no balde em ritmo constante, cada solicitação gasta uma ficha e, se o balde está vazio, a solicitação é rejeitada | Permite rajadas curtas e mantém a média no longo prazo | Exige dois ajustes: capacidade do balde e ritmo de reposição |

A Cloudflare mostra o cálculo aproximado da janela deslizante com um exemplo [no artigo em que descreve o seu próprio limitador](https://blog.cloudflare.com/counting-things-a-lot-of-different-things/): o limite é de 50 solicitações por minuto, no minuto anterior chegaram 42 e, no segundo 15 do minuto atual, foram contadas 18. A estimativa é `42 × (45/60) + 18 = 49,5`, logo abaixo do limite. A Stripe resume o token bucket [no artigo em que descreve os seus próprios limitadores](https://stripe.com/blog/rate-limiters): cada usuário tem um balde, cada solicitação pega uma ficha e novas fichas vão pingando no balde aos poucos.

O jeito mais curto de ver a diferença é dar o mesmo tráfego aos três. O script Python abaixo não usa conexão de rede; ele só pergunta a três contadores sobre marcas de tempo.

```python
LIMIT = 10      # solicitações permitidas por janela
WINDOW = 60     # duração da janela (segundos)

class FixedWindow:
    def __init__(self):
        self.window_id, self.count = None, 0

    def allow(self, now):
        window_id = int(now // WINDOW)
        if window_id != self.window_id:          # janela nova: o contador é zerado
            self.window_id, self.count = window_id, 0
        if self.count >= LIMIT:
            return False
        self.count += 1
        return True

class SlidingWindow:
    def __init__(self):
        self.window_id, self.count, self.previous = None, 0, 0

    def allow(self, now):
        window_id = int(now // WINDOW)
        if window_id != self.window_id:
            # se a janela anterior passou vazia, nada é transportado
            self.previous = self.count if window_id - 1 == self.window_id else 0
            self.window_id, self.count = window_id, 0
        elapsed = now % WINDOW
        # a contagem da janela anterior pesa na proporção da parte que resta dela
        estimate = self.previous * (WINDOW - elapsed) / WINDOW + self.count
        if estimate >= LIMIT:
            return False
        self.count += 1
        return True

class TokenBucket:
    def __init__(self):
        self.tokens, self.updated = float(LIMIT), 0.0

    def allow(self, now):
        # fichas são adicionadas pelo tempo decorrido; o balde não passa da capacidade
        self.tokens = min(LIMIT, self.tokens + (now - self.updated) * LIMIT / WINDOW)
        self.updated = now
        if self.tokens < 1:
            return False
        self.tokens -= 1
        return True

def run(name, timestamps):
    print(name)
    for limiter in (FixedWindow(), SlidingWindow(), TokenBucket()):
        accepted = sum(limiter.allow(t) for t in timestamps)
        print(f"  {type(limiter).__name__:<14} {accepted}/{len(timestamps)} aceitas")

# Cenário 1: duas rajadas dos dois lados da borda da janela (segundos 59 e 61)
run("Rajada na borda", [59.0] * 10 + [61.0] * 10)
# Cenário 2: uma solicitação a cada 7,5 segundos durante dois minutos (8 por minuto)
run("Ritmo constante", [i * 7.5 for i in range(16)])
```

Saída:

```text
Rajada na borda
  FixedWindow    20/20 aceitas
  SlidingWindow  11/20 aceitas
  TokenBucket    10/20 aceitas
Ritmo constante
  FixedWindow    16/16 aceitas
  SlidingWindow  16/16 aceitas
  TokenBucket    16/16 aceitas
```

No primeiro cenário, a janela fixa deixou passar 20 solicitações em dois segundos apesar da regra de "10 por minuto", porque o contador foi zerado no segundo 60. A janela deslizante lembrou a carga do minuto anterior e aceitou uma única solicitação da segunda rajada (como o cálculo é aproximado, ela não parou exatamente em 10). O token bucket gastou as fichas na primeira rajada e rejeitou a segunda inteira. O segundo cenário traz a lição que importa para o cliente: tráfego abaixo do limite e que chega de forma regular não vê um 429 em nenhum algoritmo. O que bate no limite não é a média, é o acúmulo.

Há um exemplo que usa essa mesma lógica de token bucket do lado do cliente, para frear as suas próprias solicitações, em [Acesso seguro à web para LLMs: limites e permissões](/pt-br/blog/llm-safe-web-access).

## Se você usa uma API: como ler o limite nos cabeçalhos?

APIs bem documentadas fazem o limite deixar de ser surpresa: em cada resposta informam, nos cabeçalhos, quanto da sua cota ainda resta. O endpoint de cota do GitHub é adequado para testar isso, porque as chamadas a esse endpoint não são descontadas da sua cota principal:

```bash
curl -s -o /dev/null -D - https://api.github.com/rate_limit | grep -i -E "^HTTP|^x-ratelimit"
```

Em uma chamada sem autenticação, a resposta se parece com isto:

```text
HTTP/1.1 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 53
X-RateLimit-Used: 7
X-RateLimit-Resource: core
X-RateLimit-Reset: 1789799592
```

`Limit` dá o total disponível na janela, `Remaining` o que resta e `Reset` o momento em que o contador é zerado (tempo Unix, em segundos). O 60 daqui pertence ao seu endereço IP; um colega que executa o mesmo comando no mesmo escritório gasta do mesmo contador. Um programa que lê esses cabeçalhos consegue desacelerar sozinho ao se aproximar do limite.

Há três pontos de atenção:

- **Os nomes dos cabeçalhos não são padronizados.** `X-RateLimit-*` é um hábito difundido, mas `Reset` é tempo Unix em umas APIs e segundos restantes em outras. Para organizar isso, o IETF trabalha em [um rascunho](https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/) que define os cabeçalhos `RateLimit` e `RateLimit-Policy`; quando este artigo foi escrito, o texto ainda não era uma RFC.
- **O limite nem sempre chega como 429.** O GitHub escreve no mesmo documento que, ao exceder o limite, pode retornar `403` ou `429`. Olhe não só o código, mas também os cabeçalhos e a mensagem do corpo.
- **Limite de taxa e cota são coisas diferentes.** Um limite por minuto se abre com a espera; uma cota mensal ou um saldo esgotado se resolve no plano e no pagamento. Os dois podem chegar com o mesmo código, e quem diz a diferença é a mensagem do corpo.

Para o que vem depois de um 429, a regra é curta. Se houver `Retry-After`, siga-o; se não, aplique backoff exponencial (1, 2, 4, 8 segundos, somando a cada um uma parcela aleatória), coloque um teto no número de tentativas e aplique a espera a todas as suas solicitações para aquele serviço. Demos as duas formas de `Retry-After` e um exemplo em Python testado que aplica essas decisões em [Códigos de status HTTP no web scraping: 403, 407, 429, 503](/pt-br/blog/http-status-codes-web-scraping); não repetimos o mesmo código aqui. O efeito da concorrência na taxa de 429 está em [Concorrência e paralelismo no web scraping](/pt-br/blog/concurrency-vs-parallelism).

## Dá para superar um rate limit trocando de IP?

Na maioria dos casos, não. Se o contador está ligado à conta, à sessão ou à chave de API, o endereço IP nem entra na conta: a solicitação que chega de um endereço novo é anotada no contador da mesma conta.

Mesmo quando o contador está ligado ao IP, trocar de IP não resolve o problema, só o muda de lugar. O limite não se preocupa com a sua identidade, e sim com a carga que você coloca sobre o serviço. Dividir o mesmo ritmo entre outros endereços cansa o servidor na mesma medida; o serviço que percebe isso escreve a regra de acordo com o comportamento, e o bloqueio passa de um 429 para algo mais permanente. Escrever um endereço falso no cabeçalho `X-Forwarded-For` ou trocar o User-Agent a cada solicitação entra na mesma classe: um servidor bem configurado não confia no endereço que o cliente escreve, e cabeçalhos incoerentes são um sinal visível de tráfego automatizado. Como os sites leem esses sinais está em [nosso artigo sobre como funciona a detecção de bots](/pt-br/blog/how-bot-detection-works).

A rotação de IP tem um lugar legítimo, mas esse lugar não é "depois de receber um 429". Em um trabalho de coleta de dados autorizado e de grande volume, primeiro o ritmo total é reduzido a um nível que o site aguente e que seja compatível com o robots.txt e os termos de uso; depois esse tráfego é distribuído entre endereços. As formas práticas de respeitar o ritmo estão em [Como fazer web scraping sem ser bloqueado](/pt-br/blog/web-scraping-without-getting-blocked). Como a rotação funciona está em [nosso artigo sobre rotação de IP](/pt-br/blog/ip-rotation-explained), e o lado de produto, na nossa página de [proxies rotativos](/pt-br/rotating-proxy).

## Quem lida com limite de taxa por causa do trabalho?

- **Equipes que acompanham preços e estoque.** Um trabalho que lê milhares de páginas de produto por dia vê a taxa de 429 subir rápido se não ajusta o ritmo ao site: [solução de monitoramento de preços](/pt-br/price-monitoring).
- **Quem coleta dados de catálogo e de mercado.** Para cada site se mantém um orçamento de ritmo separado: [solução de extração de dados](/pt-br/data-scraping).
- **Quem se conecta a APIs que exigem uma lista de IPs autorizados.** A cota é anotada naquele endereço ou naquela chave: [nosso artigo sobre IP estático para acesso a APIs](/pt-br/blog/static-ip-for-api-access).
- **Quem monta automações.** Um fluxo que dispara centenas de chamadas no mesmo minuto bate no limite logo na primeira execução; os ajustes de espera estão em [Web scraping com n8n: HTTP Request e ajustes de proxy](/pt-br/blog/n8n-proxy).
- **Equipes de operações que trabalham em uma rede cheia.** Se dezenas de funcionários se conectam ao mesmo painel por um único endereço de escritório, um contador por IP enxerga o total da equipe. O que se busca aqui não é superar o limite, e sim ligar o contador apenas ao seu próprio uso: [Proxies ISP](https://proxynet.io/pt-br/static-isp-residential-proxy) fornece um endereço fixo, registrado em um provedor de internet e que não é compartilhado com ninguém.

## Erros comuns

- **Continuar recarregando na tela do 429.** Cada recarga é anotada no contador.
- **Continuar tentando senhas no limite de login.** A espera aumenta e, em alguns serviços, a conta é bloqueada temporariamente.
- **Supor que o limite está ligado ao IP.** Se o contador está ligado à conta ou à chave, trocar de rede é tempo perdido.
- **Tentar de novo sem esperar, do lado do desenvolvedor.** A resposta a uma nova tentativa imediata depois de um 429 é outro 429.
- **Usar a mesma chave de API em vários programas e procurar o limite em cada programa separadamente.** O contador pertence à chave; sem ver o total não há diagnóstico.

## Guia de decisão

| A sua situação | O que fazer |
|---|---|
| Você está vendo o erro pela primeira vez | Feche a aba, espere alguns minutos, tente uma vez |
| A tela de login mostra "muitas tentativas" | Pare de tentar senhas, espere e, se for preciso, redefina a senha; atualize os dispositivos com a senha antiga |
| Abre nos dados móveis, mas não na rede do escritório ou de casa | O endereço é compartilhado; se houver VPN ativa, desative e avise o administrador da rede |
| O mesmo erro em todas as redes e em todos os dispositivos | O contador está ligado à sua conta; remova as ferramentas de terceiros conectadas e espere |
| A tela mostra Error 1015 | É a página de limite de taxa da Cloudflare; siga os passos do [nosso artigo sobre o 1015](/pt-br/blog/cloudflare-error-1015) |
| O seu programa recebe 429 de uma API | Siga o `Retry-After`, leia os cabeçalhos de cota, reduza a concorrência |
| Você coleta dados autorizados e em grande volume | Primeiro reduza o ritmo total, depois distribua o tráfego entre endereços |

## Perguntas frequentes

### 429 Too Many Requests é um bloqueio permanente?

Não. Um 429 vem de um contador ligado ao tempo, e o acesso se abre sozinho quando o contador esvazia. Nada é feito com a sua conta.

### "Too many requests" significa vírus ou falha na internet?

Não. A mensagem vem do servidor do serviço ao qual você se conectou e diz respeito apenas ao número de solicitações. Se outros sites abrem normalmente, a sua internet está em ordem.

### Reiniciar o roteador resolve o erro 429?

Não é um método confiável. Quando o roteador se reconecta, o endereço IP muda em algumas assinaturas e em outras não; se o contador está ligado à conta, tanto faz. As condições em que o endereço IP muda estão em [nosso artigo sobre como trocar o endereço IP](/pt-br/blog/how-to-change-ip-address).

### Rate limit e banimento de IP são a mesma coisa?

Não. Rate limit é um contador ligado ao tempo: vale para todos e se abre com a espera. O banimento de IP é uma decisão de longa duração sobre um endereço específico e costuma aparecer como `403`. Um endereço que força o limite o tempo todo pode, com o tempo, passar para o segundo grupo.

### Quanto devo esperar se não houver cabeçalho Retry-After?

Se você é usuário, comece com alguns minutos e aumente a espera a cada tentativa sem sucesso. Se está escrevendo um programa, aplique backoff exponencial e coloque um teto no número de tentativas.

### Usar um proxy resolve o erro 429?

Se quem enche o limite é o seu próprio ritmo ou comportamento, não: o mesmo ritmo enche também o contador do endereço novo, e um contador ligado à conta nem vê o endereço. O caso em que um proxy faz diferença é quando quem enche o contador não é você, e sim as outras pessoas com quem você divide o endereço. Aí um endereço fixo que é só seu reduz o contador ao seu próprio uso.

## Em resumo

**429 Too Many Requests** é uma resposta temporária que informa que você bateu no limite de taxa (rate limit) de um serviço. O limite pode ser contado por endereço IP, conta, sessão, chave de API ou um único endpoint; é isso que decide o que ajuda. Para o usuário, a solução é parar, fechar o que envia solicitações em segundo plano e esperar. Para o desenvolvedor, é ler os cabeçalhos de cota, seguir o `Retry-After` e reduzir o ritmo. O limite não se supera rotacionando IPs; a rotação serve apenas para distribuir uma carga planejada desde o início e que respeita o site. Você encontra os tipos de endereço adequados ao seu trabalho em [nossos serviços de proxy](/pt-br/proxy).