HTTP 429 Too Many Requests: Bedeutung und Behebung

Was dieser Fehler bedeutet und wie du ihn erkennst

• Ein Browser, API-Client, Monitoring-Tool oder Checker erhält 429 Too Many Requests.
• Die Antwort kann nur eine URL, API-Route, HTTP-Methode, IP-Adresse, ein Konto oder einen Client betreffen und nicht die gesamte Website.
• Nach einer Wartezeit funktionieren Anfragen möglicherweise wieder, was mit einem vorübergehenden Rate-Limit vereinbar ist.
• Die Antwort kann Retry-After oder andere Rate-Limit-bezogene Header enthalten.
• DNS kann aufgelöst werden und TLS kann erfolgreich sein, weil die Anfrage einen HTTP-fähigen Endpunkt erreicht hat. Diese Prüfungen beweisen jedoch nicht, dass die Anfrage auf Anwendungsebene zulässig ist.
• Verschiedene Clients oder Netzwerke können unterschiedliche Ergebnisse erhalten, wenn das Limit auf eine IP-Adresse, Identität, ein Token oder eine Sitzung beschränkt ist.

Hauptursachen nach Wahrscheinlichkeit

1. Ein Anfragelimit wurde überschritten. Die Anwendung, das API-Gateway oder der Webserver kann Anfragen nach IP-Adresse, Konto, Sitzung, API-Key, Route oder einer anderen Client-Identität begrenzen.
2. Ein Proxy, CDN oder WAF hat eine eigene Richtlinie angewendet. Ein Vermittler kann 429 zurückgeben, bevor die Anfrage den Origin-Server erreicht.
3. Automatisierter Datenverkehr sendet Anfragen zu schnell. Crawler, Monitoring-Prüfungen, Skripte, Wiederholungen oder parallele Worker können ein Limit auslösen, selbst wenn einzelne Anfragen gültig erscheinen.
4. Ein Client wiederholt Anfragen ohne Backoff. Wiederholte Anfragen nach Fehlern können dazu führen, dass der Client im Limit-Zeitfenster bleibt oder die Last erhöht.
5. Eine Konfiguration oder ein Deployment hat den effektiven Schwellenwert verändert. Eine neue Regel, Routing-Änderung, Authentifizierungsintegration oder Proxy-Richtlinie kann beeinflusst haben, welche Anfragen gezählt oder begrenzt werden.
6. Das Limit ist beabsichtigt, aber der Client-Workflow ist damit nicht kompatibel. Ein Batch-Prozess benötigt beispielsweise möglicherweise eine kontrollierte Taktung, die Wiederverwendung von Verbindungen oder ein genehmigtes Anfragekontingent statt wiederholter sofortiger Wiederholungen.

So behebst du den Fehler

Für Besucher und API-Nutzer

1. Stoppen Sie während der Untersuchung schnelle Aktualisierungen, parallele Anfragen und automatische Wiederholungen.
2. Prüfen Sie die Response-Header auf Retry-After. Wenn der Header vorhanden ist, warten Sie die angegebene Dauer oder den angegebenen Zeitpunkt ab, bevor Sie es erneut versuchen.
3. Wiederholen Sie nach der Wartezeit die Anfrage an genau dieselbe URL oder denselben API-Endpunkt mit derselben Methode. Wechseln Sie nicht die Methode und variieren Sie Anfragen nicht wiederholt, nur um das Limit zu umgehen.
4. Wenn Sie den Client kontrollieren, verwenden Sie begrenzte Wiederholungen mit exponentiellem Backoff und Jitter und beachten Sie das dokumentierte Anfragekontingent des Dienstes. Wiederholen Sie Anfragen, die nicht sicher erneut ausgeführt werden können, nur dann, wenn die API das entsprechende Verhalten definiert.
5. Prüfen Sie, ob das Problem nur einen Client, ein Konto, einen API-Key, ein Netzwerk oder einen Endpunkt betrifft. Ein anderes Ergebnis bei einem anderen Client identifiziert die Ursache nicht automatisch.
6. Wenn der 429-Fehler bestehen bleibt, wenden Sie sich mit Endpunkt, Methode, Zeitstempel, Response-Headern und einer Beschreibung der Anfragefrequenz an den Betreiber der Website oder API. Entfernen Sie Cookies, Autorisierungswerte und API-Secrets aus allen weitergegebenen Informationen.

Für Website-Betreiber und Entwickler

1. Reproduzieren Sie die Antwort mit dem kleinsten autorisierten Test, der hinsichtlich betroffener Methode, URL, Client-Identität und Anfragefrequenz übereinstimmt. Zeichnen Sie Status, Zeitstempel und relevante Response-Header auf.
2. Identifizieren Sie die erzeugende Schicht. Prüfen Sie die Antwortdetails von CDN oder WAF, Reverse-Proxy-Logs, Webserver-Logs und Anwendungs-Logs in der Reihenfolge, die Ihrer Architektur entspricht. Gehen Sie nicht davon aus, dass der Origin die Antwort erzeugt hat.
3. Durchsuchen Sie die relevanten Logs nach demselben Zeitstempel, derselben Route, Client-Kennung und Rate-Limit-Entscheidung. Stellen Sie fest, was gezählt wurde und welches Limit-Zeitfenster oder welche Richtlinie angewendet wurde.
4. Vergleichen Sie die betroffene Anfrage mit einer normalen Anfrage. Prüfen Sie HTTP-Methode, Authentifizierungskontext, Quellidentität, Route, Caching-Pfad sowie kürzliche Deployments oder Konfigurationsänderungen.
5. Wenn das Limit beabsichtigt ist, verbessern Sie die Hinweise für Clients: Geben Sie, sofern angebracht, einen korrekten Retry-After-Wert zurück, dokumentieren Sie Kontingente und stellen Sie sicher, dass Clients kontrolliertes Backoff statt enger Wiederholungsschleifen verwenden können.
6. Wenn das Limit fehlerhaft ist, nehmen Sie die kleinstmögliche autorisierte Korrektur an der Schicht vor, die die Antwort erzeugt hat. Prüfen Sie deren Auswirkung auf die betroffene Route, ohne andere Sicherheits- oder Missbrauchsschutzmaßnahmen zu schwächen.
7. Testen Sie dieselbe Anfrage mit derselben Frequenz erneut und prüfen Sie anschließend repräsentative benachbarte Routen und Client-Identitäten. Stellen Sie sicher, dass beabsichtigte Limits weiterhin funktionieren und die Antwort legitimen Datenverkehr nicht mehr blockiert.

Vorbeugung und Überprüfung der Lösung

• Definieren und dokumentieren Sie Anfragekontingente, Geltungsbereich der Limits und Wiederholungsverhalten für APIs und automatisierte Clients.
• Geben Sie nützliche Rate-Limit-Informationen zurück, einschließlich Retry-After, sofern dies angebracht und vom Servicedesign unterstützt wird.
• Implementieren Sie in Clients begrenztes exponentielles Backoff mit Jitter statt sofortiger wiederholter Anfragen.
• Überwachen Sie 429-Raten nach Route, Client-Identität, Netzwerk und Deployment, damit umfassende Anstiege von isoliertem Missbrauch oder fehlerhaft arbeitenden Clients unterschieden werden können.
• Halten Sie Rate-Limit-Einstellungen von CDN, WAF, Proxy, Server und Anwendung versionskontrolliert und prüfen Sie Änderungen vor der Veröffentlichung.
• Testen Sie wichtige API-Methoden und öffentliche Routen nach Deployments, einschließlich des erwarteten Verhaltens beim Erreichen eines Schwellenwerts.
• Bewahren Sie ausreichend bereinigte Anfrage- und Richtlinienentscheidungs-Logs auf, um eine 429-Antwort der Komponente zuordnen zu können, die sie erzeugt hat.

Häufig gestellte Fragen