这类问题我又碰上了一次。WordPress 站点前面挂 nginx 反代，登录后台时偶发 502，error_log 里写 upstream sent too big header while reading response header from upstream，把 buffer 参数随手加了 4k 之后还是偶发。
第一反应是「fastcgi_buffers 的数量和大小按默认值配，大响应头直接被截断」，验证下来不成立。
原因不止一个，得分开看。上游返回的 Set-Cookie 和 X-Powered-By 加起来超过了 proxy_buffer_size；PHP 那边输出了很长的 header，反代默认只给 4k 的头缓冲；浏览器把历史 cookie 一起带上来，服务端又把这些回写进响应头。
去上游确认响应头到底多大
curl -sI -H 'Cookie: test=1' http://127.0.0.1:8080/ | wc -c随后把代理相关缓冲调大并写进站点配置
grep -rnE 'proxy_buffer_size|fastcgi_buffer_size' /etc/nginx/整段替换成显式参数再检查重载
nginx -t && nginx -s reload带大 cookie 复现一次看是否还报
curl -s -o /dev/null -w '%{http_code}' -H 'Cookie: a=1;b=2' https://www.example.com/同事提醒我看一下最近一次发布，时间点确实对得上。
怎么算真的好了，看的是同一批现象。带大 cookie 反复请求两百次都返回 200，error_log 里不再出现 too big header，后台登录不再掉线。
补一句。把 proxy_buffer_size 调到 16k 以上会多占内存，先查清是哪个头在膨胀，多数情况是 cookie 没有及时瘦身。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。