如何设置proxy_cache_path的inactive参数来自动清除低热度缓存？

本文共计789个文字，预计阅读时间需要4分钟。

inactive 参数是

inactive 的真实作用逻辑

它不是定时删除，而是“懒清理”：Nginx 的 cache manager 进程会周期性扫描缓存元数据，把 inactive 时间内未被访问的条目从共享内存中移除，并在后续磁盘清理时（比如 max_size 触发 LRU）一并删掉对应文件。所以 inactive 是“软淘汰”，真正物理删除依赖后续空间压力或主动触发。

• 例如 inactive=30m：某条缓存自写入后 30 分钟内没被任何请求匹配到，就会被标记为不活跃
• 即使它还没到 proxy_cache_valid 设定的有效期（比如设置了 24h），也会被提前踢出缓存索引
• 如果该缓存之后又被请求，会重新拉取后端、重建缓存，不受之前 inactive 状态影响

合理设置 inactive 值的参考依据

值太小会导致频繁回源，值太大又起不到清理低热度数据的效果。建议结合业务访问特征来定：

• 静态资源（JS/CSS/图片）：通常 inactive=1h～6h 足够，热门资源自然常驻，冷门资源几小时无访问就释放
• API 接口类缓存（如列表页、详情页）：若页面有明显访问波峰（如早九点、晚八点），可设 inactive=12h～24h，覆盖一个完整低谷周期
• 临时活动页或灰度接口：建议 inactive=10m～30m，快速回收非活跃路径，防止缓存堆积

配合其他参数提升清理效率

单独调大 inactive 效果有限，需与 max_size 和 keys_zone 协同使用：

• max_size 必须明确设置：比如 max_size=5g，否则 cache manager 不会主动触发磁盘级清理，inactive 标记的条目可能长期滞留
• keys_zone 内存要留余量：每 1MB 共享内存约支持 8000 条缓存键；如果 keys_zone 太小，旧键挤不出去，新缓存就无法写入，反而降低命中率
• use_temp_path=off 推荐开启：避免临时文件拷贝延迟清理判断，让 inactive 生效更及时

验证 inactive 是否生效的小技巧

不需要等满时间，可通过日志和目录观察快速确认：

• 用 curl -I http://your-domain/path 多次请求目标 URL，记录首次和末次时间间隔
• 等待超过 inactive 设置的时间后，再次请求，观察响应头是否含 X-Cache: MISS（说明已失效）
• 进缓存目录（如 /Users/john/nginx_cache），执行 find . -type f -mmin +30 | head -5（假设 inactive=30m），看是否有文件修改时间远超 inactive，这类就是待清理但尚未被 manager 扫描到的残留