proxy_buffer_size 必须基于实测响应头大小精准配置,只缓存状态行和响应头(含rn),设小导致502,设大浪费内存;需实测最大头体积、加20%~30%余量、向上取整至2的幂次,且小于proxy_buffers单块大小。
proxy_buffer_size 不能凭经验乱设,必须基于实测响应头大小精准配置。它只负责缓存状态行和所有响应头(含每行末尾的 rn),不处理响应体,也不影响 TCP 层传输。设小了会直接报 502 Bad Gateway,设大了则在高并发下浪费内存——每个请求都会独占这块空间。
先实测最大响应头体积
别猜,要真实数据:
- 用 curl -v https://your-api/ 2>&1 | grep '^< ' 抓原始响应头,逐行统计字符数 + 每个 rn(各算 1 字节)
- 或临时开启 debug 日志:error_log /var/log/nginx/error.log debug;,复现请求后日志中会出现类似 header: 13782 bytes 的明确提示
- 取多次请求中的最大值,再加 20%~30% 余量防波动
按规则向上取整并满足约束
得到实测值后,按以下两步定值:
- 向上取整到最近的 2 的幂次:实测 5212 字节 → 推荐 proxy_buffer_size 8k;实测 12345 字节 → 设 16k;实测 28900 字节 → 设 32k
- 该值必须小于 proxy_buffers 的单块大小:例如 proxy_buffers 8 128k,则 proxy_buffer_size 最大只能设 128k,但通常 16k 就够用;若设得更大,Nginx 启动时直接报错 upstream sent too big header
确保生效前提和配套动作
这个参数不是“设了就起作用”:
- 必须放在 location 或 server 块中,且在 proxy_pass 指令之前
- 仅在 proxy_buffering on 时生效;若关了(如 SSE、gRPC-Web、LLM 流式场景),Nginx 直接透传 header,此参数被完全忽略
- HTTP/2 环境下还需同步检查 http2_max_field_size(默认仅 4k),它限制 HPACK 解码后单字段长度,同样可能触发 502;建议设为 16k 或与 proxy_buffer_size 同量级
- 优先精简后端 header:排查重复 Set-Cookie、未清理的调试头(如 X-Trace-ID)、多层 Vary 字段等,从源头降低体积比调参更有效
典型值参考与常见误区
根据业务特征可快速对标:
- 普通 REST API / 静态资源:默认 4k 通常够用
- JWT 认证的 SSR 页面(Next.js/Nuxt):建议 12k–16k
- 多中间件链路 + 动态 Cookie + Vary 组合:实测常达 10–14k,起步设 16k
- 严禁设 1m 或无限制;不推荐全局写在 http 块里——必须作用于具体 location 才生效
- 这不是 TCP 缓冲参数,和 tcp_rmem 无关;也不是为了提升吞吐,核心目标是防 502