单设 client_header_buffer_size 不行，因其仅提供初始缓冲，当某行请求头（如超长 Cookie）超出该值时，Nginx 需依赖 large_client_header_buffers 中的扩容缓冲区；但若后者单个 buffer 大小 ≤ 前者，扩容机制失效，直接返回 400 错误。
要真正支持超长请求头（比如含 JWT、多域 Cookie、埋点参数的请求），不能只调大 client_header_buffer_size，必须同步配置 large_client_header_buffers，否则 Nginx 仍会返回 400 错误。
为什么单设 client_header_buffer_size 不行
Nginx 解析请求头时采用两级缓冲机制：
- 第一级用
client_header_buffer_size存常规请求头（如 Host、User-Agent）和首条 Cookie 行； - 当某一行（例如整条
Cookie:字段）超出该大小，Nginx 就尝试用large_client_header_buffers中的一个 buffer 接收它； - 但如果后者中每个 buffer 的大小 ≤ 前者，扩容逻辑不会触发，直接报 400。
推荐配置值与逻辑关系
两个参数需满足：前者 ≤ 后者中单个 buffer 的大小。常见安全有效的组合是：
-
client_header_buffer_size 8k;—— 覆盖多数含长 Token 的 Cookie 场景； -
large_client_header_buffers 4 16k;—— 最多分配 4 个缓冲区，每个最大 16KB，单行可容纳约 16KB 请求头（含换行符等开销）。
这个组合也兼顾了 414 错误（URI 过长）——因为请求行 + 所有请求头必须能放进一个 large buffer 中。
配置位置与生效范围
在负载均衡或反向代理场景下，建议统一放在 http 块中，确保所有 server 和 location 一致生效：
http {
client_header_buffer_size 8k;
large_client_header_buffers 4 16k;
# 其他全局配置...
}若仅静态资源路径（如 .js、.css）偶发报错，也可限定在对应 server 或 location 块内，但需注意继承关系和覆盖优先级。
验证与安全提醒
修改后必须执行两步操作：
- 运行
nginx -t检查语法是否正确； - 执行
sudo nginx -s reload平滑重载配置，不中断服务。
避免无节制放大（如设为 64k 单 buffer），否则可能被用于 slowloris 类型攻击，消耗服务器内存。若日志中同时出现 414，说明 URI 本身也很长，需确认 large buffer 是否足够承载整个请求行+头。
