核心是协同控制“已收未发”内存上限、落盘时机和写入粒度；需合理设置proxy_buffers总量与单块大小，同步配置proxy_busy_buffers_size为总量的1/4～1/2且不低于单块大小，并调优proxy_max_temp_file_size、proxy_temp_file_write_size及proxy_temp_path。
要解决后端响应过大引发的磁盘临时文件 IO 瓶颈，核心不是单纯加proxy_buffers，而是协同控制“已收未发”数据的内存上限、落盘时机和写入粒度。只调大缓冲区数量或大小，不配好 busy 区和临时文件策略，反而容易让 Nginx 频繁刷盘、卡住上游连接，甚至触发 502 或超时。
合理设置 proxy_buffers 总量与单块大小proxy_buffers 决定了 Nginx 为每个请求分配多少内存来缓存响应体（不含响应头）。设得太小，大响应很快溢出进磁盘；设得太大，单 worker 进程可能吃掉数百 MB，增加 OOM 风险。
常规 HTML/API 响应：用proxy_buffers 8 16k（共 128KB），兼顾内存效率与稳定性报表导出、模板渲染等中大响应（几 MB）：可设为proxy_buffers 16 64k（共 1MB）
避免极端值，例如proxy_buffers 32 4m（128MB）易导致 worker 内存失控，不推荐必须同步配置 proxy_busy_buffers_size这个参数管的是“已接收但还没发给客户端”的那部分缓冲区内存上限。它不是独立池子，而是从 proxy_buffers 总量里划出来的“忙区”。设错会直接导致后端写入阻塞。
推荐设为 proxy_buffers 总量的1/4 到 1/2，且不低于单块 buffer 大小例如proxy_buffers 8 1M（总 8MB），busy 值设为2M 或 4M较稳妥若单块是 128k，busy 值就不能低于 128k；设成 64k 就可能过早暂停接收，拖慢后端约束临时文件行为，减少磁盘 I/O 压力当响应超出内存缓冲，Nginx 默认写临时文件——这是 IO 瓶颈的主因。不能禁用，但要管住它怎么写、写在哪。
proxy_max_temp_file_size不建议设为 0（会丢请求），也不宜过大（如 4G）。对 GB 级下载，1024m是较稳选择proxy_temp_file_write_size提高到128k 或 256k，显著降低 write() 系统调用频次，减轻 I/O 压力若条件允许，把临时目录挂到内存盘：proxy_temp_path /dev/shm/nginx_temp 1 2，跳过磁盘直走 RAM验证是否真正绕开磁盘瓶颈改完配置 reload 后，不能只看服务是否起来，要观察真实效果：用curl -I请求，确认响应头含准确的Content-Length（说明未被 chunked 截断，缓冲完整生效）
检查 error log 是否仍有upstream response is buffered to a temporary file—— 若还有，说明整体缓冲仍不足或落盘策略不合理对比前后端日志：后端连接释放是否变快？access_log 中响应时间是否更稳定？