Rate limiting em camadas no Nginx — do limit_req_zone ao Cloudflare e de volta

Rate limiting no Nginx é uma daquelas coisas que existe em toda config e funciona em talvez metade delas. O bloco limit_req padrão enterrado em uma config de exemplo não sobrevive a um scrape real, e definitivamente não a um ataque real. Pior, limites mal ajustados vão bloquear o crawler legítimo do Google no dia antes da sua equipe perceber por que o ranking caiu.

Empilhamos rate limiting em três pontos: no edge (Cloudflare ou equivalente), no perímetro (Nginx) e na aplicação (por endpoint, por usuário). Esta é a camada do perímetro que entregamos em cada instalação Nginx gerenciada.

Limites por rota com tolerância de burst

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
limit_req_zone $binary_remote_addr zone=api:10m rate=20r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;
 
server {
    location = /login {
        limit_req zone=login burst=3 nodelay;
        limit_conn conn 20;
        proxy_pass http://app;
    }
 
    location /api/ {
        limit_req zone=api burst=40 nodelay;
        proxy_pass http://app;
    }
}

/login é o alvo do brute-force — 5 requisições por minuto é generoso para humanos e brutal para bots de credential stuffing. /api é bem mais permissivo mas ainda limitado.

O artigo completo cobre:

• Edge → perímetro → origin: quais ataques cada camada pega
• limit_req_status 429 e headers Retry-After apropriados para que clientes legítimos recuem
• Diretivas geo para fazer allowlist de crawlers conhecidos como bons
• A consideração de memória $binary_remote_addr vs $remote_addr (4 vs 24 bytes por IP)
• Coordenar mudanças de regras no Cloudflare com mudanças de limite no origin (não disparar os dois ao mesmo tempo)
• Ler as linhas de log de limit_req para distinguir ataques reais de má configuração

Fale conosco se o seu origin está sendo scrapeado agora e você não sabe como ler os logs.