HTTP 429 Too Many Requests: Ursache und Lösung

Nein, der Standardstatus ist 503. Setze limit_req_status 429;, wenn du den Standardcode willst.

Nein. Warte mindestens die Zeit aus Retry-After, falls vorhanden, und erhöhe die Wartezeit bei jeder Wiederholung, sonst bleibst du begrenzt.

daniele@mikweb: ~/errors — less http-429-too-many-requests.md

So sieht die Meldung aus

HTTP/2 429
retry-after: 30

203.0.113.5 - - [29/Oct/2026:10:22:41 +0000] "GET /api/items HTTP/2.0" 429 169 "-" "python-requests"

Ein Client oder Skript sendet zu schnell, ohne Back-off oder Wiederholung, und überschreitet ein Kontingent.
Ein Rate-Limit in nginx (limit_req mit limit_req_status 429), fail2ban, einer WAF oder dem CDN ist strenger als der echte Verkehr.
Viele Nutzer teilen sich eine IP (Büro, Mobilfunknetz, Proxy) und werden als ein Client gezählt, oder die echte Besucher-IP wird hinter einem Proxy nicht wiederhergestellt.
Bots, Crawler oder ein Schwachstellen-Scan überlasten die Seite.
Eine fremde API (die 429 kommt von einem Dritten) hat ihr Kontingent aufgebraucht.

Wer bekommt 429 im Access-Log (der Status ist im Standardformat Feld 9)?
awk '$9 == 429 {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head
Welche Limits sind konfiguriert?
nginx -T 2>/dev/null | grep -nE 'limit_req|limit_conn|limit_req_status'
Was sagt die Antwort zum Limit?
curl -sI https://example.com/ | grep -iE '^(HTTP|retry-after|x-ratelimit)'
Ist die Client-IP im Log die echte Besucher-IP?
nginx -T 2>/dev/null | grep -nE 'real_ip|set_real_ip_from'

Zuerst die Ebene identifizieren: das Access-Log (eigener Server), die Antwort-Header (CDN oder API) und der fail2ban-Status zeigen, wer antwortet.
Beim eigenen Limit anpassen: zum Beispiel limit_req zone=perip burst=20 nodelay; mit einer Rate, die zur normalen Nutzung passt.
Hinter einem Proxy die echte Client-IP wiederherstellen (real_ip_header, set_real_ip_from), damit Nutzer nicht zusammengezählt werden.
Bekannte gute Clients über geo und map oder eine Erlaubnisliste vom Limit ausnehmen und missbräuchliche Bots separat sperren.
Als Client: Retry-After beachten, exponentielles Back-off nutzen, Antworten cachen und Anfragen bündeln.

Nein, der Standardstatus ist 503. Setze limit_req_status 429;, wenn du den Standardcode willst.

Nein. Warte mindestens die Zeit aus Retry-After, falls vorhanden, und erhöhe die Wartezeit bei jeder Wiederholung, sonst bleibst du begrenzt.

daniele@mikweb: ~/tools — ls

daniele@mikweb: ~/errors — ls