设为0可彻底禁用代理响应的磁盘临时文件写入，但需proxy_buffering on且上游未触发流式退化；不影响日志、请求体等其他磁盘IO。
proxy_max_temp_file_size 设为 0 真的能禁用磁盘写入吗
能，但前提是 proxy_buffering 保持 on（默认值），且后端响应头中没有 Content-Length: 0 或 Transfer-Encoding: chunked 导致 Nginx 提前判定为流式响应。设为 0 后，Nginx 会跳过所有 proxy_temp_path 下的文件创建逻辑，包括 proxy_temp/xxx、fastcgi_temp/xxx 等路径下的临时文件。
常见误判点：
- 误以为设为
0就等于关掉所有缓冲 —— 实际只是关磁盘缓存，内存缓冲仍由proxy_buffers等控制； - 未检查
upstream是否返回了Connection: close，这会导致 Nginx 放弃缓冲策略，退化为直传，此时proxy_max_temp_file_size不生效； - 在
location块里覆盖了全局配置，但忘记同步调整proxy_buffering和proxy_buffers，结果内存缓冲区太小，连接被 reset。
为什么设成 0 后 iowait 还是高
说明磁盘 IO 并非全来自代理响应缓存，需排查其他源头：
-
access_log开启了未缓冲写入（缺少buffer=64k flush=5s）； -
error_log级别设为debug，日志量爆炸； - 用了
client_body_in_file_only on，大 POST 请求体直接落盘； - fastcgi/uwsgi/scgi 协议自身有临时文件机制，与
proxy_max_temp_file_size无关； - 系统层有其他进程（如监控 agent、logrotate）在刷盘，
iotop -o要盯准具体 worker pid，再用lsof -p $PID确认 fd 对应文件。
设为 0 后必须同步调优的三个内存参数
单独改 proxy_max_temp_file_size 0 是危险操作，不配内存缓冲极易引发 502 Bad Gateway 或连接超时：
-
proxy_buffering on：必须开启，否则proxy_buffers失效，只剩proxy_buffer_size单块转发，吞吐骤降； -
proxy_buffer_size 4k：只存响应头，4k 足够，设太大浪费； -
proxy_buffers 8 128k：建议至少 8 块 × 128k，确保常见响应体（如 JSON 报表、HTML 页面）能装进内存；若常处理 >1MB 响应，可升至16 256k，但要监控 RSS 内存增长； -
proxy_busy_buffers_size 256k：必须 ≥ 单块 buffer 大小，且 ≤ 所有proxy_buffers总和，否则 busy 状态下无法接力转发，连接卡住。
哪些场景不该设为 0
不是所有高负载都适合关磁盘缓存：
- 需要 Nginx 缓存响应做审计或重试（比如上游偶发 5xx，靠
proxy_cache+proxy_cache_use_stale回源重试）； - 客户端网络极差（如弱网 IoT 设备），靠磁盘临时文件抗抖动比内存更稳；
- 上游响应头缺失
Content-Length且不支持chunked，Nginx 只能等收完才发，此时设为 0 会导致 OOM； - 容器环境内存受限（如 512MB Pod），又没做 cgroup 限制，盲目加大
proxy_buffers可能触发 OOMKilled。
真正起作用的从来不是单个参数，而是 proxy_buffering、proxy_buffers、proxy_busy_buffers_size 和 proxy_max_temp_file_size 四者的协同边界。磁盘 IO 抖动只是表象，内存缓冲是否“接得住、转得顺、不卡死”，才是关键。
