nginx 官方不支持 purger 参数，自动清理由内置 cache manager 进程完成，关键参数为 manager_sleep、manager_files 和 inactive；其中 inactive 决定冷数据淘汰条件，manager_sleep 和 manager_files 控制扫描节奏与批处理粒度。
proxy_cache_path 中没有 purger 参数用于“定时清理过期文件”，这是常见误解。Nginx 官方版本（包括 1.20+ 及 Nginx Plus）不支持 purger=on、purger_sleep、purger_files 等任何以 purger_ 开头的配置项——这些仅存在于已废弃的第三方模块（如旧版 ngx_cache_purge），且早已不再维护。
你真正需要调优的是 Nginx 内置的 cache manager 进程，它才是负责自动清理缓存文件的核心机制。所谓“定时清理”，本质是控制这个后台进程的扫描节奏与批处理行为。
关键参数：manager_sleep 和 manager_files
这两个是 proxy_cache_path 的官方合法参数，直接决定清理任务的等待窗口和执行粒度：
-
manager_sleep：cache manager 每处理完一批缓存后，休眠多少毫秒再启动下一轮（默认200ms） -
manager_files：每轮最多检查并清理多少个缓存文件（默认200）
它们共同构成你想要的“等待窗口”——不是按固定时间点触发，而是以循环扫描方式持续调控清理节奏。
例如：
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mycache:10m
inactive=12h max_size=5g
manager_files=300 manager_sleep=150;
表示：每轮最多清理 300 个文件，完成后只休眠 150ms 就继续扫描，适合 SSD + 中小缓存规模，加快空间回收。
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
inactive 才是决定“是否该删”的依据
inactive 不是清理指令，而是清理条件：
它定义“一个缓存条目在多长时间内未被访问，就视为可删除”。
比如 inactive=12h，意味着只要某缓存文件在 12 小时内没有任何请求命中，cache manager 在扫描时就会把它物理删除。
⚠️ 注意：
- 它不看响应头里的
Expires或Cache-Control，只看最后访问时间（atime） - 它不等于“TTL 到期即删”，而是“冷数据淘汰”
- 若没设
inactive，即使缓存逻辑过期，文件也会一直留在磁盘上
不要混淆：purge 模块 ≠ 自动清理
第三方 proxy_cache_purge 模块（如 ngx_cache_purge）只提供 proxy_cache_purge 指令，用于手动或程序化地按 URI 删除缓存，例如：
location ~ /purge(/.*) {
proxy_cache_purge mycache "$scheme://$host$1";
}
但它：
- 不扫描磁盘
- 不识别过期状态
- 不定时运行
- 必须由外部请求或脚本主动触发
它和 proxy_cache_path 的自动清理完全无关。
实用建议组合
| 场景 | 推荐配置 |
|---|---|
| SSD 存储、缓存 ≤ 50GB、追求快速释放 | inactive=6h; manager_files=500; manager_sleep=100ms |
| HDD 或 NFS 共享存储、需降低 I/O 冲突 | inactive=24h; manager_files=200; manager_sleep=500ms |
| 高频更新内容（如分钟级 API） | 缩短 inactive（如 5m），比调小 manager_sleep 更有效 |
不需要额外模块，不依赖定时任务，也不用写脚本——只要配好 inactive、manager_files 和 manager_sleep，Nginx 就会持续、自治地完成物理清理。
