nginx proxy_cache 最稳妥的冷数据清理方式是靠 inactive 参数自动淘汰——它依据最后一次访问时间而非响应头过期时间，由 cache manager 进程周期扫描清理，需配合足够 keys_zone、慎用 proxy_cache_lock 及搭配 max_size 才能有效。

靠 inactive 参数自动清理，是 Nginx proxy_cache 清理长时间未访问陈旧缓存最稳妥、最推荐的方式——它不依赖响应头过期时间，只认“最后一次被访问到现在过了多久”，超时即删，由后台进程安静执行。

用 inactive 参数启用自动冷数据淘汰

在 proxy_cache_path 指令中设置 inactive，就启用了基于最后访问时间的自动清理：

• inactive=30m 表示：任意缓存条目若连续 30 分钟没被任何请求命中（包括正常访问或 proxy_cache_use_stale 触发的读取），就会被标记为待清理
• 清理动作不是实时发生的，而是由 Nginx 内置的 cache manager 进程周期性扫描（默认每秒一次）完成的
• 它和 proxy_cache_valid 完全独立：即使后端返回了 Cache-Control: max-age=3600，只要 30 分钟没人访问，照样删

确保 inactive 发挥作用的关键配置配合

单独设 inactive 不够，还需注意以下三点，否则可能失效或误删：

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

• keys_zone 大小要足够：共享内存太小会导致 key 频繁被挤出，Nginx 就无法更新 last_access_time，冷数据实际存活时间会远短于 inactive 设定值
• 慎用 proxy_cache_lock：开启后首次未命中会锁住回源；若此时有大量并发冷请求，可能因排队等待导致 key 的访问时间没被及时刷新，变相缩短缓存寿命
• 搭配 max_size 使用：当磁盘缓存逼近上限时，Nginx 会优先删除 last_access_time 最早的文件（不管是否超 inactive），形成“访问热度 + 空间压力”双重淘汰机制

验证 inactive 是否生效

可以快速验证清理逻辑是否按预期工作：

• 用 curl 访问某个资源一次，确认 $upstream_cache_status 为 HIT
• 等待超过设定的 inactive 时间（如设了 2m，就等 2 分半）
• 再次访问同一 URL，观察日志或变量：$upstream_cache_status 变为 MISSED，且 access log 中 upstream 地址出现，说明已回源——缓存确实被清除了

不要直接 rm -rf 替代 inactive

手动删磁盘文件看似简单，但会破坏 Nginx 缓存的两级结构：

• 删了文件，共享内存里的 key 索引还在；后续请求会先查索引命中，再尝试读文件，发现不存在才回源——这会造成短时集中穿透，引发后端压力激增
• worker 进程可能还持有已删文件的句柄，磁盘空间不会立刻释放
• 对长期无人访问的“冷数据”，inactive 是无感、渐进、可控的清理方式；rm -rf 是暴力重置，适合发布大版本等场景，不适合日常冷数据治理