调优 client_header_buffer_size 的核心是让初始缓冲覆盖绝大多数真实请求头长度以避免回退到 large_client_header_buffers。需基于线上流量取 p95～p99 请求头长度并向上取整至 1k/2k/4k，且 large_client_header_buffers 必须匹配（如 4k + 2 8k），配置仅在 http 或 server 块顶层生效，须 nginx -t 校验并监控内存抖动与错误日志。
调优 client_header_buffer_size 的核心不是“设大一点”，而是让初始缓冲刚好覆盖绝大多数真实请求头长度，从而避免频繁回退到 large_client_header_buffers——减少内存反复分配、上下文切换和潜在碎片。
实测 P99 请求头长度是配置起点
盲目设 8k 或 16k 会让每个连接都预占大量内存，万级并发时 worker 进程 RSS 可能陡增数百 MB。必须基于线上真实流量取分位值：
- 在
log_format中加入$request_length和$http_cookie，用awk '{print $12}' access.log | wc -c或sort -n | tail -20提取最长 Cookie 或总头长 - 抓取典型带 JWT 的登录请求，执行
echo -n "完整请求头字符串" | 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 的大小是否 ≥ 第一级：
- 若设
client_header_buffer_size 4k，则large_client_header_buffers至少得是2 4k或4 8k（不能是4 2k） - 推荐组合：
• P99 头长 ≤ 3k →4k + 2 8k
• P99 ≤ 6k →8k + 4 16k - 数量不宜过多（如 8 或 16），否则单个恶意请求可能耗尽 worker 内存；常规业务 2–4 个已足够兜底
配置位置和校验不可跳过
该指令仅在 http 或 server 块顶层生效，放在 location 内会被 Nginx 静默忽略：
- 全局统一策略：直接写在
http { }最外层，所有 server 共享 - 差异化场景（如静态资源 vs API）：分别在对应
server { }块内、location外设置 - 务必执行
nginx -t，确认语法正确，且client_header_buffer_size ≤ large_client_header_buffers的第二个数值
上线后验证是否真减少了内存抖动
效果不能只看是否不再报 400，更要观察是否降低了内存开销：
- 开启
error_log /path/to/error.log notice;，搜索client sent too large header出现次数是否归零 - 监控 worker 进程 RSS 内存变化，对比调优前后高并发时段的波动幅度
- 观察
nginx -s reload后 error.log 是否仍有 fallback 相关日志（如缓冲区重分配提示）
