proxy_buffers是Nginx为每个代理请求预分配的内存缓冲区集合,专存后端响应体数据;它不是全局池、非page cache、更非磁盘文件,而是per-request、固定大小、仅在proxy_buffering on时生效的内存块组。

proxy_buffers 是什么,不是什么
proxy_buffers 是 Nginx 为每个活跃代理请求预分配的一组内存缓冲区,专用于暂存后端返回的响应体(body)数据。它不是全局共享池,也不是操作系统 page cache,更不是磁盘临时文件——它是 per-request 的、可复用的、固定大小的内存块集合。
关键点: • 每个请求独占一组 buffer,数量 × 单块大小 = 该请求最大可用缓冲内存 • 它只在 proxy_buffering on 时生效;一旦设为 off,整个 proxy_buffers 配置完全失效 • proxy_buffer_size 不属于它,那是单独管响应头的,二者互不干扰
怎么设才不踩坑:按响应体分档配总量
设错的核心原因是“拿一套参数套所有业务”。真实场景中,API 响应和报表导出的体积差百倍,必须分档处理:
-
中小响应(JSON/API/SSR HTML,平均 50–200KB):用
proxy_buffers 8 256k(总量 2MB)。够覆盖 95% 请求,单 worker 在百并发下 RSS 稳定可控 -
大响应(报表导出、镜像回源,10–100MB):用
proxy_buffers 32 256k(总量 8MB),但必须同步限制并发或改用proxy_buffering off -
高频小包(IoT 上报、心跳):用
proxy_buffers 16 16k(总量 256KB/连接),单块匹配典型消息,避免跨 buffer copy 和频繁分配抖动
严禁:proxy_buffers 64 4m——单请求吃 256MB,10 并发就能触发 OOM。
安全更新和维护 CLI Proxy API(CPA)部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
proxy_busy_buffers_size:决定“已收未发”能留多少
这个值不是额外加内存,而是从 proxy_buffers 总量里划出一块,专供“正在发给客户端但还没清空”的数据驻留。设错会直接卡住后端:
- 推荐设为总量的 1/4 至 1/2,且 不低于单块大小
→
proxy_buffers 8 128k(总量 1MB)→ 设proxy_busy_buffers_size 512k→proxy_buffers 16 256k(总量 4MB)→ 设proxy_busy_buffers_size 2m - 设太小(如沿用默认 8k):Nginx 收几 KB 就暂停读上游,后端 write() 阻塞,日志出现
upstream timed out - 设太大(如 8m 对应总量仅 2MB):启动失败或退化为同步阻塞
配套动作:禁落盘、控超时、验实效
只调 proxy_buffers 不解决问题,必须协同收敛:
-
禁用临时文件:内存充足时设
proxy_max_temp_file_size 0,超限直接 502,比默默刷盘更利于暴露瓶颈 -
延长等待窗口:对慢响应(如导出),设
proxy_read_timeout 300,防中途断连 -
验证是否真起效:
• 查
/proc/<nginx-pid>/status | grep VmRSS,确认单 worker RSS 符合预期(如总量 4MB 缓冲 + 开销 ≈ 120–180MB) • curl -I 看响应头是否含准确 Content-Length(说明没被 chunked 截断) • error_log 开 debug,搜writing to temp file或upstream buffer is too small


















