proxy_busy_buffers_size控制nginx“已接收但未发送完”数据的缓冲区总上限大小,仅作用于proxy_buffering on时处于“忙”状态的缓冲区,推荐设为proxy_buffers总量的1/4至1/2且不低于单块大小。

proxy_busy_buffers_size 控制的是 Nginx 在反向代理模式下,“已从后端接收完成、但尚未全部发送给客户端”这部分数据所占用缓冲区的**总上限大小**,它不叫“繁忙缓存区”,而是“忙碌缓冲区”——关键在“忙”(busy),即处于“正在发送中”状态的缓冲区容量配额。
它管什么、不管什么
只管那一段卡在中间的数据:已收完响应体、正往客户端发,但还没发完。这部分内存不能无限占着,否则后端会因 Nginx 暂停读取而阻塞。
它不管:
FastAPI + Flask 混合部署最佳实践,解决路由定义、API 代理等常见问题,适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 响应头(那是 proxy_buffer_size 的职责)
- 总缓存能力(那是 proxy_buffers 的总量)
- 落盘行为(那是 proxy_max_temp_file_size 和 proxy_temp_file_write_size)
- 流量监控或带宽限速(它不是流控开关,也不统计字节数)
合理值怎么定
必须和 proxy_buffers 挂钩,不能孤立设置:
- 推荐设为 proxy_buffers 总量的 1/4 至 1/2(例如
proxy_buffers 16 256k;总量 4MB →proxy_busy_buffers_size 1m;或2m;) - 必须 ≥ 单块 buffer 大小(如单块是 128k,就不能设成 64k)
- 必须 ≤ proxy_buffers 总量,否则 nginx -t 直接报错
不同场景怎么调
一刀切配置容易出问题,要按响应特征区分:
-
中小响应(SSR 页面、API JSON,≤100KB):用
proxy_buffers 8 128k;+proxy_busy_buffers_size 128k;或256k;就够用 -
持续流式响应(SSE、日志 tail):直接
proxy_buffering off;,此时该参数完全不生效,调大也没意义 -
大文件下载(≥10MB):优先关缓冲(
proxy_buffering off;);若必须开,则 busy 值建议设为单块大小的 2–4 倍(如单块 256k → 设 512k~1m)
怎么确认它起效了
reload 后别只看服务是否启动,盯两个信号:
- 用
curl -I请求,看响应头是否有 Content-Length(说明缓冲完整,没被 chunked 截断) - 查 error log 是否还有 upstream response is buffered to a temporary file —— 若频繁出现,说明 busy 区或总量仍不足
- 对比
$upstream_response_time和$request_time:若后者明显更长,说明数据积压在 busy 区没及时发出










