Nginx默认client_header_buffer_size（通常1k或4k）不足以容纳超长Cookie时，会直接返回400 Bad Request；应调大该值（如8k）并同步配置large_client_header_buffers（如4 16k），确保单行请求头最长支持16KB，同时避免无限制增大以防慢速攻击。
当用户 Cookie 过长（例如含大量跟踪参数、登录态或前端埋点数据），Nginx 默认的 client_header_buffer_size（通常为 1k 或 4k）可能不足以容纳完整的请求头，导致直接返回 400 Bad Request，且日志中常出现 client sent too large header 或 too long URI 类似提示——这不是应用层问题，而是 Nginx 在解析 HTTP 请求头阶段就拒绝了连接。
理解 client_header_buffer_size 的作用
该指令定义 Nginx 读取客户端请求头时，为单个请求头行分配的初始缓冲区大小。它不控制整个请求头总长，而是每行（如 Cookie: xxx、User-Agent: xxx）各自独立使用该缓冲。若某一行（尤其是超长 Cookie 行）超出该值，Nginx 就会报 400。
注意：client_header_buffer_size 必须 ≤ large_client_header_buffers 中单个 buffer 的大小；后者用于当首缓冲不够时的扩容，但前提是首缓冲已满且行未结束。
推荐配置方案（兼顾安全与兼容）
多数场景下，将 client_header_buffer_size 调至 8k 即可覆盖绝大多数含长 Cookie 的合法请求（如 SSO 登录后携带多域 Token、A/B 测试参数等）。同时必须同步调整 large_client_header_buffers，否则扩容机制不生效：
- 在 http 块或 server 块中添加：
client_header_buffer_size 8k; large_client_header_buffers 4 16k;
含义：初始缓冲 8KB；最多允许 4 个扩容缓冲，每个最大 16KB。这样单行最长可支持约 16KB（实际略小，因需存放换行符等）。
⚠️ 不建议无限制调大（如设为 64k），否则可能被用于慢速攻击（如发送超长畸形头耗尽内存）。
验证是否生效 & 排查要点
修改后重载 Nginx（nginx -s reload），再通过以下方式确认：
- 用 curl 模拟长 Cookie 请求：
curl -H "Cookie: $(printf 'a=%.0s' {1..7000})" https://yoursite.com/（生成约 7KB Cookie） - 检查 Nginx 错误日志（
error_log）是否还有400相关 header 报错 - 确认响应状态码是否变为 200 或后端真实返回码（说明请求已透传）
若仍报 400，请检查：
– 是否在多个配置块（如 http/server/location）中重复定义并被低优先级覆盖
– 后端服务（如 Node.js、Tomcat）自身也有 header 长度限制，需同步调大
– 浏览器实际发送的 Cookie 总长是否超过 8KB（HTTP 规范建议单个 Cookie ≤ 4KB，但现代浏览器支持更大）
更健壮的长期策略
单纯调大缓冲只是兜底，治本建议结合业务优化：
- 前端减少 Cookie 写入量：用 localStorage 存非关键标识，仅保留必要 session_id
- 后端改用 Header 传 Token（如
Authorization: Bearer xxx），避免挤占 Cookie 字段 - 对登录态做服务端 Session + 短 ID Cookie，而非全量信息存客户端
- 在 Nginx 中用
map或 Lua 检测超长 Cookie 并记录告警，便于定位异常来源
不复杂但容易忽略。
