inactive参数专为清理“高频未被访问”的冷数据而设，它不看内容是否过期、不依赖请求频率，仅依据最后一次命中后的闲置时长由cache manager每200ms扫描并异步清理；需配合max_size、keys_zone、use_temp_path=off及proxy_cache_valid协同配置，典型文档场景推荐inactive=30d、keys_zone=30m、max_size=10g。
inactive 参数专为清理“高频未被访问”的冷数据而设——它不看内容是否过期，也不管请求多频繁，只盯住一个事实：这个缓存项最后一次被成功命中后，已经闲置多久了。只要超时，就会被 cache manager 进程扫描标记并异步清理。
理解 inactive 的真实作用机制
它不是缓存有效期，而是缓存驻留容忍期：
- 每次 proxy_cache hit（包括正常命中或 stale 状态下启用 proxy_cache_use_stale）都会重置该缓存项的 last_access_time 计时器
- cache manager 默认每 200ms 扫描一次共享内存，检查 last_access_time + inactive 是否已过期
- 只有同时满足“超时”和“当前无活跃请求占用”两个条件，才真正触发清理
- 清理是异步的：先移除共享内存中的 key 索引，再在磁盘空间压力（如 max_size 触发）或后续扫描中物理删除文件
按资源热度节奏设置合理值
不能统一设为 10m 或 1h，必须匹配实际访问衰减周期：
- 新闻/活动页（热度集中于 1–3 天）：inactive=1d～2d
- 博客文章、文档页、技术手册（长尾流量明显）：inactive=7d～30d
- 静态资源（JS/CSS/图片，更新少但复用高）：inactive=30d
- API 配置类、管理后台页（更新少、访问稀疏）：inactive=24h
- 临时灰度接口、测试路径：inactive=10m～30m
必须配合的关键参数才能闭环生效
单独调大 inactive 不起作用，需形成空间与时间双维控制：
- max_size 必须显式设置：例如 max_size=10g。否则 cache manager 不会主动触发磁盘级清理，inactive 标记的冷数据可能长期滞留
- keys_zone 要够大：估算公式为 1MB ≈ 8000 个 key；若预期有 30 万个缓存项且 inactive=30d，建议 keys_zone ≥ 36m（30w ÷ 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，超限时自动按 last_access_time 从最早开始释放
