HTTP Error 429 Too Many Requests: Bedeutung & Lösung

Was ist der HTTP Error 429?

HTTP 429 Too Many Requests bedeutet, dass der Server Ihre Zugriffe per Rate Limiting begrenzt: Sie, Ihre IP-Adresse oder Ihre App haben in einem bestimmten Zeitraum mehr Anfragen gesendet, als er erlaubt. Das ist vorübergehend. Der Server funktioniert, er beantwortet Ihre Anfragen nur gerade nicht.

Der Code wurde in RFC 6585 (2012) genau für diesen Fall eingeführt, und die Antwort kann einen Retry-After-Header enthalten, der sagt, wie lange Sie warten sollen. Sie begegnen ihm auf stark besuchten Websites, bei API-Aufrufen, bei Massen-Downloads oder in einem VPN, dessen IP-Adresse sich viele Nutzer teilen.

Er unterscheidet sich von seinen Nachbarn: Ein 401 bedeutet, dass Sie nicht angemeldet sind, ein 403, dass Sie keinen Zutritt haben, und ein 429, dass Sie zwar zugreifen dürfen, aber zu schnell sind.

Wie sieht der Fehler 429 aus?

Die Meldung hängt davon ab, wer antwortet. Das sind die, nach denen Menschen suchen:

Anders als ein 500er-Fehler, bei dem auf dem Server etwas kaputtgegangen ist, ist 429 im HTTP-Sinn ein Client-Fehler: Der Server schützt sich vor zu vielen Anfragen.

Wie funktioniert Rate Limiting?

Rate Limiting ist ein Verfahren, mit dem Server steuern, wie viele Anfragen ein Client in einem Zeitfenster stellen darf. Wird das Limit überschritten, antwortet der Server meist mit 429 (manche antworten stattdessen mit 403 oder 503).

Es gibt mehrere verbreitete Rate-Limiting-Algorithmen:

• Fixed Window — Der Server erlaubt N Anfragen pro Zeitfenster (z. B. 100 Anfragen pro Minute). Der Zähler wird in festen Intervallen zurückgesetzt.
• Sliding Window — Ähnlich wie Fixed Window, aber das Zeitfenster verschiebt sich mit jeder Anfrage. Dadurch werden Anfragenspitzen an Fenstergrenzen verhindert.
• Token Bucket — Der Server vergibt Tokens, die in gleichmäßigem Tempo nachgefüllt werden. Jede Anfrage verbraucht ein Token. Sind alle Tokens aufgebraucht, werden Anfragen abgelehnt.
• Leaky Bucket — Anfragen werden unabhängig von der Spitzenlast mit konstanter Rate verarbeitet. Überschüssige Anfragen werden in eine Warteschlange gestellt oder verworfen.

Viele APIs nennen ihre Limits in den Antwort-Headern. Bei GitHub sind das zum Beispiel x-ratelimit-limit (erlaubte Anfragen pro Stunde), x-ratelimit-remaining, x-ratelimit-used und x-ratelimit-reset (wann das Zeitfenster zurückgesetzt wird, in Unix-Sekunden). Ein IETF-Entwurf schlägt standardisierte RateLimit- und RateLimit-Policy-Header für dieselbe Aufgabe vor.

Wer weiß, welchen Algorithmus und welches Zeitfenster ein Dienst verwendet, kann seinen Client so entwerfen, dass er innerhalb des Limits bleibt.

Häufige Ursachen für den HTTP Error 429

Die Ursache hängt davon ab, wen der Fehler trifft:

HTTP 429 beheben (für Besucher)

Wenn Sie beim Surfen auf einer Website den Fehler 429 sehen, können Sie folgende Lösungen ausprobieren. Beginnen Sie mit der einfachsten und arbeiten Sie sich vor.

1. Warten und erneut versuchen

Am einfachsten ist es zu warten. Ein 429 ist vorübergehend: Der Server bittet Sie, langsamer zu werden, er sperrt Sie nicht.

Wie lange, hängt vom Limit der Website ab: Manche setzen sich innerhalb einer Minute zurück, andere stündlich oder täglich. Sendet die Seite oder API einen Retry-After-Header, ist das die genaue Wartezeit. Laden Sie die Seite danach einmal.

Laden Sie nicht ständig neu: Jedes Neuladen ist eine weitere Anfrage und zählt gegen dasselbe Limit.

2. Cookies der Website löschen

Das hilft selten, aber manche Websites zählen Anfragen pro Sitzungs-Cookie. Löschen Sie die Cookies nur dieser einen Website, um eine neue Sitzung zu bekommen, ohne sich überall sonst abzumelden:

• Chrome / Edge: Öffnen Sie chrome://settings/content/all (Edge: edge://settings/content/all), suchen Sie die Website und löschen Sie deren Daten
• Firefox: Klicken Sie auf das Schloss in der Adressleiste → Cookies und Website-Daten löschen…
• Safari: Safari → Einstellungen → Datenschutz → Websitedaten verwalten → Website suchen → Entfernen

Schließen Sie nach dem Löschen den Browser und öffnen Sie ihn erneut, bevor Sie die Seite wieder aufrufen.

3. VPN oder Proxy trennen

Wenn Sie ein VPN oder einen Proxy nutzen, teilen Sie sich die IP-Adresse möglicherweise mit Hunderten anderer Nutzer. Übersteigen deren gemeinsame Anfragen das Limit des Servers, wird jeder auf dieser IP gedrosselt.

Trennen Sie das VPN und rufen Sie die Website über Ihre normale Internetverbindung auf. Verschwindet der Fehler 429, lag es an der IP des VPNs.

Brauchen Sie das VPN, wechseln Sie den Serverstandort: Die IP dort wird möglicherweise von weniger Nutzern geteilt.

4. Browser-Erweiterungen deaktivieren

Manche Erweiterungen senden im Hintergrund Anfragen an die Websites, die Sie besuchen: Preis-Tracker, SEO-Tools und Auto-Refresh-Erweiterungen können zusammen ein Rate Limit erreichen. (Werbeblocker tun meist das Gegenteil und verringern die Anfragen.)

Zum Testen öffnen Sie die Website in einem Inkognito-/privaten Fenster, in dem die meisten Erweiterungen ausgeschaltet sind. Inkognito startet außerdem ohne Cookies. Verschwindet der Fehler 429, spielt also eine Erweiterung oder ein sitzungsbasiertes Limit eine Rolle.

Deaktivieren Sie die Erweiterungen einzeln, um die problematische zu finden. In Chrome rufen Sie dafür chrome://extensions/ auf und schalten sie nacheinander aus.

5. Prüfen, ob Ihre IP-Adresse geteilt wird

Viele Menschen können sich eine öffentliche IP-Adresse teilen: ein Firmen- oder Schulnetz, das Netz eines Mobilfunkanbieters (CGNAT) oder ein VPN-Server. Ihre Anfragen zählen gegen dasselbe Limit wie Ihre.

Befinden Sie sich in einem solchen Netz, zeigt Ihnen der Aufruf der Website über Ihren eigenen Heimanschluss oder per Mobilfunk, ob die geteilte Adresse das Problem ist. Liegt das Limit auf Ihrer eigenen Adresse, warten Sie, bis es zurückgesetzt wird, statt das Netz zu wechseln, um es zu umgehen. Mit Wie ist meine IP-Adresse? sehen Sie Ihre aktuelle öffentliche IP.

HTTP 429 beheben (für Entwickler)

Wenn Ihr Code 429 erhält, sendet er Anfragen schneller, als die API erlaubt. Gehen Sie in dieser Reihenfolge vor: Retry-After lesen, mit Backoff und Jitter wiederholen, dann die Zahl der Anfragen senken.

1. Exponentielles Backoff implementieren

Exponentielles Backoff ist die Standard-Wiederholstrategie: Statt nach einem 429 sofort erneut zu senden, verdoppeln Sie die Wartezeit bei jedem Versuch (1 Sekunde, 2, 4, 8…) und fügen Jitter hinzu, eine zufällige Zusatzverzögerung, damit nicht viele Clients im selben Moment wiederholen.

Diese Version nutzt Retry-After, wenn der Server einen gültigen Wert sendet (in beiden möglichen Formaten), greift sonst auf Backoff mit Jitter zurück und gibt nach einigen Versuchen auf. (Im Browser lässt sich Retry-After bei der API einer fremden Website nur lesen, wenn diese den Header mit Access-Control-Expose-Headers freigibt.)

async function fetchWithBackoff(url, options = {}, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url, options);
    if (response.status !== 429 || attempt === maxRetries) return response;

    // Retry-After is either a number of seconds or an HTTP date
    const header = response.headers.get('Retry-After');
    let delay = NaN;
    if (header) {
      const seconds = Number(header);
      delay = Number.isNaN(seconds) ? Date.parse(header) - Date.now() : seconds * 1000;
    }
    if (!Number.isFinite(delay)) delay = 2 ** attempt * 1000 + Math.random() * 1000; // backoff + jitter
    await new Promise((resolve) => setTimeout(resolve, Math.max(delay, 0)));
  }
}

2. Den Retry-After-Header beachten

Sendet ein Server mit einem 429 den Header Retry-After, nennt er genau, wie lange Sie warten sollen. RFC 9110 erlaubt zwei Formen: eine Anzahl Sekunden oder ein HTTP-Datum.

Retry-After: 60 heißt: 60 Sekunden warten. Retry-After: Wed, 21 Oct 2026 07:28:00 GMT heißt: bis zu diesem Zeitpunkt warten. Prüfen Sie ihn vor Ihrer eigenen Backoff-Logik: Der Server weiß es besser als Ihr Code.

In Python behandeln Sie beide Formen und hören nach einigen Versuchen auf, statt endlos zu rekursieren:

import random
import time
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime

import requests


def get_with_retry(url, max_retries=5):
    for attempt in range(max_retries + 1):
        response = requests.get(url)
        if response.status_code != 429 or attempt == max_retries:
            return response
        retry_after = response.headers.get("Retry-After", "")
        try:
            if retry_after.isdigit():
                wait = int(retry_after)
            else:  # an HTTP date
                wait = (parsedate_to_datetime(retry_after) - datetime.now(timezone.utc)).total_seconds()
        except (TypeError, ValueError):  # missing or unparseable: back off with jitter
            wait = 2 ** attempt + random.random()
        time.sleep(max(wait, 0))

3. API-Antworten cachen

Wenn Ihre Anwendung denselben API-Aufruf mehrfach durchführt, speichern Sie die Antwort zwischen, anstatt die API jedes Mal erneut aufzurufen. Dadurch reduziert sich die Anzahl Ihrer Anfragen drastisch.

Verwenden Sie einen In-Memory-Cache (wie Redis oder eine einfache Map) für häufig abgerufene Daten. Setzen Sie eine sinnvolle TTL (Time-to-Live) basierend darauf, wie oft sich die Daten ändern.

Wenn Sie beispielsweise DNS-Einträge für eine Domain abfragen, ändern sich die Ergebnisse in den nächsten 5 Minuten wahrscheinlich nicht — cachen Sie sie.

const cache = new Map();
const CACHE_TTL = 5 * 60 * 1000; // 5 minutes

async function cachedFetch(url) {
  const cached = cache.get(url);
  if (cached && Date.now() - cached.time < CACHE_TTL) return cached.data;

  const response = await fetch(url);
  if (!response.ok) throw new Error(`HTTP ${response.status}`); // never cache errors (a 429 included)
  const data = await response.json();
  cache.set(url, { data, time: Date.now() });
  return data;
}

4. Webhooks statt Polling verwenden

Wenn Sie eine API wiederholt abfragen, um auf Änderungen zu prüfen (z. B. alle 10 Sekunden den Bestellstatus prüfen), wechseln Sie zu Webhooks, sofern der Dienst dies unterstützt.

Mit Webhooks sendet der Server Aktualisierungen an Ihre Anwendung, sobald sich etwas ändert — kein ständiges Polling mehr nötig. Dadurch reduzieren sich Ihre API-Aufrufe von Tausenden pro Stunde auf nur eine Handvoll.

Die meisten modernen APIs (Stripe, GitHub, Twilio, Shopify) unterstützen Webhooks. Schauen Sie in der API-Dokumentation nach der Webhook-Konfiguration.

5. Höhere Rate Limits beantragen

Wenn Sie wirklich mehr API-Aufrufe brauchen, wenden Sie sich an den Anbieter. Viele APIs bieten höhere Rate Limits für kostenpflichtige Tarife oder verifizierte Anwendungen.

Erklären Sie bei der Anfrage Ihren Anwendungsfall und nennen Sie das erwartete Anfragevolumen. Viele APIs, darunter die von Google, haben dafür ein Formular oder einen kostenpflichtigen Tarif mit höheren Limits.

Manche APIs bieten außerdem Bulk-Endpunkte, mit denen Sie mehrere Ressourcen in einer einzigen Anfrage abrufen und so die Zahl der Aufrufe senken.

HTTP 429 beheben (für Website-Betreiber)

Wenn Ihre Besucher oder API-Nutzer 429-Fehler erhalten, liegt das Problem in Ihrer Serverkonfiguration. So diagnostizieren und beheben Sie es.

1. Rate Limits anpassen

Wenn echte Nutzer ein 429 bekommen, finden Sie zuerst heraus, welche Schicht zuerst antwortet: Ihr CDN oder WAF, Ihr Webserver oder Ihre App. Passen Sie dann die Limits dieser Schicht an.

In nginx erledigt limit_req die Arbeit. Beachten Sie, dass es standardmäßig mit 503 antwortet: Fügen Sie limit_req_status 429; hinzu, damit Clients wissen, dass sie langsamer werden sollen, statt anzunehmen, der Server sei ausgefallen:

# Define rate limit zone: 10 requests per second per IP
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        # Up to 20 extra requests pass at once (nodelay); more than that get 429
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

Der Parameter burst lässt kurze Lastspitzen ohne 429 durch. Ohne ihn kann schon ein normaler Seitenaufruf mit vielen Anfragen das Limit erreichen.

Apache hat keinen eingebauten Begrenzer für die Anfragerate: Sein mod_ratelimit begrenzt die Bandbreite, nicht die Zahl der Anfragen, und das Drittanbieter-Modul mod_evasive antwortet mit 403. Nutzen Sie für 429 einen Reverse Proxy, eine WAF oder Ihre App. In Node.js antwortet express-rate-limit standardmäßig mit 429.

2. Vertrauenswürdige IPs auf die Whitelist setzen

Wenn bestimmte Clients (Monitoring-Dienste, Zahlungsanbieter, Ihre eigenen Microservices) gedrosselt werden, setzen Sie deren IP-Adressen auf die Whitelist.

In nginx geben geo und map vertrauenswürdigen Adressen einen leeren Schlüssel, und nginx zählt Anfragen mit leerem Schlüssel nicht. Das ersetzt die Zeile limit_req_zone aus dem vorherigen Beispiel:

geo $rate_limit {
    default        1;
    192.168.0.0/16 0;  # Internal network
    10.0.0.0/8     0;  # Internal network
    203.0.113.50   0;  # Payment processor
}

map $rate_limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}

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

Drosseln Sie Suchmaschinen-Crawler nicht versehentlich: Google behandelt ein 429 als Serverfehler und verlangsamt das Crawling (Google Search Central). Prüfen Sie echte Anfragen von Googlebot und Bingbot mit dem Reverse DNS Lookup, den Sie durch eine Vorwärtsabfrage dieses Namens bestätigen, oder nehmen Sie die veröffentlichten IP-Bereiche der Crawler aus.

3. WAF- und CDN-Einstellungen prüfen

Wenn Sie Cloudflare, AWS WAF, Sucuri oder einen anderen Sicherheitsdienst nutzen, können dessen Rate-Limiting-Regeln antworten, bevor Ihr Server die Anfrage überhaupt sieht.

Cloudflare zeigt Besuchern „Error 1015: You are being rate limited“, wenn eine Rate-Limiting-Regel greift. Suchen Sie die Regel in den Sicherheitsregeln des Dashboards, prüfen Sie ihre Ereignisse und erhöhen Sie den Schwellenwert oder schränken Sie ihren Geltungsbereich ein.

AWS WAF zählt bei ratenbasierten Regeln die Anfragen pro IP (oder einem anderen Schlüssel) in einem Zeitfenster von 1, 2, 5 oder 10 Minuten, mit einem Mindestlimit von 10. Eine blockierte Anfrage erhält standardmäßig 403. Legen Sie eine eigene Antwort mit 429 fest, damit Clients wissen, dass sie sich zurückhalten sollen.

Werten Sie die Analysen des CDN aus, um echte Besucher von Bots zu trennen, bevor Sie etwas ändern.

4. Serverleistung optimieren

Manche Dienste drosseln stärker, wenn sie unter Last stehen, als Sicherheitsventil. Eine bessere Serverleistung erlaubt es Ihnen, die Limits gefahrlos anzuheben.

Wichtige Optimierungen: Response-Caching aktivieren, um das Backend zu entlasten, ein CDN für statische Dateien nutzen, Datenbank-Query-Caching mit Redis oder Memcached ergänzen, Connection Pooling für Datenbankverbindungen einsetzen und bei entsprechendem Traffic horizontal mit Load Balancing skalieren.

Mit unserem HTTP-Header-Checker prüfen Sie, ob Ihre Caching-Header richtig gesetzt sind.

429 im Vergleich zu anderen HTTP-Fehlern

Der 429-Fehler kann leicht mit anderen HTTP-Statuscodes verwechselt werden. So unterscheiden sie sich:

Der entscheidende Unterschied: 429 ist beabsichtigt und vorübergehend: Der Server weist Sie für den Moment ab. Die meisten 5xx-Codes bedeuten, dass auf dem Server etwas fehlgeschlagen ist, ein 503 kann aber auch eine geplante Wartung sein oder, bei nginx, ein Rate Limit.

Wie Sie 429-Fehler vermeiden

Vorbeugung ist besser als Nachsorge. Hier sind Best Practices, um 429-Fehler von vornherein zu vermeiden:

• API-Dokumentation lesen — Kennen Sie die Rate Limits, bevor Sie Code schreiben. Die meisten Dienste veröffentlichen ihre Limits klar und deutlich.
• Nutzung überwachen — Verfolgen Sie den X-RateLimit-Remaining-Header, um zu wissen, wie nah Sie am Limit sind.
• Anfragen bündeln — Nutzen Sie Bulk-Endpunkte, wenn verfügbar, statt einzelne Aufrufe zu senden.
• Anfragen verteilen — Verteilen Sie API-Aufrufe gleichmäßig über die Zeit, anstatt sie gebündelt zu senden.
• API-Schlüssel verwenden — Authentifizierte Anfragen erhalten in der Regel höhere Rate Limits als anonyme.
• Circuit Breaker implementieren — Wenn Sie wiederholt 429-Fehler erhalten, stoppen Sie die Anfragen komplett für eine Abkühlphase.
• Mit Rate-Limit-Simulatoren testen — Simulieren Sie 429-Antworten in der Entwicklungsumgebung, um sicherzustellen, dass Ihre Fehlerbehandlung funktioniert.
• 429-Antworten protokollieren — Verfolgen Sie, wann und wo Rate Limiting auftritt, um Ihre Anfragemuster zu optimieren.