大文件下载应关闭proxy_buffering以实现流式透传，避免首字节延迟、磁盘I/O瓶颈及proxy_max_temp_file_size触发的中断；仅在需动态计算ETag或gzip压缩等极少数场景才可开启并严格调优缓冲参数。
在大文件下载场景下，开启 proxy_buffering 通常不能提速，反而容易导致卡顿、中断甚至失败。真正能提速的，是根据下载特征选择关闭缓冲，并配合适当的流式传输参数。所谓“开启能提速”的说法，混淆了不同场景下的优化目标——它适用于后端慢、客户端快的常规 API 场景，但不适用于大文件下载。
大文件下载的本质是流式透传，不是缓存中转
下载一个 500MB 的视频或安装包时，用户需要的是低首字节延迟、稳定持续的吞吐，而不是等 Nginx 把整个文件收完再开始发。开启 proxy_buffering on 后：
- Nginx 会先从后端读取完整响应体（即整个大文件），存入内存或临时磁盘文件；
- 只有全部接收完毕，才开始向客户端发送第一个字节；
- 若文件超 1GB，默认
proxy_max_temp_file_size 1024m会触发写入失败，连接中断； - 即使没超限，频繁小块落盘（如默认
proxy_temp_file_write_size 8k）也会拉垮磁盘 I/O，拖慢整体速度。
为什么有人误以为“开 buffering 能提速”
这种误解常来自两类混淆：
- 把“后端释放快”当成“下载快”：开启 buffering 确实能让 Nginx 快速收完响应、立刻关掉与后端的连接，缓解 Java/PHP 等服务的线程堆积——但这只提升后端并发能力，不改变客户端下载速率；
- 把小响应优化套用到大文件上：对 20KB 的 HTML 页面，4KB 缓冲足够；但对 GB 级文件，同样配置只会引发大量磁盘写、高延迟和 OOM 风险。
真正提速的大文件下载配置要点
核心思路是：绕过缓冲，让数据从后端直通客户端，同时防止因网络波动断连。
-
proxy_buffering off;—— 强制流式转发，消除首字节延迟和临时文件瓶颈； -
proxy_read_timeout 3600;和proxy_send_timeout 3600;—— 避免慢速网络或移动客户端触发超时； -
proxy_buffer_size 16k;—— 单独保障响应头空间，防止重定向或 Cookie 过大报错； -
proxy_temp_path /data/nginx/tmp;（可选）—— 若必须用临时文件，确保路径在高速独立分区，避免系统盘 IO 拥塞。
例外情况：什么大文件场景可以开 buffering
极少数情形下可开启，但需严格配套调优：
- 需在响应头中动态注入 ETag 或 Content-MD5 校验值（必须看到完整响应体才能计算）；
- 要统一启用 gzip 压缩，且后端未压缩（Nginx 需先收全再压）；
- 此时必须同步设置：
proxy_buffers 16 1M;、proxy_busy_buffers_size 8M;、proxy_max_temp_file_size 0;，并监控磁盘写入与内存 RSS。
