Der Client sendet Anfragen zu schnell.
Wann du ihn verwendest
Rate Limiting. Gib einen Retry-After-Header mit.
Häufige Ursachen und Lösungen
Du hast ein Rate Limit erreicht. Lies den Retry-After-Header, in Sekunden oder als HTTP-Datum, und alle RateLimit- oder X-RateLimit-Remaining-Header, und warte dann mit exponentiell wachsenden Abständen und Jitter, statt sofort erneut zu senden. Häufige Quellen: API-Kontingente pro Key oder IP, Rate-Limiting-Regeln von Cloudflare, Login-Drosselung und nginx limit_req, das 503 zurückgibt, sofern du nicht limit_req_status 429 setzt.
Viele Benutzer hinter einem NAT oder Firmen-Proxy können ein IP-Limit gemeinsam auslösen. Wenn dein Limiter hinter einem Load Balancer läuft, verwende als Schlüssel die echte Client-IP aus X-Forwarded-For, sonst teilen sich alle Benutzer die Adresse und das Kontingent des Load Balancers. Bündle auf Client-Seite Anfragen, cache Antworten und versieh geplante Jobs mit einer zufälligen Verzögerung, damit sie nicht alle in derselben Sekunde starten.
Client-Fehler (4xx)
4xx-Codes sind Client-Fehler: Die Anfrage selbst ist fehlerhaft, nicht autorisiert oder verweist auf etwas, das es nicht gibt. Dieselbe Anfrage erneut zu senden hilft nicht.
So sieht es aus
HTTP/1.1 429 Too Many RequestsSo sendest du ihn
| Node.js / Express | res.status(429).end() |
|---|---|
| Python / Flask | return '', 429 |
| nginx | return 429; |
So prüfst du ihn
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/