400 Bad Request: Request Header Or Cookie Too Large

So sieht die Meldung aus

400 Bad Request – Request Header Or Cookie Too Large

Häufige Ursachen

• Viele Cookies derselben Domain, z. B. von Analytics, A/B-Tests und mehreren Apps auf Subdomains.
• SSO/OIDC-Session-Cookies oder Bearer-Tokens mit vielen Gruppen-Claims.
• Weiterleitungsschleife, die bei jedem Durchlauf ein weiteres Cookie setzt.
• large_client_header_buffers zu klein für die Anwendung.
• Auch das Backend (Node, Tomcat, Gunicorn) hat eigene Header-Limits.

Prüfen

1. Aktuelle Puffergrößen in der Konfiguration anzeigen
   nginx -T 2>/dev/null | grep -nE 'large_client_header_buffers|client_header_buffer_size'Kopieren
2. Mit einem 12-KB-Cookie testen, ob nginx 400 liefert
   curl -sS -o /dev/null -w '%{http_code}\n' -H "Cookie: test=$(head -c 12000 /dev/zero | tr '\0' a)" https://example.com/Kopieren
3. Passende Einträge im error.log suchen
   grep -i 'too large' /var/log/nginx/error.log | tail -n 5Kopieren

Lösung

• Für den Benutzer: Cookies der Domain löschen – das bestätigt die Ursache sofort.
• Im server-Block large_client_header_buffers 4 32k; setzen und nginx -t && systemctl reload nginx ausführen.
• Bei SSO die Anzahl der Gruppen im Token begrenzen oder Gruppen per Userinfo-Endpoint holen.
• Cookies auf die nötige Domain und den nötigen Pfad beschränken statt auf .example.com.
• Header-Limits am Backend mit anheben, sonst kommt dort ein 431 oder 400.

Häufige Fragen

Wie groß darf ich die Puffer setzen?

32k pro Puffer reicht fast immer. Viel größere Werte kosten Speicher pro Verbindung und erleichtern Missbrauch. Besser die Ursache – das große Cookie – verkleinern.

Warum betrifft es nur einzelne Benutzer?

Weil nur deren Browser so viele Cookies gesammelt hat, z. B. durch viele Apps oder eine alte Schleife. Ein privates Fenster bestätigt das schnell.