client_header_buffer_size 应设为覆盖95%～99%真实请求头长度的最小值，避免回退分配；需同步配置 large_client_header_buffers（单个size≥前者），并基于 $request_length 统计P95～P99分位值确定具体数值。
client_header_buffer_size 配置得当，确实能减少请求头解析耗时——关键不是“设大”，而是让初始缓冲刚好覆盖绝大多数真实请求头长度，避免触发回退机制。
Nginx 解析请求头时，先尝试用 client_header_buffer_size 这块固定大小的内存缓冲区；一旦超出，就得丢弃原缓冲、重新分配 large_client_header_buffers 中的更大 buffer。这个“回退”过程涉及内存重分配、上下文切换，甚至可能引发短暂锁竞争，在高并发下会明显拖慢首字节时间（TTFB）。
所以优化目标很明确：让 95%～99% 的请求头都能被第一级缓冲直接容纳，不触发 fallback。
看真实数据，别猜长度
不能凭经验或“保险起见”设成 8k 或 16k。万级并发下，每个连接多占 7KB，worker 进程 RSS 内存可能飙升几百 MB。
你需要从线上日志或抓包中获取真实请求头总长（含请求行 + 所有 header 字段）：
- 在
log_format中加入$request_length（它表示请求行 + 请求头总字节数） - 或用
awk '{print $12}' access.log | wc -c提取$request_length字段并统计分布 - 更准的做法：对典型 JWT 登录请求，手动构造完整请求头字符串，执行
echo -n "GET /api/login HTTP/1.1\r\nHost: a.com\r\nAuthorization: Bearer xxx..." | wc -c
取 P95～P99 分位值（不是最大值），然后向上取整到最近的 1k/2k/4k。
例如实测 P99 是 2350 字节 → 设为 client_header_buffer_size 4k。
必须同步配好 large_client_header_buffers
只调大 client_header_buffer_size 没用，还可能导致 nginx -t 校验失败。
第二级 buffer 的单个 size 必须 ≥ 第一级 size，否则 Nginx 不会启用 fallback。
推荐组合（基于 P99 头长）：
- P99 ≤ 3k →
client_header_buffer_size 4k; large_client_header_buffers 2 8k; - P99 ≤ 6k →
client_header_buffer_size 8k; large_client_header_buffers 4 16k; - 数量别设太多（如 8 或 16），否则单个恶意超长请求可能耗尽 worker 内存
注意：large_client_header_buffers 4 8k 表示最多用 4 个 buffer，但每个请求头必须放进单个 8k buffer 中，不能拼接。
放对位置，且必须校验
该指令只能在 http { } 或 server { } 块顶层生效，写在 location 里会被静默忽略。
- 全局统一策略：直接放在
http块内 - 差异化场景（如 API server 和静态资源 server）：分别在对应
server块内、location外设置
上线前务必运行：
nginx -t
确保语法正确，且 client_header_buffer_size ≤ large_client_header_buffers 的 size 值。
上线后验证是否真有效
不能只看有没有 400 错误，重点观察两个指标：
- 查 error 日志：
grep "client sent too large header" /var/log/nginx/error.log，次数应趋近于 0 - 监控 worker 进程 RSS 内存：对比调优前后高并发时段的波动幅度，若抖动明显收敛，说明减少了频繁内存分配
解析耗时下降通常体现在 TTFB 缩短，尤其在大量带 JWT 或埋点头的移动端请求中效果显著。
