400 Bad Request

Die Anfrage ist fehlerhaft oder ungültig.

Wann du ihn verwendest

Nicht parsebares JSON, fehlende Pflichtfelder, falsche Typen.

Häufige Ursachen und Lösungen

Häufige Ursachen: fehlerhaftes JSON wie ein abschließendes Komma oder Strings in einfachen Anführungszeichen, ein Body, der nicht zum angegebenen Content-Type passt, fehlende Pflichtfelder oder ungültige Query-Parameter. Bevor du dem Server die Schuld gibst, sieh dir die exakt gesendeten Bytes an, mit curl -v oder im Request-Payload im Network-Tab der DevTools. Die meisten APIs erklären das Problem im Response-Body, also lies ihn.

Auch Infrastruktur erzeugt 400: nginx gibt „Request Header Or Cookie Too Large“ zurück, wenn Cookies large_client_header_buffers sprengen, und „The plain HTTP request was sent to HTTPS port“, wenn du http:// auf Port 443 verwendest. Load Balancer lehnen fehlerhafte Header oder Host-Werte ab. Die Cookies der Website zu löschen, behebt viele 400er, die nur im Browser auftreten. Reserviere 400 auf deinem eigenen Server für nicht parsbare Eingaben und nimm 422 für fehlgeschlagene Validierung.

Client-Fehler (4xx)

4xx-Codes sind Client-Fehler: Die Anfrage selbst ist fehlerhaft, nicht autorisiert oder verweist auf etwas, das es nicht gibt. Dieselbe Anfrage erneut zu senden hilft nicht.

So sieht es aus

HTTP/1.1 400 Bad Request

So sendest du ihn

So prüfst du ihn

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/

HTTP-Statuscodes öffnen