502错误因后端响应头过大导致，需调大proxy_buffer_size（如16k/32k），并同步配置proxy_buffers和proxy_busy_buffers_size，同时从源头精简Cookie、JWT、调试头等冗余响应头。
遇到 502 Bad Gateway，且错误日志里明确写着 “upstream sent too big header while reading response header from upstream”，基本就是 proxy_buffer_size 不够用了。它专管后端返回的响应头（Header），比如长 Cookie、JWT、链路追踪 ID、重复的 Set-Cookie 或调试头，和响应体（Body）完全无关。默认 4k 或 8k 在现代应用里很容易撞墙。
先确认是不是它的问题
别急着改配置，先看证据：
- 查 Nginx 错误日志（如
/var/log/nginx/error.log），找那句带 “too big header” 的报错 - 用
curl -v http://your-api/ 2>&1 | grep '^ 统计原始响应头总字节数（<code>-I可能截断，不准） - 如果实测头大小明显超过 4KB 或逼近 8KB，基本可以锁定
合理设置 proxy_buffer_size
这个值要略大于你实测的最大响应头长度，但不是越大越好：
- 起始建议设为
16k或32k；若后端明确返回超长头（如某些 OAuth2 回调），可设为64k - 不建议盲目设成
1m等过大值——浪费内存，还可能被用于缓冲区耗尽类攻击 - 加在
http、server或具体location块里，确保在proxy_pass之前生效
必须同步调好配套参数
proxy_buffer_size 单独调大没用，它和另外两个参数是流水线协作：
-
proxy_buffers 8 32k：分配 8 个缓冲区，每个 32KB，专存响应体（Body） -
proxy_busy_buffers_size 64k：划出最多 64KB 边收边发给客户端；该值必须 ≥ 单个proxy_buffer大小，且 ≤(数量 − 1) × 单个大小 - 三者分工清晰：先用
proxy_buffer_size存 Header，再用proxy_buffers接 Body，proxy_busy_buffers_size控制转发节奏
优先从后端源头压减响应头
调大缓冲区只是临时兜底，不是根本解法：
- 检查是否重复写入
Set-Cookie、未清理的X-Trace-ID、中间件注入的调试头 - 确认有没有因循环重定向或认证逻辑缺陷，导致 Header 层层叠加膨胀
- JWT 等长 Token 尽量别塞进响应头，改用短 ID + 后端查表；精简非必要字段（如
X-Powered-By） - 若用 HTTP/2，还要额外检查
http2_max_field_size（默认 4k），它独立限制 HPACK 解码后的字段长度
