400 Bad Request: Bedeutung und Lösung

2026-09-16 Aktualisiert: 2026-09-19

Ein 400 Bad Request bedeutet, der Server konnte die Anfrage überhaupt nicht parsen, noch bevor er entscheiden konnte, ob er sie zulässt. Das setzt 400 einen Schritt vor Fehler wie 401 oder 403, die bedeuten, dass der Server die Anfrage vollkommen verstanden und dann aus einem Grund der Richtlinie abgelehnt hat.

Was 400 Bad Request bedeutet

RFC 9110 definiert 400 als die Art des Servers zu sagen, dass die Anfrage wegen fehlerhafter Syntax nicht verstanden werden konnte. Das Schlüsselwort ist Syntax: Der Server bewertet nicht, wer Sie sind, was Sie dürfen, oder ob die Ressource existiert. Er sagt, dass die Anfrage selbst, als Bytes auf der Leitung, nicht als gültige HTTP-Anfrage geparst werden kann. Das kann die Anfragezeile, die Header oder den Body betreffen, je nachdem, wo der Parser aufgibt.

Wie sich der Fehler zeigt

Browser rendern die einfache Fehlerseite, die der Server für einen 400 zurückschickt; es gibt keine dedizierte Browser-Fehlerseite wie bei einem DNS- oder Zertifikatsfehler, da die Verbindung erfolgreich war und eine Antwort tatsächlich eintraf. Eine verbreitete Variante lautet genau "400 Bad Request - request header or cookie too large", was die Ursache direkt benennt. Von der Kommandozeile aus:

curl -I https://example.com/some/path
HTTP/1.1 400 Bad Request
Content-Type: text/html

Server-Logs sind hier der nützlichste Beleg, denn anders als bei einem gescheiterten TLS-Handshake erreichte die Anfrage die Anwendungsschicht und wird protokolliert, oft mit dem genauen Header oder der Zeile, die nicht geparst werden konnte.

Was einen 400 Bad Request erzeugt

Für einen Besucher, in der Reihenfolge, in der Sie am wahrscheinlichsten darauf stoßen:

Übergroße oder beschädigte Cookies. Über Jahre angesammelte Cookies für eine Domain, oder ein Cookie, das durch eine Erweiterung oder eine fehlerhafte Weiterleitung verstümmelt wurde, erzeugen regelmäßig genau die Meldung "400 Bad Request - request header or cookie too large", sobald die gesamte Header-Größe das Limit des Servers überschreitet.
Eine falsch getippte oder schlecht kodierte URL. Ein verirrtes Zeichen, ein nicht kodiertes Leerzeichen oder eine kaputte Prozent-Kodierung in der Adressleiste oder einem eingefügten Link kann als gültige Syntax nicht geparst werden.
Eine Browser-Erweiterung, die Anfragen verändert. Ad-Blocker, Privacy-Tools und manche VPN-Erweiterungen schreiben Header oder die Anfragezeile um, und ein Bug in einer davon kann dem Server etwas Fehlerhaftes übergeben.
Eine zwischengespeicherte Weiterleitung, die auf eine kaputte URL zeigt. Der Browser folgt einer veralteten Weiterleitung zu einer URL, die selbst ungültig ist, und der 400 erscheint auf dem Ziel, nicht auf dem Link, den Sie tatsächlich angeklickt haben.
Ein Datei-Upload, größer als der Server erlaubt. Manche Serverkonfigurationen beantworten einen übergroßen Upload mit 400 statt mit dem spezifischeren 413 Payload Too Large.

Für den Website-Betreiber, ungefähr in der Reihenfolge, die zuerst zu prüfen sich lohnt:

Header- oder Cookie-Größenlimits, die zu niedrig gesetzt sind für das, was die Anwendung tatsächlich sendet, besonders nach dem Hinzufügen von Tracking-Cookies, JWTs in Headern oder einem Session-Mechanismus, der mit der Zeit wächst.
Ein ungültiger oder fehlender Host-Header, den ein Reverse-Proxy oder ein falsch konfigurierter Client erzeugen kann, und den die meisten Server brauchen, um die Anfrage überhaupt zu routen.
Eine Content-Length, die nicht zum tatsächlich gesendeten Body passt, was ein kaputter Client oder ein fehlerhafter Proxy dazwischen verursachen kann.
Web-Application-Firewall- oder ModSecurity-Regeln, die eine Anfrage ablehnen, deren Syntax für einen Menschen in Ordnung aussieht, aber zu einem defensiven Muster passt, das die WAF als fehlerhaft behandelt.
Eine API, die absichtlich fehlerhaftes JSON mit 400 ablehnt. Das ist korrektes Verhalten, kein Bug: Ein Anfrage-Body, der sich nicht als gültiges JSON parsen lässt, oder dem ein Pflichtfeld fehlt, das die API auf Syntaxebene prüft, sollte per Design 400 zurückgeben.

So finden Sie heraus, wer schuld ist

Reproduzieren Sie dieselbe Anfrage aus einer sauberen Umgebung: einem privaten Browserfenster ohne Erweiterungen und ohne angesammelte Cookies, oder einem einfachen curl-Aufruf gegen dieselbe URL. Gelingt die saubere Anfrage, lag die Ursache lokal, meist Cookies oder eine Erweiterung. Schlägt sie identisch von einem sauberen Client und von ganz woanders fehl, lehnen die eigenen Limits oder Regeln des Servers eine legitim geformte Anfrage ab, und der schnellste Weg, das im großen Maßstab zu bestätigen, ist eine HTTP-Prüfung von mehreren Standorten gleichzeitig auszuführen und den Statuscode zu vergleichen, den jeder zurückbekommt.

So beheben Sie einen 400 Bad Request

Wenn Sie Besucher sind

Löschen Sie zuerst die Cookies für die Website, denn übergroße oder beschädigte Cookies sind mit Abstand die häufigste Ursache. Die meisten Browser lassen Sie Cookies für eine Website löschen, ohne jeden anderen Login zu entfernen.
Versuchen Sie es erneut in einem privaten oder Inkognito-Fenster. Ein sauberes Fenster hat keine angesammelten Cookies und deaktiviert, je nach Browser, standardmäßig die meisten Erweiterungen, was beide häufigen Ursachen auf einmal isoliert.
Prüfen Sie die URL auf Tippfehler oder verirrte Zeichen, besonders nach dem Einfügen eines Links von irgendwoher, der Tracking-Parameter hinzugefügt oder die Kodierung zerstört haben könnte.
Deaktivieren Sie Erweiterungen einzeln, falls der Fehler in einem normalen Fenster bestehen bleibt, aber nicht im privaten Browsen, um zu finden, welche die Anfrage umschreibt.
Probieren Sie ein anderes Gerät oder Netzwerk, um ein Captive Portal oder einen lokalen Proxy auszuschließen, der mit der Website gar nichts zu tun hat.

Wenn Sie die Website betreiben

Erhöhen Sie Header- und Puffer-Limits, falls die Anwendung sie tatsächlich größer braucht. Bei nginx:
```
large_client_header_buffers 4 16k;
```
Bei Apache:
```
LimitRequestFieldSize 16384
```
Bei IIS prüfen Sie sowohl maxRequestLength in web.config für den Anfrage-Body als auch die HTTP.sys-MaxFieldLength-Registry-Einstellung für einzelne Header-Felder.
Reduzieren Sie, was Sie tatsächlich in Cookies und Headern senden, statt nur die Obergrenze anzuheben. Veraltete Cookies zu entfernen, große Tokens aus Headern zu verlagern und kürzere Cookie-Laufzeiten zu setzen verhindert, dass das Problem mit wachsender Nutzung wiederkehrt.
Prüfen Sie die Host-Header-Behandlung am Reverse-Proxy oder Load Balancer, und bestätigen Sie, dass er einen gültigen, erwarteten Wert an die Anwendung weiterleitet.
Lesen Sie die WAF- oder ModSecurity-Logs nach der konkreten Regel, die ausgelöst hat, falls eine vor der Anwendung sitzt; ein Fehlalarm dort braucht eine gezielte Ausnahme, kein deaktiviertes Regelwerk.
Bestätigen Sie, dass ein 400 aus Ihrer API beabsichtigt ist, bevor Sie ihn "reparieren". Ein fehlerhafter JSON-Body oder ein Feld, das auf Syntaxebene die Validierung nicht besteht, sollte 400 zurückgeben; die Lösung ist in diesem Fall eine klarere clientseitige Fehlermeldung, nicht das Ändern des Statuscodes.

400 gegenüber ähnlichen Codes

401 Unauthorized bedeutet, die Anfrage wurde einwandfrei verstanden, aber gültige Zugangsdaten fehlen oder wurden abgelehnt.
403 Forbidden bedeutet, die Anfrage wurde einwandfrei verstanden, aber der Server weigert sich, sie unabhängig von Zugangsdaten zu autorisieren.
404 Not Found bedeutet, die Anfrage wurde einwandfrei verstanden, und keine Ressource passte zum Pfad.
413 Payload Too Large ist der spezifische Code für einen Body, der ein Größenlimit überschreitet, obwohl manche Server in der Praxis stattdessen 400 antworten.
414 URI Too Long ist der spezifische Code für eine Anfragezeile, die ein Längenlimit überschreitet.
422 Unprocessable Content bedeutet, die Syntax wurde einwandfrei geparst, aber die Semantik nicht, zum Beispiel gültiges JSON mit einem Wert, der die Geschäftsvalidierung nicht besteht, eine feinere Unterscheidung, die sich die meisten APIs von 400 gar nicht erst machen.

Wie Sie verhindern, dass ein 400-Fehler eine Seite lahmlegt

Ein 400, den ein Deploy einführt, das Header-Limits verschärft hat, oder eine WAF-Regel-Aktualisierung, die anfängt, legitimen Traffic zu treffen, zeigt sich nicht als Absturz oder Timeout, da der Server sofort und nach seinen eigenen Regeln korrekt antwortet. Eine geplante HTTP-Prüfung mit einer Zusicherung auf den erwarteten Statuscode erkennt das in dem Moment, in dem es beginnt, statt zu warten, bis sich Support-Tickets stapeln. Kombiniert mit Monitoring von mehreren Standorten aus sagt sie Ihnen außerdem, ob der 400 überall auftritt oder an die Edge-Konfiguration einer Region gebunden ist.

Häufig gestellte Fragen

Warum behebt das Löschen von Cookies einen 400-Fehler?

Weil Cookies bei jeder Anfrage als Request-Header mitfahren, und ein Server eine maximale Gesamt-Header-Größe durchsetzt. Jahrelang angesammelte Cookies, oder ein einziges beschädigtes Cookie, können die Summe über dieses Limit drücken, und der Server antwortet mit 400, bevor er sonst etwas an der Anfrage liest.

Ist ein 400-Fehler auf jeder Website, die ich besuche, gleich?

Der Code und die allgemeine Ursache, fehlerhafte Anfragesyntax, sind überall gleich, aber das genaue Limit, das überschritten wurde, und der genaue Wortlaut der Fehlerseite werden von der jeweiligen Serverkonfiguration festgelegt.

Sollte meine API bei ungültiger Eingabe 400 zurückgeben?

Ja, wenn die Eingabe nicht geparst werden kann oder ein Feld fehlt, das die API auf Syntaxebene prüft. Das ist 400, wie es gedacht ist, kein Bug, den man durch gelockerte Validierung beheben sollte.

Kann eine WAF einen 400-Fehler bei einer völlig normal aussehenden Anfrage verursachen?

Ja. Eine WAF-Regel kann ein Muster in einer URL, einem Header oder einem Body markieren, das technisch gültiges HTTP ist, aber zu einer defensiven Signatur passt, und manche WAF-Konfigurationen antworten mit einem generischen 400 statt mit einer spezifischeren Blockseite.

Was ist der Unterschied zwischen 400 und 413?

413 ist der spezifische Code für einen Anfrage-Body, der ein konfiguriertes Größenlimit überschreitet. Viele Server verwenden ihn korrekt, aber manche antworten stattdessen mit 400 für dieselbe übergroße Body-Bedingung, verlassen Sie sich also nicht allein auf den Code für die genaue Ursache, ohne die eigene Dokumentation oder die Logs des Servers zu prüfen.