proxy_busy_buffers_size控制nginx“已接收但尚未发完”响应数据的内存上限，需设为proxy_buffers总量的1/4至1/2且不低于单块大小；设小致后端阻塞，设大则削弱并发接收能力，仅在proxy_buffering on时生效。

proxy_busy_buffers_size 并不控制后端写入响应的行为，而是影响 Nginx 作为代理时，如何缓冲从后端（上游服务器）接收并准备发送给客户端的响应数据。

它管的是“发给客户端前”的缓冲区大小

当 Nginx 从上游服务器（如 PHP-FPM、Tomcat）读取响应时，会先把一部分响应体暂存在内存缓冲区中。这个指令定义的是：在尚未把响应全部发给客户端前，Nginx 允许占用的“忙碌”缓冲区的总大小（注意不是单个缓冲区，而是多个 busy 缓冲区之和）。

• 默认值通常是 4KB 或 8KB（取决于系统页面大小），常见为 proxy_busy_buffers_size 4k|8k;
• 它必须 ≤ proxy_buffer_size + proxy_buffers 的总大小，否则启动会报错
• 如果响应体超过该值，Nginx 就可能把部分数据写入临时文件（除非禁用 proxy_buffering off）

和后端写入无关，但会影响响应传递效率

后端服务器按自己的节奏写响应（比如 flush 输出、流式返回），Nginx 只是接收方。是否能及时收、存、转，才由这个参数间接影响：

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

• 设得太小 → 缓冲区很快“忙满”，被迫频繁落盘或阻塞读取，增加 I/O 和延迟
• 设得过大 → 占用更多内存，尤其高并发时可能放大内存消耗
• 对大响应（如文件下载、API 流式响应）建议适当调大，配合 proxy_buffering off 可绕过缓冲直接转发

典型搭配参考

常见配置组合示例（适用于中等负载 Web 应用）：

• proxy_buffering on;
• proxy_buffer_size 4k;（存放响应头）
• proxy_buffers 8 16k;（共 8 个缓冲区，每个 16KB）→ 总缓冲能力 = 128KB
• proxy_busy_buffers_size 16k;（允许最多 16KB 处于“正在发给客户端”状态）

怎么判断要不要调？

观察日志和行为：

• 出现大量 upstream prematurely closed connection 或 client intended to send too large body 类错误？先查后端，再看缓冲是否不足
• 用 strace -p $(pgrep nginx) -e trace=write,open,unlink 看是否高频写临时文件（如 /var/lib/nginx/proxy/...）
• 开启 proxy_buffering off; 后问题消失 → 说明原缓冲策略不适合当前响应模式（如 SSE、大文件流）