inactive参数核心作用是按实际访问热度自动清理冷数据，而非依赖过期时间；它与proxy_cache_valid控制的expired状态正交，需配合max_size实现时空双维缓存管理。
inactive 参数的核心作用是自动清理“不再被访问”的缓存条目，而非简单按过期时间删除——这是释放存储空间最可控、最贴近真实访问热度的方式。
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
理解 inactive 与 expired 的本质区别
缓存条目有两个独立状态：是否过期（expired）、是否活跃（accessed）。
- expired由 proxy_cache_valid 控制，只决定该响应还能不能对外提供服务；
- inactive则完全看实际访问行为：只要某缓存文件在设定时间内没被任何请求命中，无论它是否过期，都会被后台进程强制清除。
这意味着即使你设了 1 小时缓存有效期，但某页面半年没人访问，它会在 inactive 时间一到就被删掉，不占磁盘。
设置合理的 inactive 值需匹配业务冷热周期
不是越大越好，也不是越小越省。关键看你的内容自然衰减节奏：
- 新闻/活动页类：用户集中访问期通常就 1–3 天 → inactive=1d 或 2d 即可
- 商品详情页、博客文章：长尾流量明显，可能持续被零星访问 → inactive=7d 到 30d 更合适
- 静态资源（JS/CSS/图片）：更新少、复用高 → inactive=30d 甚至 90d 都合理
- 跨国 WordPress 站点（含区域化 cookie）：因 key 中含 $cookie，不同用户看到不同版本，冷数据堆积快 → 推荐 inactive=7d，避免缓存键爆炸式增长
配合 max_size 实现双层空间保护
inactive 单独使用不够稳健，必须和 max_size 组合：
- inactive 解决“时间维度”的冷数据淘汰
- max_size 解决“空间维度”的硬上限兜底
例如配置：
proxy_cache_path /data/nginx_cache levels=1:2 keys_zone=my_cache:100m inactive=7d max_size=50g use_temp_path=off;
这样即使某些 key 因异常访问模式长期不被淘汰，磁盘也不会突破 50GB；Nginx 会按 LRU 清理最久未用的文件，确保空间可控。
验证与调优建议
上线后通过以下方式确认 inactive 是否生效：
- 查看缓存目录下文件修改时间分布：find /data/nginx_cache -type f -mtime +7 | wc -l（应显著减少）
- 监控 Nginx 日志中的 cache miss 和 cache expired 比例变化
- 使用 nginx -t && nginx -s reload 修改 inactive 后无需重启，热生效
注意：inactive 时间变更后，已存在的缓存项会按新规则重新计时，旧计时器立即作废
