429 Too Many Requests: Rate Limiting verstehen und umgehen

Was bedeutet der Statuscode 429?

Der HTTP-Statuscode 429 Too Many Requests teilt dem Client mit, dass er in einem bestimmten Zeitraum zu viele Anfragen gesendet hat. Der Server akzeptiert die Anfrage also nicht, weil der Client sein zugewiesenes Kontingent überschritten hat.

Der Code wurde in RFC 6585 definiert und hat sich als Standard für Rate Limiting etabliert. Vor seiner Einführung wurden oft 503 oder 403 für denselben Zweck verwendet, was zu Verwirrung führte.

Warum setzen Server Rate Limits ein?

Rate Limiting schützt Infrastruktur vor mehreren Arten von Missbrauch und Überlastung:

Schutz vor DDoS-Angriffen: Wenn jeder Client nur eine begrenzte Anzahl von Anfragen pro Zeiteinheit stellen kann, wird die Wirkung von verteilten Angriffen deutlich abgeschwächt.

Faire Ressourcenteilung: In Multi-Tenant-Umgebungen verhindert Rate Limiting, dass ein einzelner Nutzer die Kapazität monopolisiert und andere Nutzer beeinträchtigt.

Kostenkontrolle: Bei Cloud-Diensten und APIs mit nutzungsbasierter Abrechnung schützen Rate Limits vor unerwarteten Kosten durch Fehler in Client-Anwendungen.

Qualitätssicherung: Ein kontrollierter Durchsatz ermöglicht vorhersehbare Antwortzeiten für alle Nutzer.

Typische Szenarien, in denen 429 auftritt

Web-Scraping: Automatisierte Tools, die Webseiten schnell durchsuchen, treffen häufig auf Rate Limits. Viele Betreiber erlauben maschinellen Zugriff nur in begrenztem Umfang.

API-Integration: Entwickler, die mit externen APIs arbeiten, müssen die dokumentierten Limits kennen. Plötzliche 429-Antworten beim Testen oder bei Lastspitzen im Produktivbetrieb sind ein häufiges Problem.

Login-Schutz: Viele Websites begrenzen die Anzahl von Anmeldeversuchen pro IP-Adresse, um Brute-Force-Angriffe zu erschweren. Nach zu vielen Fehlversuchen kommt 429.

Monitoring-Tools: Wenn ein externes Monitoring-Tool zu häufige Checks durchführt, kann es selbst als Angreifer eingestuft werden und 429-Antworten erhalten. Das Tool auf dieser Seite verwendet angemessene Intervalle, um solche Probleme zu vermeiden.

Was steckt technisch dahinter?

Server implementieren Rate Limiting über verschiedene Algorithmen. Die gebräuchlichsten sind:

Token Bucket: Jeder Client erhält einen Eimer mit Tokens. Jede Anfrage verbraucht einen Token. Tokens werden in einem festen Intervall nachgefüllt. Überschreitet die Anfragerate die Nachfüllrate, leert sich der Eimer, und weitere Anfragen werden mit 429 beantwortet.

Sliding Window: Statt fester Zeitfenster (z. B. genau jede Minute) wird ein gleitendes Fenster betrachtet. Das verhindert Missbrauch durch das exakte Einhalten von Fensterrändern.

Fixed Window Counter: Einfachste Variante. Anfragen werden pro Zeitfenster (z. B. pro Stunde) gezählt. Nachteil: Am Übergang zweier Fenster können kurzzeitig doppelt so viele Anfragen durchkommen.

Den Retry-After-Header auswerten

Bei einem 429 sollte der Server einen Retry-After-Header mitsenden:

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1716192000

Der Retry-After-Wert gibt an, wie viele Sekunden der Client warten soll, bevor er es erneut versucht. Manche Server senden stattdessen einen Zeitstempel nach RFC 1123 (z. B. Retry-After: Fri, 23 May 2026 14:00:00 GMT).

Die X-RateLimit-Header sind nicht standardisiert, aber weit verbreitet. Sie zeigen das Gesamtlimit, verbleibende Anfragen und den Zeitpunkt des Resets.

Strategien für Client-Entwickler

Exponential Backoff: Nach einem 429 wartet der Client kurz, versucht es erneut, und verdoppelt die Wartezeit bei erneutem Fehler. Typische Implementierung: 1 Sekunde, 2 Sekunden, 4 Sekunden, 8 Sekunden. Ein Jitter (zufällige Verzögerung) verhindert, dass viele Clients gleichzeitig nach einem Ausfall wiederanlaufen.

Request Queuing: Anfragen werden in einer Queue gesammelt und kontrolliert abgearbeitet, anstatt gleichzeitig gesendet zu werden. Bibliotheken wie p-queue für Node.js vereinfachen das.

Caching: Antworten von APIs zwischenspeichern und für wiederholte Anfragen nutzen, anstatt die API jedes Mal neu anzufragen. Für unveränderliche Daten kann eine lange Cache-Dauer sinnvoll sein.

Rate-Limit-bewusstes Design: Vor dem Start einer Batch-Operation berechnen, wie viele Anfragen benötigt werden, und die Rate entsprechend drosseln.

Rate Limits auf der Server-Seite konfigurieren

Wer selbst Rate Limits einrichten möchte, hat mehrere Optionen:

Bei Nginx lässt sich Rate Limiting über das ngx_http_limit_req_module einrichten:

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

location /api/ \{
    limit_req zone=api burst=20 nodelay;
    limit_req_status 429;
\}

Dieses Beispiel erlaubt 10 Anfragen pro Sekunde mit einem Burst von 20. Anfragen darüber hinaus erhalten sofort 429.

Für API-Gateways wie Kong oder AWS API Gateway gibt es fertige Rate-Limiting-Plugins, die über das Dashboard konfigurierbar sind.

Unterschied zu verwandten Codes

503 Service Unavailable: Der Server ist generell nicht verfügbar, nicht wegen eines bestimmten Clients. 429 ist spezifisch für einen Client, der sein Limit überschritten hat.

403 Forbidden: Der Zugriff ist dauerhaft verweigert, nicht nur vorübergehend. Ein 403 legt nahe, dass der Client grundsätzlich keine Berechtigung hat, unabhängig von der Anfragerate.