Nginx返回400或414错误主因是client_header_buffer_size与large_client_header_buffers未配对配置、位置错误或数值不合理;前者仅控单行请求头初始缓冲(如整条Cookie),不控总长及请求体,必须≤后者单块大小,且须置于server块顶层生效。

Nginx 返回 400 或 414 错误,常常不是请求本身有问题,而是 client_header_buffer_size 和配套参数没配对、没放对位置、或设得不合理。单改一个值基本无效,必须理解它的作用边界和协作逻辑。
client_header_buffer_size 管什么、不管什么
这个参数只控制每行请求头的初始缓冲区大小,比如整条 Cookie: 或 Authorization: 字段。它不控制整个请求头总长,也不管请求体(body)、上传文件、JSON 数据——那些归 client_max_body_size 管。
默认值通常是 1k(1024 字节),现代应用里一个带 JWT 的 Authorization 头就可能超 2KB,一个含多域追踪 ID 的 Cookie 轻松破 4KB,所以默认值根本不够用。
必须同步配置 large_client_header_buffers
client_header_buffer_size 是“第一道门”,但门太小,后面得有“备用房间”。large_client_header_buffers 就是这组备用缓冲池,格式是 数量 大小,例如 4 16k 表示最多分配 4 个、每个 16KB 的缓冲区。
关键规则:
-
client_header_buffer_size的值 必须 ≤large_client_header_buffers的第二个参数(单个 buffer 大小) - 否则 Nginx 启动失败,或 reload 报错
- 如果超长的那一行(如整条 Cookie)比
large_client_header_buffers的单个 buffer 还大,照样返回 400
按场景选合理数值,别堆大
盲目设成 64k 或 1m 不仅浪费内存,还可能被用于 slowloris 类攻击。推荐按实测最大请求头长度向上取整:
- 纯静态站点、无认证:保持
1k即可 - 含 JWT 鉴权(典型 1.2–2.5KB):
client_header_buffer_size 4k; large_client_header_buffers 2 8k - SSR 页面 + 多层网关透传头(X-Forwarded-*, 自定义埋点):
client_header_buffer_size 8k; large_client_header_buffers 4 16k - 前端路由极长 + query 参数爆炸(如 Next.js 动态路由):
client_header_buffer_size 384k; large_client_header_buffers 4 512k(注意前者 ≤ 后者单块)
配置位置要精准,否则不生效
这两个指令只在 http 块顶层或 server 块顶层(location 外)生效。常见误区:
写在 location 里 → 忽略
放在 phpEnv 等集成环境的主 nginx.conf http 块里 → 可能被精简或覆盖
更稳妥的做法:在对应站点的 vhost 文件(如
vhost/your-site.conf)中,server { }块最外层、所有location上方直接写入-
示例:
server { listen 443 ssl; server_name api.example.com; client_header_buffer_size 8k; large_client_header_buffers 4 16k; location / { proxy_pass http://backend; } }
验证与收尾动作不能少
改完必须做两件事:
- 运行
nginx -t检查语法是否正确(尤其注意大小写、分号、单位 k/m) - 执行
sudo nginx -s reload平滑重载,不中断服务
上线后建议: - 用
curl -H "Cookie: $(python3 -c 'print(\"a=\" + \"x\"*8000)')" https://yoursite.com模拟长头请求 - 查看
error.log是否还有too large header或400相关报错 - 若同时出现 414,说明 URI 本身也超长,需确认
large_client_header_buffers单块是否足够容纳“请求行 + 所有头”
不复杂但容易忽略










