HTTP 429 im Monitoring: wenn ein Anfragelimit die Prüfung blockiert
Der Monitor erhält Too Many Requests, während Besucher die Website öffnen können. So finden Sie die ablehnende Regel, prüfen gemeinsame Limits und bewerten die Auswirkungen.
Das Monitoring meldet einen Fehler, beim Öffnen der Website im Browser tritt er jedoch nicht auf. Die Prüfung erhält HTTP 429 Too Many Requests: Die Anfrage ist an einer Ratenbegrenzung gescheitert. Klären Sie, wo und für wen das Limit gilt, und prüfen Sie die Auswirkungen auf Benutzer gesondert. Diese Anleitung behandelt HTTP-Prüfungen; die Konfigurationsbeispiele verwenden NGINX und Cloudflare, das curl-Diagnosebeispiel setzt Linux voraus.
Ermitteln Sie zuerst die Schicht, die die Anfrage abgelehnt hat
Sichern Sie genaue URL, Methode, Zeitpunkt, Messort und Antwort der Prüfung. Für eine einzelne lesende URL können Sie curl -sS -D - -o /dev/null https://example.com/health verwenden. Domain und Pfad sind Beispiele; ersetzen Sie beide durch eigene Werte. Der Befehl zeigt Header und verwirft den Antwortkörper. Erfassen Sie Status und gegebenenfalls Retry-After. Bestätigen Sie den Bezug zu einer konkreten Regel anhand verfügbarer Logs.
Gehen Sie CDN, Reverse Proxy und Anwendung durch. Prüfen Sie bei Cloudflare die betreffende Rate-Limiting-Regel, ihren Ausdruck, Zählmerkmale und Zeitraum. Untersuchen Sie bei NGINX limit_req und limit_req_status; der voreingestellte Ablehnungsstatus dieses Moduls ist 503. Die Zahl 429 allein identifiziert daher kein bestimmtes Modul. Ordnen Sie ihr einen Ablehnungsnachweis in der richtigen Schicht zu, bevor Sie Monitoreinstellungen ändern.
Klären Sie, welche Prüfungen dasselbe Limit verbrauchen
Prüfen Sie den Schlüssel, nach dem die Regel Anfragen gruppiert. NGINX kann beispielsweise $binary_remote_addr verwenden, also die Clientadresse. Mehrere Monitore mit gemeinsamer ausgehender IP können dadurch dasselbe Limit verbrauchen. Erfassen Sie ihre Häufigkeit, parallele Läufe und zusätzliche Versuche innerhalb dieses Schlüssels. Die Betrachtung nur eines Monitors kann einen Teil des Verkehrs auslassen.
Prüfen Sie hinter einem Proxy, welche Adresse der Server tatsächlich verwendet. Bei NGINX hängt die Wiederherstellung der Clientadresse mit set_real_ip_from und real_ip_header zusammen: Ersatzadressen müssen von einem vertrauenswürdigen Proxy kommen. X-Forwarded-For allein bestätigt ohne Vertrauensprüfung keine tatsächliche Clientidentität. Vergleichen Sie das Ergebnis mit Logs und Konfiguration. Prüfen Sie ebenso ein Limit, das an ein Testkonto oder einen API-Schlüssel gebunden ist.
Beachten Sie die Wartezeit und passen Sie den Prüfplan an
Eine Antwort mit 429 kann Retry-After enthalten, der Header ist jedoch optional. Sein Wert kann ein HTTP-Datum oder eine Anzahl von Sekunden ab Empfang der Antwort sein. Prüfen Sie, wie der Monitor ihn interpretiert und ob der nächste Versuch tatsächlich wartet. Ein fehlender Header allein bestimmt kein geeignetes Intervall. Leiten Sie dieses aus der Regel und der benötigten Erkennungsgeschwindigkeit ab.
Verteilen Sie gleichzeitig startende Prüfungen und begrenzen Sie unnötige Wiederholungen. Berücksichtigen Sie auch die Sperrdauer; bei Cloudflare ist sie ein eigener Regelparameter. Eine erfolgreiche Anfrage nach einer Pause prüft noch nicht den gesamten üblichen Ablauf. Testen Sie die Änderung zuerst mit wenigen Prüfungen und anschließend mit der erwarteten Parallelität. Behalten Sie den Dienstschutz bei und richten Sie die Messung nach Zweck und Kapazität aus.
Bestätigen Sie das Ergebnis auch für normale Clients
Vergleichen Sie nach der Änderung Monitorergebnisse mit abgelehnten Anfragen und Antwortzeiten der Anwendung. Nutzen Sie auch eine unabhängige, angemessene Prüfung über den üblichen Besucherweg. Prüfen Sie, ob der Monitor weiterhin eine wichtige Funktion verfolgt statt nur einer einfacheren URL, die der Begrenzung entgeht. Definieren Sie bei einer eigenen lesenden Prüfung, was sie nachweist und welche Ausfälle sie nicht mehr abdeckt.
Erhalten auch berechtigte Benutzer 429, behandeln Sie deren Zugriff als tatsächliches Betriebsproblem. Ist nur der Messverkehr eingeschränkt, dokumentieren Sie diese Ursache und korrigieren Sie dessen Konfiguration. Sichern Sie in beiden Fällen Regel, betroffenen Schlüssel und Prüfergebnis. Beim nächsten Vorfall liegen dann Belege dafür vor, ob der Dienst oder seine Prüfung nicht verfügbar ist.
- Ordnen Sie die Antwort einer konkreten Schicht und Regel zu.
- Erfassen Sie Prüfungen und Versuche mit gemeinsamem Limit.
- Prüfen Sie Retry-After, Ablaufplan und Sperrdauer.
- Bestätigen Sie die Verfügbarkeit der überwachten Funktion auch für Besucher.
Was Sie mitnehmen
Bewerten Sie HTTP 429 im Zusammenhang mit einer konkreten Regel und einem Client. Ermitteln Sie den gemeinsamen Zählschlüssel, stimmen Sie die Messung auf das Limit ab und prüfen Sie das Ergebnis über den Benutzerweg. So unterscheiden Sie ein Prüfproblem von einer Begrenzung, die den Dienst tatsächlich beeinträchtigt.
