proxy_buffer_size 是专用于存储响应头的缓冲区，仅处理状态行和响应头（含\r\n），不涉及响应体或tcp层；需根据实测最大头长度加20%余量后向上取整至2的幂次设定，且必须小于单块proxy_buffers大小。
proxy_buffer_size 不是用来“提升性能”的通用缓冲参数，而是专为防止 502 错误设置的响应头专用缓冲区。它只存状态行和所有响应头（含每行末尾的 \r\n），不碰响应体，也不影响 TCP 层。调对了，能稳住登录态、SSR 页面、JWT 认证等关键链路；调错了，要么白耗内存，要么照样报错。
先确认要不要调，而不是直接加到 64k
很多业务实际响应头不到 2KB，设 4k 就够。盲目拉大反而浪费内存——它是每个请求独占的固定开销。真需要调的情况包括：
- 登录后返回带长 JWT 的 HTML/SSR 页面（如 Next.js、Nuxt）
- Set-Cookie 字段多且值长（比如跨域 Cookie + 签名 + 过期时间）
- Vary 头组合复杂（Vary: Cookie, User-Agent, Accept-Encoding）且 Cookie 动态增长
- 错误日志反复出现 upstream sent too big header
实测最大头长度，再向上取整到 2 的幂次
别猜，要算：
- 用 curl -v https://your-api/ 2>&1 | grep '^ 抓原始响应头
- 手动统计所有字符 + 每行末尾的 \r\n（各占 1 字节）
- 或开启 debug 日志：error_log /var/log/nginx/error.log debug;，复现请求后日志会明确写 “header: 13782 bytes”
- 实测 5212 字节 → 加 20% 余量 ≈ 6254 → 向上取整到最近的 2 的幂次 → 设 proxy_buffer_size 8k
- 实测 28900 字节 → 设 proxy_buffer_size 32k
必须满足硬约束：小于单块 proxy_buffers 大小
这个值不是孤立存在的，它受底层内存分配逻辑限制：
- 若配置 proxy_buffers 8 128k，表示每块 buffer 是 128k → proxy_buffer_size 最大只能设 128k，但通常 16k 就足够
- 如果设成 256k，Nginx 启动直接报错，拒绝加载配置
- 它和 proxy_buffers、proxy_busy_buffers_size 职责分离：前者管头，后两者管体，不能互相替代
配套动作缺一不可
单改 proxy_buffer_size 是半套方案：
- 确保 proxy_buffering on —— 关闭后该参数完全失效
- HTTP/2 环境下同步检查 http2_max_field_size（默认 4k），否则 HPACK 解码失败也会 502
- 优先精简后端响应头：关调试头、合并重复 Set-Cookie、避免中间件层层追加 X-Trace-ID
- 若 header 持续膨胀，应查后端逻辑（比如 Token 未压缩、Cookie 未分片），而不是无限制扩大 buffer
