设 proxy_max_temp_file_size 0 并不能提升稳定性，反而将磁盘压力转为连接失败；其仅在 proxy_buffering on、非流式响应、可缓存且内存缓冲满时生效，控制单临时文件上限而非总磁盘用量。

直接设 proxy_max_temp_file_size 0 并不能“提升稳定性”，反而可能把磁盘压力转化为连接失败风险。真正有效的调优，是让 Nginx 在内存与磁盘之间做合理分工——该用内存扛的别落盘，该用磁盘兜底的别硬塞进内存。

先搞清它到底管什么

这个参数只在四个条件同时满足时起作用：
- proxy_buffering on（默认开启）
- 后端响应不是流式（即没有 Transfer-Encoding: chunked 或 Content-Length: 0）
- 响应未被标记为不可缓存（比如没带 Cache-Control: no-store）
- 内存缓冲区（proxy_buffer_size + proxy_buffers）已满，但响应还没传完

此时 Nginx 才会考虑写临时文件。而 proxy_max_temp_file_size 控制的是“单个临时文件最多写多大”，不是总磁盘用量，也不影响日志、SSL 缓存、请求体等其他磁盘行为。

高负载下磁盘抖动的真实来源

如果 iostat -x 1 显示 %util 接近 100%、await 毫秒级飙升，但 error log 没报错，大概率不是大文件单次刷盘，而是小响应高频落盘。常见源头包括：

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

• access_log 未启用缓冲：缺 buffer=64k flush=5s，每条日志都同步写盘
• error_log 级别设为 debug，日志量爆炸
• client_body_in_file_only on，大 POST 请求体直落磁盘
• fastcgi/uwsgi 自身有独立临时文件机制，和该参数无关
• 系统层其他进程（如监控 agent、logrotate）正在刷盘，需用 iotop -o 和 lsof -p $PID 锁定具体 worker

设为 0 的前提和配套动作

设成 0 表示“宁可 502，也不写磁盘”，但必须同步满足三个条件，否则极易触发连接重置或超时：

• proxy_buffering on：必须保持开启，否则内存缓冲完全失效
• proxy_buffer_size 4k：只存响应头，4k 足够；设太大浪费且不提升吞吐
• proxy_buffers 8 128k（总 1MB）或更高：确保常见响应（JSON、HTML）能装进内存；若常处理 >1MB 响应，可升至 16 256k，但要监控 RSS 内存增长
• proxy_busy_buffers_size 256k：必须 ≥ 单块 buffer 大小，且 ≤ 总 buffers 大小，否则 busy 状态无法接力转发，连接卡死

更稳的折中方案

压测发现，抖动往往来自几十 KB 响应 × 数万 QPS 的高频小文件刷盘。与其激进设 0，不如控制粒度+隔离路径：

• 把 proxy_max_temp_file_size 设为 1m（而非 0），限制单文件上限
• 用 proxy_temp_path /dev/shm/nginx_temp 1 2 把临时目录挂到内存文件系统（tmpfs），避免真实磁盘 IO
• 确认 proxy_temp_path 所在分区有足够空间和 inode 余量
• 对明确的大文件路径（如 /download/），直接关缓冲：proxy_buffering off，走边收边发