400 Bad Request: Bedeutung und so behebst du den Fehler

Was ist der Fehler 400 Bad Request?

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

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 dein Browser oder deine 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 meist auf deiner Seite und dauert eine Minute: Hinter den meisten 400-Fehlern stecken ein vertippter Link oder ein beschädigtes Cookie.

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üfe die URL

Sieh dir die Adressleiste genau an. Darauf solltest du 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ösche alles ab dem ? und versuche es erneut.

Bist du über einen Link von einer anderen Website gekommen, geh stattdessen auf die Startseite der Website und navigiere von dort zur gewünschten Seite.

Lösung 2: Lösche die Cookies dieser einen Website

Das behebt die meisten 400-Fehler auf Websites, die du schon einmal genutzt hast, vor allem Meldungen, in denen Cookies oder Header „too large“ oder „too long“ sind. Du musst nicht die Cookies aller Websites löschen, nur die dieser einen:

• Chrome / Edge: Klicke auf das Symbol links in der Adressleiste → Cookies und Websitedaten (oder Website-Einstellungen) → lösche die Daten der Website und lade neu.

• Firefox: Klicke 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

Öffne 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 und ohne Erweiterungen. Funktioniert die Seite dort, lösen Lösung 2 oder Lösung 4 das Problem dauerhaft.

Scheitert auch Inkognito, leere den Browser-Cache (Strg + Umschalt + Entf → Bilder und Dateien im Cache) und leere als letzten Schritt deinen DNS-Cache. DNS ist selten die Ursache eines 400-Fehlers, aber nach einem Serverumzug der Website kann dich eine veraltete Adresse auf einen Server führen, der deine 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. Deaktiviere alle, lade neu und schalte sie dann nacheinander wieder ein, um den Schuldigen zu finden.

Tritt der Fehler beim Hochladen auf, probiere eine kleinere Datei. Komprimiere Bilder oder teile große Dateien auf. So erfährst du, 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 deiner Website, fang mit der genauen Meldung an, die sie sehen, und mit deinen Server-Logs. nginx und Apache protokollieren den Grund auf dem Level info. Siehst du ihn nicht, setz das Log-Level des Error-Logs vorübergehend herauf. Das Access-Log zeigt, welche URLs 400 liefern. Das Tool HTTP-Headers von DNS Robot zeigt den Statuscode, die Serversoftware und jeden Set-Cookie-Header, den eine Seite sendet. So erkennst du Cookies, die immer weiter wachsen.

# 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. Eine einzelne Header-Zeile, meist der Cookie-Header, die nicht in einen Puffer passt, löst diesen 400-Fehler aus. Das Gegenstück bei Apache ist LimitRequestFieldSize, standardmäßig 8.190 Byte.

Die saubere Lösung ist, weniger zu senden: Entferne Cookies, die du nicht mehr brauchst, halte Session-Cookies klein und beschränke Cookies auf die Pfade und Subdomains, die sie nutzen. Brauchst du wirklich größere Header, etwa für große Single-Sign-on-Tokens, hebe das Limit an:

# nginx (http- oder server-Block)
large_client_header_buffers 4 16k;

# Entsprechung bei Apache (httpd.conf / vhost)
# 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. Typische Ursachen sind ein Load Balancer oder Proxy, der http://-Traffic an Port 443 weiterleitet, ein Link wie http://example.com:443 oder eine alte ssl on;-Einstellung, durch die ein Port TLS erwartet, obwohl er das nicht sollte.

Sorge 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. Stell 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. Rufst du eine API auf, lies den Response-Body, denn die meisten APIs erklären, welches Feld falsch ist. Prüfe dann, ob du gültiges JSON, den richtigen Header Content-Type: application/json und alle Pflichtparameter sendest.

Baust du selbst eine API, gib einen Body zurück, der das Problem benennt (zum Beispiel {"error": "email is required"}), und erwäge 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, lies ERR_TOO_MANY_REDIRECTS, und der Weiterleitungs-Checker zeigt jeden einzelnen Hop.