Gestaffeltes Rate Limiting in Nginx — von limit_req_zone bis Cloudflare und zurück

Rate Limiting in Nginx ist eines dieser Dinge, das in jeder Konfig existiert und in vielleicht der Hälfte funktioniert. Der Standard-limit_req-Block, der in einer Beispiel-Konfig vergraben ist, übersteht keinen echten Scrape, und schon gar keinen echten Angriff. Schlimmer noch, schlecht getunte Limits blockieren den legitimen Google-Crawler am Tag, bevor Ihrem Team auffällt, warum das Ranking abgestürzt ist.

Wir stapeln Rate Limiting an drei Punkten: am Edge (Cloudflare oder Äquivalent), am Perimeter (Nginx) und in der Anwendung (per Endpoint, per Benutzer). Dies ist die Perimeter-Schicht, die wir auf jeder gemanagten Nginx-Installation ausliefern.

Per-Route-Limits mit Burst-Toleranz

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 ist das Brute-Force-Ziel — 5 Anfragen pro Minute sind großzügig für Menschen und brutal für Credential-Stuffing-Bots. /api ist viel großzügiger, aber dennoch begrenzt.

Der vollständige Beitrag behandelt:

• Edge → Perimeter → Origin: welche Angriffe jede Schicht fängt
• limit_req_status 429 und ordentliche Retry-After-Header, damit legitime Clients zurückweichen
• geo-Direktiven, um bekannte gute Crawler auf die Allowlist zu setzen
• Die Speicher-Erwägung $binary_remote_addr vs $remote_addr (4 vs 24 Byte pro IP)
• Cloudflare-Regeländerungen mit Origin-Limit-Änderungen koordinieren (nicht beide auf einmal auslösen)
• Die limit_req-Log-Zeilen lesen, um echte Angriffe von Fehlkonfiguration zu unterscheiden

Melden Sie sich, wenn Ihr Origin gerade gescrapt wird und Sie nicht wissen, wie Sie die Logs lesen sollen.