proxy_busy_buffers_size控制Nginx“已接收但未发送完”数据的最大内存占用，需与proxy_buffering、proxy_buffers等协同设置；建议设为proxy_buffers总量的1/4至1/2，且不低于单块大小。
关键在让 Nginx 在接收后端响应时，既不卡住上游，也不压垮自身缓冲区管理逻辑。proxy_busy_buffers_size 不是独立生效的参数，它必须和 proxy_buffering、proxy_buffers、proxy_buffer_size 协同设置，否则容易出现“后端还在发、Nginx 却停着不收”的假阻塞现象。
明确它的作用边界
这个值控制的是：当部分缓冲区已写入但尚未全部发送给客户端时，Nginx 最多允许多少内存处于“忙”状态（即已接收、待发送）。它不决定能收多少数据，只决定“收了但没发完”的数据最多占多大空间。
- 设得太小（如默认 8k），会导致 Nginx 很快认为“忙区满了”，暂停从上游读取——后端可能因此被 TCP 窗口压制或超时中断
- 设得太大（如超过 proxy_buffers 总量的一半），可能挤占空闲缓冲区，反而降低并发接收能力
- 它和 proxy_buffer_size 无关，后者只管响应头；也和 proxy_temp_file_write_size 无关，后者管落盘块大小
匹配 proxy_buffers 总量来设值
先确认你启用了 proxy_buffering on（这是大多数需缓冲场景的前提），再按比例配置：
- 若用 proxy_buffers 8 128k;（总 1MB），busy 值建议设为 128k–256k
- 若用 proxy_buffers 16 256k;（总 4MB），busy 值可设为 1m–2m
- 通用经验：busy 值取 buffers 总量的 1/4 到 1/2，且不低于单块大小（如 128k）
结合业务响应特征微调
不是所有大响应都一样。Next.js SSR 页面首屏 HTML 可能 80KB，CDN 回源下载的安装包可能是 500MB：
- 对中小响应（
- 对持续流式响应（如日志 tail、SSE）：建议 proxy_buffering off，此时该参数不生效，无需调整
- 对后端响应头较大（含长 Cookie、自定义 Header 或启用 gzip_vary）：可同步把 proxy_buffer_size 提到 16k，但 busy 值仍按 body 缓冲逻辑设，不必跟着加
验证是否真起效
改完别只 reload 就完事。观察两个信号：
- 用 curl -I 请求，看响应头是否含 X-Accel-Buffering: no（说明 buffering 已关）或有 Content-Length（说明未被 chunked 截断）
- 查 access_log 中 $upstream_response_length 字段，对比前后是否稳定增长而非频繁中断重连
- 若仍有后端写入停滞，检查 proxy_read_timeout 是否足够（建议 ≥300），避免 Nginx 主动断开上游连接
