429 Too Many Requests: Was ist ein Rate-Limit-Fehler?

Sie sehen auf einer Spieleplattform Tauschangebote durch, schreiben in einem KI-Chat eine Frage nach der anderen oder öffnen immer wieder dieselbe Seite, um zu prüfen, ob ein Visatermin frei geworden ist. Plötzlich ändert sich die Seite und auf dem Bildschirm steht nur noch eine Zeile: „429 Too Many Requests“. Manchmal ist die Meldung für Menschen formuliert („Zu viele Versuche, bitte später erneut versuchen“), manchmal erscheint sie in einer App als „Request failed with status code 429“ und manchmal heißt es „rate limit exceeded“. Alle sagen dasselbe: Der Dienst auf der anderen Seite hat die Anfragen gezählt, die von Ihnen kommen, und die Zahl hat die Grenze überschritten.

In diesem Beitrag erklären wir, was der Code 429 und der Begriff Rate-Limit bedeuten, woran die Grenze gezählt wird, warum der Fehler auch bei Menschen erscheint, die „nichts getan haben“, und wie lange Sie warten müssen. Die erste Hälfte richtet sich an alle, die den Fehler auf dem Bildschirm sehen, die zweite an Entwickler, die eine API nutzen, und an Teams, die Daten erfassen.

Was bedeutet 429 Too Many Requests?#

Jedes Mal, wenn Ihr Browser oder eine App eine Verbindung zu einem Server aufbaut, stellt der Server einen dreistelligen Statuscode an den Anfang seiner Antwort. 200 bedeutet „in Ordnung“, 404 bedeutet „diese Seite gibt es nicht“. 429 bedeutet: „Ich habe Ihre Anfrage verstanden, bearbeite sie aber jetzt nicht, weil Sie in kurzer Zeit zu viele Anfragen gesendet haben.“ Definiert ist der Code in Abschnitt 4 von RFC 6585. Derselbe Abschnitt überlässt dem Server zwei Dinge: wie der Nutzer erkannt wird und wie Anfragen gezählt werden. Die Regel hinter einer 429 ist also bei jedem Dienst anders; gemeinsam ist nur die Meldung.

Derselbe Fehler nimmt je nach Oberfläche des Dienstes verschiedene Formen an:

Zur letzten Zeile gibt es einen eigenen Beitrag: Jede Zeile auf diesem Bildschirm, den Ray-ID-Code und die Möglichkeiten des Website-Betreibers erklären wir in Was ist Error 1015? You Are Being Rate Limited beheben.

Was ist ein Rate-Limit und wozu dient es?#

Ein Rate-Limit ist die Obergrenze für die Zahl der Anfragen, die ein Dienst von einem einzelnen Nutzer in einem bestimmten Zeitraum annimmt. Es ist eine Regel wie „60 Anfragen pro Minute“, „5 Anmeldeversuche pro Stunde“ oder „1.000 Suchanfragen pro Tag“. „Rate limit exceeded“ sagt, dass diese Grenze überschritten wurde, „rate limited“ sagt, dass Sie deshalb gedrosselt werden. Auf Deutsch spricht man auch von Ratenbegrenzung oder Anfragelimit.

Dienste setzen diese Grenze aus vier Gründen:

• Kapazität schützen. Die Zahl der Anfragen, die ein Server verarbeiten kann, ist endlich. Ein einzelner Nutzer oder ein fehlerhaftes Programm soll nicht die gesamte Kapazität verbrauchen.
• Kontosicherheit. Auf Anmeldeseiten wird die Grenze bewusst niedrig gehalten. Wer ein Passwort erraten will, möchte Tausende Versuche machen; eine Regel wie „nach fünf falschen Versuchen warten“ bremst diesen Angriff so stark, dass er sinnlos wird.
• Faire Verteilung. Kostenlose und bezahlte Tarife haben unterschiedliche Kontingente; die Grenze legt den Anteil jedes Einzelnen fest.
• Kosten. Jede Anfrage hat einen Gegenwert in Rechenzeit, Bandbreite und manchmal in Gebühren an Dritte.

Woran wird die Grenze gezählt?#

Die erste Frage nach einer 429 lautet: In wessen Namen wird der Zähler geführt? Die MDN-Seite zu 429 nennt die möglichen Verfahren: für den gesamten Server, für eine einzelne Ressource, pro IP-Adresse, pro Nutzer oder pro Anwendung. Welches Verfahren im Einsatz ist, entscheidet darüber, was hilft und was nicht.

Die meisten Dienste führen mehrere dieser Zähler gleichzeitig. GitHub ist ein gutes Beispiel, weil es seine Regel offen nennt: Laut der Dokumentation zu den Rate-Limits der REST-API sind nicht authentifizierte Anfragen auf 60 pro Stunde begrenzt, und dieser Zähler hängt nicht am Nutzer, sondern an der IP-Adresse, von der die Anfrage kommt. Für authentifizierte Nutzer liegt die Grenze bei 5.000 Anfragen pro Stunde und hängt am Konto.

Wie funktioniert ein Rate-Limit?#

Die Einzelheiten unterscheiden sich je nach Dienst, der Ablauf ist derselbe:

1. Der Dienst schreibt eine Regel. Eine Regel hat drei Teile: wer gezählt wird (IP, Konto, Schlüssel), den Zeitraum und den Schwellenwert.
2. Jede eingehende Anfrage wird auf einen Zähler gebucht. Bevor der Server die Anfrage verarbeitet, prüft er, zu welchem Zähler sie gehört, und erhöht diesen um eins.
3. Ist der Schwellenwert überschritten, wird die Anfrage unbearbeitet abgelehnt. Statt die Seite aufzubereiten, sendet der Server eine kurze 429-Antwort.
4. Der Server kann mitteilen, wie lange Sie warten müssen. Das geschieht über den Antwort-Header Retry-After. Der Header ist nicht verpflichtend, nicht jede Website sendet ihn.
5. Mit der Zeit leert sich der Zähler. Das Fenster schließt sich oder ein neues Token fällt in den Eimer, und der Zugriff wird von selbst wieder frei.
6. Wer darauf beharrt, kann härter bestraft werden. Manche Dienste sperren einen Client, der trotz 429 im selben Tempo weitermacht, länger und mit einem strengeren Code. Die GitHub-Dokumentation sagt es offen: Wer weiter Anfragen sendet, während er begrenzt ist, riskiert die Sperrung seiner Integration.

Eine Anmerkung zum zweiten Schritt: Das Öffnen einer Seite ist nicht eine einzelne Anfrage. Der Browser fordert Bilder, Skripte und Hintergrundabfragen getrennt an; ein einziger Klick kann Dutzende Anfragen an den Server senden.

Ich habe nichts getan, warum bekomme ich eine 429?#

In Suchvorschlägen tauchen neben diesem Fehler am häufigsten Steam, Roblox, ChatGPT, Outlook und Seiten für Visatermine auf. Gemeinsam ist ihnen: Nutzer erzeugen dort viele Anfragen, ohne es zu merken.

• Markt- und Tauschseiten auf Spieleplattformen. Preislisten, Inventar- und Angebotsseiten senden bei jedem Öffnen zahlreiche Abfragen im Hintergrund. Eine Browser-Erweiterung, die Preise verfolgt, kann die Grenze innerhalb von Minuten ausschöpfen. Auch Drittanbieter-Tools, die Sie mit Ihrem Konto verbunden haben, senden Anfragen in Ihrem Namen.
• KI-Chats. Jede Nachricht ist ein teurer Vorgang, deshalb gilt die Grenze sowohl für die Gesamtzahl der Nachrichten als auch für ihre Häufigkeit. Wenn mehrere Personen ein Konto teilen oder eine Antwort immer wieder neu erzeugt wird, ist die Grenze am schnellsten erreicht.
• E-Mail-Konten. Anmeldeversuche mit falschem Passwort, ein vergessenes Smartphone, das sich noch mit dem alten Passwort verbinden will, oder ein E-Mail-Programm füllen den Zähler an Ihrer Stelle.
• Termin- und Ticketseiten. Hier erzeugt der Nutzer die Anfragen selbst: eine Seite, die alle paar Sekunden neu geladen wird, um zu sehen, ob ein Platz frei geworden ist.

Trifft nichts davon auf Sie zu, bleibt die geteilte IP-Adresse. Hängt der Zähler an der IP, gelten alle, die über dieselbe Adresse ins Internet gehen (sämtliche Rechner im Büro, Mobilfunkkunden hinter derselben öffentlichen Adresse), als eine Person: Jemand anderes füllt den Zähler, und Sie sehen die 429. Den Mechanismus und wie Sie ihn an Ihrem eigenen Anschluss erkennen, erklären wir in Was ist CGNAT? So erkennen Sie es und kommen heraus. Bei kostenlosen VPN- und Proxy-Diensten nutzt eine weit größere Gruppe dieselbe Ausgangsadresse; Einzelheiten dazu in Sind kostenlose Proxys und Web-Proxy-Seiten sicher?.

Wie lange dauert ein 429-Fehler? Warum hilft Neuladen nicht?#

Eine einzige Antwort gibt es nicht, weil nicht der Standard, sondern der Dienst selbst die Dauer festlegt. Ein Sekundenfenster öffnet sich nach wenigen Sekunden, ein Stundenkontingent innerhalb einer Stunde, ein Tageskontingent am nächsten Tag. In der Beispielantwort von MDN steht Retry-After: 3600, also eine Stunde.

Neuladen hilft nicht, weil F5 aus Sicht des Servers eine neue Anfrage ist: Sie wird entweder direkt abgelehnt oder dem Zähler hinzugefügt und kann so die Wartezeit verlängern. Bei einem Dienst mit gleitendem Fenster (weiter unten erklärt) leert sich der Zähler eines Nutzers, der es ständig weiter versucht, nie.

Statt die Dauer zu schätzen, können Sie sie ablesen: Öffnen Sie mit F12 die Entwicklertools, laden Sie die Seite im Tab „Netzwerk“ (Network) einmal neu und klicken Sie auf die Zeile mit 429. Steht Retry-After unter den Antwort-Headern, ist die Zahl daneben die Wartezeit in Sekunden.

Was sollten Sie als Besucher tun?#

1. Hören Sie auf. Schließen Sie den Tab, verlassen Sie die App und versuchen Sie einige Minuten lang nichts.
2. Schalten Sie ab, was in Ihrem Namen Anfragen sendet. Weitere offene Tabs derselben Website, Erweiterungen für automatisches Neuladen und Preisverfolgung, eine Desktop-App im Hintergrund, mit Ihrem Konto verbundene Drittanbieter-Tools.
3. Erscheint der Fehler auf der Anmeldeseite, probieren Sie keine Passwörter mehr. Jeder falsche Versuch kann die Wartezeit verlängern. Sind Sie unsicher, warten Sie und nutzen Sie danach den Weg „Passwort vergessen“. Versucht ein Gerät weiterhin das alte Passwort, aktualisieren Sie es.
4. Versuchen Sie es einmal. Öffnet sich die Seite, ist das Problem erledigt. Wenn nicht, verlängern Sie die Wartezeit: zehn Minuten, eine halbe Stunde, einige Stunden.
5. Messen Sie den Anteil der Verbindung. Ist ein VPN oder ein kostenloser Proxy aktiv, schalten Sie ihn aus und versuchen Sie es dann über die mobilen Daten Ihres Smartphones. Öffnet sich die Seite dort, im Büro- oder Heimnetz aber nicht, gehört der Zähler zu der Adresse, die Sie teilen. Erhalten Sie auf beiden Verbindungen denselben Fehler, hängt der Zähler an Ihrem Konto, und es bleibt nur das Warten.
6. Erscheint der Fehler bei normaler Nutzung täglich, schreiben Sie dem Support des Dienstes. Geben Sie an, was Sie getan haben und welche Meldung erschienen ist.

Cookies löschen, den Browser wechseln oder den Router neu starten stehen nicht auf dieser Liste, weil der Zähler meist an etwas hängt, das sich dadurch nicht ändert: an Ihrem Konto oder an der geteilten Adresse. Die ähnliche Warnung bei Google-Suchen hat eigene Ursachen; wir behandeln sie in unserem Beitrag zum Google-Fehler „Ungewöhnlicher Datenverkehr“.

Rate-Limit-Algorithmen: Fixed Window, Sliding Window und Token Bucket#

Ab hier richtet sich der Beitrag an Entwickler. Die Regel „10 Anfragen pro Minute“ verhält sich auf drei verschiedene Arten, je nachdem, wie der Zähler geführt wird.

Die Näherungsrechnung des gleitenden Fensters zeigt Cloudflare in dem Beitrag über seinen eigenen Rate-Limiter an einem Beispiel: Die Grenze liegt bei 50 Anfragen pro Minute, in der vorigen Minute kamen 42 Anfragen, und in der 15. Sekunde der laufenden Minute sind 18 Anfragen gezählt. Die Schätzung lautet 42 × (45/60) + 18 = 49,5, also knapp unter der Grenze. Den Token Bucket fasst Stripe in dem Beitrag über seine eigenen Rate-Limiter zusammen: Jeder Nutzer hat einen Eimer, jede Anfrage nimmt ein Token, und nach und nach tropfen neue Tokens in den Eimer.

Am schnellsten sieht man den Unterschied, wenn man allen dreien denselben Verkehr gibt. Das folgende Python-Skript nutzt keine Netzwerkverbindung; es befragt lediglich drei Zähler zu Zeitstempeln.

LIMIT = 10      # erlaubte Anfragen pro Fenster
WINDOW = 60     # Fensterlänge (Sekunden)


class FixedWindow:
    def __init__(self):
        self.window_id, self.count = None, 0

    def allow(self, now):
        window_id = int(now // WINDOW)
        if window_id != self.window_id:          # neues Fenster: Zähler wird zurückgesetzt
            self.window_id, self.count = window_id, 0
        if self.count >= LIMIT:
            return False
        self.count += 1
        return True


class SlidingWindow:
    def __init__(self):
        self.window_id, self.count, self.previous = None, 0, 0

    def allow(self, now):
        window_id = int(now // WINDOW)
        if window_id != self.window_id:
            # war das vorige Fenster leer, wird nichts übertragen
            self.previous = self.count if window_id - 1 == self.window_id else 0
            self.window_id, self.count = window_id, 0
        elapsed = now % WINDOW
        # der Wert des vorigen Fensters zählt anteilig nach seinem verbleibenden Anteil
        estimate = self.previous * (WINDOW - elapsed) / WINDOW + self.count
        if estimate >= LIMIT:
            return False
        self.count += 1
        return True


class TokenBucket:
    def __init__(self):
        self.tokens, self.updated = float(LIMIT), 0.0

    def allow(self, now):
        # Tokens kommen für die vergangene Zeit hinzu, der Eimer läuft nicht über die Kapazität
        self.tokens = min(LIMIT, self.tokens + (now - self.updated) * LIMIT / WINDOW)
        self.updated = now
        if self.tokens < 1:
            return False
        self.tokens -= 1
        return True


def run(name, timestamps):
    print(name)
    for limiter in (FixedWindow(), SlidingWindow(), TokenBucket()):
        accepted = sum(limiter.allow(t) for t in timestamps)
        print(f"  {type(limiter).__name__:<14} {accepted}/{len(timestamps)} akzeptiert")


# Szenario 1: zwei Lastspitzen beiderseits der Fenstergrenze (Sekunde 59 und 61)
run("Lastspitze an der Grenze", [59.0] * 10 + [61.0] * 10)
# Szenario 2: zwei Minuten lang alle 7,5 Sekunden eine Anfrage (8 pro Minute)
run("Gleichmäßiges Tempo", [i * 7.5 for i in range(16)])

Ausgabe:

Lastspitze an der Grenze
  FixedWindow    20/20 akzeptiert
  SlidingWindow  11/20 akzeptiert
  TokenBucket    10/20 akzeptiert
Gleichmäßiges Tempo
  FixedWindow    16/16 akzeptiert
  SlidingWindow  16/16 akzeptiert
  TokenBucket    16/16 akzeptiert

Im ersten Szenario ließ das feste Fenster trotz der Regel „10 pro Minute“ in zwei Sekunden 20 Anfragen durch, weil der Zähler in Sekunde 60 zurückgesetzt wurde. Das gleitende Fenster erinnerte sich an die Last der vorigen Minute und nahm aus der zweiten Spitze eine einzige Anfrage an (weil die Rechnung eine Näherung ist, blieb es nicht exakt bei 10 stehen). Der Token Bucket verbrauchte seine Tokens in der ersten Spitze und lehnte die zweite vollständig ab. Das zweite Szenario enthält die eigentliche Lehre für den Client: Verkehr, der unter der Grenze bleibt und gleichmäßig eintrifft, sieht bei keinem Algorithmus eine 429. An die Grenze stößt nicht der Durchschnitt, sondern die Ballung.

Ein Beispiel, das dieselbe Token-Bucket-Logik auf der Client-Seite einsetzt, um die eigenen Anfragen zu bremsen, finden Sie in Sicherer Webzugriff für LLMs: Rate-Limits und Berechtigungen.

Wenn Sie eine API nutzen: Wie liest man die Grenze aus den Headern?#

Gut dokumentierte APIs nehmen der Grenze die Überraschung: Jede Antwort meldet in ihren Headern, wie viel von Ihrem Kontingent übrig ist. Der Kontingent-Endpunkt von GitHub eignet sich zum Ausprobieren, weil Aufrufe dieses Endpunkts nicht von Ihrem primären Kontingent abgezogen werden:

curl -s -o /dev/null -D - https://api.github.com/rate_limit | grep -i -E "^HTTP|^x-ratelimit"

Bei einem nicht authentifizierten Aufruf sieht die Antwort etwa so aus:

HTTP/1.1 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 53
X-RateLimit-Used: 7
X-RateLimit-Resource: core
X-RateLimit-Reset: 1789799592

Limit nennt das gesamte Guthaben im Fenster, Remaining den Rest und Reset den Zeitpunkt, an dem der Zähler zurückgesetzt wird (Unix-Zeit in Sekunden). Die 60 gehört hier zu Ihrer IP-Adresse; eine Kollegin, die denselben Befehl aus demselben Büro ausführt, verbraucht aus demselben Zähler. Ein Programm, das diese Header liest, kann von selbst langsamer werden, wenn es sich der Grenze nähert.

Drei Punkte verdienen Aufmerksamkeit:

• Die Header-Namen sind nicht standardisiert. X-RateLimit-* ist eine verbreitete Gewohnheit, aber Reset ist in der einen API Unix-Zeit, in der anderen die verbleibenden Sekunden. Um das zu ordnen, arbeitet die IETF an einem Entwurf, der die Header RateLimit und RateLimit-Policy definiert; als dieser Beitrag entstand, war der Text noch kein RFC.
• Die Grenze kommt nicht immer als 429. GitHub schreibt im selben Dokument, dass beim Überschreiten der Grenze 403 oder 429 zurückkommen kann. Achten Sie nicht nur auf den Code, sondern auch auf die Header und die Meldung im Body.
• Rate-Limit und Kontingent sind verschiedene Dinge. Ein Rate-Limit pro Minute löst sich durch Warten; ein Monatskontingent oder ein aufgebrauchtes Guthaben wird auf der Tarif- und Zahlungsseite gelöst. Beide können mit demselben Code kommen, den Unterschied nennt die Meldung im Body.

Für die Zeit nach einer 429 ist die Regel kurz. Ist Retry-After vorhanden, halten Sie sich daran; wenn nicht, wenden Sie exponentielles Backoff an (1, 2, 4, 8 Sekunden, jeweils mit einem zufälligen Zuschlag), begrenzen Sie die Zahl der Versuche und wenden Sie die Wartezeit auf alle Ihre Anfragen an diesen Dienst an. Die beiden Formen von Retry-After und ein erprobtes Python-Beispiel, das diese Entscheidungen umsetzt, finden Sie in HTTP-Statuscodes beim Web Scraping: 403, 407, 429, 503; denselben Code wiederholen wir hier nicht. Wie sich Nebenläufigkeit auf die 429-Quote auswirkt, steht in Concurrency und Parallelism: Was bestimmt Scraping-Tempo?.

Lässt sich ein Rate-Limit durch einen IP-Wechsel überwinden?#

In den meisten Fällen nein. Hängt der Zähler am Konto, an der Sitzung oder am API-Schlüssel, spielt die IP-Adresse in der Rechnung gar keine Rolle: Eine Anfrage von einer neuen Adresse wird auf den Zähler desselben Kontos gebucht.

Selbst wenn der Zähler an der IP hängt, löst ein IP-Wechsel das Problem nicht, er verlagert es. Der Grenze geht es nicht um Ihre Identität, sondern um die Last, die Sie dem Dienst aufbürden. Dasselbe Tempo auf andere Adressen zu verteilen belastet den Server im selben Maß; ein Dienst, der das bemerkt, schreibt die Regel nach dem Verhalten, und aus der 429 wird eine dauerhaftere Sperre. In dieselbe Klasse fällt es, eine gefälschte Adresse in den Header X-Forwarded-For zu schreiben oder bei jeder Anfrage den User-Agent zu wechseln: Ein sauber konfigurierter Server vertraut der Adresse nicht, die der Client angibt, und widersprüchliche Header sind ein sichtbares Zeichen für automatisierten Verkehr. Wie Websites diese Zeichen lesen, erklären wir in unserem Beitrag zur Funktionsweise der Bot-Erkennung.

IP-Rotation hat einen legitimen Platz, aber dieser Platz ist nicht „nach einer 429“. Bei einer erlaubten, umfangreichen Datenerfassung wird zuerst das Gesamttempo auf ein Niveau gesenkt, das die Website tragen kann und das mit robots.txt und den Nutzungsbedingungen vereinbar ist; erst danach wird dieser Verkehr auf Adressen verteilt. Praktische Wege, das Tempo einzuhalten, stehen in Web Scraping ohne Sperren: Daten regelkonform erfassen. Wie Rotation funktioniert, lesen Sie in unserem Beitrag zur IP-Rotation, die Produktseite dazu ist unsere Seite zu Rotating Proxys.

Wer hat beruflich mit Rate-Limits zu tun?#

• Teams, die Preise und Bestände beobachten. Ein Job, der täglich Tausende Produktseiten liest, sieht seine 429-Quote schnell steigen, wenn das Tempo nicht auf die Website abgestimmt ist: Lösung für Preisüberwachung.
• Wer Katalog- und Marktdaten erfasst. Für jede Website wird ein eigenes Tempobudget geführt: Lösung für Datenerfassung.
• Wer sich mit APIs verbindet, die eine IP-Freigabeliste verlangen. Das Kontingent wird auf diese Adresse oder diesen Schlüssel gebucht: unser Beitrag zu statischen IPs für den API-Zugriff.
• Wer Automatisierungen baut. Ein Workflow, der in derselben Minute Hunderte Aufrufe startet, stößt beim ersten Lauf an die Grenze; die Warteeinstellungen stehen in Web Scraping mit n8n: HTTP Request und Proxy-Einstellungen.
• Operations-Teams in einem stark genutzten Netz. Verbinden sich Dutzende Mitarbeitende über eine einzige Büroadresse mit demselben Panel, sieht ein IP-basierter Zähler die Summe des Teams. Gesucht ist hier nicht ein Weg über die Grenze, sondern ein Zähler, der nur an Ihrer eigenen Nutzung hängt: ISP-Proxy liefert eine feste Adresse, die bei einem Internetanbieter registriert ist und mit niemandem geteilt wird.

Häufige Fehler#

• Auf dem 429-Bildschirm weiter neu laden. Jedes Neuladen wird auf den Zähler gebucht.
• An der Anmeldegrenze weiter Passwörter probieren. Die Wartezeit wächst, bei manchen Diensten wird das Konto vorübergehend gesperrt.
• Annehmen, die Grenze hänge an der IP. Hängt der Zähler am Konto oder am Schlüssel, ist ein Netzwechsel verlorene Zeit.
• Auf Entwicklerseite ohne Wartezeit erneut versuchen. Die Antwort auf einen sofortigen neuen Versuch nach einer 429 ist eine weitere 429.
• Denselben API-Schlüssel in vielen Programmen nutzen und die Grenze in jedem Programm einzeln suchen. Der Zähler gehört zum Schlüssel; ohne Blick auf die Summe gibt es keine Diagnose.

Entscheidungshilfe#

Häufige Fragen#

Ist 429 Too Many Requests eine dauerhafte Sperre?#

Nein. Eine 429 kommt von einem Zähler, der an der Zeit hängt, und der Zugriff wird von selbst frei, sobald sich der Zähler geleert hat. An Ihrem Konto wird nichts verändert.

Bedeutet „too many requests“ einen Virus oder eine Internetstörung?#

Nein. Die Meldung kommt vom Server des Dienstes, mit dem Sie sich verbunden haben, und betrifft nur die Zahl der Anfragen. Wenn andere Websites normal laden, ist mit Ihrem Internet alles in Ordnung.

Behebt ein Neustart des Routers einen 429-Fehler?#

Das ist kein verlässlicher Weg. Wenn sich der Router neu verbindet, ändert sich die IP-Adresse bei manchen Anschlüssen und bei anderen nicht; hängt der Zähler am Konto, spielt es ohnehin keine Rolle. Unter welchen Bedingungen sich die IP-Adresse ändert, erklären wir in IP-Adresse ändern: Smartphone, PC und Router.

Sind Rate-Limit und IP-Sperre dasselbe?#

Nein. Ein Rate-Limit ist ein Zähler, der an der Zeit hängt: Er gilt für alle und gibt den Zugriff frei, wenn Sie warten. Eine IP-Sperre ist eine langfristige Entscheidung über eine bestimmte Adresse und zeigt sich meist als 403. Eine Adresse, die die Grenze ständig ausreizt, kann mit der Zeit in die zweite Gruppe wechseln.

Wie lange sollte ich warten, wenn es keinen Retry-After-Header gibt?#

Als Nutzer beginnen Sie mit einigen Minuten und verlängern die Wartezeit nach jedem erfolglosen Versuch. Wenn Sie ein Programm schreiben, wenden Sie exponentielles Backoff an und begrenzen Sie die Zahl der Versuche.

Behebt ein Proxy einen 429-Fehler?#

Wenn Ihr eigenes Tempo oder Verhalten die Grenze füllt, nein: Dasselbe Tempo füllt auch den Zähler der neuen Adresse, und ein Zähler, der am Konto hängt, sieht die Adresse gar nicht. Ein Proxy macht dann einen Unterschied, wenn nicht Sie den Zähler füllen, sondern die anderen, mit denen Sie die Adresse teilen. Dann reduziert eine feste Adresse, die nur Ihnen gehört, den Zähler auf Ihre eigene Nutzung.

Fazit#

429 Too Many Requests ist eine vorübergehende Antwort, die Ihnen mitteilt, dass Sie an das Rate-Limit eines Dienstes gestoßen sind. Die Grenze kann pro IP-Adresse, Konto, Sitzung, API-Schlüssel oder für einen einzelnen Endpunkt gezählt werden; das entscheidet darüber, was hilft. Für Nutzer besteht die Lösung darin, aufzuhören, alles abzuschalten, was im Hintergrund Anfragen sendet, und zu warten. Für Entwickler besteht sie darin, die Kontingent-Header zu lesen, Retry-After zu befolgen und das Tempo zu senken. Durch IP-Rotation lässt sich die Grenze nicht überwinden; Rotation dient nur dazu, eine von Anfang an geplante Last, die die Website respektiert, zu verteilen. Die zu Ihrer Arbeit passenden Adresstypen finden Sie in unseren Proxy-Diensten.