合理范围是根据实测p99请求头长度向上取整的最小够用值，通常1k–8k，95%业务在2k–4k；必须与large_client_header_buffers单buffer大小匹配（如设4k则后者至少4k），且配置于http或server块顶层。
合理范围不是固定数值，而是根据真实请求头长度动态确定的最小够用值——通常在 1k 到 8k 之间，95% 以上业务落在 2k–4k 区间；盲目设到 16k 或更高，反而会放大内存开销与攻击面。
按实测 P99 长度向上取整
不靠猜测，靠线上数据：
- 在 log_format 中加入
$request_length，统计访问日志中请求头实际字节数 - 抓取典型长请求（如带 JWT 的登录后 API 调用），用
echo -n "完整请求头" | wc -c精确测量 - 取 P99 分位值（覆盖 99% 的请求），再向上取整到最近的 1k/2k/4k/8k ——例如实测 2350 字节，就设为 4k，而非直接跳到 8k
必须匹配 large_client_header_buffers 单 buffer 大小
client_header_buffer_size 单独调大无效，关键看它和第二级缓冲的大小关系：
- 若设为 4k，则
large_client_header_buffers中每个 buffer 至少得是 4k 或更大，比如2 8k或4 8k - 不能写成
4 2k—— 因为单 buffer（2k）＜初始 buffer（4k），扩容逻辑直接失效，仍返回 400 - 推荐组合：
• 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;
配置位置与生效层级要准确
放错地方等于没配：
- 只能写在
http { }或server { }块顶层，不能放在 location 内 —— Nginx 会静默忽略 - 全局统一策略：写在 http 块最外层，所有虚拟主机共享
- 差异化需求（如 API 服务需更大缓冲，静态资源保持默认）：分别在对应 server 块内设置
上线后验证是否真起效
调完不验证，等于白调：
- 先执行
nginx -t，确保语法正确且client_header_buffer_size ≤ large_client_header_buffers的单 buffer 值 - 开启 error_log 的 notice 或 warn 级别，搜索关键词
client sent too large header，确认该提示归零 - 观察 worker 进程 RSS 内存是否稳定 —— 若从频繁抖动变为平缓，说明扩容次数显著下降
