client_header_buffer_size 与 large_client_header_buffers 必须匹配才能保障请求头正常解析；前者为初始缓冲大小，后者提供扩容能力，不匹配则请求在解析阶段即返回400错误，无法进入后续处理流程。
client_header_buffer_size 本身不“优化”请求处理链，它只是请求头解析流程的第一道门槛。真正影响处理效率和稳定性的，是它与 large_client_header_buffers 的协同关系——两者不匹配，请求直接失败；匹配得当，才能让合法的大请求头被顺利解析、进入后续处理环节。
理解两级缓冲如何影响请求流转
Nginx 不是一次性把整个请求头读进一块大内存，而是分两步：
- 先用 client_header_buffer_size 这块小内存接收请求行（如 GET /api HTTP/1.1）和常规头（Host、User-Agent 等）
- 当某一行头（比如整条 Cookie 或 Authorization）超出该大小，就尝试启用 large_client_header_buffers 中的一个缓冲区来承接
- 但如果后者的单个 buffer 大小 ≤ 前者，扩容逻辑跳过，请求立刻中断，返回 400 错误
这意味着：请求根本没机会走到 location 匹配、反向代理、SSL 解密等后续环节——卡在解析阶段就被拒了。
按实测长度设最小够用值
别靠经验拍脑袋，关键看真实流量：
- 用浏览器 DevTools 或 curl -v 抓一个出错请求，复制全部请求头（含换行符）
- 执行 echo -n "头内容" | wc -c 得到字节数
- 查 Nginx access log 的 $request_length 字段，对比异常请求中 header 占比
- 若最大实测为 3200 字节，向上取整到 4k（预留 20%~30% 余量），而非直接设 8k 或 64k
必须同步配置 large_client_header_buffers
只改 client_header_buffer_size 是无效操作，甚至可能让 nginx -t 校验失败：
- 要求：client_header_buffer_size ≤ large_client_header_buffers 的第二个值（单 buffer 大小）
- 普通 Web 应用（含 JWT）：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 校验语法，再 nginx -s reload 平滑重载
- 开启 error_log warn 级别，紧盯是否还有 “client sent too large header” 提示
- 对高风险路径（如 /api/）可单独调大，公开接口（如 /health）保持默认 1k，缩小攻击面
