inactive参数是Nginx自动淘汰冷缓存最直接可靠的方式，仅依据最后一次命中后的闲置时长由cache manager异步清理，不依赖响应头过期或请求频率；需配合max_size、keys_zone大小、use_temp_path=off及proxy_cache_valid协同配置，典型文档场景推荐inactive=30d、keys_zone=30m、max_size=10g。
inactive 参数是 Nginx 自动淘汰代理冷数据最直接、最可靠的方式——它不看响应头是否过期，也不管请求频率高低，只认一个标准：这个缓存项最后一次被成功命中后，已经闲置多久了。
只要超过设定时间没被访问，Nginx 就会在后台由 cache manager 进程扫描并标记为可清理。这不是立即删除，而是“懒淘汰”：先从共享内存中移除索引，再在磁盘空间压力（如 max_size 触发）或后续扫描时物理清除文件。
inactive 的核心行为必须清楚
- 每次
proxy_cache成功命中（HIT或STALE且启用proxy_cache_use_stale），都会重置该缓存项的最后访问时间 - 它和
proxy_cache_valid独立：即使缓存还“新鲜”，只要inactive时间到了且没被访问，照样被踢 - 清理动作由
cache manager执行，默认每 200ms 扫描一次，检查last_access_time + inactive 的条目 - 文件不会立刻消失，但失去索引后，新请求无法命中，旧文件也会在
max_size回收或下一次清理周期中被删
怎么设才真正管用：按业务场景选值
静态资源（JS/CSS/图片）：
inactive=1h～6h
热门资源自然常驻，冷门几小时无访问就释放，避免堆积API 接口类（列表页、详情页）：
inactive=12h～24h
覆盖典型低谷周期（比如夜间无人访问），兼顾复用与清理文档页、旧博客、PDF 归档等长尾内容：
inactive=7d～30d
月均访问几次的内容，设太短等于白缓；设90d也可，但需同步扩大keys_zone临时活动页、灰度接口：
inactive=10m～30m
快速回收非活跃路径，防止缓存残留干扰测试
⚠️ 避免设 inactive=1y：keys_zone 共享内存会长期保留 key 元信息，浪费空间；cache loader 启动变慢；磁盘空间也难及时释放
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
必须配合的关键参数
max_size必须显式设置
例如max_size=10g。否则cache manager不会主动触发磁盘级清理，inactive标记的冷数据可能长期滞留keys_zone要够大
每 1MB 共享内存约支持 8000 个 key。若你设inactive=30d，预计有 50 万个缓存 key，那keys_zone至少要64m（50w ÷ 8000 × 1.2）use_temp_path=off推荐开启
关闭临时路径，让缓存文件直落目标目录，避免rename残留导致inactive判定延迟或失效inactive ≥ proxy_cache_valid
例如proxy_cache_valid 200 2h，则inactive至少设2h或4h。否则缓存“有效但活不过两小时”，形同虚设
一个典型生产配置示例
proxy_cache_path /var/cache/nginx/docs levels=1:2 keys_zone=docs_cache:30m inactive=30d max_size=10g use_temp_path=off;
含义：
- 缓存键存在 30MB 共享内存中（支持约 24 万 key）
- 所有缓存文件按两级目录散列存储
- 任意条目连续 30 天未被访问，就会被标记淘汰
- 总磁盘占用不超过 10GB，超限时优先清最久未访问项
怎么验证它真在工作
- 用
curl -I http://example.com/some-path访问一次，记录时间 - 等待超过
inactive设定时间（如设了30d，就等 31 天；测试可用30m快速验证） - 再次请求，观察响应头中
$upstream_cache_status变为MISS，说明已失效 - 进缓存目录执行
find /var/cache/nginx/docs -type f -mmin +31 | wc -l（注意：mtime 不完全准确，仅作辅助参考）
不复杂但容易忽略
