400 Bad Request: Bedeutung und so beheben Sie den Fehler

Was ist der Fehler 400 Bad Request?

400 Bad Request ist ein HTTP-Statuscode und bedeutet, dass der Server Ihre Anfrage erhalten hat, sie aber nicht verarbeitet, weil mit der Anfrage selbst etwas nicht stimmt. Der HTTP-Standard definiert ihn so: Der Server kann oder will eine Anfrage nicht verarbeiten, „weil etwas als Fehler des Clients wahrgenommen wird (z. B. fehlerhafte Anfragesyntax, ungültiges Message-Framing oder irreführendes Request-Routing)“ (RFC 9110 §15.5.1).

Anders als ein 500er-Fehler, der heißt, dass der Server kaputt ist, zeigt ein 400 auf die Anfrage: die URL, die Header, die Cookies oder die Daten, die Ihr Browser oder Ihre App gesendet hat. Für alle anderen funktioniert die Website meist ganz normal.

Für Besucher ist das eine gute Nachricht, denn die Lösung liegt oft auf Ihrer Seite und dauert eine Minute: ein vertippter oder beschädigter Link oder Cookies, die für den Server zu groß geworden sind.

So sieht ein 400-Fehler aus

Die Meldung hängt von der Serversoftware ab, und der Zusatztext ist oft der beste Hinweis auf die Ursache:

Was verursacht einen 400 Bad Request?

• Eine fehlerhafte URL. Ein verirrtes %-Zeichen, ein Leerzeichen, ein Zeichen, das hätte codiert werden müssen, oder ein Link, der abgeschnitten oder doppelt eingefügt wurde.
• Beschädigte oder zu große Cookies. Websites, die viele Cookies setzen (Logins, A/B-Tests, Analytics), können den Cookie-Header über das Limit des Servers treiben. Auch ein Cookie, das bei einem Update beschädigt wurde, kann abgelehnt werden.
• Zu große Request-Header. Neben Cookies summieren sich lange Authentifizierungs-Tokens oder Header, die Erweiterungen und Proxys hinzufügen.
• Ungültige Daten an eine API. Fehlende Pflichtfelder, fehlerhaftes JSON oder der falsche Content-Type-Header.
• HTTP an einen HTTPS-Port gesendet. Häufig hinter Load Balancern und Reverse Proxys.
• Eine zu große Datei. Viele Server antworten mit 413 Content Too Large, manche Apps und Frameworks liefern stattdessen aber 400.

Lösung 1: Prüfen Sie die URL

Sehen Sie sich die Adressleiste genau an. Darauf sollten Sie achten:

• Ein %, auf das keine zwei Hexadezimalzeichen folgen (%20 ist in Ordnung, %2 oder %zz nicht).
• Leerzeichen, { }, |, \ oder andere ungewöhnliche Zeichen, vor allem in Links, die aus E-Mails, PDFs oder Chat-Apps kopiert wurden.
• Ein Link, der doppelt eingefügt (https://example.com/https://example.com/...) oder mittendrin abgeschnitten wurde.
• Eine sehr lange URL mit Tracking-Parametern. Löschen Sie alles ab dem ? und versuchen Sie es erneut.

Sind Sie über einen Link von einer anderen Website gekommen, gehen Sie stattdessen auf die Startseite der Website und navigiere von dort zur gewünschten Seite.

Lösung 2: Löschen Sie die Cookies dieser einen Website

Das ist die Lösung für Meldungen, in denen Cookies oder Header „too large“ oder „too long“ sind, und sie lohnt sich bei jedem 400 auf einer Website, die Sie schon einmal genutzt haben. Sie müssen nicht die Cookies aller Websites löschen, nur die dieser einen:

• Chrome: Klicken Sie links in der Adressleiste auf Website-Informationen anzeigen → Cookies und Websitedaten → Websitedaten auf dem Gerät verwalten → löschen Sie die Daten der Website und laden Sie neu.
• Edge: Einstellungen und mehr → Einstellungen → Datenschutz, Suche und Dienste → Cookies → Alle Cookies und Websitedaten anzeigen → nach der Website suchen → löschen.
• Firefox: Klicken Sie auf das Schloss-Symbol → Cookies und Website-Daten löschen …
• Safari (Mac): Safari → Einstellungen → Datenschutz → Websitedaten verwalten … → nach der Website suchen → Entfernen.
• iPhone: Einstellungen → Apps → Safari → Erweitert → Websitedaten → auf der Website nach links wischen, um sie zu löschen.

Lösung 3: Inkognito testen, dann den Cache leeren

Öffnen Sie die Seite in einem Inkognito- bzw. privaten Fenster (Strg + Umschalt + N in Chrome und Edge, Strg + Umschalt + P in Firefox, Cmd + Umschalt + N in Safari). Private Fenster starten ohne Cookies, ohne Dateien im Cache und meist ohne Erweiterungen. Funktioniert die Seite dort, lösen Lösung 2, Lösung 4 oder das Leeren der Cache-Dateien (Strg + Umschalt + Entf → Bilder und Dateien im Cache) das Problem dauerhaft.

Scheitert auch Inkognito, sind weder Cookies noch Cache oder Erweiterungen die Ursache: Prüfen Sie die URL noch einmal, schalten Sie ein VPN oder einen Proxy aus und leeren Sie als letzten Schritt Ihren DNS-Cache. DNS ist selten die Ursache eines 400-Fehlers, aber nach einem Serverumzug der Website kann eine veraltete Adresse Sie auf einen Server führen, der Ihre Anfrage ablehnt.

Lösung 4: Erweiterungen deaktivieren und Dateigrößen prüfen

Erweiterungen, die Anfragen verändern, etwa Datenschutz-Tools, Header-Editoren, Gutschein-Finder und manche Werbeblocker, können Header so hinzufügen oder ändern, dass ein Server sie ablehnt. Deaktivieren Sie alle, laden Sie neu und schalten Sie sie dann nacheinander wieder ein, um den Schuldigen zu finden.

Tritt der Fehler beim Hochladen auf, probieren Sie eine kleinere Datei. Komprimieren Sie Bilder oder teilen Sie große Dateien auf. So erfahren Sie, ob der Server die Größe ablehnt, auch wenn er das als 400 statt als 413 meldet.

Für Website-Betreiber: Die Ursache von 400-Fehlern finden

Melden Nutzer 400-Fehler auf Ihrer Website, fangen Sie mit der genauen Meldung an, die sie sehen, und mit Ihren Server-Logs. nginx protokolliert den Grund auf dem Level info; Apache protokolliert zu große Header auf info, fehlerhafte URLs und Header aber erst auf debug. Setzen Sie das Log-Level des Error-Logs daher vorübergehend herauf, falls Sie den Grund nicht sehen (error_log … info; in nginx, LogLevel debug in Apache). Das Access-Log zeigt, welche URLs 400 liefern. Der HTTP-Header-Checker von DNS Robot zeigt den Statuscode, die Serversoftware und jedes Cookie, das ein Erstbesuch setzt, samt Größe. Cookies, die Skripte später hinzufügen, etwa Analytics, sehen Sie nur in den DevTools Ihres Browsers (Application → Cookies).

# Welche Anfragen bekommen 400? (nginx-Logformat "combined")
sudo awk '$9 == 400 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Die Gründe, die nginx protokolliert hat (braucht error_log ... info;)
sudo grep -i "client sent\|too large\|bad request" /var/log/nginx/error.log | tail -20

„Request Header Or Cookie Too Large“

nginx liest Request-Header in Puffer ein, die large_client_header_buffers festlegt, standardmäßig 4 Puffer zu je 8 KB. Ein Header-Feld, das nicht in einen Puffer passt (meist der Cookie-Header), löst diesen 400-Fehler aus, ebenso Header, die zusammen mehr als alle 4 Puffer brauchen (etwa 32 KB). Eine zu lange Request-Zeile (die URL) liefert dagegen 414 (nginx). Das Gegenstück bei Apache ist LimitRequestFieldSize, standardmäßig 8.190 Byte (Apache).

Wir haben es am 27. Oktober 2026 auf nginx.org selbst getestet (nginx 1.31.3): Eine Anfrage mit einem 7.000 Byte großen Cookie bekam die normale Seite, eine mit einem 9.000 Byte großen Cookie genau diese:

<html>
<head><title>400 Request Header Or Cookie Too Large</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>Request Header Or Cookie Too Large</center>
<hr><center>nginx/1.31.3</center>
</body>
</html>

Die saubere Lösung ist, weniger zu senden: Entfernen Sie Cookies, die Sie nicht mehr brauchen, halten Sie Session-Cookies klein und beschränken Sie Cookies auf die Pfade und Subdomains, die sie nutzen. Brauchen Sie wirklich größere Header, etwa für große Single-Sign-on-Tokens, heben Sie das Limit an:

# nginx: http-Block oder Default-Server (andere server-Blöcke lassen sich ignorieren)
large_client_header_buffers 4 16k;

# Entsprechung bei Apache: Hauptkonfiguration oder zuerst aufgeführter Virtual Host
# LimitRequestFieldSize 16380

„The plain HTTP request was sent to HTTPS port“

nginx liefert diesen 400-Fehler, wenn etwas unverschlüsseltes HTTP an einen Port schickt, an dem nginx TLS erwartet, meist 443; curl http://nginx.org:443/ zeigt die Seite. Typische Ursachen sind ein Load Balancer oder Proxy, der http://-Traffic an Port 443 weiterleitet, ein Link wie http://example.com:443 oder, bei nginx vor 1.25.1, eine Zeile ssl on; in einem server-Block, der auch auf Port 80 lauscht (1.25.1 hat die Direktive entfernt, neuere nginx-Versionen starten damit nicht; verwenden Sie listen 443 ssl;).

Sorgen Sie dafür, dass jede listen-Zeile zu dem passt, was dort ankommt: listen 443 ssl; für HTTPS und listen 80; für unverschlüsseltes HTTP, mit einer Weiterleitung von 80 auf 443. Stellen Sie außerdem sicher, dass der vorgeschaltete Proxy HTTPS mit Port 443 spricht (bzw. HTTP mit Port 80).

400-Fehler von APIs

APIs nutzen 400 für Anfragen, die die Validierung nicht bestehen. Rufen Sie eine API auf, lesen Sie den Response-Body, denn die meisten APIs erklären, welches Feld falsch ist. Prüfen Sie dann, ob Sie gültiges JSON, den richtigen Header Content-Type: application/json und alle Pflichtparameter senden.

Bauen Sie selbst eine API, geben Sie einen Body zurück, der das Problem benennt (zum Beispiel {"error": "email is required"}), und erwägen Sie 422 Unprocessable Content für Anfragen, die formal korrekt, aber inhaltlich ungültig sind. 400 bleibt dann für Anfragen, die sich gar nicht erst parsen lassen.

400 vs. 401, 403, 404, 413, 429 und 431

Unsere Anleitungen zu den Nachbarn: 403 Forbidden, 401 Unauthorized und 429 Too Many Requests. Bei Weiterleitungen, die sich im Kreis drehen statt zu scheitern, lesen Sie ERR_TOO_MANY_REDIRECTS, und der Weiterleitungs-Checker zeigt jeden einzelnen Hop.