proxy_temp_path 是 Nginx 反向代理中控制临时文件落盘路径的核心指令，需显式配置为独立高性能磁盘（如 NVMe SSD）并启用两级哈希子目录，配合增大内存缓冲、关闭非必要缓冲及限制单文件大小，才能真正解耦 I/O、消除磁盘颠簸。

proxy_temp 在 Nginx 默认目录结构中不是“固定路径”，而是由 proxy_temp_path 指令显式定义的临时文件根目录（默认值为 /var/tmp/nginx/proxy，但实际是否启用、写入与否，完全取决于代理行为和缓冲配置）。它的调优作用不在于“存放位置本身”，而在于重构 I/O 路径、解耦系统负载、控制落盘行为——这是提升高并发静态分发与大响应代理稳定性的关键杠杆。

proxy_temp_path 是 I/O 瓶颈的开关，不是可有可无的缓存目录

Nginx 只在满足以下条件时才真正生成 proxy_temp 下的 .temp 文件：

• proxy_buffering on（默认开启）
• 后端响应体超过内存缓冲总量（proxy_buffer_size + proxy_buffers）
• 且未禁用落盘（即 proxy_max_temp_file_size ≠ 0）

一旦触发，所有溢出数据都会经由 proxy_temp_path 落盘。若该路径仍在系统盘（如 /var/tmp），就会和日志、内核刷脏页、Docker overlay 等共享同一物理设备，导致：

• 小文件高频随机写 → await 升高、%util 接近 100%
• inode 或空间耗尽 → 出现 502/503，却无明确错误日志
• iowait 占比突增（top 中 wa% > 30%），CPU 使用率虚高

把 proxy_temp_path 挪到独立高性能磁盘，本质是切断 I/O 耦合

这不是“优化参数”，而是重新划分资源边界：

FastAPI Flask Proxy

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

下载

• 必须用物理直连 NVMe SSD：lsblk -d -o NAME,ROTA,MODEL 确认 ROTA=0，绕过 LVM、加密卷、NFS、ZFS
• 新建专用目录并赋权：mkdir -p /ssd/nginx_temp && chown nginx:nginx /ssd/nginx_temp
• 启用两级哈希子目录：proxy_temp_path /ssd/nginx_temp 1 2; —— 避免单目录文件过多拖慢 lookup
• 挂载选项加固：noatime,nobarrier,commit=60（XFS/ext4 下适用），减少元数据开销

proxy_temp_path 的调优必须配合三类协同动作才生效

单设路径没用，容易陷入“新瓶装旧酒”：

• 增大内存缓冲，压低落盘频率：
  proxy_buffer_size 128k;
proxy_buffers 8 256k;
proxy_busy_buffers_size 512k;
• 对超大文件流式转发，绕过落盘：
  在特定 location 中设 proxy_buffering off; sendfile on;
• 限制单文件大小，防止拆分放大 IO：
  proxy_max_temp_file_size 512m;（SSD 场景），避免一个 1GB 响应被切成几十个 32MB 小文件反复写

验证是否真起效，看三个硬指标

重启后别只查配置，要实证：

• iostat -x 1 观察目标磁盘（如 nvme0n1）的 %util 和 await 是否显著高于系统盘
• ls -R /ssd/nginx_temp | head -20 确认已生成多级子目录（如 /a/1/xxx.tmp），而非空或仅顶层目录
• 压测 100MB 文件回源，对比开启前后平均响应时间下降幅度与失败率变化

不复杂但容易忽略