确认Nginx 502是否由响应头过大引起，需查error.log中“upstream sent too big header while reading response header from upstream”报错，用curl -v实测响应头字节数，超4KB则调大proxy_buffer_size（如16k），并同步配置proxy_buffers和proxy_busy_buffers_size。
直接看 Nginx 错误日志里有没有 “upstream sent too big header” 这行报错，有就基本锁定是响应头过大导致的 502。这不是后端挂了，也不是网络断了，而是 Nginx 在读响应头时发现“头太长、桶太小”，直接中止连接并返回 502。
查 error.log 找关键线索
打开 /var/log/nginx/error.log，搜索完整错误行：
- 必须匹配 upstream sent too big header while reading response header from upstream —— 这是唯一有效标识
- 注意记录对应时间、请求路径（如
/login、/api/refresh）、客户端 IP，这些常与 Cookie 写入或 Token 刷新强相关 - 观察是否集中在特定操作后出现，比如登录成功、跨子域跳转、JWT 续期，这是 Cookie 或 Header 膨胀的典型信号
实测后端响应头真实大小
别靠猜，用 curl -v 直连后端获取完整响应头（-I 可能被截断）：
- 执行：
curl -v http://127.0.0.1:8000/login 2>&1 | grep '^<'，再用wc -c统计字节数 - 重点检查
Set-Cookie行：是否含超长 JWT、未分片的 session、重复SameSite=None; Secure、base64 签名等 - 留意其他大头字段：如
X-Trace-ID、Link、WWW-Authenticate、自定义调试头
确认代理类型，选对配置参数
先分清你用的是 HTTP 代理还是 FastCGI：
- 直连 Java/Python/Go 后端（HTTP 协议）→ 用
proxy_buffer_size、proxy_buffers等 - 通过 FastCGI 连 PHP-FPM → 必须用
fastcgi_buffer_size、fastcgi_buffers，proxy_*完全无效 - 错误日志里若出现
fastcgi header字样，就只调fastcgi_buffer_size
调参要配套，不能只改一个
仅增大 proxy_buffer_size 容易掩盖问题，需协同调整：
-
proxy_buffer_size 16k或32k（建议从 16k 起步，按实测值向上取整） -
proxy_buffers 8 16k（控制响应体缓冲，避免与 header 缓冲争资源） -
proxy_busy_buffers_size 32k（建议设为proxy_buffers总量的 50%~100%） - 若用 HTTP/2，额外检查
http2_max_field_size（默认 4k，可能单独触发截断）
