Nginx报“Request Header Or Cookie Too Large”400错误，本质是单行请求头（如整条Cookie）超出缓冲区容量；必须同步配置client_header_buffer_size≤large_client_header_buffers单buffer大小（如8k和4 16k），并优先从源头精简Cookie。
HTTP 400 报错中“Request Header Or Cookie Too Large”这类提示，基本是 Nginx 在解析请求头时被拦下来的——真正卡住的不是总长度，而是单行头部（尤其是整条 Cookie）超出了缓冲区容量。large_client_header_buffers 不是万能开关，它和 client_header_buffer_size 是一对协作参数，必须配对调整才有效。
先确认是不是它在报错
别急着改配置，先看证据：
- 查 Nginx error.log，搜索 "client sent too large header"、"too long header line" 或 "400 Bad Request"，重点关注静态资源路径（如 /app.js、/style.css）
- 用 curl 模拟长 Cookie：curl -H "Cookie: $(python3 -c 'print(\"a=\" + \"x\"*12000)')" https://yoursite.com/app.js，看是否稳定复现 400
- 打开浏览器 Network 面板，点开失败请求 → Headers → 找到 Cookie 行 → 右键 Copy value → 粘贴到编辑器里数字符数（注意：URL 编码后字节数会增加）
合理设置 large_client_header_buffers
这个指令控制的是“备用大缓冲区”的数量和单个大小，只用于承接超出初始缓冲的超长单行（比如一条 14KB 的 Cookie）。关键不是堆总量，而是确保单 buffer 能装下最长的那一行：
- 若实测最长 Cookie 接近 12KB，推荐设为 large_client_header_buffers 4 16k（单 buffer ≥ 16KB，数量 ≥ 2，留出 Host、Referer 等其他头的空间）
- 不要设成 16 64k——总上限达 1MB，易被用于 DoS 攻击，也浪费 worker 进程内存
- 可放在 http 块（全局）、server 块（单域名）或精准的 location 块（如 location ~* \.(js|css|png|jpg|gif|ico)$），优先选 server 块，避免影响无关服务
必须同步配 client_header_buffer_size
large_client_header_buffers 是“后备方案”，能否触发取决于初始缓冲是否溢出：
- client_header_buffer_size 必须 ≤ large_client_header_buffers 中的单 buffer 大小；例如设了 large_client_header_buffers 4 16k，那 client_header_buffer_size 最多只能是 16k（通常设 4k 或 8k 更稳妥）
- 如果 client_header_buffer_size 设成 32k，但 large_client_header_buffers 是 4 16k，Nginx 启动会直接报错
- 推荐组合：client_header_buffer_size 8k; + large_client_header_buffers 4 16k;
更治本的优化方向
调大缓冲区只是快速止血，长期应减少请求头体积：
- 静态资源走 Cookie-free 域名（如 static.example.com），彻底隔离 Cookie 传输
- 把 JWT、用户上下文等大字段从 Cookie 移到 Authorization Header 或请求体，配合后端适配
- 精简第三方 SDK 注入的冗余 Cookie（如 _ga、amplitude_id），通过子域隔离或定期清理
- 后端 Set-Cookie 时主动截断超长值，或改用服务端 session + 短 ID 存 Cookie
