Nginx 本身不支持定时清理过期 proxy_cache 物理文件，仅通过 proxy_cache_path 的 inactive 参数由 cache manager 进程自动删除长期未访问的冷缓存；真正按 TTL 精确清理需依赖外部脚本解析元数据或 find 按修改时间粗删，而第三方 purge 模块仅支持手动/程序化主动清除，不具备定时能力。
nginx 本身不提供直接的定时清理过期 proxy_cache 物理文件的功能，proxy_cache_path 的 purger 模块并非 Nginx 官方模块，而是由第三方（如 nginx-cache-purge 或某些定制分支）提供的扩展功能，主要用于按 URL 主动触发删除，而非自动定时扫描清理过期缓存。要实现“定时清理过期物理缓存”，需结合 Nginx 缓存机制与外部工具协同完成。
理解 Nginx 缓存过期的本质
Nginx 的 proxy_cache 不维护独立的“过期时间数据库”，它依赖两个关键机制判断缓存是否过期：
- 响应头中的 Cache-Control / Expires：Nginx 在缓存时记录这些头，并在后续请求中比对当前时间；
- proxy_cache_valid 配置：为不同状态码（如 200、404）强制设定缓存有效期，覆盖响应头；
- 过期仅影响“是否可被使用”，过期文件仍保留在磁盘上，不会自动删除。
官方推荐方式：利用 proxy_cache_path 的 inactive 参数
这是最接近“自动清理”的原生方案，通过 inactive 限制缓存项的**最后访问存活期**：
proxy_cache_path /var/cache/nginx/proxy levels=1:2 keys_zone=mycache:10m inactive=1h max_size=1g;
说明：
-
inactive=1h表示：如果一个缓存文件在 1 小时内没有任何请求命中（即未被访问），Nginx 的 cache manager 进程会自动将其删除； - 该清理由 Nginx 自身的后台进程（cache manager）执行，无需额外模块或脚本；
- 注意：它清理的是“冷数据”，不是严格按 TTL 过期时间清理——即使某条缓存 TTL 是 10 分钟，只要它每 5 分钟被访问一次，就不会被 inactive 清理。
补充方案：用外部脚本定期扫描并清理真正过期的文件
若必须按原始 TTL 精确清理（例如防止磁盘被大量已过期但仍有访问的缓存占满），可编写脚本解析 Nginx 缓存目录结构，结合元数据判断过期状态：
- Nginx 缓存文件是二进制格式，但其文件名由 key 的 MD5 哈希生成（如
/var/cache/nginx/proxy/a/b/c/abc123...）； - 每个缓存条目对应一个文件 + 一个同名的
.temp或.cache元数据文件（取决于版本），其中包含响应头、过期时间戳等； - 可用 Python / Bash 脚本读取元数据（需解析二进制 header 区域，较复杂），或更稳妥地：配合
log_format记录 key 和响应头中的Expires/Cache-Control，再通过日志反推过期时间； - 简单实用做法：用
find按修改时间粗略清理（不精确但有效）：find /var/cache/nginx/proxy -type f -mmin +60 -delete（删除 60 分钟前写入且未更新的文件，需确保无长连接或断点续传干扰）。
关于所谓 “purger 模块” 的常见误解
社区中提到的 “purge 模块”（如 ngx_http_cache_purge_module）只提供 HTTP 接口（如 location ~ /purge(/.*)）用于手动或程序化删除指定 URL 的缓存，它不提供定时、批量、按过期策略清理的能力。它解决的是“主动失效”，不是“自动回收”。
若你看到文档声称某 purger 模块支持定时清理，大概率是封装了外部定时任务（如 cron + curl purge 接口 + URL 列表），而非模块自身功能。
