Rate limiting en capas en Nginx — desde limit_req_zone hasta Cloudflare y de vuelta

El rate limiting en Nginx es una de esas cosas que existe en cada config y funciona en quizás la mitad. El bloque limit_req por defecto enterrado en una config de ejemplo no sobrevive a un scrape real, y desde luego no a un ataque real. Peor, límites mal ajustados bloquearán al crawler legítimo de Google el día antes de que tu equipo se dé cuenta de por qué cayó el ranking.

Apilamos rate limiting en tres puntos: en el edge (Cloudflare o equivalente), en el perímetro (Nginx) y en la aplicación (por endpoint, por usuario). Esta es la capa de perímetro que entregamos en cada instalación Nginx gestionada.

Límites por ruta con tolerancia 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 es el objetivo del brute-force — 5 peticiones por minuto es generoso para humanos y brutal para bots de credential stuffing. /api es mucho más permisivo pero sigue acotado.

El artículo completo cubre:

• Edge → perímetro → origin: qué ataques pilla cada capa
• limit_req_status 429 y cabeceras Retry-After adecuadas para que los clientes legítimos se echen atrás
• Directivas geo para whitelist de crawlers conocidos buenos
• La consideración de memoria $binary_remote_addr vs $remote_addr (4 vs 24 bytes por IP)
• Coordinar cambios de reglas en Cloudflare con cambios de límites en origin (no disparar ambos a la vez)
• Leer las líneas de log de limit_req para distinguir ataques reales de mala configuración

Háblanos si tu origin está siendo scrapeado ahora mismo y no sabes cómo leer los logs.