Fehlercode 400 Bad Request: Bedeutung und Lösungen

Sie öffnen einen Link aus einer E-Mail oder eine Website, die Sie jeden Tag nutzen, und sehen einen weißen Bildschirm mit „400 Bad Request“ in fetter Schrift. Manchmal steht darunter eine zweite Zeile mit mehr Details, etwa „Request Header Or Cookie Too Large“, und ganz unten „nginx“. Chrome zeigt stattdessen manchmal eine eigene graue Seite: „Diese Seite funktioniert nicht“ und HTTP ERROR 400. Entwickler bekommen dieselbe Zahl von einer API, meist mit einer kurzen JSON-Meldung.

All das bedeutet: Der Server hat eine Anfrage erhalten, die er nicht annehmen wollte. Im Folgenden: was der Code bedeutet, wer die Seite geschickt hat, Ursachen und Lösungen für Besucher, wie sich 400 von 401, 403, 404 und 413 unterscheidet und was Entwickler prüfen sollten, mit einem nachgestellten Beispiel.

Was bedeutet 400 Bad Request?#

400 Bad Request bedeutet, dass der Server sich weigert, eine Anfrage zu verarbeiten, weil er die Anfrage selbst für fehlerhaft hält. Der HTTP-Standard RFC 9110 nennt drei Beispiele: eine fehlerhafte Anfragesyntax, eine ungültige Nachrichtenrahmung (falsche Angaben dazu, wo eine Nachricht beginnt und endet) und ein irreführendes Anfrage-Routing. Einfach gesagt: Die Adresse, die Header oder die Daten haben gegen die Regeln verstoßen, nach denen der Server arbeitet.

Codes im 400er-Bereich beschreiben Probleme auf der Seite der Anfrage, doch „Client-Fehler“ heißt nicht immer, dass Sie etwas falsch gemacht haben: Ein Cookie, das die Website selbst gesetzt hat, kann die Anfragen Ihres Browsers zu groß machen. Aus der Definition folgt eine Regel. Wie die MDN-Referenz festhält, scheitert eine unverändert wiederholte Anfrage mit demselben Fehler; Neuladen hilft also nicht, die Anfrage zu ändern dagegen schon.

Wer hat die 400-Seite geschickt, die Sie sehen?#

Die zweite Zeile der Seite und der Name ganz unten verraten, welches Programm die Anfrage abgelehnt hat, und oft auch, warum.

Die Chrome-Zeile haben wir mit einem kleinen Testserver auf unserem eigenen Computer geprüft, der mit 400 und leerem Inhalt antwortet, geöffnet in Chromium 145: In der deutschen Oberfläche erscheinen genau diese Zeilen und eine Schaltfläche Neu laden. Chrome schreibt diesen Text selbst, deshalb sagt er nichts über die Ursache.

Wie entsteht ein 400, Schritt für Schritt?#

Eine Anfrage hat drei Teile, und der Server prüft sie der Reihe nach:

1. Die Anfragezeile. Methode und Adresse, etwa GET /search?q=shoes. Sonderzeichen werden als % mit zwei Hexadezimalziffern übertragen (Prozentkodierung); ein % ohne diese beiden Ziffern lässt sich nicht dekodieren.
2. Die Header. Zeilen wie Host und User-Agent, dazu Cookie, das alle Cookies trägt, die der Browser für diese Website gespeichert hat. Server begrenzen jede Headerzeile: bei nginx standardmäßig auf 8 KB, bei Apache auf 8.190 Byte.
3. Der Body. Der Inhalt der Anfrage, also Formular- oder API-Daten, oft JSON, deren Format und Pflichtfelder die Anwendung prüft.
4. Das Urteil. Die erste Prüfung, die scheitert, beendet die Anfrage mit 400, meist mit einer kurzen Begründung.
5. Die Wiederholung. Nichts hat sich geändert, also schickt der nächste Versuch dieselbe Adresse, dieselben Cookies und dieselben Daten und bekommt denselben 400.

Was unterscheidet 400 von 401, 403, 404 und 413?#

400 ist der allgemeine Code; passt ein spezifischerer, senden Server diesen. Ein 401 bedeutet, dass der Server die Anfrage lesen konnte, aber wissen will, wer sie geschickt hat; darum geht es in Fehlercode 401 Unauthorized: Bedeutung und Lösungen. Ein zu großer Upload bekommt normalerweise 413 (nginx nimmt standardmäßig 1 MB Anfrageinhalt an), manche Anwendungen antworten aber mit 400.

Warum bekomme ich den Fehler 400 Bad Request?#

Aus Sicht des Besuchers sind das die üblichen Ursachen:

• Eine vertippte oder beschädigte Adresse. Links, die aus E-Mails und Chat-Apps kopiert werden, werden abgeschnitten oder bekommen überzählige Zeichen; ein % ohne zwei Hexadezimalziffern dahinter, wie in 50%off, lässt sich nicht dekodieren.
• Zu viele oder zu große Cookies für diese Website, die Ursache hinter „Request Header Or Cookie Too Large“.
• Ein beschädigtes oder veraltetes Cookie. Nachdem eine Website ihr Anmeldesystem umgestellt hat, kann ein altes Cookie einen Wert tragen, den der neue Code nicht lesen kann.
• Eine Erweiterung, die Anfragen umschreibt, etwa eine, die Header oder Cookies bearbeitet.
• Etwas dazwischen, selten: Sicherheitssoftware, die den Webverkehr prüft, oder ein Proxy, der mit dem falschen Schema oder Port eingerichtet ist.

Was bedeutet „Request Header Or Cookie Too Large“?#

Es bedeutet, dass die Cookies, die Ihr Browser für diese Website speichert, zusammen mit den übrigen Headern nicht mehr in die Größenbegrenzung des Servers passen; deshalb lehnt nginx die Anfrage mit 400 ab. Ihr Browser schickt bei jeder Anfrage alle Cookies einer Website in einem einzigen Cookie-Header, und nginx lehnt jede Headerzeile ab, die größer als ein Puffer ist, standardmäßig 8 KB, wie die Dokumentation zu large_client_header_buffers erklärt.

Die Grenzen beider Seiten passen nicht zusammen. Der Cookie-Standard RFC 6265 verlangt von Browsern, mindestens 4.096 Byte pro Cookie und mindestens 50 Cookies pro Domain zu speichern, zusammen weit mehr als 8 KB. Eine Website mit vielen Analyse- und Sitzungscookies kann die Grenze nach Wochen normaler Nutzung überschreiten, und der Fehler trifft dann nur diese eine Website, weil nur ihre Cookies mit ihren Anfragen mitgeschickt werden.

IIS formuliert es als „HTTP 400 - Bad Request (Request header too long)“, und manche Server senden den spezifischeren Code 431. Die Lösung auf Ihrer Seite ist dieselbe: Löschen Sie die Cookies dieser Website.

Wie beheben Sie einen 400-Fehler als Besucher?#

Gehen Sie die Punkte der Reihe nach durch; die ersten drei dauern eine Minute.

1. Adresse prüfen. Tippen Sie sie neu ein, oder öffnen Sie die Startseite der Website und navigieren Sie von dort aus. Einen langen Link aus einer E-Mail probieren Sie ohne den Teil nach dem ?.
2. Nur die Cookies dieser Website löschen. Damit werden Sie nur bei dieser einen Website abgemeldet; die anderen bleiben unberührt.
   • Chrome: Dreipunkt-Menü > Einstellungen > Datenschutz und Sicherheit > Drittanbieter-Cookies > Alle Websitedaten und -berechtigungen ansehen, nach der Website suchen, Löschen wählen und bestätigen (die Anleitung von Google).
   • Edge: Einstellungen und mehr > Einstellungen > Datenschutz, Suche und Dienste > Cookies > Alle Cookies und Websitedaten anzeigen, nach der Website suchen, den Abwärtspfeil daneben öffnen und das Symbol zum Löschen wählen.
   • Firefox: Klicken Sie auf der Website auf das Schild-Symbol links neben der Adressleiste und wählen Sie Cookies und Website-Daten löschen…
   • Safari auf dem Mac: Safari > Einstellungen > Datenschutz > Websitedaten verwalten, die Website auswählen und auf Entfernen klicken.
3. Ein privates Fenster probieren. In Chrome Dreipunkt-Menü > Neues Inkognitofenster oder Strg + Umschalttaste + N. Es startet ohne die Cookies der Website, und Erweiterungen bleiben aus, sofern Sie sie dort nicht zugelassen haben. Öffnet sich die Seite, war ein Cookie oder eine Erweiterung die Ursache.
4. Erweiterungen einzeln ausschalten, in Chrome unter Dreipunkt-Menü > Erweiterungen > Erweiterungen verwalten, zuerst die, die Inhalte blockieren oder Anfragen bearbeiten.
5. Den Upload verkleinern, wenn der Fehler beim Senden einer Datei erscheint.
6. Ohne VPN oder Proxy probieren, oder über mobile Daten. Lädt die Seite dann, verändert etwas im ersten Netz Ihre Anfragen.
7. Die Website kontaktieren, mit der Adresse, der Uhrzeit und dem, worauf Sie geklickt haben. Kommt der Fehler Tage nach dem Löschen der Cookies zurück, setzt die Website mehr Cookies, als ihr eigener Server annimmt.

Den DNS-Cache zu leeren oder den Router neu zu starten, hilft selten: Wenn ein Server mit 400 antwortet, hat Ihr Computer ihn längst gefunden.

Was sollten Entwickler prüfen, wenn ihr Code einen 400 bekommt?#

Im Code bedeutet ein 400, dass der Server die Anfrage abgelehnt hat, die Ihr Programm gebaut hat, und der Antworttext nennt meist das Feld oder die Regel. Protokollieren Sie den Antworttext, bevor Sie etwas ändern. Die üblichen Ursachen:

• Ungültiges JSON: ein Komma am Ende, einfache Anführungszeichen, ein von Hand zusammengesetzter String. Nutzen Sie den Encoder Ihrer Sprache, etwa JSON.stringify oder json.dumps.
• Ein Content-Type, der nicht zum Body passt, etwa JSON, das mit einem Formulartyp gesendet wird.
• Fehlende oder falsche Parameter: ein ausgelassenes Pflichtfeld, eine als Text gesendete Zahl, ein Datum im falschen Format.
• Von Hand gebaute Query-Strings. Leerzeichen, & und % in Werten müssen kodiert werden; URLSearchParams oder urllib.parse.urlencode erledigen das für Sie.
• Header, die der Server nicht annimmt. Ein großes Cookie oder ein langes Token kann das Limit pro Header überschreiten: 8 KB bei nginx, LimitRequestFieldSize bei Apache, MaxFieldLength bei IIS. HTTP/1.1 verlangt außerdem einen 400 bei fehlendem oder doppeltem Host-Header.
• HTTP/1.1-Gewohnheiten in HTTP/2. HTTP/2 verlangt kleingeschriebene Headernamen und verbietet Verbindungs-Header wie Connection und Keep-Alive; der Server setzt eine solche Anfrage zurück oder antwortet mit 400. Das passiert, wenn Code oder ein Proxy HTTP/1.1-Header in HTTP/2 übernimmt.

Ein 400 wegen ungültigem JSON, nachgestellt#

Wir haben auf unserem eigenen Computer einen kleinen Node.js-Server laufen lassen, der mit 400 antwortet, wenn der Body einer Bestellung kein gültiges JSON ist, und dann mit curl -i (-i gibt Statuszeile und Header aus) eine Anfrage mit einem Komma am Ende des Bodys gesendet:

curl -i http://127.0.0.1:18400/api/orders -H "Content-Type: application/json" -d '{"product": "sku-123", "qty": 2,}'

Die Ausgabe (curl 8.22 unter Windows 11, Node.js 24):

HTTP/1.1 400 Bad Request
Content-Type: application/json
Date: Thu, 12 Nov 2026 01:21:06 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Transfer-Encoding: chunked

{"error":"invalid JSON","detail":"Expected double-quoted property name in JSON at position 32 (line 1 column 33)"}

position 32 in der Meldung ist das Zeichen } direkt nach dem Komma: JSON erlaubt kein Komma vor einer schließenden geschweiften Klammer. Entfernen Sie das Komma, und der Body ist gültig. Eine echte API formuliert ihre Meldung anders, aber das Muster bleibt: Die Statuszeile sagt, dass die Anfrage falsch ist, der Antworttext sagt, wo.

Was ändert sich hinter einem Proxy?#

Nichts an der Anfrage, wenn der Proxy richtig eingerichtet ist. Bei einer https://-Adresse bittet der Client den Proxy mit einer CONNECT-Anfrage, einen Tunnel zu öffnen, und der Proxy reicht die Bytes in beide Richtungen weiter, ohne sie zu lesen; ein 400, der zurückkommt, ist also das Urteil der Website. Ein typischer Einrichtungsfehler ist ein Schema, das nicht zum Port passt: Eine einfache http://-Anfrage an einen Port, der HTTPS erwartet, bekommt von nginx „The plain HTTP request was sent to HTTPS port“. Bei einem HTTPS-Proxy übernehmen Sie Host, Port und Schema genau so, wie der Endpoint-Generator sie anzeigt.

Wie sollte ein Scraper mit einem 400 umgehen?#

Als Fehler in der eigenen Anfrage, nicht als Sperre. Unverändert wiederholt, bringt die Anfrage denselben 400, und auch ein Residential-Proxy mit seinem Adresspool ändert nur die Adresse, die die Website sieht, nicht die Anfrage, die Ihr Code sendet. Halten Sie an, protokollieren Sie Anfrage und Antworttext und beheben Sie, was dort steht.

Andere Codes verdienen dagegen einen neuen Versuch, etwa ein 503 nach einer Pause; HTTP-Statuscodes beim Web Scraping trennt diese von denen, die Stopp bedeuten.

Wo Ihnen ein 400 begegnen kann#

• Eine Website, die Sie täglich nutzen, zeigt plötzlich „Request Header Or Cookie Too Large“.
• Lange Links aus E-Mails, Chat-Apps und Newslettern, die unterwegs abgeschnitten werden.
• Upload-Formulare mit einer Größengrenze, die die Seite nicht nennt.
• Schaltflächen zur Anmeldung mit einem Google-Konto in falsch eingerichteten Apps, mit dem Code „Error 400“.
• API-Aufrufe aus Skripten, Postman und No-Code-Tools, nachdem sich der Name oder Typ eines Feldes geändert hat.

Häufige Fehler#

• Alle Browserdaten löschen. Damit werden Sie auf jeder Website abgemeldet; es kommt nur auf die Cookies der Website an, die den Fehler zeigt.
• Immer wieder neu laden. Die Anfrage ändert sich nicht, also auch die Antwort nicht.
• Der Verbindung die Schuld geben. Ein 400 heißt, dass die Anfrage angekommen ist.
• Entwickler: einen 400 in einer Schleife wiederholen oder dafür IP-Adressen rotieren und den Statuscode ohne Antworttext protokollieren.
• Betreiber: Header-Limits anheben, statt Cookies zu reduzieren. Schon der Cookie-Standard rät Servern, Cookies wenige und klein zu halten.

Entscheidungshilfe#

Häufige Fragen#

Bin ich an einem 400-Fehler schuld oder die Website?#

Beides ist möglich; der Code sagt nur, dass die Anfrage fehlerhaft war. Ein Tippfehler oder eine Erweiterung liegt auf Ihrer Seite, ein zu großes Cookie hat die Website selbst gesetzt, und ein 400 von einer API ist ein Fehler im aufrufenden Code.

Warum bekomme ich 400 Bad Request nur auf einer Website?#

Weil die Ursache meist in den Cookies oder Limits dieser Website liegt: Jede Website bekommt nur ihre eigenen Cookies und legt ihre eigenen Größengrenzen fest. Löschen Sie die Cookies dieser Website; zeigt auch ein privates Fenster denselben Fehler, muss die Website ihn beheben.

Kann ein VPN oder Proxy einen 400-Fehler verursachen?#

Selten. Ein VPN und ein Proxy, der HTTPS tunnelt, reichen Ihre Anfrage unverändert weiter, der 400 kommt also von der Website. Erscheint der Fehler nur mit eingeschaltetem Proxy, prüfen Sie dessen Schema und Port; auch Sicherheitssoftware, die den Datenverkehr prüft, kann Header verändern.

Wie behebe ich 400 Bad Request auf dem iPhone oder unter Android?#

Unter Android öffnen Sie die Website in Chrome, tippen links in der Adressleiste auf Seiteninfo, dann auf Cookies und Websitedaten und neben den gespeicherten Daten auf Löschen. Auf dem iPhone probieren Sie zuerst einen privaten Tab; klappt es dort, entfernt Einstellungen > Apps > Safari > Erweitert > Website-Daten > Alle Websitedaten entfernen die Daten, meldet Sie aber auf allen Websites ab.

Warum bekomme ich in Postman 400 Bad Request?#

Meist liegt es am Body oder an seinem Typ. Ist der Body auf raw und JSON gestellt, fügt Postman den passenden Content-Type-Header hinzu, doch ein Header, den Sie selbst eingetragen haben, hat Vorrang. Prüfen Sie das JSON und die Pflichtparameter und lesen Sie dann den Antworttext.

Was bedeutet „Error 400: redirect_uri_mismatch“?#

Die Meldung erscheint, wenn eine App Sie zur Anmeldung zu Google schickt: Die Rücksprungadresse (Redirect-URI), die die App an Google übergeben hat, passt zu keiner Adresse, die für diese App registriert ist. Nur der Entwickler der App kann das beheben, in deren Google-Cloud-Einstellungen.

Fazit#

Ein 400 Bad Request bedeutet, dass der Server Ihre Anfrage erhalten und in dieser Form nicht angenommen hat. Als Besucher prüfen Sie die Adresse, löschen die Cookies dieser einen Website, probieren ein privates Fenster und schalten Erweiterungen aus. Als Entwickler lesen Sie den Antworttext, korrigieren JSON, Header oder Parameter und wiederholen einen 400 nie unverändert. Wenn Sie Proxys für Monitoring oder Datenerhebung brauchen, vergleichen Sie die Typen auf unserer Proxy-Seite.