inactive参数是Nginx控制缓存冷数据自动清理的核心机制，依据最后一次命中后闲置时长由cache manager周期扫描清理，不依赖响应头过期时间或请求频率；合理设置可防止低频资源占满磁盘，需结合proxy_cache_valid与max_size协同优化。

inactive 参数是 Nginx 缓存生命周期管理中最直接控制“冷数据”自动清理的机制，它不依赖响应头或业务逻辑，而是纯粹基于访问行为——只要缓存项在指定时间内没被命中，就标记为可淘汰。配置得当，能有效释放磁盘、避免缓存池淤积。

inactive 的核心逻辑

• 它定义的是“最后访问时间”窗口，不是缓存有效期（那是 proxy_cache_valid 的职责）
• 一旦超过该时间未被 proxy_cache 命中，Nginx 不会立即删除文件，而是在后续由 cache manager 进程统一扫描并移除
• 清理动作与缓存是否“过期”无关：一个刚缓存 5 分钟但 60 分钟内再没被访问的资源，也会被 inactive=60m 清掉
• 默认值是 10m，对多数静态资源偏短，需按业务热度调优

如何设置才真正适配低热度场景

• 根据资源真实访问周期设定

  • 博客文章、文档页等长尾内容：inactive=7d 或 inactive=30d
  • API 接口返回的配置类数据（更新不频繁但访问稀疏）：inactive=24h
  • 日志归档页、历史版本页：inactive=90d
  • 切忌设为 inactive=1y：共享内存中键仍长期驻留，浪费 keys_zone 空间，且 cache loader 启动慢

• 配合 max_size 形成双保险

  proxy_cache_path /var/cache/nginx/api_cache
    levels=1:2
    keys_zone=api_cache:50m
    inactive=24h
    max_size=20g;

  即使某些冷数据侥幸躲过 inactive 扫描，max_size 触发 LRU 淘汰时也会被优先清除

• 关闭 use_temp_path=off 提升清理效率
  若启用临时路径（默认 on），cache manager 需额外处理重命名残留；设为 off 后文件直落目标目录，inactive 判定和清理更干净

• 避免与 proxy_cache_valid 冲突
  例如：

  proxy_cache_valid 200 1h;
  proxy_cache_path ... inactive=10m;

  这会导致缓存“1 小时内有效”，但“10 分钟不访问就被删”——有效时间形同虚设。应让 inactive ≥ proxy_cache_valid，比如 inactive=2h

  

  Umbrel Proxy Manager

  高效管理与交互 Umbrel 代理服务，支持 Docker 容器。自动发现运行服务，将内部 Docker IP 映射为可访问的外部地址。

  下载

验证冷数据是否真被清理

• 查看缓存目录层级下文件年龄：

  find /var/cache/nginx/api_cache -type f -mmin +1440 | head -5  # 找 24h 以上未修改文件（注意：mtime ≠ 最后访问时间，仅作粗略参考）

• 更准确方式是观察 cache manager 日志（开启 error_log /path/info;），搜索 cache manager 关键字，会打印类似：
  cache manager process 12345 exited with code 0
cache manager started
deleting cache item ...

• 使用 nginx -t && nginx -s reload 后，留意 cache loader 是否报错（如权限/路径不存在），否则 inactive 机制无法启动

基本上就这些。关键不是设多大数值，而是理解它只认“沉默时长”，结合你的数据冷热分布来定。