设 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，走边收边发
