应根据错误日志中“upstream sent too big header”后的实际字节数设置fastcgi_buffer_size，取略大的2的幂值（如14280→16k），并确保其不超过fastcgi_buffers单块大小，同时配套调整fastcgi_busy_buffers_size和fastcgi_temp_file_write_size。
直接看错误日志定值，别凭感觉设 64k 或 128k——fastcgi_buffer_size 只管响应头（status line + 所有 headers），和页面内容大小无关。设小了报 502 或头截断，设大了纯属浪费内存。
从 error.log 抓真实头大小
遇到 502 或 Cookie/Location 头不完整，打开 Nginx 错误日志（如 /var/log/nginx/error.log），搜索关键词：
upstream sent too big header
找到对应行，后面紧跟着类似：
header: 14280 bytes
这个数字就是 PHP 实际输出的响应头总字节数，记下来。
设一个“刚好够用”的值
取比日志数字略大的、2 的幂值（利于内存对齐，也符合 Nginx 内部机制）：
• 14280 → 推荐 16k（16384 字节）
• 21500 → 推荐 32k（32768 字节）
• 超过 48KB 才考虑 64k，一般伪静态或调试模式下 16k–32k 覆盖 95% 场景
在 location ~ \.php$ { } 块里加上：
fastcgi_buffer_size 16k;
检查 fastcgi_buffers 单块大小是否匹配
这个值必须 ≤ fastcgi_buffers 中每个 buffer 的 size，否则无效：
• 若已有 fastcgi_buffers 8 16k;，那 fastcgi_buffer_size 最大只能是 16k
• 想设 32k？就得同步改成 fastcgi_buffers 8 32k; 或 fastcgi_buffers 12 32k;
不用删原有配置，补上 fastcgi_buffer_size 即可生效。
顺手调好配套参数防连锁问题
单改一个容易出新问题，建议一并确认：
• fastcgi_busy_buffers_size：设为单个 buffer 大小的 2 倍，如用 16k buffer 就设 32k
• fastcgi_temp_file_write_size：也设成和 busy_buffers_size 一致，避免小块频繁刷磁盘
• 确保 fastcgi_pass 指向正确（127.0.0.1:9000 或 socket 路径），且 PHP-FPM 正在运行
改完执行：
nginx -t && nginx -s reload
再用 curl -I 访问原页面，检查 Set-Cookie、Location 等关键头是否完整返回。
