429 Too Many Requests

Verwendung

Der Statuscode 429 Too Many Requests zeigt an, dass die Anzahl der HTTP-Anfragen den zulässigen Schwellenwert überschritten hat. Das geschieht beispielsweise dann, wenn der Server die Anzahl der API-Aufrufe pro Stunde begrenzen möchte.

Die Spezifikation legt nicht fest, wie der Server HTTP-Anfragen zählt oder Nutzer identifiziert. Die Ratenbegrenzung erfolgt pro Ressource, pro Nutzer, über den gesamten Server hinweg oder über mehrere Server hinweg. Die Identifizierung der Nutzer geschieht über Anmeldedaten oder alternativ über Cookies.

Der Server fügt optional einen Retry-After-HTTP-Header hinzu, um dem Client mitzuteilen, wann Anfragen wieder angenommen werden.

Hinweis

Die Ratenbegrenzung (rate limiting) deckelt die Gesamtzahl der Anfragen in einem Zeitfenster (harte Abschaltgrenze), während die Drosselung (throttling) die Anfrageverarbeitung durch Einreihen in eine Warteschlange oder durch verzögerte Antworten verlangsamt. Die Wartedauer hängt vom Retry-After-Header ab. Ohne Retry-After reichen übliche Zeitfenster je nach API von 60 Sekunden bis zu 24 Stunden. VPN-Nutzer teilen sich IP-Adressen mit vielen anderen Nutzern, sodass Ratenbegrenzungen pro IP alle VPN-Nutzer auf demselben Server betreffen.

SEO-Auswirkung

Googlebot wertet 429 als Signal für einen Serverfehler. Wenn eine Website 429-Antworten zurückgibt, reduziert Google die Crawling-Rate für die gesamte Website vorübergehend. Sobald wieder normale Antworten erfolgen, erholt sich die Crawling-Rate allmählich. Anders als andere 4xx-Codes wirken sich 429-Antworten auf das Crawl-Budget aus. Dauerhafte 429-Antworten auf indexierten URLs führen zur Entfernung aus den Suchergebnissen. Um Googlebot zu bremsen, ist 429 der richtige Statuscode. 401 und 403 senken die Crawling-Rate nicht. Auch Bingbot reduziert seine Crawling-Rate bei 429-Antworten. Bing unterstützt zusätzlich crawl-delay in der robots.txt als Alternative zur statuscodebasierten Drosselung.

Beispiel

Der Client fordert eine Ressource an, und der Server antwortet mit 429 Too Many Requests.

Anfrage

GET /current-news HTTP/1.1
Host: example.com

Antwort

HTTP/1.1 429 Too Many Requests
Retry-After: 1800
Content-Type: text/html
Content-Length: 173

<html>
  <head>
    <title>Request Limit Exceeded</title>
  </head>
  <body>
   <p>The request limit has been reached.
   Try again in 30 minutes.</p>
  </body>
</html>

Behebung

Prüfen Sie den Retry-After-Header in der Antwort. Der Wert gibt entweder eine Anzahl von Sekunden oder ein HTTP-Datum an und bezeichnet den Zeitpunkt, ab dem der Server wieder Anfragen annimmt. Pausieren Sie alle Anfragen bis zum angegebenen Zeitpunkt.

Implementieren Sie zwischen den Wiederholungsversuchen einen exponentiellen Backoff mit Jitter. Verdoppeln Sie die Wartezeit nach jedem Fehlschlag (1s, 2s, 4s, 8s) und fügen Sie einen zufälligen Versatz hinzu, damit nicht mehrere Clients im selben Moment erneut anfragen und eine neue Lastspitze erzeugen.

Überwachen Sie die Rate-Limit-Header, bevor Sie an die Obergrenze stoßen. Viele APIs liefern die Header X-RateLimit-Limit, X-RateLimit-Remaining und X-RateLimit-Reset mit. Verfolgen Sie den verbleibenden Zählerstand und drosseln Sie Anfragen vorausschauend.

Standardisierte Rate-Limit-Felder

Über die de-facto etablierten X-RateLimit-*-Header hinaus standardisiert die IETF derzeit die Antwortfelder RateLimit und RateLimit-Policy für die Signalisierung von Kontingent und Zurücksetzung.

Reihen Sie ausgehende Anfragen auf der Client-Seite in eine Warteschlange ein. Eine Anfragewarteschlange mit kontrollierter Versandrate verhindert, dass Lastspitzen das Limit überschreiten. Bündeln Sie mehrere Operationen in einem einzigen API-Aufruf, sofern der Endpunkt Massenoperationen unterstützt.

Zwischenspeichern Sie Antworten für Daten, bei denen zwischen den Anfragen keine Änderung zu erwarten ist. Redundante identische Aufrufe sind die häufigste Ursache für unnötigen Verbrauch des Ratenkontingents.

Auf der Serverseite steuern in nginx die Direktiven limit_req_zone und limit_req die Ratenbegrenzung pro IP oder pro Endpunkt. Setzen Sie limit_req_status 429;, damit ratenbegrenzte Anfragen den korrekten Statuscode statt des voreingestellten 503 zurückgeben. Verwenden Sie die Parameter burst und nodelay, um kurze Lastspitzen zuzulassen, ohne Clients sofort abzuweisen.

Konfigurieren Sie bei AWS API Gateway die Drosselungseinstellungen auf Stage- oder Methodenebene. Erhöhen Sie die Raten- und Burst-Kapazität passend zu den erwarteten Verkehrsmustern, wenn die Standardschwellenwerte zu restriktiv sind.

Code-Referenzen

.NET

HttpStatusCode.TooManyRequests

Rust

http::StatusCode::TOO_MANY_REQUESTS

Rails

:too_many_requests

http.StatusTooManyRequests

Symfony

Response::HTTP_TOO_MANY_REQUESTS

Python3.5+

http.HTTPStatus.TOO_MANY_REQUESTS

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_TOO_MANY_REQUESTS

Angular

@angular/common/http/HttpStatusCode.TooManyRequests