inactive参数用于冷缓存淘汰,即缓存项最后一次被成功命中后若在指定时间内未被访问即删除,不评估热度,仅依据最后访问时间,需配合proxy_cache启用且依赖cache manager进程定期扫描清理。

nginx 的 proxy_cache_path 中的 inactive 参数,是自动清理“长时间未被访问”的缓存文件的核心机制,但它**不按热度高低判断**,而是纯粹基于“最后访问时间”。所谓“低热度无效缓存”,实际应理解为“冷数据”——即缓存创建或命中后,在指定时间内再没被任何请求触发过 proxy_cache_use_stale 以外的正常访问。
inactive 的真实作用:冷缓存淘汰,非热度评估
inactive 定义的是缓存项在缓存区中“最后一次被成功命中(或验证)之后,多长时间内未再被访问,就视为过期并删除”。它和 proxy_cache_valid(控制响应有效期)相互独立:
– proxy_cache_valid 决定“是否允许直接返回缓存”(即是否新鲜);
– inactive 决定“即使缓存已过期、甚至从未成功缓存过,只要它躺在磁盘上且 N 秒没被碰过,就删掉”。
例如:
proxy_cache_path /var/cache/nginx/mycache levels=1:2 keys_zone=mycache:10m inactive=1h max_size=1g;
表示:所有存于该缓存区的文件,若在 1 小时内没有任何请求读取(包括 stale 状态下的读取),就会被后台 cache manager 进程扫描并删除。
安装并运行 Aperture(Lightning Labs 的 L402 闪电反向代理),用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
确保 inactive 生效的关键前提
-
必须启用 proxy_cache:仅配置
proxy_cache_path不生效,还需在 location 或 server 块中显式设置proxy_cache mycache; - 缓存 key 必须稳定可复用:若每次请求生成不同 key(如含随机参数、未忽略无关 query),相同资源会反复写新 entry,旧 entry 很快因 inactive 被删,但“冷数据”清理效果反而被掩盖;
- 避免误用 proxy_cache_bypass / proxy_no_cache:这些指令若频繁跳过缓存,会导致缓存项始终无法被命中,加速触发 inactive 删除——这不是问题,而是预期行为;
- cache manager 进程需正常运行:nginx 启动后会自动派生该进程,默认每 200ms 扫描一次缓存目录(不可配置),检查并清理超 inactive 时限的条目。
配合其他指令提升“低效缓存”清理效果
单靠 inactive 无法识别“高热度但内容已失效”的缓存(如源站更新了但缓存仍 fresh)。建议组合使用:
- 设置合理的 proxy_cache_valid:对静态资源(js/css/png)设较长有效期(如 1d),对 API 响应设较短(如 5m),让 stale 机制有机会介入,避免 inactive 成为唯一清理手段;
- 启用 proxy_cache_lock:防止缓存失效瞬间大量回源,造成重复生成缓存,减少冗余 entry;
-
定期人工校验缓存命中率:通过
$upstream_cache_status日志变量统计 HIT / MISS / EXPIRED / STALE 比例;若 MISS 持续偏高,可能是 key 设计或 inactive 设置过短,而非缓存“无效”本身; - 必要时主动 purge(慎用):nginx 开源版不支持 PURGE,可用第三方模块(如 nginx-cache-purge)或通过临时重命名缓存目录触发全量重建——这属于运维动作,不在 inactive 自动机制范畴内。
常见误判与排查建议
当发现缓存“莫名消失”或“清理过快”,先确认:
- 日志中
$upstream_cache_status是否大量出现MISS?说明请求根本没进缓存流程(可能被 bypass、no_cache、或 key 不一致); - 检查系统时间是否同步:若 worker 进程看到的 mtime 和 cache manager 不一致(如容器时钟漂移),可能导致误删;
- 观察
inactive值是否远小于业务真实访问间隔:比如用户平均 30 分钟刷一次页面,却设inactive=10m,大部分缓存会在下次访问前就被清掉; - 注意缓存文件权限:cache manager 需对缓存目录有读写权限,否则无法 unlink 文件,表现为磁盘空间不释放,但
inactive逻辑仍会标记其为待删。










