请求头超限导致400需四步协同解决：先查error.log确认“header too large”等日志线索，再用curl -v统计请求头字节数；必须同步配置client_header_buffer_size（如4k）和large_client_header_buffers（如4 16k）；收紧client_header_timeout至5–10s防攻击；最后精简前端cookie、jwt及多层代理头，并校准后端header限制。
请求头超限导致 400 Bad Request，不是简单调大一个参数就能解决。Nginx 对请求头的限制是分层生效的，必须从日志确认、缓冲区匹配、安全收紧、源头精简四方面协同处理。
先确认是不是请求头真超限
别急着改配置，先看证据：
- 查 Nginx 错误日志（如 /var/log/nginx/error.log），搜索 request header or cookie too large、client sent too large request 或 400 相关记录
- 用 curl 模拟真实请求并统计头部字节数：
curl -v http://your-api/ 2>&1 | grep '^>' | wc -c
注意：每行>是一个请求头字段（含 CRLF 换行符），总和超过 4KB 就很可能触发限制 - 如果日志里没报错但请求静默失败，也可能是解析阶段崩溃太早，没来得及打全日志——这时更需依赖实测数据
调整请求头缓冲区参数
这两个指令必须配合设置，缺一不可：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- client_header_buffer_size：每个连接初始分配的请求头缓冲区，默认 1k。若业务常用长 JWT（比如 2KB）、或带多层代理头，建议设为 2k 或 4k
-
large_client_header_buffers：备用缓冲池，格式为
数量 大小，例如4 16k表示最多启用 4 个 16KB 缓冲区。关键点是：单个请求头字段（如一个 Cookie 值）必须能完整放进一个 buffer，不能拆分。若某 Cookie 达 12KB，就不能用4 8k，而应至少设为4 16k - 推荐起始值：
client_header_buffer_size 2k;+large_client_header_buffers 4 16k;；高频大头场景可试8 16k，但避免设成16 64k这类过大值，内存压力会明显上升
同步收紧网关安全边界
调大缓冲区的同时，必须防攻击：
- client_header_timeout：默认 60 秒，建议降至 5s 或 10s，防止慢速头攻击长期占用连接
-
client_max_body_size 虽管请求体，但攻击常组合超大 body + 长 header，建议按业务设合理上限（如
10m），禁用0或无限大 - 所有相关指令应放在
http块或具体server块内；若使用upstream，这些配置仍作用于入口请求解析阶段，不是后端通信环节
从上游减少冗余请求头
参数调优是兜底手段，长期要优化前端和中间链路：
- 精简前端调试头（如
X-Debug-Token、X-Request-ID多层重复）、压缩 JWT token 长度、清理过期或冗余 Cookie - 检查是否有多层反向代理（如 CDN → Nginx → Nginx → 后端），每层都可能追加
X-Forwarded-For等头，造成累积膨胀 - 后端服务自身也有 header 限制（如 Spring Boot 的
server.max-http-header-size、Node.js 的--max-http-header-size），需一并校准，Nginx 限制应略大于后端值
