nginx 缓存定时清理需依赖 proxy_cache_path 的 inactive 参数和系统 cron 扫描，而非 ngx_cache_purge 模块；该模块仅支持手动 url 清理，不支持自动过期扫描。
Proxy cache purger 模块（如 ngx_cache_purge）本身不支持“定时清理过期缓存”，它只提供按 URL 主动触发删除的能力。真正实现“定时清理过期反代缓存”，需结合 Nginx 原生缓存过期机制 + 外部脚本或系统定时任务，而非依赖 purger 模块自动扫描清理。
理解 Nginx 缓存过期的核心逻辑
Nginx 的 proxy_cache_valid 和 proxy_cache_path 中的 inactive 参数共同控制缓存生命周期：
-
proxy_cache_valid：决定响应状态码（如 200/301）被缓存多久（基于后端返回的Cache-Control或Expires，但可被覆盖）； -
inactive（在proxy_cache_path中设置）：指定缓存项在多长时间内**未被访问**就自动删除 —— 这是清理“冷过期缓存”的关键机制，无需外部干预； -
过期 ≠ 立即删除：即使缓存已过
proxy_cache_valid时间，只要仍在被访问（inactive未超时），Nginx 仍会返回它，并在后台异步校验（若配了proxy_cache_revalidate）或直接返回过期副本（若配了proxy_cache_use_stale）。
用 ngx_cache_purge 实现精准手动清理（非定时）
该模块仅用于按需清除特定 URL 缓存，例如：
location ~ /purge(/.*) {
allow 127.0.0.1;
deny all;
proxy_cache_purge my_cache $host$1$is_args$args;
}
访问 http://example.com/purge/some/path 即可清除对应缓存。但它不会遍历目录、不识别过期时间、也不支持 cron 调度。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
真正可行的定时清理方案：系统级 cron + 缓存路径扫描
若你确实需要定期清理磁盘上“已过期且无访问”的缓存文件（比如防止 inactive 设置过大导致缓存堆积），可借助 Linux 定时任务扫描 proxy_cache_path 对应目录：
- 确认缓存路径：例如
proxy_cache_path /var/cache/nginx/my_cache levels=1:2 keys_zone=my_cache:10m inactive=12h max_size=1g;→ 实际文件存在/var/cache/nginx/my_cache/下； - 缓存文件名由 key hash 生成，无法直接读取 HTTP 头判断过期时间，但 Nginx 会在每个缓存文件旁写入一个
.temp或无扩展名的元数据文件（含 header 和过期时间戳）； - 更可靠做法：用
find按文件最后访问时间（-amin）或修改时间（-mmin）清理，模拟inactive行为：# 清理 12 小时内未被访问的缓存文件（与 inactive=12h 对齐）<br>find /var/cache/nginx/my_cache -type f -amin +720 -delete
- 加入 crontab（如每天凌晨 2 点执行）：
0 2 * * * find /var/cache/nginx/my_cache -type f -amin +720 -delete 2>/dev/null
推荐配置组合（兼顾自动管理与可控清理）
不依赖 purger 定时，而是让 Nginx 自身高效管理，辅以少量人工干预：
- 设合理
inactive（如inactive=1h），让冷缓存快速释放； - 用
max_size防止磁盘占满，Nginx 会自动 LRU 清理最旧缓存； - 开启
proxy_cache_lock和proxy_cache_lock_age避免缓存穿透； - 保留
ngx_cache_purge用于紧急场景（如发布后清某接口）； - 监控
proxy_cache_path目录大小和 inodes 使用率，异常时再介入。
不复杂但容易忽略：Nginx 缓存的“过期清理”本质是 lazy 的，靠 inactive 和 max_size 驱动，不是后台守护进程轮询。强行定时扫描文件系统反而增加 I/O 开销，通常没必要。
