proxy_busy_buffers_size控制Nginx“已接收但未发送完”数据的缓冲区总上限大小，仅作用于proxy_buffering on时处于“忙”状态的缓冲区，推荐设为proxy_buffers总量的1/4至1/2且不低于单块大小。
proxy_busy_buffers_size 控制的是 Nginx 在反向代理模式下，“已从后端接收完成、但尚未全部发送给客户端”这部分数据所占用缓冲区的**总上限大小**，它不叫“繁忙缓存区”，而是“忙碌缓冲区”——关键在“忙”（busy），即处于“正在发送中”状态的缓冲区容量配额。
它管什么、不管什么
只管那一段卡在中间的数据：已收完响应体、正往客户端发，但还没发完。这部分内存不能无限占着，否则后端会因 Nginx 暂停读取而阻塞。
它不管：
FastAPI Flask Proxy
下载
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 区没及时发出
