Türkei (Türkisch)
Germany (German)
Worldwide (English)
AnforderungsflussClient, NGINX und Backend-Verbindungsbrempunkt
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Dieser 400-Fehler tritt auf, wenn die Anforderungszeile oder ein einzelnes HTTP-Header-Feld die NGINX-Pufferkapazität überschreitet. In den meisten Fällen liegt es an einer überdimensionierten Sitzungs-Cookie, JWT, SSO-Daten oder einer Header-Kette, die von einem Reverse-Proxy hinzugefügt wurde.
2026/07/17 04:02:19 [info] 2381#2381: *1223 client sent too large header while reading client request headers
400 Bad Request
Request Header Or Cookie Too LargeNGINX, liest die Request-Header zuerst in den normalen Puffer, und wenn groß, in die large_client_header_buffers-Area. Wenn ein einzelner Header oder Request-Line-Puffergröße überschritten wird, gibt es 400 oder in einigen Fällen 414 zurück.
Das Löschen von Browser-Cookies kann das Problem vorübergehend lösen, aber die Ursache liegt in der Regel darin, dass die Anwendung auf dem gleichen Domain eine übermäßige Anzahl oder große Cookies produziert. Ein erhöhter Puffer kann die Symptome reduzieren, aber der Cookie-Design muss korrigiert werden.
Das Hinzufügen von übermäßigen Benutzerberechtigungen, Profilen und Sitzungsdaten in die JWT erhöht den Authorization-Header. Dies kann zu mehreren Tokens in einem einzelnen Anfrage in SSO- und OAuth-Systemen führen.
In Reverse-Proxy-Ketten können X-Forwarded-For, Cookie und benutzerdefinierte Trace-Header über die Schichten wachsen. Wenn der Fehler nur über CDN/Last-Engine-Balancer auftritt, sollte der Ursprung und der direkte Zugriff verglichen werden.
Bufferwerte können wie benötigt für jede Verbindung zugewiesen werden; unnötig große Werte erhöhen den Speicherbedarf bei hoher Konkurrenz.
Bevor Sie den Buffer erhöhen, messen Sie, welcher der größte Header ist, Cookie oder Autorisierung oder Anfrage-URI, und bestimmen Sie, welche Daten auf der Anwendungsseite reduziert werden können.
Suchen Sie nach dem Ausdruck, den Sie in der E-Mail, im Browser oder im SSH-Protokoll sehen. Jede Karte enthält eine Bedeutung, eine wahrscheinliche Ursache und eine sichere erste Maßnahme.
Bedeutung: Ein Header-Feld hat die effektive große Pufferbegrenzung überschritten.
Mögliche Ursache: Großer Cookie, Autorisierung/JWT oder Proxy-Header
Bedeutung: NGINX kann den Client-Header nicht akzeptieren.
Mögliche Ursache: Überprüfen Sie die Cookie-Anhäufung oder die unzureichenden large_client_header_buffers.
Bedeutung: Allgemeines 400-Nachricht; Log-Rootursache wird angezeigt.
Mögliche Ursache: Header, Anforderungszeile, TLS oder gebrochener HTTP-Anfrage.
Bedeutung: Anfragezeile/URI-Puffer überschritt die Grenze.
Mögliche Ursache: Langsames Abfragestring, Filter oder falsche Umleitung.
Bedeutung: Der Client ist nicht der Backend-Antwortkopf den Proxy-Puffer überschritten.
Mögliche Ursache: Großer Set-Cookie oder Anwendungsheader
Bedeutung: Einige Mittelschichten können 431 für große Header zurückgeben.
Mögliche Ursache: CDN, Gateway oder Anwendungsserver-Limit
Bedeutung: Die Anwendung oder Proxy-Cookie-Größe wurde abgelehnt.
Mögliche Ursache: Session-Daten werden in den Cookie übermäßig geschrieben.
Bedeutung: JWT oder Authentifizierungsheader überschritt die Grenze.
Mögliche Ursache: Große Claim-Menge oder verketteter Token.
Es wurden keine Datensätze gefunden, die diesem Ausdruck entsprechen.
Befehle sind für den Root-Zugriff vorgesehen. Sammeln Sie zunächst nur den Status und die Protokolle. Ändern Sie die dauerhafte Einstellung nicht, ohne den Grund dafür zu erkennen.
curl -skD - https://example.com/ -o /dev/null | grep -i '^set-cookie:'
curl -sk -H 'Cookie: TEST=1' -o /dev/null -w '%{http_code}\n' https://example.com/Produziert Set-Cookie und überwacht kontrollierte Cookie-Anfragen.
nginx -T | grep -nE 'client_header_buffer_size|large_client_header_buffers|proxy_buffer_size'Zeigt die Client- und Upstream-Header-Buffer-Werte an.
grep -R 'too large header\|too long URI' /var/log/nginx 2>/dev/null | tail -n 100Finds the error type and affected request.
curl -sk -D /tmp/basliklar.txt https://example.com/ -o /dev/null
wc -c /tmp/basliklar.txtMisst die Gesamtgröße des Antwort-Headers ungefähr.
curl -skI https://example.com/
curl -skI --resolve example.com:443:ORIGIN_IP https://example.com/Trennt, ob die CDN/Proxy-Schicht die Header-Größe erhöht
nginx -t && systemctl reload nginxMacht eine vernünftige Buffer-Änderung sicher.
Obwohl die Grundursache des NGINX-Fehlers dieselbe ist, variieren Paketpfade, Dienstnamen, Sicherheitsebenen und die Verwaltung virtueller Hosts je nach verwendeter Linux-Distribution oder Plesk-Infrastruktur.
systemd, Paketpfad und journald-Prüfunglen für NGINX 400 Header oder Cookie Too Large.
nginx -T | grep -nE 'client_header_buffer_size|large_client_header_buffers'
grep -R 'too large header' /var/log/nginx | tail -n 50SELinux, PHP-FPM-Pool und RHEL-basierte Dienstkontrollen für NGINX 400 Header oder Cookie Too Large.
nginx -T | grep -nE 'client_header_buffer_size|large_client_header_buffers'
grep -R 'too large header' /var/log/nginx | tail -n 50Plesk-generierte NGINX-Virtualhostdateien in nginx 400 Header oder Cookie too large Prüfungle.
grep -R 'large_client_header_buffers' /var/www/vhosts/system/example.com/conf /etc/nginx 2>/dev/null
tail -n 100 /var/www/vhosts/system/example.com/logs/proxy_error_logZuerst herausfinden Sie, welcher Header gewachsen ist; die Anwendungsdaten verringern und den Puffer nur dann erhöhen, wenn dies erforderlich ist.
Vergleichen Sie mit versteckter Fenster oder cookiesloser curl-Anfrage.
curl -sk -c /dev/null -b /dev/null -o /dev/null -w '%{http_code}\n' https://example.com/Machen Sie eine Unterscheidung zwischen Client-Header, langer URI oder Upstream-Antwort-Header.
tail -n 100 /var/log/nginx/error.logIdentifizieren und entfernen Sie unnötige Daten aus der Anwendung durch größte Cookie/JWT-Bereiche.
curl -skD - https://example.com/ -o /dev/null | grep -i '^set-cookie:'Überprüfen Sie die Client-Header-Einstellung innerhalb des gleichen Server-Gültigkeitsbereichs.
nginx -T | grep -nE 'client_header_buffer_size|large_client_header_buffers'Wählen Sie für den relevanten vhost statt übermäßiger Werte auf dem Server maßvolle Größen.
nginx -tTesten, ob neue und alte Cookie-Benutzer auf die gleiche Seite zugreifen können.
nginx -t && systemctl reload nginxDie Sitzung oder JWT-Kochnie kann bei der Anmeldung zu groß sein.
curl -skD - https://example.com/giris -o /dev/null | grep -i set-cookieSession-Cookies und Erweiterungsdaten überprüfen.
grep 'too large header' /var/log/nginx/error.log | tailMehrere Token-, Status- und Claim-Cookies können auf der gleichen Domäne ansammeln.
Browser Application > Cookies, Größe vergleichen.Forwarded- und Trace-Header-Kette kann wachsen.
curl --resolve example.com:443:ORIGIN_IP -skI https://example.com/Die Suchzeichenfolge muss möglicherweise in POST oder einen kurzen Zustandstoken konvertiert werden.
python3 - <<'PY'
url='https://example.com/uzun-url'
print(len(url))
PYDies ist ein Client-Puffer-Problem, nicht proxy_buffer_size, und ein Set-Cookie-Problem.
grep 'upstream sent too big header' /var/log/nginx/error.log | tailTritt auf, wenn ein Cookie, Authorization/JWT, eine lange URI oder ein anderes Header-Feld die NGINX-Puffergröße überschreitet.
Nein. Es bietet vorübergehend Zugriff; wenn die Anwendung den gleichen großen Cookie wiederherstellt, wiederholt sich der Fehler.
Große Anforderungszeile und Header-Felder zum Lesen, definiert Puffergröße in Zahlen und Bytes; ein Feld muss innerhalb einer Puffergröße passen.
Ja. Insbesondere bei hoher Konkurrenz können unnötige große Werte den Speicherbedarf erhöhen.
Nein. Der Fehler liegt darin, dass der Antwortkopf des Backends den Proxy-Puffer überschreitet; dies ist von den Einstellungen der Anforderungskopfdaten des Clients getrennt.
Wenn zu viel Claim- oder Profildaten in den Token eingefügt werden, wächst der Authorization- oder Cookie-Header schnell an.
Das Feld Additional nginx directives in Domain > Apache- & nginx-Einstellungen kann verwendet werden; die effektive Konfiguration muss nach Änderungen validiert werden.
Durch die gemeinsame Analyse von cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim und Sicherheitsebenen beheben wir die Grundursache des Fehlers, anstatt nur den Dienst zu entfernen.