400 Bad Request 错误常因 Cookie 过长触发，需调大 client_header_buffer_size（默认1k）至4k或8k，并配合large_client_header_buffers；更应从源头精简Cookie、隔离埋点、使用服务端session。
当用户访问网站时遇到 400 Bad Request 错误，且日志中提示 "client sent too long header line" 或类似信息，大概率是 Cookie 过长，超出了 Nginx 默认的请求头缓冲区大小。client_header_buffer_size 正是控制这一缓冲区的关键参数。
理解 client_header_buffer_size 的作用
该指令定义 Nginx 读取客户端请求头（包括 Cookie、User-Agent、Host 等）时，初始分配的内存缓冲区大小。默认值通常为 1k（1024 字节）。如果单行请求头（例如一个超长的 Cookie）超过这个值，Nginx 就会直接返回 400，并记录错误。
注意：它只影响“单行”长度，不是整个请求头总和；整行超限即触发限制，不等待后续合并或分块处理。
如何合理调整该参数
调整需兼顾安全与兼容性，不宜盲目设大：
- 先确认实际 Cookie 长度：用浏览器开发者工具 → Network → 点击请求 → Headers → 查看
Cookie字段字节数（含等号、分号、空格） - 常见业务场景下，登录态 + 多个追踪 ID 的 Cookie 可能达 2–4KB；建议初始调至
4k或8k - 在
http、server或location块中设置，推荐放在server块内以精准控制特定站点：client_header_buffer_size 8k; - 若仍报错，再配合
large_client_header_buffers（用于处理超大但合法的多行头），例如：large_client_header_buffers 4 16k;（表示最多 4 个缓冲区，每个 16k）
比调参更治本的优化方向
单纯加大缓冲区只是兜底手段，长期应从源头减少 Cookie 膨胀：
- 避免在 Cookie 中存储 JSON、Token 原文或大量元数据；改用服务端 session + 短 ID 存 Cookie
- 对前端 SDK、埋点脚本产生的冗余 Cookie（如
_ga、amplitude_id）做域名隔离或子域清理 - 启用
Cookie SameSite=Lax和HttpOnly等策略，虽不减长度，但可降低被滥用导致异常写入的风险 - 后端响应时检查
Set-Cookie总长，对超长值主动截断或拒绝下发
验证是否生效
修改配置后必须重载 Nginx（nginx -s reload），然后通过真实请求复现测试：
- 用
curl构造长 Cookie 请求：curl -H "Cookie: $(python3 -c 'print(\"a=\" + \"x\"*6000)')" https://yoursite.com/ - 观察响应状态码是否变为 200（或预期行为），同时检查 error.log 不再出现相关 400 报错
- 也可临时把
client_header_buffer_size设为极小值（如100），快速验证拦截逻辑是否起作用
