client_header_buffer_size需与large_client_header_buffers协同配置才能有效解析大请求头；单独调整无效，且必须满足前者≤后者单缓冲区大小，推荐按实测头部长度向上取整并置于http或server块顶层。
client_header_buffer_size 本身不能单独“优化”大请求头的解析，它只是解析流程的第一道门槛。真正起作用的是它和 large_client_header_buffers 的配合关系。设得小，多数请求够用但易报 400；设得大，又浪费内存、放大攻击风险。关键在匹配真实头部长度、保证两级缓冲协同生效。
必须同步配置 large_client_header_buffers
Nginx 解析请求头时用的是两级缓冲机制：
- 第一级用
client_header_buffer_size存请求行（如GET /path?x=y HTTP/1.1）和常规头（如Host、User-Agent） - 当某一行（比如整条
Cookie:或Authorization:）超出这个大小，Nginx 就尝试启用large_client_header_buffers中的一个缓冲区来接管 - 但如果后者中单个 buffer 的大小 ≤ 前者，扩容逻辑直接跳过，立刻返回 400
所以只改 client_header_buffer_size 是无效操作，甚至可能让 Nginx 启动失败（校验不通过）。
按实测长度设最小够用值
别猜，先看真实数据：
- 用
curl -v或浏览器 DevTools 抓一个出错请求，复制全部请求头（含换行符） - 执行
echo -n "完整头字符串" | wc -c得到字节数 - 查 Nginx access log 中
$request_length字段，对比异常请求的头部占比 - 若最大实测为 3200 字节，建议向上取整到
4k（预留 20%~30% 余量），而非直接拍板8k或64k
推荐组合与位置
- 普通 Web 应用（含 JWT Token）：
client_header_buffer_size 4k;large_client_header_buffers 2 8k; - 反向代理/多层网关（X-Forwarded-* 叠加严重）：
client_header_buffer_size 8k;large_client_header_buffers 4 16k; - SSR 或长 URI + 多参数 API：
client_header_buffer_size 384k;large_client_header_buffers 4 512k;
⚠️ 注意：所有配置必须放在http { }块顶层，或至少在server { }块内、location外；放在location内可能不生效。
配套动作不能少
- 运行
nginx -t校验语法，确认client_header_buffer_size ≤ large_client_header_buffers的第二个值 - 执行
sudo nginx -s reload平滑重载（不要 kill 进程） - 开启 error log 的
warn级别，盯住是否还有client sent too large header提示 - 对高风险路径（如
/api/）可单独配置，公开接口（如/health）保持默认1k，缩小攻击面
