Nginx警告暴露性能瓶颈：响应超缓冲区时写临时文件，磁盘I/O拖慢速度；高并发下争抢带宽致卡顿；临时文件堆积或引发磁盘满、碎片化；实为后端与配置失配信号，需根因排查而非仅调大缓冲。
这个警告本身不中断请求，但暴露了潜在的性能瓶颈：Nginx 正在用磁盘代替内存来中转响应数据。
磁盘 I/O 成为关键拖累
内存读写速度通常是磁盘的千倍以上。当响应体超出缓冲区总容量，Nginx 就会把多余部分写入 /var/cache/nginx/proxy_temp/ 这类路径下的临时文件。每次写入、再读取、最后发给客户端，都引入额外延迟。尤其在高并发场景下，多个请求争抢磁盘带宽，响应时间明显拉长，用户感知就是页面卡顿、图片加载慢或偶发中断。
临时文件堆积引发连锁问题
如果上游响应普遍偏大（比如报表导出、API 批量返回、大图直出），临时文件会高频生成。若 proxy_max_temp_file_size 未设限，单个请求可能占满整个 proxy_temp_path 分区；若磁盘空间不足，后续请求可能直接失败。更隐蔽的是，大量小文件还容易触发文件系统碎片，进一步降低 I/O 效率。
掩盖真实瓶颈，误导排查方向
这个警告常被当作“只是个 warn”，但它是上游服务与 Nginx 配置失配的信号灯。例如：后端 Ruby 应用用了老旧 gem 在响应中偷偷启动后台任务，导致连接提前关闭；或 Tomcat 返回了异常大的 Cookie/头信息，而 proxy_buffer_size 只设了默认的 4K。此时只调大缓冲区治标不治本，甚至掩盖了后端逻辑缺陷或资源泄漏。
影响缓存与流式传输行为
启用 proxy_buffering on（默认）时，Nginx 必须收完整个响应才开始发给客户端。一旦走临时文件，首字节时间（TTFB）必然延长。对视频流、SSE 或大文件下载这类需要低延迟传递的场景，反而应考虑在特定 location 中关闭缓冲：proxy_buffering off，让数据边收边传，避免全量暂存。
