inactive参数是proxy_cache_path中控制缓存冷数据自动淘汰的核心机制，依据最后一次命中后闲置时长触发清理，不依赖请求频率或响应头过期时间，由cache manager周期扫描执行。
inactive 参数是 proxy_cache_path 中控制缓存“冷数据”自动淘汰的关键机制，它不依赖请求频率或时间戳，而是以“最后一次被访问后经过多久未再被命中”为依据，定期清理长期闲置的缓存文件。合理设置 inactive 能有效防止磁盘被低频但长期不更新的资源占满，尤其适合内容更新慢、访问分布不均的站点（如文档库、归档页面、旧版 API 响应等）。
理解 inactive 的真实作用逻辑
它不是缓存过期时间，也不影响新请求是否命中缓存；而是 Nginx 缓存管理器（cache manager）周期性扫描时，对每个缓存条目检查：
— 该条目最后一次被成功提供给客户端（即被 hit）是什么时候？
— 如果距今已超过 inactive 设定的时长，且当前未被任何请求占用（非 active 状态），就标记为可删除。
注意：即使响应头中设置了 Cache-Control: max-age=3600，只要在 inactive 期限内被再次访问，就会重置计时；反之，哪怕 max-age 还剩 59 分钟，只要超出了 inactive 时限，也会被清除。
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
配置 inactive 的实用建议
- 值不宜过短：低于 10 分钟容易误删刚缓存但尚未被二次访问的内容，尤其对新上线或低流量页面不友好
- 推荐起步值：静态资源类设为 1h～6h，动态接口类设为 30m～2h，归档类内容可设为 24h 或 7d
- 必须配合 keys_zone 大小使用：inactive 时间越长，keys_zone 内存需越大，否则 key 元信息可能被挤出，导致无法准确追踪访问时间
- 与 max_size 协同工作：当磁盘空间逼近 max_size 时，Nginx 会优先按 inactive 规则清理最久未访问的条目，这是它的第一级空间回收策略
典型配置示例与效果对比
比如以下配置：
proxy_cache_path /var/cache/nginx/docs levels=1:2 keys_zone=docs_cache:20m inactive=7d max_size=2g;
表示：
— 缓存键存储在 20MB 共享内存中
— 所有缓存文件保存在 /var/cache/nginx/docs 下，按两级目录散列
— 任意缓存条目若连续 7 天没被访问过，就会被自动清理
— 总磁盘占用上限为 2GB，超限时按 inactive 从最老未访问项开始释放空间
对比不设 inactive 或设为 1h 的情况：7d 设置下，一份每月仅被查一次的 PDF 文档能稳定保留在缓存中，既节省回源开销，又不会因“过期却未访问”而被误删；而 1h 设置会导致它每次访问后都得重新缓存，失去意义。
验证与调优方法
- 用
sudo nginx -t检查配置语法，再sudo nginx -s reload生效 - 观察日志：
tail -f /var/log/nginx/cache.log（需提前在 nginx.conf 中开启log_format cache …和access_log … cache）可看到 cache manager 的清理动作 - 手动触发清理检查：
sudo find /var/cache/nginx/docs -type f -mtime +7 | wc -l可粗略估算当前有多少文件符合 inactive 条件（注意：实际清理由 Nginx 自行执行，不依赖系统 find） - 监控磁盘使用趋势：结合
df -h /var/cache/nginx和缓存命中率（$upstream_cache_status）判断 inactive 是否设得过松或过紧
