O que é rate limiting, como fixed window, sliding window, token bucket e leaky bucket se diferenciam, com um simulador ao vivo, o status 429, o Retry-After e um exemplo em Nginx.
Rate limiting limita quantas requisições um visitante, uma chave ou um endereço IP pode enviar em um período de tempo. As requisições acima do limite são recusadas, geralmente com o status HTTP 429 Too Many Requests e um cabeçalho Retry-After dizendo quando tentar de novo. Ele protege formulários de login, formulários de contato e APIs contra avalanches de tráfego e contas que disparam.
Os quatro algoritmos de rate limiting mais comuns
Se o seu site tem uma página de login, um formulário de contato, um checkout ou uma API que outros apps chamam, alguém vai acabar martelando isso, por acidente ou de propósito. Rate limiting é a regra que diz quanto é demais. Abaixo você pode apertar botões para enviar requisições e ver cada algoritmo aceitar ou recusar, e depois copiar uma configuração de Nginx que funciona.
A RFC 6585 define 429 Too Many Requests como o status para um cliente que enviou requisições demais em um determinado período. A resposta pode trazer um cabeçalho Retry-After dizendo ao cliente quanto tempo esperar.
Por padrão, o módulo limit_req responde às requisições recusadas com 503. Você pode trocar para 429 com a diretiva limit_req_status, que a maioria das APIs prefere porque diz a quem chamou exatamente o que aconteceu.
Ainda não. Os campos RateLimit e RateLimit-Policy vêm de um Internet-Draft de um grupo de trabalho da IETF que ainda estava em andamento em outubro de 2026, então alguns serviços enviam os cabeçalhos X-RateLimit mais antigos. Trate-os como dicas úteis.
Um token bucket deixa quem chama gastar tokens acumulados em uma rajada e depois se estabiliza no ritmo de recarga. Um leaky bucket suaviza o tráfego em uma vazão fixa. O Nginx documenta que o módulo limit_req usa o método leaky bucket.
Não. Ele lida bem com abuso vindo de poucas fontes, mas tráfego espalhado por milhares de endereços também precisa de proteção na sua hospedagem ou CDN. Rate limiting é uma camada, não a defesa inteira.
Isto permite a cada endereço IP 5 requisições por segundo no caminho de login, com uma rajada de 10 atendida de uma vez, e responde às requisições extras com 429 em vez do 503 padrão.
A zona de 10m guarda os contadores; a documentação diz que um megabyte comporta cerca de 16 mil estados de 64 bytes.
Para um único servidor, um token bucket cabe em poucas linhas. Guarde as contagens em um armazenamento compartilhado se rodar mais de um servidor.
Cada chave recebe 10 tokens que recarregam a 1 por segundo. Uma chamada recusada recebe 429 e um Retry-After em segundos inteiros.
Status 429 com um Retry-After de 30 segundos.
Cada algoritmo permite cerca de 5 requisições a cada 5 segundos (ou um balde de 5 que anda a 1 por segundo). Envie requisições, deixe o tempo passar e veja o que passa.
Algoritmo
Fixed window
Sliding window
Token bucket
Leaky bucket
Enviar 1 requisição
Enviar uma rajada de {n}
Esperar 1 segundo
Reiniciar
Tempo: {v} s
Permitidas: {n}
Recusadas com 429: {n}
Log de requisições
t={v}s permitida
t={v}s recusada (429)
Nenhuma requisição ainda. Aperte um botão acima.
Um modelo didático com passos de segundos inteiros. Limitadores reais medem em milissegundos.
Comece grátis · Sem cartão de crédito