Rate limiting en couches dans Nginx — de limit_req_zone à Cloudflare et retour

Le rate limiting dans Nginx est l'une de ces choses qui existe dans chaque config et qui fonctionne dans peut-être la moitié d'entre elles. Le bloc limit_req par défaut enterré dans une config d'exemple ne survit pas à un vrai scrape, et certainement pas à une vraie attaque. Pire, des limites mal tunées bloqueront le crawler Google légitime la veille du jour où votre équipe réalisera pourquoi le ranking a chuté.

Nous empilons le rate limiting à trois points : à l'edge (Cloudflare ou équivalent), au perimeter (Nginx) et à l'application (par endpoint, par utilisateur). Voici la couche perimeter que nous livrons sur chaque install Nginx managée.

Limites par route avec une tolérance 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 est la cible du brute-force — 5 requêtes par minute est généreux pour les humains et brutal pour les bots de credential stuffing. /api est bien plus permissif mais reste borné.

L'article complet couvre :

• Edge → perimeter → origin : quelles attaques chaque couche attrape
• limit_req_status 429 et de bons headers Retry-After pour que les clients légitimes reculent
• Directives geo pour whitelister les crawlers connus bons
• La considération mémoire $binary_remote_addr vs $remote_addr (4 vs 24 octets par IP)
• Coordonner les changements de règles Cloudflare avec les changements de limites origin (ne pas se déclencher en même temps)
• Lire les lignes de log limit_req pour distinguer les vraies attaques de la mauvaise config

Contactez-nous si votre origin est actuellement scrapé et que vous ne savez pas comment lire les logs.