proxy_max_temp_file_size=0仅禁用响应体缓冲溢出时的磁盘临时文件写入，不干预请求体处理、日志落盘、SSL会话缓存等其他磁盘行为，真实作用是强制内存缓冲或流式转发以规避IO抖动。

设为 0 并不能“彻底禁用磁盘暂存”，它只关闭响应体缓冲溢出时的临时文件写入，而请求体处理、日志落盘、SSL 会话缓存、临时路径本身等环节仍依赖磁盘。追求极致延迟的关键，是让整个代理链路尽可能绕过磁盘，靠内存与流控协同实现低抖动转发。

明确 proxy_max_temp_file_size 0 的真实作用

该配置仅在以下条件同时满足时生效：

• proxy_buffering on（默认开启）
• 后端响应体超过 proxy_buffer_size + proxy_buffers 总和
• 响应可缓存（如非 5xx、不含 no-store）

设为 0 后，Nginx 不再写临时文件，而是直接中断连接并返回 502 —— 或者，在 proxy_buffering off 时转为纯流式转发（此时该参数实际失效）。它不干预 client_body_temp_path、access_log、error_log、ssl_session_cache shared 等任何其他磁盘行为。

真正影响延迟的磁盘环节必须单独处理

即使 proxy_max_temp_file_size=0，以下操作仍会触发磁盘 I/O，且往往是延迟抖动主因：

WebChat Voice Proxy

⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**

下载

• 访问日志同步刷盘：默认 access_log 每次写都 fsync，高并发下引发明显 wa%；建议改用 buffer=64k flush=1s，或转向 syslog / /dev/stdout
• 请求体暂存：大文件上传触发 client_body_temp_path 写入，需配合 client_max_body_size 和 client_body_buffer_size 控制，必要时设 client_body_buffer_size 足够大并禁用 temp_path
• SSL 会话缓存：若启用 ssl_session_cache shared:SSL:10m，底层仍使用 shm 区域，但初始化/重建可能涉及少量磁盘元数据操作；确保 /dev/shm 可用且足够
• resolver DNS 缓存：某些 resolver 配置（如带 valid 参数）会在 /var/cache/nginx 下持久化 DNS 结果，应避免或改用无状态 resolver

内存优先的代理转发组合配置

要逼近极致延迟，需放弃“全缓存”思路，转向可控流式 + 内存背压：

• 关闭代理缓冲：proxy_buffering off;（此时 proxy_max_temp_file_size 无效，但获得最低转发延迟）
• 启用流式控制：proxy_busy_buffers_size 4k; + proxy_buffers 2 4k;，一旦接收 >4KB 且未及时发出，Nginx 主动暂停读上游，形成轻量级背压，保护 worker 内存不被撑爆
• 指定内存临时路径（可选）：proxy_temp_path /dev/shm/nginx/proxy_temp 1 2;，前提是 /dev/shm 挂载为 tmpfs 且权限/大小充足
• 压缩策略收敛：gzip off;（若后端已压缩），避免 Nginx 在流式过程中因 gzip 缓冲不足被迫落盘

配套可观测性与兜底措施

无磁盘不等于无风险，需监控与容错并重：

• 通过 error_log notice 级别观察是否频繁出现 "upstream sent too big header" 或 "client intended to send too large body"，及时调优 proxy_buffer_size / client_max_body_size
• 用 strace -e trace=openat,write -p $(pidof nginx) 验证是否仍有 write 系统调用指向磁盘路径
• 对关键 upstream 设置 proxy_next_upstream error timeout http_502，避免单次 502 影响整体可用性
• 若业务允许，搭配 proxy_http_version 1.1 和 Connection: keep-alive，减少 TCP 建连开销