proxy_busy_buffers_size是防止写阻塞的节流阀，限制已发未收数据量，避免内存堆积；推荐设为proxy_buffers总量的1/4至1/2且不低于单块buffer大小，需配合proxy_buffering on等配置使用。
proxy_busy_buffers_size 不是提升“写速度”的加速器，而是防止写阻塞的节流阀——它通过限制“已发给客户端但尚未确认接收”的数据量，让 Nginx 在后端持续输出和客户端缓慢接收之间保持平衡，避免内存堆积或上游卡死。
它真正管什么：已发未收的数据上限
这个参数不控制响应头（那是 proxy_buffer_size 的事），也不决定能缓存多少整体响应（那是 proxy_buffers 的总量），它只管一件事：当前有多少字节处于“Nginx 已调用 write() 发出、但 TCP 层还没被客户端 ACK 确认收完”的状态。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
一旦这部分数据占满 proxy_busy_buffers_size，Nginx 就暂停从 upstream 读取新数据，等客户端消费掉部分缓冲、腾出空间后再继续——这就是背压机制的核心。
怎么设才合理：比例 + 下限双约束
- 推荐值 = proxy_buffers 总大小的 1/4 至 1/2，且 不低于单块 buffer 大小
- 例如：
proxy_buffers 8 128k;→ 总量 1MB →proxy_busy_buffers_size 256k;或512k; - 再如：
proxy_buffers 16 256k;→ 总量 4MB →proxy_busy_buffers_size 1m;或2m; - 绝对避免设为等于或超过 proxy_buffers 总量（如总 4MB 设成 4m），否则 Nginx 停止读 upstream，后端可能超时断连
- 也别沿用默认 8k —— 对 SSR 页面或几十 KB 的 HTML 都会立刻触发假阻塞
必须联动的关键配置
- proxy_buffering on;：该参数仅在此开启时生效；建议显式声明，避免被 location 块覆盖为 off
- proxy_max_temp_file_size 0;：关闭落盘，让内存压力直接暴露，便于观察 busy 区是否饱和
- send_timeout / client_body_timeout：配合设置合理超时，使慢连接及时断开，释放 busy 缓冲
- proxy_http_version 1.1; proxy_set_header Connection '';：确保复用连接，减少握手开销对缓冲节奏的干扰
验证是否起效的实操信号
- 用
curl -I请求，检查响应头是否有准确 Content-Length（说明未被 chunked 截断，buffering 正常） - 对比 access log 中
$upstream_response_time和$request_time：差值显著缩小，说明数据不再卡在 busy 区 - 用
strace -p $(pgrep nginx) -e trace=write观察是否仍有大量write() = -1 EAGAIN—— 这是 busy 区满、无法继续发送的直接证据 - error log 中不再频繁出现
upstream prematurely closed connection或upstream timed out
