inactive 是 nginx 缓存“自我瘦身”的核心开关，按实际访问热度软淘汰冷数据，需分层设定值（如静态资源2h～6h、动态接口12h～24h、归档类7d～30d），并必须配合足够大的 keys_zone（1mb≈8000 key）和 max_size 才能实现时空双控的自动清理。

要让 Nginx 缓存目录真正“自我瘦身”，inactive 是最直接、最贴近业务热度的控制开关——它不靠时间戳或响应头，只看文件是否被真实访问过。设对了，冷数据自动退场；设错了，要么频繁回源，要么磁盘悄悄胀满。

按内容冷热节奏定 inactive 值

同一个值无法适配所有资源。关键不是“统一设大”或“统一设小”，而是分层匹配自然访问周期：

• 静态资源（JS/CSS/图片）：用户刷新后常复用，但低流量页面可能几小时才二次访问 → 推荐 inactive=2h～6h
• 动态接口（列表页、用户配置）：访问集中在早晚高峰，中间有明显空档 → inactive=12h～24h 可覆盖完整低谷期
• 归档类内容（PDF、历史 API、旧文档）：每月查一次，但每次访问都值得省掉回源 → inactive=7d 或 30d 更合理
• 临时活动页或灰度路径：生命周期短、热度集中 → inactive=10m～30m 避免缓存堆积

确保 keys_zone 足够大，让 inactive “记得住”

inactive 生效的前提是：Nginx 必须在共享内存里长期保存每个缓存项的最后访问时间。如果 keys_zone 太小，key 元信息被挤出，系统就“忘了”它上次啥时候被访问过，inactive 形同虚设。

估算方法很简单：1 MB keys_zone ≈ 存储 8000 个唯一 key。例如你预计最多有 32 万个缓存条目，建议至少设 keys_zone=40m（320000 ÷ 8000 = 40），再加 20% 余量更稳妥。低于 10m 容易失效，超过 200m 可能引发内核延迟。

必须搭配 max_size，形成时空双控

inactive 是“时间维度”的软标记，max_size 才是“空间维度”的硬闸门。两者缺一不可：

• 只设 inactive 不设 max_size：cache manager 不会主动触发磁盘级清理，冷文件可能长期滞留
• 只设 max_size 不设 inactive：Nginx 会按 LRU 清理，但优先删最新写入的——反而把热数据干掉了
• 理想组合示例：proxy_cache_path /var/cache/nginx/docs levels=1:2 keys_zone=docs:20m inactive=7d max_size=2g; → 7 天没访问的 PDF 自动退场，总量超 2GB 时从最老未访问项开始释放

验证瘦身是否真在发生

不用等几天，几个命令就能快速确认：

• 检查缓存状态码分布：在 log_format 中加入 $upstream_cache_status，若某类资源 MISS 持续升高但后端稳定，大概率是 inactive 设太短
• 抽样看文件年龄：find /var/cache/nginx/docs -type f -mmin +420 | wc -l（对应 inactive=7d），结果显著下降说明清理已启动
• 观察磁盘变化：du -sh /var/cache/nginx/docs/* | sort -hr | head -5，若大量二级目录变空或极小，说明 key 元信息还在，inactive 正常工作