nginx 报“400 bad request: request header or cookie too large”错误，主因是 client_header_buffer_size（默认1kb）和 large_client_header_buffers 设置过小，无法承载加密cookie（常3–8kb），需同步调大二者并源头优化cookie体积。
遇到“400 Bad Request: Request Header Or Cookie Too Large”错误，大概率不是后端出错，而是 Nginx 在解析请求头阶段就拒绝了连接——根源在于 client_header_buffer_size 默认值太小（通常仅 1KB），根本装不下含 JWT、Base64 加密状态或跨域追踪 ID 的超大 Cookie 单行。
先确认是不是 Cookie 真的太大
别靠猜测，用真实数据判断：
- 打开浏览器开发者工具 → Network → 找一个失败请求 → Headers → 查看 Request Headers 中的
Cookie:行 - 右键复制该行内容，粘贴到编辑器里，统计字节数（ASCII 编码下，1 字符 ≈ 1 字节）
- 常见加密 Cookie（如含完整 JWT、用户画像 JSON、多埋点 ID）常达 3–8KB；若超过 4KB，基本可确认触发限制
- 同时检查 Nginx 错误日志（
error_log），典型报错为：
"client sent too large header while reading client request headers" 或明确提示 cookie too large
必须协同调整两个参数，不能只改一个
client_header_buffer_size 是“第一道门”，而真正兜底的是 large_client_header_buffers。两者分工明确，缺一不可：
-
client_header_buffer_size 4k;—— 提升初始缓冲，覆盖 95% 含加密态的常规请求，比默认 1k 更稳，又不浪费内存 -
large_client_header_buffers 4 16k;—— 允许最多 4 个备用缓冲区，每个最大 16KB；这意味着单行 Cookie 最长可支持约 16KB（实际略小，含换行符等开销） - 关键约束：
client_header_buffer_size的值必须 ≤large_client_header_buffers中单个 buffer 的大小，否则扩容机制不会触发 - 配置位置建议放在
http块（全局生效）或具体server块（精准控制某域名），避免层级冲突
加密 Cookie 场景下的实用建议
加密 Cookie 往往体积膨胀严重，光调参是兜底，源头优化更关键：
- 避免在 Cookie 中直接存原始 JWT 或 Base64 编码的长串；改用服务端 session + 短 token ID（如
sess_abc123） - 对前端 SDK、埋点脚本注入的冗余 Cookie（如
_ga、amplitude_id）做子域隔离，防止与主站 Cookie 合并变长 - 启用
SameSite=Lax和HttpOnly，虽不减长度，但能降低异常写入风险 - 后端响应时校验
Set-Cookie总长，对超 4KB 的值主动截断或拒绝下发，从源头阻断膨胀
验证是否生效
改完配置别跳过验证步骤：
- 执行
nginx -t检查语法，再用nginx -s reload平滑重载 - 用 curl 构造测试请求：
curl -v -H "Cookie: $(python3 -c 'print(\"auth=\" + \"x\"*5000)')" https://yoursite.com/ - 观察返回是否变为 200（或预期状态），同时确认 error.log 不再出现相关 400 报错
- 若仍失败，说明 Cookie 实际长度已接近或超过 16KB，可临时尝试
large_client_header_buffers 4 32k;进一步排查
