{"id":30446,"date":"2026-03-12T11:49:00","date_gmt":"2026-03-12T10:49:00","guid":{"rendered":"https:\/\/contabo.com\/blog\/429-zu-viele-anfragen-ein-vollstaendiger-troubleshooting-guide\/"},"modified":"2026-05-06T11:52:48","modified_gmt":"2026-05-06T09:52:48","slug":"429-too-amyn-requests-ein-vollstaendiger-troubleshooting-guide","status":"publish","type":"post","link":"https:\/\/contabo.com\/blog\/de\/429-too-amyn-requests-ein-vollstaendiger-troubleshooting-guide\/","title":{"rendered":"429 Too Many Requests: Ein vollst\u00e4ndiger Troubleshooting-Guide"},"content":{"rendered":"\n
\"429<\/figure>\n\n\n\n

Dein Browser, dein Skript oder deine Anwendung hat ein Anfrage-Limit erreicht. Der Server hat in einem zu kurzen Zeitraum zu viele Anfragen von deiner Adresse registriert und die T\u00fcr zugemacht. Das ist die Meldung „429 Too Many Requests“ \u2013 kein Absturz, keine Fehlkonfiguration, sondern einfach eine harte Drosselung.<\/p>\n\n\n\n

Die L\u00f6sung h\u00e4ngt davon ab, auf welcher Seite des Problems du stehst. Besucher haben drei Optionen. Seiteninhaber haben vier weitere M\u00f6glichkeiten. Und wenn das \u00f6fter passiert, gibt es drei Pr\u00e4ventionsma\u00dfnahmen, die du jetzt umsetzen solltest.<\/p>\n\n\n\n

Was bedeutet „429 Too Many Requests“?<\/h2>\n\n\n\n

HTTP 429 ist eine Antwort zur Ratenbegrenzung. Der Server verfolgt, wie viele Anfragen ein Client pro Zeiteinheit stellt \u2013 pro Sekunde, Minute oder Stunde \u2013 und gibt bei \u00dcberschreitung den Fehler 429 anstatt der Inhalte aus.<\/p>\n\n\n\n

Das ist ein absichtlicher Mechanismus und keine Fehlfunktion. Server nutzen dies zum Schutz vor \u00dcberlastung, DDoS-Versuchen, Brute-Force-Angriffen auf Logins und Scrapern. APIs nutzen es, um eine faire Nutzung unter allen Clients zu erzwingen. Shared-Hosting-Plattformen verhindern damit, dass eine einzelne Website so viele Ressourcen verbraucht, dass andere auf demselben Server beeintr\u00e4chtigt werden.<\/p>\n\n\n\n

Wenn der Fehler 429 auftritt, enth\u00e4lt die Antwort oft einen „Retry-After“-Header, der dir genau sagt, wie lange du warten musst:<\/p>\n\n\n\n

HTTP\/1.1 429 Too Many Requests Retry-After: 3600<\/code><\/pre>\n\n\n\n
Diese 3600 steht f\u00fcr 3600 Sekunden \u2013 also eine Stunde. \u00dcberpr\u00fcfe zuerst die Antwort-Header, bevor du irgendetwas anderes unternimmst. Wenn dort ein „Retry-After“-Wert steht, ist das bereits die L\u00f6sung.<\/p>\n\n\n\n
Wie du „429 Too Many Requests“ als Besucher beheben kannst<\/h2>\n\n\n\n
L\u00f6sung 1 f\u00fcr Nutzer: Warten und erneut versuchen<\/h3>\n\n\n\n
Wenn du ein Limit erreichst, ist die einfachste L\u00f6sung auch die richtige: H\u00f6r auf, Anfragen zu senden, und warte kurz. Serverseitige Ratenbegrenzungen werden nach einem festen Zeitraum zur\u00fcckgesetzt \u2013 meistens dauert das zwischen 30 Sekunden und einer Stunde.<\/p>\n\n\n\n
Pr\u00fcfe den „Retry-After“-Header in der Fehlermeldung, falls die Website oder die API <\/a>diesen anzeigt. Dieser Header zeigt dir die exakte Anzahl an Sekunden an, bis das Limit zur\u00fcckgesetzt wird. Ein erneuter Versuch, bevor dieses Fenster geschlossen ist, wird den Z\u00e4hler nur wieder von vorne starten lassen.<\/p>\n\n\n\n
Falls kein solcher Header vorhanden ist, warte einfach ein paar Minuten, bevor du es noch einmal versuchst. Dr\u00fccke nicht st\u00e4ndig auf „Aktualisieren“ \u2013 genau das hat dich wahrscheinlich erst in die Ratenbegrenzung getrieben.<\/p>\n\n\n\n
L\u00f6sung 2 f\u00fcr Nutzer: Browser-Cache und Cookies leeren<\/h3>\n\n\n\n
Besch\u00e4digte oder veraltete Browserdaten k\u00f6nnen dazu f\u00fchren, dass dein Browser fehlerhafte oder wiederholte Anfragen sendet, die ein Ratenbegrenzungsmechanismus als verd\u00e4chtigen Traffic markiert. Das Leeren von Cache und Cookies erm\u00f6glicht dir einen sauberen Neustart.<\/p>\n\n\n\n
In Google Chrome:<\/p>\n\n\n\n