proxy_buffer_size过小导致Nginx无法容纳后端返回的响应头，触发“upstream sent too big header”错误并返回502；该参数专用于缓存响应头，默认4k或8k，需根据实测头部大小设为16k–64k，并同步配置proxy_buffers和proxy_busy_buffers_size。
这个错误直接说明 Nginx 在读取后端（upstream）返回的响应头时，发现其大小超过了自身分配的缓冲区容量，于是中断连接并返回 502。关键不在于“后端出错”，而在于“Nginx 装不下它发来的头”。根因分析必须聚焦在响应头实际体积和 Nginx 缓冲能力的匹配关系上。
查日志确认错误上下文
打开 Nginx 错误日志（通常是 /var/log/nginx/error.log），搜索完整报错行：
- 确认是否为 upstream sent too big header while reading response header from upstream —— 这是标准标识，排除其他 502 类型（如超时、连接拒绝）
- 记录对应时间点、client IP、请求路径（如
/login或/api/refresh），这些往往是 Cookie 写入密集的操作 - 观察是否集中出现在特定接口或用户行为后（例如登录成功、Token 刷新、多域名跳转），这是 Cookie 爆炸的典型信号
抓响应头验证真实体积
用 curl -v 获取原始响应头，比 -I 更可靠（后者可能被中间代理截断）：
- 执行：
curl -v https://your-domain.com/login 2>&1 | grep '^ - 结果若明显超过 4096 字节（4KB），尤其是达到 8KB～16KB，基本可锁定是 header 过大
- 重点看
Set-Cookie:行：是否有多条？单条是否含长 JWT、base64 编码串、或重复的SameSite=None; Secure字段？这些都会快速推高体积
排查后端 Cookie 构造逻辑
很多问题不出在 Nginx 配置，而出在服务端无意识地堆叠 Cookie：
- Spring Boot 应用检查
CookieSameSiteSupplier或过滤器中是否反复调用response.addCookie() - Node.js（Express）查看是否有多个
res.cookie()调用，或未清理旧 Cookie 就写新 Token - 跨子域场景（如
a.example.com和b.example.com）是否共享了同一份长 Cookie，导致每次响应都携带冗余字段 - OAuth2 或 SSO 流程中，是否把整个用户信息 JSON 序列化后塞进 Cookie，而非仅存 ID + 签名
区分 proxy 与 fastcgi 场景
配置参数不能混用，先确认你的架构类型：
- 如果 Nginx 直连 Java/Python/Go 后端（HTTP 协议），用的是 proxy_* 系列指令（
proxy_buffer_size等） - 如果 Nginx 通过 FastCGI 连 PHP-FPM，则必须用 fastcgi_* 指令（
fastcgi_buffer_size），proxy_*完全无效 - 错误日志里若出现
fastcgi字样（如upstream sent too big header while reading upstream fastcgi header），就只调 fastcgi 参数
