inactive参数是Nginx冷数据自动剔除的核心机制，它依据缓存最后一次命中后的闲置时长触发清理，不依赖Cache-Control或proxy_cache_valid，由cache manager周期扫描执行；需按资源类型设1h–30d合理值，并同步调优keys_zone大小与max_size协同实现两级空间回收。
inactive 参数是 Nginx 实现冷数据自动化剔除最直接、最可靠的方式。它不看响应头里的 Cache-Control，也不依赖请求频率或业务逻辑，只认一个事实：这个缓存项最后一次被成功返回给用户后，已经闲置多久了。
inactive 的真实作用机制
它不是控制“缓存是否过期”，而是决定“缓存文件能在磁盘上躺多久没人管”。Nginx 的 cache manager 进程会周期性扫描缓存目录，对每个条目检查三项：
- 该条目最后一次被命中（HIT）是什么时候
- 从那次命中起，是否已连续超过 inactive 设定的时间未被再次访问
- 当前是否没有请求正在使用它（即非 active 状态）
三项同时满足，就标记为可删除。哪怕 proxy_cache_valid 还剩 59 分钟，只要 inactive 到期，照样清。
按资源类型设定合理值
设太小会误删，设太大则冷数据堆积。关键看真实访问节奏：
- 静态资源（JS/CSS/图片）：推荐 1h～6h。新页面首访后可能隔几分钟才二次访问，低于 10 分钟容易丢
- 动态接口（用户配置、列表页）：建议 30m～2h。更新较频繁，但重复请求常集中在短时间窗内
- 归档类内容（PDF、旧文档、历史 API）：可用 24h、7d 或 30d。每月查一次的文件，设 7d 就能稳留；设 1h 就每次都要回源
必须同步调优 keys_zone 大小
inactive 要生效，前提是缓存键和它的最后访问时间能长期驻留在共享内存中。如果 keys_zone 太小，key 元信息被挤出，Nginx 就“忘了”上次啥时候访问过，inactive 形同虚设。
- 估算公式：1 MB keys_zone ≈ 存储 8000 个唯一 key（含元数据）
- 例如预期有 40 万个活跃缓存项，建议 keys_zone ≥ 50m（400000 ÷ 8000 = 50），再加 20% 余量更稳妥
- 避免极端值：低于 10m 容易导致 key 频繁淘汰；超过 200m 可能引发内核 slab 分配延迟
与 max_size 协同形成两级回收
inactive 是第一道自动清理策略，max_size 是兜底硬限制：
- 即使没到 max_size，只要某个缓存项闲置超 inactive 时长且无活跃引用，也会被清理
- 当磁盘缓存总大小逼近 max_size 时，Nginx 会优先按 inactive 规则，从“最久未被访问”的条目开始删
- 搭配 use_temp_path=off 可提升清理效率，避免临时文件残留干扰判定
不复杂但容易忽略
