client_header_buffer_size 控制 Nginx 为每个请求分配的初始请求头缓冲区大小，仅影响请求行和 Header 行读取，不处理请求体、不共享内存、不加速传输；默认 1k 常不足，需结合 large_client_header_buffers 合理配置，以避免回退分配带来的性能损耗。
client_header_buffer_size 本身不“提升性能”，它只决定请求头能否被完整读入内存；真正影响读取效率的是它与 large_client_header_buffers 的协同是否合理——配得小，多数请求快但易报 400；配得大，单次读取可能省事，却增加内存开销和攻击面。优化目标不是让缓冲区变快，而是让绝大多数请求一次命中初始缓冲、避免回退分配，从而减少内存分配次数和上下文切换。
它到底管什么：别被名字带偏
这个参数仅控制 Nginx 为每个请求分配的**初始请求头缓冲区大小**，用于存放：
- 请求行（如 GET /api/user?id=123 HTTP/1.1）
- 各 Header 行（如 Host: example.com、Cookie: a=b; c=d、Authorization: Bearer xxx）
它不管请求体（body），也不共享内存，更不加速网络传输。默认 1k 对现代业务常不够用，尤其当 Cookie 含 JWT 或代理链叠加 X-Forwarded-* 头时，一行就可能超 2KB。
怎么配才减少读取开销
关键不是“越大越好”，而是让真实请求头长度 ≤ client_header_buffer_size，从而跳过 fallback 流程。Nginx 每次触发 large_client_header_buffers 分配，都要额外 malloc + copy，高并发下可观测到 worker 内存波动和 CPU 上升。
- 用 curl -v 或浏览器 DevTools 抓一个典型请求，复制全部请求头（含换行符）
- 执行 echo -n "头内容" | wc -c 得到字节数
- 查 access log 中 $request_length 字段，减去 URI 和 query 长度，估算头部净长
- 取 P99 实测值，向上取整到最近的 2k/4k/8k —— 比如实测最大 3120 字节，设为 4k 即可
必须同步调的配套参数
只改 client_header_buffer_size 是无效甚至危险的。它必须和 large_client_header_buffers 形成有效配合：
- client_header_buffer_size 必须 ≤ large_client_header_buffers 的第二个值（单块大小），否则 Nginx 启动失败
- 例如设 client_header_buffer_size 4k，则 large_client_header_buffers 2 8k 合理，而 2 2k 会直接跳过扩容逻辑，仍返回 400
- 普通 Web 应用推荐：4k + 2 8k；反向代理场景建议：8k + 4 16k
- 所有配置放在 http {} 块顶层 或 server {} 块内（不在 location 中），否则可能不生效
验证是否真起作用
改完别只看能不能通，要确认是否真正减少了缓冲区回退：
- 执行 nginx -t 校验语法，特别检查大小关系
- 重载配置：nginx -s reload
- 开启 error_log warn 级别，盯住日志是否还有 "client sent too large header"
- 模拟超长头测试：curl -H "Cookie: $(python3 -c 'print(\"a=\"+\"x\"*3500)')" http://your.site/，应返回 200 而非 400
