Werkzeuge Anmelden 14 Tage testen
Illustration: Ein Drehkreuz auf einem weiten Platz: davor stauen sich viele graue Kugeln, dahinter rollen nur wenige mit Abstand weiter.
Software

HTTP Statuscode 429: Too Many Requests

· 11 Min. Lesezeit

Der HTTP-Statuscode 429 sagt: Der Aufrufer hat in einem bestimmten Zeitraum zu viele Anfragen gestellt. Es ist keine Aussage über die Adresse, nicht über die Methode und nicht über eine Berechtigung — sondern über ein Tempo, das jemand gezählt und für zu hoch befunden hat.

Der Code hat zwei Seiten. Entweder du rufst eine Schnittstelle auf und bekommst 429 zurück. Oder deine Website liefert ihn aus, und du merkst es erst, wenn die falschen Besucher ausgesperrt sind. Beides gehört in denselben Beitrag, weil ein Zwischenglied wie CDN oder Firewall in beiden Rollen stecken kann.

Die 4 am Anfang täuscht: Für Google ist 429 ein Serverfehler. Dazu unten mehr.

Was der Standard festlegt#

429 steht nicht in RFC 9110, dem Haupttext von HTTP, sondern in RFC 6585, einer Ergänzung um vier zusätzliche Statuscodes. Die Definition dort ist kurz, und drei Sätze daraus tragen alles Weitere.

Erstens: Die Antwort sollte erklären, was los ist, und darf eine Retry-After-Kopfzeile enthalten. Ein 429 ohne jede Angabe zur Wartezeit ist also standardkonform — nur nicht hilfreich.

Zweitens: Antworten mit 429 dürfen nicht von einem Cache gespeichert werden. Ein 429, den du nach der Wartezeit noch einmal siehst, kommt also frisch vom Server und nicht aus einem Puffer.

Drittens, und das ist der Satz, der beim Eingrenzen am meisten hilft: Der Standard legt nicht fest, wie der Server den Nutzer erkennt und wie er zählt. Als Beispiele nennt er die Zählung je Ressource, über den ganzen Server oder über eine Gruppe von Servern. Ob nach IP-Adresse, nach Schlüssel, nach Konto oder nach Sitzung gezählt wird, entscheidet allein der Betreiber. Deshalb hilft bei 429 kein allgemeines Rezept, sondern nur der Blick in die Dokumentation der Gegenseite oder in die eigene Konfiguration.

Illustration: Eine kleine Küchenuhr mit orangem Drehknopf steht vor einer geschlossenen Holztür auf einem Schiefertisch.

Retry-After: zwei Formate, eine Regel#

Die Kopfzeile ist in RFC 9110, Abschnitt 10.2.3 definiert und kennt zwei Schreibweisen:

Retry-After: 120
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT

Die erste Form ist eine nicht-negative ganze Zahl in Sekunden, gerechnet ab Empfang der Antwort. Die zweite ist ein HTTP-Datum, also ein absoluter Zeitpunkt. Ein Client, der die Kopfzeile auswertet, muss beide verarbeiten können — wer nur auf eine Zahl prüft, wartet bei der Datumsform gar nicht oder wirft einen Fehler.

Der RFC nennt für die Kopfzeile ausdrücklich zwei Anwendungsfälle: bei 503, um die erwartete Dauer der Nichtverfügbarkeit anzugeben, und bei 3xx-Weiterleitungen als Mindestwartezeit vor dem Folgeaufruf. Für 429 gilt über RFC 6585 dieselbe Kopfzeile mit derselben Bedeutung: so lange nicht wieder anklopfen.

Seite A: Du rufst eine API auf#

Der Fehler kommt vom Anbieter, und du kannst nur dein eigenes Verhalten ändern. Drei Regeln, in dieser Reihenfolge.

1. Steht ein Retry-After in der Antwort, ist er die Wartezeit. Nicht kürzer, nicht geschätzt. GitHub etwa schreibt in seiner Dokumentation zur REST-API, dass bei vorhandenem retry-after erst nach Ablauf dieser Sekunden erneut angefragt werden soll.

2. Fehlt die Kopfzeile, weiche exponentiell zurück — mit Zufallsanteil. Google beschreibt das Verfahren in der Dokumentation der Drive-API für genau diesen Fall: Bei einer Antwort mit 429 oder 403 wegen überschrittener Kontingente soll der Client nach einem exponentiellen Backoff erneut anfragen. Das Schema dort: nach dem ersten Fehlschlag 1 Sekunde plus eine zufällige Zahl Millisekunden warten, dann 2 Sekunden plus Zufall, dann 4, und so weiter bis zu einer Obergrenze. Als Formel:

Wartezeit = min((2^n) + zufall_ms, maximale_wartezeit)

Der Zufallsanteil ist laut Google eine Zahl von höchstens 1.000 Millisekunden, die Obergrenze liegt typischerweise bei 32 oder 64 Sekunden. Der Zufall ist keine Kosmetik: Ohne ihn treffen alle Clients, die gleichzeitig abgewiesen wurden, nach exakt derselben Pause wieder gleichzeitig ein — und lösen den nächsten 429 aus. Google Cloud Storage nennt in seiner Retry-Strategie dieselbe Kombination und listet 408, 429 und 5xx als die Antworten, bei denen ein Wiederholungsversuch sinnvoll ist.

3. Lies die Kopfzeilen des Anbieters, bevor die Grenze erreicht ist. Anbieter wie GitHub sagen im Antwortkopf jeder normalen Antwort, wie viel Kontingent noch übrig ist. GitHub nutzt dafür x-ratelimit-limit, x-ratelimit-remaining, x-ratelimit-used und x-ratelimit-reset, wobei der letzte Wert den Zeitpunkt des Zurücksetzens in UTC-Epochensekunden angibt. Die Namen sind bei jedem Anbieter anders, das Prinzip nicht: Wer remaining mitliest, drosselt sich selbst, bevor der Server es tut. Welche Grenzen konkret gelten, steht ausschließlich in der jeweiligen Dokumentation. Und der Code allein sagt nicht, welche Grenze du getroffen hast — GitHub antwortet beim Überschreiten des primären Limits wahlweise mit 403 oder 429; der Antworttext und die Kopfzeilen sagen es.

Seite B: Deine Website liefert 429#

Hier bist du der Zählende, und die Frage lautet: Wer hat die Zählung eingebaut, und wen trifft sie?

nginx. Das Modul ngx_http_limit_req_module begrenzt die Verarbeitungsrate je Schlüssel, typischerweise je IP-Adresse, nach dem Leaky-Bucket-Verfahren. Ein Minimalbeispiel aus der Doku:

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

    server {
        location /search/ {
            limit_req zone=one burst=5;
        }
    }
}

Überzählige Anfragen werden zunächst verzögert, bis die burst-Grenze überschritten ist; erst dann werden sie abgewiesen. Der Statuscode dafür ist per Voreinstellung 503, nicht 429 — die Direktive limit_req_status setzt ihn um. Eine nginx-Installation, die 429 liefert, hat also jemand bewusst so eingestellt. Das ist ein Hinweis darauf, wo du in der Konfiguration suchen musst.

Apache. Das mitgelieferte mod_ratelimit tut etwas anderes, als der Name vermuten lässt: Es begrenzt die Bandbreite je Verbindung in KiB/s, während die Antwort übertragen wird, und zählt nicht Anfragen je Zeit. Wer bei Apache einen 429 sucht, sucht in diesem Modul am falschen Ort. Der Code kommt dort aus der Anwendung, aus einem Zusatzmodul oder aus einem vorgeschalteten Proxy.

WAF und CDN. Cloudflare lässt in seinen Rate-Limiting-Regeln einen Schwellwert aus Anfragen je Zeitraum definieren und blockt danach für eine einstellbare Dauer weiter. Der Statuscode der Sperre ist per Voreinstellung 429, konfigurierbar sind Werte von 400 bis 499. Cloudflare beantwortet die Anfrage dann selbst, mit dem Code aus der Regel. Ein 429, den dein eigener Server nie protokolliert hat, hat deshalb einen naheliegenden Absender.

Illustration: Ein zugefallenes Gartentor in einer Steinmauer; davor lehnt ein voller Postsack mit orangem Riemen.

Der versehentliche Treffer. Alle drei Varianten können je Quelladresse zählen; das Beispiel in der nginx-Doku tut genau das. Ein Bot, der viele Seiten schnell hintereinander abruft, fällt damit in dasselbe Raster wie ein Angreifer — und genau das tut ein Suchmaschinen-Crawler, der gerade eine große Sitemap abarbeitet. Google berechnet sein Crawl-Limit laut Doku zum Crawling-Budget aus der Zahl paralleler Verbindungen und deren Dauer und hebt es an, wenn der Server stabil und schnell antwortet. Eine Regel wie „eine Anfrage je Sekunde je IP" kann ihn deshalb treffen wie jeden anderen schnellen Abrufer.

Ob das passiert, steht im Server-Protokoll: nach Statuscode 429 filtern und die Quelladressen ansehen. Ist ein Großteil davon der Bot, den du eigentlich haben willst, ist die Regel falsch geschnitten. Wie du an die Zahlen kommst und was sie bedeuten, steht in Wie oft crawlt Google meine Seite?

Was Google aus einem 429 macht#

Hier wird es für Website-Betreiber ernst, und die Quelle ist eindeutig. Googles Dokumentation zu HTTP-Statuscodes hält fest, dass die Crawler 429 als Signal für einen überlasteten Server werten und den Code als Serverfehler behandeln. Die Konsequenzen sind dieselben wie bei 5xx:

  • Google verlangsamt das Crawling vorübergehend. Die Drosselung ist laut Doku proportional zur Zahl der einzelnen Adressen, die mit einem Serverfehler antworten.
  • Inhalte, die mit einem Serverfehler zurückkommen, werden ignoriert. Der Text, den deine 429-Seite anzeigt, wird nicht als Inhalt der Adresse gewertet.
  • Bereits indexierte Adressen bleiben zunächst im Index, werden aber bei anhaltendem Fehler entfernt.

Google bestätigt das an zweiter Stelle in der Doku zum Crawling-Budget: Antwortet die Website mit Serverfehlern oder mit Drosselungssignalen wie HTTP 429, sinkt das Crawl-Limit, und Google crawlt weniger.

Google beschreibt dieselbe Wirkung auch als Werkzeug. Wer das Crawling kurzfristig bremsen muss, soll laut Anleitung zum Reduzieren der Crawling-Frequenz auf Crawl-Anfragen mit 500, 503 oder 429 statt mit 200 antworten. Die reduzierte Frequenz gilt für den ganzen Hostnamen und steigt von selbst wieder, sobald die Fehler nachlassen. Google rät aber ausdrücklich davon ab, das länger als ein bis zwei Tage zu tun — und warnt, dass eine Adresse, die über mehrere Tage diese Codes liefert, aus dem Index fallen kann.

Ein 429 an Googlebot ist also eine Notbremse, keine Dauerkonfiguration. Eine Rate-Limiting-Regel, die den Crawler täglich ein paar hundert Mal trifft, ist keine Sicherheitsmaßnahme mehr, sondern ein schleichender Indexverlust. In der Crawling-Statistik der Search Console taucht das nicht unter einer eigenen Zeile auf: Der Bericht führt laut Google-Hilfe 200, 301, 302, 304, 404, 401/407 und „Serverfehler (5xx)" einzeln und sammelt den Rest unter „Sonstiger Clientfehler (4xx)". Eine 429-Welle versteckt sich dort. Was Google bei einer einzelnen Adresse tatsächlich bekommen hat, zeigt die URL-Prüfung.

Abgrenzung zu 503#

Beide Codes sagen „gerade nicht", beide dürfen Retry-After tragen, und Google behandelt beide gleich. Der Unterschied liegt in der Begründung.

503 Service Unavailable bezieht sich nach RFC 9110 auf den Server: eine vorübergehende Überlastung oder geplante Wartung, die sich nach einiger Zeit voraussichtlich erledigt. Der Server kann nicht — egal, wer fragt.

429 Too Many Requests bezieht sich auf den Aufrufer: Dieser eine hat zu viel angefragt. Der Server könnte, will aber nicht für diesen Absender.

In der Praxis verwischt das, weil nginx überzählige Anfragen per Voreinstellung mit 503 abweist und Cloudflare mit 429. Derselbe Vorgang, zwei Codes, je nachdem, welches Glied der Kette zählt. Der Code allein verrät also nicht, ob dein Server überlastet ist oder ob eine Zählregel greift; die Server-Kopfzeile und die Frage, ob die Anfrage überhaupt im eigenen Protokoll auftaucht, verraten es.

RFC 9110 merkt zu 503 noch an, dass ein überlasteter Server ihn nicht verwenden muss — er darf die Verbindung auch einfach ablehnen. Dann siehst du keinen Statuscode, sondern einen Abbruch, und die Diagnose läuft wie bei einem 502.

Was nicht hilft#

Sofort wiederholen. Ein 429 ohne Wartezeit zu beantworten, ist der sicherste Weg zum nächsten: Die Wiederholung zählt in dasselbe Zeitfenster, das schon voll war.

Die IP wechseln. Der Standard legt nicht fest, wonach gezählt wird. Wer nach Schlüssel oder Konto zählt, zählt weiter, egal von wo die Anfrage kommt. Und wer nach IP zählt, wertet den Wechsel als das, was er ist.

Den Statuscode ändern, statt die Regel. Ein 429 in 200 mit Fehlermeldung im Text umzuschreiben, damit der Bot „nichts merkt", ist der schlechteste Ausweg: Google reicht laut seiner Doku alles, was mit 200 ankommt, an die Indexierung weiter, und eine Fehlermeldung mit 200 endet als „Soft 404" in der Search Console. Ein 429 in 503 umzuschreiben ändert für Google gar nichts — beide sind Serverfehler.

Die Grenze pauschal erhöhen. Wenn eine Regel Googlebot trifft, hilft eine höhere Zahl wenig, solange der Schlüssel zu grob ist. Eine Regel, die nur den Anmeldepfad oder den Suchendpunkt zählt, schützt das, was Schutz braucht, und lässt den Rest der Seite crawlbar.

Eine Ausnahme nach User-Agent eintragen. Der User-Agent ist frei wählbar, und jede Ausnahme für „Googlebot" gilt auch für jeden, der sich so nennt. Wer Crawler ausnehmen will, prüft die Herkunft, nicht die Selbstauskunft — Google beschreibt dafür in der Anleitung zur Googlebot-Verifizierung zwei Wege: eine Reverse-DNS-Abfrage der IP-Adresse oder den Abgleich mit den veröffentlichten IP-Bereichen.

Der ehrliche Schluss#

Als Aufrufer gilt: Retry-After lesen, sonst exponentiell mit Zufall zurückweichen, Kontingent-Kopfzeilen vorher auswerten. Als Betreiber gilt: wissen, welches Glied zählt, im Protokoll nachsehen, wen die Regel trifft, und sie schmal genug schneiden, dass sie Googlebot nicht als Angreifer verbucht.

Wenn Google nach einer 429-Phase weniger crawlt und Seiten aus dem Index verschwinden, ist der Zusammenhang kein Zufall — die Reihenfolge der Prüfung steht in Warum Google deine Seiten nicht indexiert. Kommt statt 429 eine Zeitüberschreitung, weil der Server tatsächlich nicht hinterherkommt, ist das ein anderer Beitrag: HTTP Statuscode 504.

Quellen#