HTTP 429 Too Many Requests: warten und dann richtig wiederholen
HTTP 429 Too Many Requests
HTTP 429 Too Many Requests: Retry-After und Backoff | We.Inc
Was der Status 429 bedeutet, wie du Retry-After liest, und Retry-Code mit Exponential Backoff und Jitter. Plane deinen eigenen Retry-Zeitplan mit dem Rechner.
Eine 429-Antwort bedeutet, dass der Server dich drosselt: Dieser Client hat in einem Zeitfenster mehr Requests gesendet, als erlaubt sind. Hör eine Weile auf zu senden. Enthält die Antwort einen Retry-After-Header, warte so lange; wenn nicht, wiederhole mit Exponential Backoff plus zufälligem Jitter, damit nicht viele Clients im Gleichschritt erneut anfragen.
Eine 429-Antwort lesen
Teil
Was es aussagt
Was dein Client tun sollte
Status 429
Zu viele Requests in einer bestimmten Zeitspanne
Diesen Client pausieren, nicht weiter bombardieren
Retry-After: 120
120 Sekunden warten (Verzögerung in Sekunden)
Mindestens so lange schlafen
Retry-After: Wed, 21 Oct 2026 07:28:00 GMT
Bis zu diesem Zeitpunkt warten (HTTP-Datumsformat)
Aktuelle Zeit abziehen, dann schlafen
Kein Retry-After
Der Server hat keinen Hinweis gegeben
Exponentiell mit Jitter zurückweichen
Caching
Ein 429 darf nicht von einem Cache gespeichert werden
Nie später einen gespeicherten 429 ausliefern
Lege die erste Verzögerung, die Obergrenze und die Anzahl erlaubter Wiederholungen fest und wähle dann eine Jitter-Variante. Der Rechner listet für jeden Versuch die Wartespanne und die Gesamtdauer im schlimmsten Fall auf, sodass du siehst, ob dein Client aufgibt, bevor das Zeitfenster des Servers zurückgesetzt wird.
Gib die Basisverzögerung in Millisekunden ein, also die Wartezeit vor der ersten Wiederholung.
Gib die Obergrenze ein, die längste Zeit, die eine einzelne Wartezeit dauern darf.
Wähle, wie viele Wiederholungen erlaubt sind, und eine Jitter-Variante.
Lies die Spannen pro Versuch und die Gesamtdauer ab und kopiere dann den passenden Code unten.
Halte dich an Retry-After statt an deinen eigenen Zeitplan, wann immer der Server es sendet. Er weiß, wann sein Zeitfenster zurückgesetzt wird, du nicht.
Wiederhole nur Requests, die sich gefahrlos wiederholen lassen. Ein wiederholter Zahlungs-POST ohne Idempotency Key kann doppelt abbuchen.
Begrenze die Anzahl der Wiederholungen ebenso wie die Verzögerung, und zeige einen klaren Fehler an, sobald sie aufgebraucht sind.
Wenn du den Server kontrollierst, gib 429 mit Retry-After zurück, statt Requests stillschweigend zu verwerfen oder zu verlangsamen, damit sich gut programmierte Clients anpassen können.
Häufige Fragen
Ist 429 ein Client- oder ein Serverfehler?
Er gehört zur 4xx-Klasse und beschreibt daher das Verhalten des Clients: zu viele Requests. Auf dem Server ist nichts kaputt. Die Lösung ist, weniger Requests zu senden oder sie zeitlich zu verteilen.
Was enthält Retry-After?
Entweder eine Anzahl Sekunden, die gewartet werden soll, etwa 120, oder ein HTTP-Datum, nach dem du es erneut versuchen darfst. Dein Client sollte beide Formen verarbeiten.
Warum Jitter zum Exponential Backoff hinzufügen?
Ohne Jitter wiederholt jeder Client, der im selben Moment gescheitert ist, auch wieder im selben Moment, was die Lastspitze neu erzeugt. Eine zufällige Wartezeit innerhalb jedes Fensters verteilt die Wiederholungen.
Warum gibt mein nginx-Rate-Limit 503 statt 429 zurück?
Das Modul limit_req lehnt mit 503 ab, sofern du es nicht änderst. Füge limit_req_status 429; neben deiner limit_req-Zeile hinzu, damit Clients den treffenderen Code sehen.
Kann ein CDN eine 429-Antwort cachen?
Es darf nicht. RFC 6585 legt fest, dass Antworten mit dem Statuscode 429 nicht von einem Cache gespeichert werden dürfen, sodass jeder Client eine frische Antwort bekommt, sobald das Limit aufgehoben ist.
Wer 429 sendet und warum
APIs, Login-Formulare und Such-Endpoints zählen Requests pro Nutzer, pro Schlüssel oder pro IP-Adresse und lehnen die überzähligen ab. Die Spezifikation überlässt das Zählen dem Server, daher begrenzt eine API pro Minute und eine andere pro Tag.
Die Antwort sollte das Limit in ihrem Body erklären und kann Retry-After ergänzen, um zu sagen, wie lange gewartet werden soll.
Die drei Backoff-Varianten im Rechner
Einfaches Exponential Backoff verdoppelt die Wartezeit jedes Mal bis zur Obergrenze: min(cap, base * 2^attempt). Full Jitter wählt eine zufällige Wartezeit zwischen null und diesem Wert. Equal Jitter behält die Hälfte davon und randomisiert die andere Hälfte, was eine gewisse Mindestpause garantiert.
Full Jitter verteilt die Last am besten, deshalb ist es ein sinnvoller Standard. Equal Jitter passt zu Clients, die nie sofort wiederholen dürfen.
Client-Code, der 429 respektiert
fetch mit Retry-After und Full Jitter
Liest beide Formen von Retry-After, fällt auf Full Jitter zurück und hört nach einer festen Anzahl Wiederholungen auf.
429 vom eigenen Server senden
nginx: pro IP begrenzen und mit 429 antworten
limit_req lehnt standardmäßig mit 503 ab; limit_req_status stellt auf 429 um.
Wie die Antwort aussieht
Ein kurzer Body, der das Limit erklärt, und ein Retry-After in Sekunden.
Rechner für den Retry-Zeitplan
Basisverzögerung (ms)
Obergrenze pro Wartezeit (ms)
Wiederholungen
Jitter-Variante
Full Jitter
Equal Jitter
Kein Jitter
Wartezeit vor jeder Wiederholung
Wiederholung
Kürzeste Wartezeit
Längste Wartezeit
Schlimmster Fall bis zum Aufgeben: {v}
Verwende ganze Zahlen über null, wobei die Obergrenze mindestens so groß wie die Basis sein muss.