关键在于proxy_busy_buffers_size需与proxy_buffers协同设置，取其总量1/4–1/2且不低于单块大小；流式或大文件响应应关闭proxy_buffering以避免阻塞。
要防止大响应载荷下 Nginx 作为网关出现“后端还在发、Nginx 却停着不收”的写入阻塞，关键不是单独调大 proxy_busy_buffers_size，而是让它与缓冲体系协同工作，让 Nginx 能持续接收后端数据，同时稳定向客户端推送。
理解它真正管什么
proxy_busy_buffers_size 控制的是“已从后端读到、但尚未全部发送给客户端”的那部分缓冲区总大小。它不决定能收多少数据，只决定“收了但没发完”的内存上限。设得太小，Nginx 很快认为“忙区满了”，就会暂停从后端读取——后端 TCP 窗口被压，可能触发超时或 RST；设太大，又会挤占空闲缓冲区，影响并发接收能力。
按 proxy_buffers 总量比例设置
该值必须基于你实际启用的 proxy_buffers 配置来定，不能脱离上下文：
- 若配置
proxy_buffers 8 128k（总量 1MB），proxy_busy_buffers_size建议设为 128k–256k - 若配置
proxy_buffers 16 256k（总量 4MB），可设为 1m–2m - 通用原则：取
proxy_buffers总量的 1/4 到 1/2，且不低于单块大小（如 128k）
区分场景，避免误配
不是所有大响应都适合用缓冲方式处理：
- 对持续流式响应（如日志 tail、SSE、视频流），建议直接
proxy_buffering off，此时proxy_busy_buffers_size不生效，无需调整 - 对一次性大文件下载（如安装包、镜像），也推荐
proxy_buffering off，实现边收边传，降低首字节延迟和内存压力 - 仅当需做响应头改写、gzip 压缩或统一错误处理时，才保留
proxy_buffering on，并同步调优缓冲参数
验证是否真正起效
修改后不能只 reload 就结束，要观察两个关键信号：
- 用
curl -I请求，检查响应头是否含X-Accel-Buffering: no（说明 buffering 已关）或有明确Content-Length（说明未被 chunked 截断） - 查看 Nginx error log 中是否有
upstream timed out或频繁client closed connection，这些往往是 busy 缓冲区卡住引发的连锁反应
