Nginx因响应头过大触发502错误，需按日志定位、实测体积、配置匹配、源头治理四步排查：先查error.log锁定报错时间、路径及IP；再用curl -v实测响应头字节数。
看到 upstream sent too big header while reading response header from upstream 这条报错，说明 Nginx 在接收后端响应头时缓冲区不够用了，不是后端挂了、也不是网络断了，而是“头太大，桶太小”，直接中断连接返回 502。排查要从日志定位、实测体积、配置匹配、源头治理四步走。
查 error.log 锁定真实报错和上下文
打开 /var/log/nginx/error.log，搜索完整错误字符串：
upstream sent too big header while reading response header from upstream
只认这一行——其他带 502 的（如 timeout、connection refused）不相关。
重点记录三样东西：
- 报错时间（精确到秒），用来和 access.log 对齐请求路径与客户端 IP
- 请求路径（如 /login、/api/token/refresh），这类接口常伴随 Cookie/JWT 写入
- 是否集中出现在登录成功、单点登出、跨子域跳转后——这是 Cookie 爆炸的典型信号
用 curl 实测响应头真实字节数
别猜，要测。执行：
结果包含状态行（如 HTTP/1.1 200 OK）、所有 Header 字段及每个字段后的 \r\n，才是真实体积。
若 ≥ 4096 字节（4KB），基本可确认超限；达到 8–16KB 就非常典型了。
重点关注 Set-Cookie: 行：
- 是否有多条？
- 单条是否含长 JWT、base64 签名、重复的 SameSite=None; Secure;？
- 有没有调试头（如 X-Debug-Info）或中间网关追加的冗余字段？
确认架构类型，选对缓冲参数
先分清你用的是 proxy 还是 fastcgi：
- 直连 Java/Python/Go 后端（HTTP 协议）→ 只调 proxy_buffer_size、proxy_buffers、proxy_busy_buffers_size
- 通过 FastCGI 连 PHP-FPM → 必须用 fastcgi_buffer_size 等，proxy_* 完全无效
错误日志里若出现 fastcgi 字样，就只看 fastcgi 相关参数。
精准调参 + 检查约束关系
proxy_buffer_size 是专存响应头的，必须完整装下最大头才能解析状态码。
它不是孤立生效的，需同步配齐：
- 根据实测值向上取整设值：比如 header: 5212 → 设 proxy_buffer_size 6k 或 8k；测出 12KB → 设 16k
- 该指令必须写在 location 块内，且出现在 proxy_pass 之前
- 配套调整：proxy_buffers 8 16k（共 128KB 存响应体），proxy_busy_buffers_size 64k（须 ≥ proxy_buffer_size，且 < 总 buffers 减一个块）
- 若用 HTTP/2，额外检查 http2_max_field_size（默认 4k），它限制单个 Header 字段长度，JWT 易触发
