proxy_busy_buffers_size 控制的是 Nginx 在“已从后端收完响应、但还没发完给客户端”这一中间状态下，最多能用多少内存来暂存这些“正在发送中”的数据。它不决定总缓存能力，也不影响响应头处理，只管那一小段卡在半路的 body 数据上限。设对了，后端能持续输出，客户端能稳定接收；设错了，轻则延迟飙升，重则触发 502 或上游写阻塞。
它的作用边界很明确
这个参数只在 proxy_buffering on 时生效，且必须和 proxy_buffers 协同使用。它不是独立内存池，而是从 proxy_buffers 总量里划出的一块“忙区”配额：
- 设得太小（比如沿用默认 8k），Nginx 很快判定“忙区满了”，立刻暂停读上游 → 后端 socket.write() 可能阻塞，连接超时断开
- 设得太大（比如超过 proxy_buffers 总量的一半），空闲 buffer 不足 → 多连接并发接收能力下降，尤其在弱网或客户端读取慢时更明显
- 它和 proxy_buffer_size 无关（后者只管响应头），也和 proxy_temp_file_write_size 无关（后者管落盘块大小）
怎么设才合理：按总量比例来
核心原则是：取 proxy_buffers 总内存的 1/4 至 1/2，且不能小于单块 buffer 大小，也不能超过总量本身。否则 nginx -t 会报错。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 若配置为 proxy_buffers 8 128k（总量 1MB），建议 proxy_busy_buffers_size 128k–256k
- 若配置为 proxy_buffers 16 256k（总量 4MB），可设为 1m–2m
- 单块为 256k 时，busy 值至少设 256k；设成 128k 就可能刚填满一块就停，频繁唤醒 epoll，吞吐反而下降
不同响应类型要区别对待
不是所有大响应都适合统一调大 busy 值，得看数据是否真需要缓冲：
- 中小响应（如 SSR 首屏 HTML、API JSON，通常 50–100KB）：按比例设即可，重点保障响应头不溢出，proxy_buffer_size 可同步提到 16k
- 持续流式响应（如日志 tail、SSE、EventSource）：直接 proxy_buffering off，此时该参数完全不生效，Nginx 边收边发，延迟更低
- 大文件下载（如安装包、报表导出）：需同步增大 proxy_buffers 总量，并把 busy 值设为单 buffer 大小的 2 倍左右（例如 buffer 是 256k，busy 设 512k），兼顾吞吐与稳定性
验证是否真起效，别只 reload 就完事
改完配置后，关键看运行态表现：
- 用 curl -I 请求，检查响应头是否含 Content-Length（说明未被 chunked 截断，缓冲完整生效）；若出现 X-Accel-Buffering: no，说明 buffering 已关，当前 busy 设置未参与逻辑
- 观察 error log 是否仍有 upstream response is buffered to a temporary file —— 若频繁出现，说明忙区或总量仍不足，需同步调大 proxy_buffers 或优化落盘策略
- 对比调优前后，后端服务的 write 阻塞时间（如 Node.js 的 socket.write() 耗时）是否明显下降
