Wie man den 429 Too Many Requests-Fehler behebt

Der 429 Too Many Requests-Fehler ist ein HTTP-Statuscode, der in RFC 6585 definiert ist und signalisiert, dass ein Client das vom Server oder einem zwischengeschalteten Proxy festgelegte Rate-Limit überschritten hat. Der Server verweigert weitere Anfragen, bis das Rate-Limiting-Fenster zurückgesetzt wird, und gibt optional einen Retry-After-Header zurück, der angibt, wie lange der Client warten muss.

Im Gegensatz zu einem 503 Service Unavailable, der einen serverseitigen Kapazitätsausfall widerspiegelt, ist ein 429 eine bewusste, richtliniengesteuerte Ablehnung. Diesen Unterschied zu verstehen ist entscheidend: Die Lösung besteht nicht immer darin, die Infrastruktur zu skalieren – es geht darum zu identifizieren, *wer* zu viele Anfragen sendet, *warum*, und dann das Verhalten auf der richtigen Ebene des Stacks zu korrigieren.

Was tatsächlich einen 429-Fehler verursacht

Der Fehler tritt auf mehreren Ebenen auf, und ihre Verwechslung führt zu Fehldiagnosen. Die Grundursache fällt in eine von vier Kategorien:

• Serverseitiges Rate-Limiting — Webserver (Apache, Nginx), Reverse-Proxies (HAProxy, Varnish) oder CDN-Edge-Nodes (Cloudflare, Fastly) erzwingen Pro-IP- oder Pro-Token-Anfragegrenzen.
• Drosselung auf Anwendungsebene — WordPress-Plugins, benutzerdefinierte Middleware oder API-Gateways setzen eigene Limits unabhängig vom Webserver durch.
• Erschöpfung von Drittanbieter-API-Kontingenten — Ihre Anwendung ruft eine externe API (Google Maps, Stripe, OpenAI) schneller auf, als das Kontingent des Anbieters erlaubt, und der 429 wird an den Endbenutzer weitergeleitet.
• Bösartiger oder unkontrollierter automatisierter Traffic — Brute-Force-Anmeldeversuche, aggressive Scraper, falsch konfigurierte Monitoring-Skripte oder schlecht geschriebene Crawler erschöpfen Anfragebudgets.

Ein häufig übersehener Sonderfall: Shared-Hosting-Umgebungen, in denen der Traffic-Spike eines benachbarten Mieters gemeinsam genutzte Verbindungspools verbraucht und dazu führt, dass Ihre Anwendung 429-Antworten von einem vorgelagerten Load-Balancer erhält, obwohl Ihr eigener Code einwandfrei funktioniert. Wenn Sie einen Shared Web Hosting-Plan nutzen und sporadische 429-Bursts ohne entsprechenden Anstieg in Ihrem eigenen Traffic beobachten, ist dies die erste Hypothese, die Sie testen sollten.

Schritt 1: Quelle der übermäßigen Anfragen identifizieren

Einen 429-Fehler zu beheben, ohne seinen Ursprung zu kennen, ist Raterei. Beginnen Sie mit den Daten.

Apache-Zugriffsprotokolle lesen

grep " 429 " /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Dieser Befehl extrahiert jede 429-Antwort, zählt Vorkommen pro IP-Adresse und ordnet sie nach Rang. Eine IP, die innerhalb von Minuten tausende Male erscheint, ist entweder ein Bot, ein falsch konfiguriertes Skript oder ein Angreifer.

Nginx-Zugriffsprotokolle lesen

awk '$9 == 429 {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Mit Anfragepfaden korrelieren

grep " 429 " /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Wenn /wp-login.php oder /xmlrpc.php die Ausgabe dominiert, haben Sie es mit einer Brute-Force- oder Credential-Stuffing-Kampagne zu tun. Wenn ein API-Endpunkt wie /api/v1/search die Liste anführt, ist der Verursacher wahrscheinlich ein falsch konfigurierter Client oder ein Scraper.

fail2ban zur Mustererkennung verwenden

fail2ban-client status
fail2ban-client status nginx-req-limit

Wenn fail2ban mit einem nginx-req-limit-Jail konfiguriert ist, zeigt es Ihnen genau, welche IPs aufgrund von Rate-Limit-Verstößen gesperrt wurden, was erhebliche Log-Analyse-Zeit spart.

Schritt 2: Rate-Limiting auf Webserver-Ebene konfigurieren

Apache: mod_ratelimit und mod_evasive verwenden

Das häufig im Internet verbreitete .htaccess-Snippet verwendet mod_rewrite, um einen 403 zurückzugeben, keinen korrekten 429. Ein semantisch korrekterer und betrieblich soliderer Ansatz verwendet mod_evasive zur DoS-Abwehr.

mod_evasive auf Debian/Ubuntu installieren und konfigurieren:

apt install libapache2-mod-evasive
a2enmod evasive

Dann zu Ihrem Apache-Virtual-Host oder der globalen Konfiguration hinzufügen:

<IfModule mod_evasive20.c>
    DOSHashTableSize    3097
    DOSPageCount        5
    DOSSiteCount        50
    DOSPageInterval     1
    DOSSiteInterval     1
    DOSBlockingPeriod   10
    DOSEmailNotify      admin@yourdomain.com
    DOSLogDir           /var/log/mod_evasive
</IfModule>

Dies sperrt jede IP, die dieselbe Seite mehr als 5 Mal pro Sekunde oder die gesamte Website mehr als 50 Mal pro Sekunde aufruft, für eine 10-sekündige Abkühlphase.

Für eine korrekte 429-Antwort über .htaccess auf Apache mit mod_rewrite benötigen Sie ein benutzerdefiniertes Fehlerdokument:

ErrorDocument 429 "Too Many Requests"

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP_USER_AGENT} ^.*(SemrushBot|AhrefsBot|MJ12bot|DotBot).*$ [NC]
    RewriteRule .* - [R=429,L]
</IfModule>

Nginx: limit_req_zone mit korrekter Burst-Behandlung

Nginxs ngx_http_limit_req_module ist eines der effektivsten verfügbaren Rate-Limiting-Tools. Die Parameter, die häufig falsch konfiguriert werden, sind burst und nodelay.

In /etc/nginx/nginx.conf oder einer dedizierten Include-Datei:

http {
    # Zone keyed by client IP, 10MB shared memory, 10 requests/second baseline
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;

    # Return 429 instead of the default 503
    limit_req_status 429;

    server {
        location /api/ {
            limit_req zone=api_limit burst=20 nodelay;
        }

        location /wp-login.php {
            limit_req zone=login_limit burst=3 nodelay;
        }
    }
}

Wichtige Nuance: Ohne limit_req_status 429 gibt Nginx standardmäßig einen 503 für rate-limitierte Anfragen zurück. Es auf 429 zu setzen ist semantisch korrekt und ermöglicht Clients, eine ordnungsgemäße Retry-After-Backoff-Logik zu implementieren.

nodelay vs. kein Flag:

• Ohne nodelay: Überschüssige Anfragen werden in die Warteschlange gestellt und mit zusätzlicher Verzögerung bedient, was Worker-Verbindungen verbraucht.
• Mit nodelay: Überschüssige Anfragen jenseits des Bursts werden sofort mit einem 429 abgelehnt, was Ressourcen schneller freigibt. Verwenden Sie nodelay für Login-Endpunkte und öffentliche APIs.

Einen Retry-After-Header hinzufügen

Clients, die RFC 6585 respektieren, werden einen Retry-After-Header berücksichtigen. In Nginx fügen Sie ihn zur Fehlerantwort hinzu:

location /api/ {
    limit_req zone=api_limit burst=20 nodelay;
    add_header Retry-After 60 always;
}

Schritt 3: WordPress-Plugin-Konflikte diagnostizieren und beheben

WordPress ist eine häufige Quelle selbst verursachter 429-Fehler. Plugins, die bei jedem Seitenaufruf externe APIs abfragen – SEO-Tools, die Keyword-Daten abrufen, Analytics-Plugins, die nach Hause telefonieren, oder WooCommerce-Erweiterungen, die Payment-Gateways abfragen – können Rate-Limits schnell erschöpfen.

Systematisches Isolationsverfahren:

1. Alle Plugins über das WordPress-Dashboard deaktivieren oder, falls das Dashboard nicht zugänglich ist, über WP-CLI:

wp plugin deactivate --all

1. Plugins einzeln reaktivieren und nach jeder Aktivierung testen:

wp plugin activate plugin-slug

1. Das Zugriffsprotokoll in einem separaten Terminal während der Reaktivierung überwachen:

tail -f /var/log/nginx/access.log | grep " 429 "

1. Sobald das problematische Plugin identifiziert wurde, dessen Einstellungen auf API-Abfrageintervalle oder Anfragehäufigkeitsoptionen prüfen, bevor es dauerhaft deaktiviert wird.

Häufige Verursacher: Jetpack (Stats- und Sync-Module), Yoast SEO (wenn mit MyYoast verbunden), WooCommerce Subscriptions und jedes Plugin, das WordPress’ eingebautes wp_remote_get() in einer Schleife ohne Transient-Caching verwendet.

Die richtige Lösung besteht fast nie darin, das Plugin zu entfernen – sondern sicherzustellen, dass API-Antworten mithilfe von WordPress-Transients gecacht werden:

$cached = get_transient( 'my_api_response' );
if ( false === $cached ) {
    $response = wp_remote_get( 'https://api.example.com/data' );
    set_transient( 'my_api_response', $response, HOUR_IN_SECONDS );
    $cached = $response;
}

Schritt 4: API-Anfragen-Drosselung im Anwendungscode implementieren

Wenn Ihre Anwendung der *Client* ist, der eine Drittanbieter-API aufruft, sind Sie dafür verantwortlich, deren Rate-Limits zu respektieren. Sich darauf zu verlassen, 429-Antworten reaktiv abzufangen, ist schlechtes Engineering – implementieren Sie proaktive Drosselung.

Node.js mit p-throttle

import pThrottle from 'p-throttle';

const throttle = pThrottle({
    limit: 10,       // max 10 calls
    interval: 1000   // per 1000ms (1 second)
});

const throttledFetch = throttle(async (url) => {
    const response = await fetch(url);
    return response.json();
});

Python mit tenacity für exponentiellen Backoff

Drosselung allein ist unzureichend, wenn die API Burst-Limits auferlegt. Kombinieren Sie Drosselung mit exponentiellem Backoff bei 429-Antworten:

import requests
from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception

def is_rate_limited(exception):
    return (
        isinstance(exception, requests.HTTPError)
        and exception.response.status_code == 429
    )

@retry(
    retry=retry_if_exception(is_rate_limited),
    wait=wait_exponential(multiplier=1, min=2, max=60),
    stop=stop_after_attempt(5)
)
def call_api(url):
    response = requests.get(url)
    response.raise_for_status()
    return response.json()

Dies wiederholt bis zu 5 Mal mit exponentiellem Backoff (2s, 4s, 8s, 16s, 32s), begrenzt auf 60 Sekunden – ein Muster, das die Infrastruktur des API-Anbieters respektiert und gleichzeitig eine elegante Wiederherstellung ermöglicht.

Den Retry-After-Header respektieren

Wenn die API einen Retry-After-Header zurückgibt, verwenden Sie ihn anstelle eines festen Backoffs:

def call_with_retry_after(url):
    response = requests.get(url)
    if response.status_code == 429:
        retry_after = int(response.headers.get("Retry-After", 5))
        time.sleep(retry_after)
        return call_with_retry_after(url)
    response.raise_for_status()
    return response.json()

Schritt 5: Bots auf mehreren Ebenen blockieren und verwalten

Bots kündigen sich selten ehrlich an, hinterlassen aber Fingerabdrücke in User-Agent-Strings, Anfrage-Mustern und Header-Anomalien.

Bekannte schädliche Bots in Nginx blockieren

map $http_user_agent $bad_bot {
    default         0;
    ~*SemrushBot    1;
    ~*AhrefsBot     1;
    ~*MJ12bot       1;
    ~*DotBot        1;
    ~*PetalBot      1;
    ~*serpstatbot   1;
}

server {
    if ($bad_bot) {
        return 429;
    }
}

Crawl-Rate über robots.txt verwalten

User-agent: Googlebot
Crawl-delay: 2

User-agent: *
Crawl-delay: 10

Beachten Sie, dass Crawl-delay nicht von allen Crawlern berücksichtigt wird, aber die Absicht signalisiert und von Bing, Yandex und den meisten wohlverhaltenen Bots respektiert wird.

Web Application Firewall (WAF)-Integration

Eine WAF, die am CDN-Edge betrieben wird (Cloudflare, AWS WAF, Sucuri), kann Rate-Limits durchsetzen, bevor Traffic Ihren Ursprungsserver erreicht, was die Last erheblich reduziert. Cloudflares Rate-Limiting-Regeln können beispielsweise so konfiguriert werden, dass IPs, die einen Schwellenwert überschreiten, ohne Änderungen an Ihrer Ursprungsserver-Konfiguration herausgefordert oder blockiert werden – ein erheblicher betrieblicher Vorteil für stark frequentierte Websites.

Schritt 6: Sicherheits-Plugin-Einstellungen in WordPress anpassen

Wenn Sie Wordfence verwenden, sind die Rate-Limiting-Schwellenwerte oft konservativ eingestellt und können falsch-positive Ergebnisse für legitime Benutzer auslösen, insbesondere auf Websites mit starker AJAX-Nutzung oder Aktivitäten eingeloggter Benutzer.

Navigieren Sie zu Wordfence > Firewall > All Firewall Options > Rate Limiting und überprüfen Sie:

• How should we treat Google’s crawlers — auf „Verified Google crawlers are not rate limited” setzen, um SEO-Auswirkungen zu verhindern.
• If anyone’s requests exceed — den Schwellenwert vom Standardwert erhöhen (z. B. von 240 auf 480 Anfragen pro Minute für eingeloggte Benutzer auf inhaltsreichen Websites).
• If a crawler’s page views exceed — basierend auf Ihren tatsächlichen Crawl-Budget-Anforderungen anpassen.

Nach der Anpassung die Wordfence-Live-Traffic-Ansicht 24–48 Stunden lang überwachen, um zu bestätigen, dass legitime Benutzer nicht mehr blockiert werden.

Schritt 7: Client-seitigen Cache leeren und Probleme auf Browser-Ebene diagnostizieren

Eine gecachte 429-Antwort im Browser ist selten, aber möglich, wenn die Antwort Cache-Control: max-age-Header enthielt (eine Server-Fehlkonfiguration). Standard-429-Antworten sollten nicht gecacht werden.

Chrome:

Settings > Privacy and Security > Clear browsing data

Wählen Sie Cached images and files und Cookies and other site data aus und löschen Sie diese.

Überprüfen Sie die Antwort-Header direkt mit curl, um browserspezifisches Verhalten auszuschließen:

curl -I -X GET https://yourdomain.com/problematic-endpoint

Suchen Sie nach Cache-Control-, Retry-After– und X-RateLimit-*-Headern in der Antwort. Diese Header zeigen genau, welche Ebene das Limit durchsetzt und wann der Client einen erneuten Versuch unternehmen kann.

Vergleich: Rate-Limiting-Ansätze nach Ebene

Wann Sie Ihren Hosting-Anbieter kontaktieren sollten

Eskalieren Sie zu Ihrem Hosting-Anbieter, wenn:

• Der 429 von einem vorgelagerten Load-Balancer oder Reverse-Proxy stammt, den Sie nicht kontrollieren.
• Die Log-Analyse zeigt, dass Ihre Anwendung gut innerhalb der erwarteten Anfragevolumen liegt, der Fehler aber weiterhin besteht.
• Sie eine vorübergehende Rate-Limit-Ausnahme während eines geplanten Traffic-Spikes benötigen (Produkteinführung, Marketingkampagne).
• Der Fehler nur in bestimmten geografischen Regionen auftritt, was auf CDN- oder Anycast-Routing-Probleme hindeutet.

Bei einem VPS Hosting-Plan haben Sie direkten Zugriff auf Server-Konfigurationsdateien und können alle oben beschriebenen Nginx- und Apache-Änderungen vornehmen, ohne ein Support-Ticket zu öffnen. Bei verwalteter Infrastruktur wie Dedicated Servers kann das Support-Team Ihres Anbieters bei Verbindungsverfolgung auf Kernel-Ebene und Hardware-Firewall-Regeln helfen, die über das hinausgehen, was die Konfiguration auf Anwendungsebene erreichen kann.

Wenn Ihr Stack ein Control-Panel enthält, bietet VPS mit cPanel ModSecurity- und Apache-Rate-Limiting-Einstellungen über eine GUI, was die Konfiguration für Teams ohne tiefe Kommandozeilen-Kenntnisse vereinfacht.

API-Endpunkte mit SSL absichern

Ein häufig übersehener Faktor: Unverschlüsselte HTTP-Endpunkte sind anfälliger für Replay-Angriffe und Credential-Stuffing, die Brute-Force-bedingte 429-Fehler verursachen. Die Durchsetzung von HTTPS mit einem gültigen SSL-Zertifikat stellt sicher, dass Authentifizierungstoken und Session-Cookies nicht von automatisierten Tools abgefangen und wiedergegeben werden können, was eine Kategorie von Rate-Limit-auslösendem Traffic an der Quelle reduziert.

Technische Entscheidungsmatrix: Die richtige Lösung wählen

Verwenden Sie diese Checkliste, um Ihre Diagnose zur richtigen Lösung zu führen:

• 429 auf /wp-login.php oder /xmlrpc.php — Nginx limit_req für diese Pfade absichern, xmlrpc.php vollständig blockieren, wenn nicht benötigt, Wordfence-Brute-Force-Schutz aktivieren.
• 429 auf API-Endpunkten aus Ihrem eigenen Anwendungscode — Exponentiellen Backoff mit Retry-After-Header-Parsing implementieren; Transient/Redis-Caching hinzufügen, um die Häufigkeit ausgehender Aufrufe zu reduzieren.
• 429 betrifft alle Benutzer sporadisch auf Shared Hosting — Zu einem VPS für isolierte Ressourcen und konfigurierbare Rate-Limits migrieren.
• 429 von einer Drittanbieter-API, die Ihre App nutzt — Aufrufhäufigkeit prüfen, Request-Queuing implementieren, Antworten aggressiv cachen und den API-Anbieter wegen Kontingenterhöhungen kontaktieren.
• 429 durch einen bestimmten Bot oder Crawler verursacht — Auf WAF- oder Nginx-map-Ebene nach User-Agent blockieren; legitime Crawler (Googlebot) per Reverse-DNS verifizieren, bevor sie blockiert werden.
• 429 erscheint nur im Browser, nicht in curl — Browser-Cache leeren; auf einen Service-Worker prüfen, der die Fehlerantwort cached; Cache-Control-Header der 429-Antwort untersuchen.
• 429 ohne erkennbares Muster in den Logs — Vorgelagerte CDN- oder Load-Balancer-Logs prüfen; das Limit wird möglicherweise auf einer Infrastrukturebene durchgesetzt, die in den Anwendungs-Logs nicht sichtbar ist.

FAQ

Was ist der Unterschied zwischen einem 429- und einem 503-Fehler?

Ein 429 ist eine bewusste, richtliniengesteuerte Ablehnung, die ausgegeben wird, wenn ein Client eine definierte Anfragerate überschreitet. Ein 503 zeigt an, dass der Server aufgrund von Überlastung oder Wartung vorübergehend keine Anfragen bearbeiten kann. Die Lösung für einen 429 ist die Anpassung des Rate-Limits oder die Korrektur des Client-Verhaltens; die Lösung für einen 503 ist Kapazitätsskalierung oder Service-Wiederherstellung.

Sollte ich Rate-Limits immer erhöhen, wenn ich einen 429 sehe?

Nein. Das Erhöhen von Limits ist nur dann angemessen, wenn legitimer Traffic blockiert wird. Wenn der 429 durch Bots, Brute-Force-Versuche oder ein falsch konfiguriertes Skript verursacht wird, verschlimmert das Erhöhen des Limits das Problem, indem mehr schädlicher Traffic durchgelassen wird. Identifizieren Sie immer zuerst die Quelle.

Was bewirkt der Retry-After-Header und sollte ich ihn immer einschließen?

Der Retry-After-Header teilt dem Client mit, wie viele Sekunden er vor einem erneuten Versuch warten soll. RFC 6585 empfiehlt, ihn bei jeder 429-Antwort einzuschließen. Wohlverhaltene HTTP-Clients und API-Konsumenten werden ihn berücksichtigen, was Retry-Stürme reduziert, die das ursprüngliche Rate-Limiting-Problem verschlimmern.

Kann ein 429-Fehler mein SEO beeinträchtigen?

Ja, wenn Googlebot konsistent 429-Antworten erhält, wird es die Crawl-Frequenz für Ihre Website reduzieren, was die Indexierung neuer oder aktualisierter Inhalte verzögern kann. Wordfence und ähnliche Plugins sollten so konfiguriert werden, dass verifizierte Google-Crawler vom Rate-Limiting ausgenommen sind. Überwachen Sie den Crawl-Stats-Bericht der Google Search Console auf Spitzen bei Server-Fehlern.

Wie verhindere ich, dass meine eigene Anwendung 429-Fehler bei externen APIs auslöst?

Implementieren Sie eine Kombination aus proaktiver Drosselung (ausgehende Anfragerate unter den dokumentierten Schwellenwert der API begrenzen), aggressivem Antwort-Caching (API-Ergebnisse in Redis oder Memcached mit angemessenen TTLs speichern) und reaktivem exponentiellem Backoff (Retry-After-Header parsen und entsprechend zurückweichen). Machen Sie niemals API-Aufrufe synchron bei jedem Seitenaufruf ohne eine vorgelagerte Caching-Schicht.