inactive参数按“最后使用时间”裁剪缓存，指定时间内未被访问的缓存项将被异步清理，优先级高于proxy_cache_valid；需配合max_size、proxy_cache_use_stale等实现空间与时间的动态平衡。

通过 proxy_cache_path 的 inactive 参数，Nginx 能在缓存空间与响应速度之间做动态权衡：保留近期被访问过的资源，主动淘汰长期未触达的内容，既避免缓存无限膨胀，又保障热数据常驻内存——这正是“空间换时间”的典型落地。

inactive 的核心作用：按“最后使用时间”裁剪缓存

inactive 不是缓存过期时间（那是 proxy_cache_valid 管的），而是定义一个“沉默期”阈值。只要某个缓存文件在指定时间内完全没有被任何请求命中过，Nginx 就会在后台清理它，不管它原本是否还在有效期内。

• 例如：inactive=10m 表示：某条缓存哪怕 Cache-Control: max-age=3600，只要连续 10 分钟没被访问，就会被自动删除
• 这个机制独立于上游响应头和 proxy_cache_valid，优先级更高
• 清理动作由 Nginx worker 进程异步执行，不阻塞请求

如何配合其他参数实现空间与时间的再平衡

单靠 inactive 不足以完成策略闭环，需协同配置：

aperture: the L402 aware reverse proxy

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

下载

• 搭配 max_size：当磁盘快满时，Nginx 会先淘汰 inactive 超时最久的缓存项，再清理仍活跃但较旧的条目，形成两级淘汰逻辑
• 搭配 proxy_cache_use_stale：对即将被 inactive 清理、但尚未过期的缓存，可允许“降级使用”，避免回源抖动
• 避免与 proxy_cache_lock 冲突：若开启锁机制，需注意 inactive 时间不宜过短（如

典型调优建议：根据业务热度设定 inactive 值

没有通用最优值，关键看请求的“访问脉冲周期”和“冷热分界点”：

• 新闻类站点（热点时效强）：inactive=5m–15m，快速释放非实时内容空间
• 电商商品页（部分长尾流量低）：inactive=1h–4h，兼顾冷门 SKU 缓存复用率
• 内部 API 网关（调用量稳定）：inactive=24h 或更长，减少无效清理开销
• 可通过 nginx -V 2>&1 | grep -o with-http-slice-module 确认是否启用 slice 模块，对大文件分片缓存时，inactive 作用于整个 key，而非单个 slice

验证与观察：确认 inactive 是否按预期工作

仅看配置不够，需结合日志与指标判断效果：

• 开启 log_format cache '$upstream_cache_status' ...，观察 MISS/EXPIRED/STALE 比例变化，若 MISS 显著上升且集中在某类 URI，可能是 inactive 过短导致热缓存被误删
• 用 find /path/to/cache -mmin +10 | wc -l 手动检查实际缓存文件年龄分布（注意：Nginx 不实时更新文件 mtime，该方式仅作粗略参考）
• 监控 ngx_http_proxy_module 暴露的 proxy_cache_miss 和 proxy_cache_bypass 指标，对比调整前后趋势