必须显式配置请求头大小限制，否则默认值易触发400错误；需先通过错误日志和curl实测确认超限（>4kb），再协同调大client_header_buffer_size（如2k）和large_client_header_buffers（如4 16k），http/2还需增设http2_max_header_size等参数，并同步收紧client_header_timeout、underscores_in_headers等安全边界。
在 Nginx 作为 HTTP 反向代理使用时，请求头大小限制不是“可选优化”，而是必须显式配置的安全边界。默认值（client_header_buffer_size 1k、large_client_header_buffers 4 8k）极易被现代前端（含 JWT、多层 trace 头、跨域 Cookie）触发 400 Bad Request，且错误日志会明确提示 request header or cookie too large。
确认问题是否真由请求头引发
别直接改配置，先验证：
- 查
/var/log/nginx/error.log，搜too large或400记录，看时间是否与故障吻合 - 用
curl -v http://your-api/模拟真实请求，执行：curl -v http://your-api/ 2>&1 | grep '^>' | wc -c
结果若持续 > 4096 字节（如 7200），基本锁定为头缓冲区不足 - 注意：浏览器开发者工具的“Headers”面板显示的是解码后内容，字节数不准确；必须用 curl 实测原始传输长度
调整两级缓冲区参数（核心动作）
这两个指令必须协同设置，缺一不可：
-
client_header_buffer_size：每个连接的初始缓冲区，建议设为
2k或4k。它覆盖绝大多数常规请求行和首部字段 -
large_client_header_buffers：备用缓冲池，格式为
数量 大小，例如4 16k。关键约束是：单个请求头字段（如一个超长 Cookie 值）必须能完整放入一个 buffer 中，不可拆分。若某 Authorization 值达 14KB，就不能用4 8k，而应至少用4 16k - 推荐起始配置：
client_header_buffer_size 2k;<br>large_client_header_buffers 4 16k;
高频大头场景（如微服务网关）可试4 32k，但避免盲目设到64k以上——这既浪费内存，也可能掩盖后端设计缺陷
HTTP/2 场景必须额外设限
若启用 listen 443 ssl http2，仅调上面两个参数不够，还需补充：
-
http2_max_header_size：控制整个头部块（所有字段总和）上限，建议设为
32k -
http2_max_field_size：限制单个字段值长度，默认
4k，防超长 User-Agent 或伪造 token，可按需微调至8k - 这些指令同样放在
http或server块内，与 HTTP/1.x 参数并存生效
同步收紧安全边界，防慢速攻击
调大缓冲区的同时，必须防范恶意构造：
-
client_header_timeout：默认 60 秒，建议降至
5s或10s，防止攻击者逐字节发头字段拖住连接 -
underscores_in_headers off：禁用下划线，避免某些框架将
X_Api_Key解析成x_api_key导致校验绕过或头膨胀 -
client_max_body_size 虽管请求体，但攻击常组合超大 body + 长 header，建议按业务设合理上限（如
10m），禁用0或无限大
