这个故障有个很明显的特征：同一个管理员、同一个商品，在无痕窗口能保存，正常窗口点击保存立即400；PHP和Magento日志里却没有请求。清Cookie后恢复几天又复发。既然请求根本没到PHP，就先查Nginx、CDN或负载均衡，不要继续改form_key。

从响应来自哪一层开始

浏览器Network里查看Server、Via、X-Cache等Header，再对照各层错误日志。Nginx通常会记录 client sent too large header 或 request header too large；CDN和WAF可能给自己的400页面。

grep -iE "too large header|request header" /var/log/nginx/error.log | tail -50
nginx -T | grep -E "large_client_header_buffers|client_header_buffer_size"

商品保存是POST，但报错不等于请求Body太大。Cookie属于请求Header，和client_max_body_size没有关系。盲目增加上传限制不会解决。

找出是谁在不断制造Cookie

在浏览器Application面板按Size和Path排序。重点看重复的admin session、表格bookmark、调试工具、A/B测试以及错误设置到顶级域名的前台Cookie。后台路径若与前台共享域名，前台营销脚本产生的几十个Cookie也会随后台请求一起发送。

  • 是否存在同名Cookie但Path不同
  • 是否每次访问都新增带随机后缀的Cookie
  • Cookie Domain是否误设为.example.com，导致所有子域都携带
  • 过期时间是否异常长，删除逻辑是否只删了一个Path

代理限制可以调，但不要只调限制

确认业务确实需要较大Header后，在合适的server/http块调整并验证语法。数值要根据真实Header大小和内存预算确定，下面只是常见示例。

client_header_buffer_size 4k;
large_client_header_buffers 4 16k;

nginx -t && systemctl reload nginx

如果前面还有ALB、Ingress或CDN，它们可能有更低且不可调的上限。此时Nginx调到64k也没用，必须减少Cookie。

Magento侧要检查的配置

  • Web > Default Cookie Settings中的Domain和Path是否过宽
  • Admin > Security中的会话生命周期是否合理
  • 是否有插件把大段JSON写进Cookie
  • 后台与前台是否应该使用独立子域，减少无关Cookie携带

临时让用户清Cookie只是止痛。真正修复后，新会话连续使用数天Cookie数量应保持稳定。可以在测试环境记录每次后台导航时Cookie Header长度，发现单调增长就继续追写入源。

验证

curl -vk https://admin.example.com/ -H 'Cookie: test=1'
# 同时在浏览器中保存商品、保存分类、导出列表，确认各类POST都正常
400发生在PHP之前时，Magento日志为空是正常现象。先沿请求链找出哪一层拒绝，再决定是缩短Cookie还是调整Header上限。