应设 use_temp_path=off 并将 proxy_cache_path 直接指向 ssd 或 hdd 挂载点，使缓存原地写入；use_temp_path=on 会导致跨设备 rename 失败，引发缓存 miss 和临时文件堆积。

直接在 proxy_cache_path 中设 use_temp_path=off，并把缓存路径明确指向 SSD 或 HDD 对应的挂载点，就能让缓存文件“原地写入”，避免跨设备移动带来的空间浪费和失败风险。关键不是靠临时目录分流，而是让缓存路径本身落在目标磁盘上，并确保该路径所在分区有足够空间与正确权限。

为什么 use_temp_path=on 会干扰 SSD/HDD 空间分配

默认开启时，Nginx 先把响应体写进系统临时目录（如 /var/tmp/nginx_temp），再用 rename() 移到 proxy_cache_path。但 rename() 要求源和目标必须在同一个挂载点 —— 如果你的缓存路径在 SSD（如 /ssd/nginx/cache），而系统临时目录在 HDD（如 /hdd/tmp），就会报错：
rename() "/hdd/tmp/xxx" to "/ssd/nginx/cache/xxx" failed (18: Invalid cross-device link)
结果是：缓存持续 MISS、/hdd/tmp 下堆积大量未清理的 .tmp 文件、SSD 上却几乎没写入任何缓存数据。

把缓存固定到指定磁盘的配置方法

只需两步，无需额外配 proxy_temp_path：

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

• 显式关闭临时路径：use_temp_path=off，让 Nginx 直接往 proxy_cache_path 写文件
• 把 proxy_cache_path 的 path 指向目标磁盘的实际挂载路径，例如：
  proxy_cache_path /ssd/nginx/cache levels=1:2 keys_zone=ssd_cache:200m max_size=20g inactive=60m use_temp_path=off;
proxy_cache_path /hdd/nginx/cache levels=1:2 keys_zone=hdd_cache:100m max_size=100g inactive=120m use_temp_path=off;
• 确保对应目录已创建、属主为 nginx 用户、且所在分区有足够空闲空间（峰值流量下完整响应体将全部落在此处）

按业务类型拆分缓存到不同磁盘的实用建议

不推荐靠 proxy_temp_path 做“软分流”，真正可控的方式是按内容特征绑定不同 keys_zone 和物理路径：

• 高频小文件（如图片、CSS、JS）→ 放 SSD：keys_zone=img_cache:300m + path /ssd/cache/img
• 低频大文件（如视频切片、日志归档）→ 放 HDD：keys_zone=video_cache:150m + path /hdd/cache/video
• 若需动态路由，可用 split_clients 按 URI 或请求头把流量打到不同 proxy_cache 名称，再各自指向不同磁盘路径

验证是否真落到目标磁盘

光改配置不够，得看实际行为：

• 访问一个接口后，立刻执行：ls -lh /ssd/nginx/cache/*/* | head -5，确认有新文件生成
• 检查 Nginx 错误日志：grep "cross-device\|rename" /var/log/nginx/error.log，应无相关报错
• 用 df -h /ssd /hdd 观察各磁盘使用率变化趋势，确认增长符合预期流量比例