网站突然返回400 Bad Request，并显示Request Header Or Cookie Too Large，很多人会先去调上传限制。其实这个错误发生在读取请求头阶段，与上传文件使用的请求体限制不是一回事。
真正要判断的是请求行、单个请求头字段还是整个请求头过大。 Cookie最常见，但反向代理重复写入认证信息、跳转链不断累积Cookie，也会让同一问题反复出现。
先确认错误来自请求头
先查看Nginx错误日志，常见路径是 /var/log/nginx/error.log，也可能在站点配置中单独指定：
sudo tail -n 100 /var/log/nginx/error.log
sudo nginx -T 2>/dev/null | grep -nE 'error_log|large_client_header_buffers|client_header_buffer_size'日志出现 client sent too large header 或 request header or cookie too large，才适合继续处理请求头缓冲区。若状态码是413，应检查 client_max_body_size；若是414，则更接近请求URI本身过长。
再用浏览器无痕窗口访问同一地址。无痕窗口正常、普通窗口报错，通常说明现有Cookie过大或已经损坏。不要只看到400就修改Nginx，普通400还可能来自无效Host、错误协议或请求格式。
理解两个缓冲区配置
Nginx先使用 client_header_buffer_size 读取普通请求头，装不下时才按需分配 large_client_header_buffers。官方文档给出的后者默认值是4个8K缓冲区：
client_header_buffer_size 1k;
large_client_header_buffers 4 8k;这里最容易误解的是，单个请求行或单个请求头字段必须放进一个缓冲区，不能靠增加缓冲区数量把一个超长Cookie拆开。 因此单个Cookie字段超过8K时，把4改成8未必有效，通常需要评估单个缓冲区的大小。
这两个指令可放在 http 或 server 上下文。多虚拟主机场景中，服务端选择阶段可能使用默认虚拟主机的配置，想避免规则落错位置，统一策略更适合放在 http 块中。
先清理异常Cookie再改配置
若只有个别浏览器报错，先在开发者工具中查看目标域名的Cookie，确认是否存在异常长值、重复会话或已经废弃的认证字段。删除该站点Cookie后重新登录，能够快速判断问题是否来自客户端残留。
网站程序也要检查Cookie的Domain、Path、过期时间和SameSite设置。多个子域共用同一个顶级域Cookie时，请求会携带更多内容；应用每次跳转都追加新值，也可能让请求头持续增长。
清Cookie只能恢复当前访问，不能修复服务端反复生成超长Cookie的逻辑。 如果新会话很快再次报错，应继续检查登录插件、SSO、购物车、A/B测试和代理层写入的响应头。
按实际需要调整Nginx
确认业务确实需要更大的认证Cookie后，先备份配置，再做小幅调整。下面只是常见起点，不应直接当成所有站点的固定值：
http {
client_header_buffer_size 2k;
large_client_header_buffers 4 16k;
}修改后必须先检查语法：
sudo nginx -t
sudo systemctl reload nginx容器中的Nginx可能没有systemd，可在对应容器内执行 nginx -t，确认通过后再用容器编排方式滚动更新。不要跳过语法检查直接重启，否则一个分号错误就可能让服务无法重新加载。
别把缓冲区无限调大
较大的请求头缓冲区会按需分配，并不等于启动时立刻占满全部内存，但并发连接多时仍会增加资源使用，也可能掩盖应用持续制造异常Cookie的问题。更大的上限还意味着网关需要接受更大的攻击输入。
若前面还有CDN、负载均衡器、WAF或Ingress，它们也有自己的请求头限制。只提高源站Nginx上限，外层设备仍可能先返回400或431。应从客户端到最外层入口逐级确认响应头和日志，找出真正拒绝请求的一层。
需要复制同版本环境验证配置时，可以在 萤光云 建立临时测试机；跨地区复现代理链时，也可使用 LightNode 按小时部署环境。测试Cookie和会话令牌必须使用脱敏数据。
修改后的验收标准
重新访问此前稳定复现的URL，同时观察状态码与错误日志：
curl -sS -o /dev/null -D - https://example.com/
sudo tail -f /var/log/nginx/error.log还要分别验证新登录会话、旧Cookie、无痕窗口和常用子域。不能只确认首页打开，还要测试登录、跳转、提交表单和退出登录等真正会改变Cookie的流程。
验收通过应同时满足原请求恢复、错误日志不再出现同类记录、Cookie没有持续增长，并且外层代理与源站限制保持一致。 若只能靠不断扩大缓冲区维持访问，根因仍在应用层。
FAQ
这个错误和413 Request Entity Too Large一样吗？
不一样。前者针对请求行或请求头，413通常针对请求体大小，配置项也不同。
只增加large_client_header_buffers的数量可以吗？
单个请求头字段仍必须放入一个缓冲区。数量增加主要影响总请求头容量，单个Cookie超长时还要评估每个缓冲区的大小。
改完配置必须重启Nginx吗？
通过 nginx -t 后执行平滑reload通常即可。容器环境应遵循现有编排和发布流程，不要直接杀掉主进程。
温馨提示
请求头上限应该满足真实业务，同时保留合理边界。先清理异常Cookie并找到生成源，再做最小幅度的缓冲区调整，比直接放大到很高的数值更稳妥。
