inactive 是 Nginx 缓存冷数据淘汰的核心机制，以最后一次命中为起点计时，超时且无活跃请求时由 cache manager 异步清理，需配合 max_size、keys_zone 等参数生效。
inactive 参数是 Nginx 清理冷数据最核心、最可靠的机制——它不看响应头是否过期，也不管请求频率高低，只盯住一个事实：这个缓存项最后一次被成功命中后，已经闲置多久了。超时即标记待删，由后台 cache manager 自动处理。
inactive 的真实作用逻辑
它不是缓存有效期，而是“驻留容忍期”：
- 每次 proxy_cache hit（包括正常 HIT 或 STALE 状态下启用了 proxy_cache_use_stale）都会重置该缓存项的 last_access_time
- cache manager 默认每 200ms 扫描一次共享内存，检查 last_access_time + inactive < now 的条目
- 只有同时满足“超时”和“当前无活跃请求占用”，才真正触发清理
- 清理是异步的：先从共享内存中移除 key 索引，再在磁盘空间压力（如 max_size 触发）或后续扫描中物理删除文件
必须配合的关键参数
单独设 inactive 没用，必须协同配置才能生效：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- max_size 必须显式设置，例如 max_size=10g；否则 cache manager 不会执行磁盘级清理，冷数据可能长期滞留
- keys_zone 要够大：每 1MB 共享内存约支持 8000 个 key；若预计有 50 万个缓存 key，keys_zone 至少要 64m
- use_temp_path=off 是推荐实践，避免临时文件干扰缓存一致性
- proxy_cache_valid 需合理设置，它决定“能否缓存”和“是否可返回 stale”，但不影响 inactive 的淘汰判断
按业务场景设值参考
不能一刀切，要匹配资源实际访问衰减节奏：
- 静态资源（JS/CSS/图片）：inactive=1h～6h —— 热门常驻，冷门几小时无访问就释放
- API 列表页、详情页：inactive=12h～24h —— 覆盖夜间低谷，兼顾复用与及时回收
- 文档页、旧博客、PDF 归档：inactive=7d～30d —— 长尾内容月均访问几次，设太短等于白缓
- 临时活动页、灰度接口：inactive=10m～30m —— 快速回收，防止残留干扰测试
典型配置示例
以下是一个生产可用的完整写法：
proxy_cache_path /var/cache/nginx/proxy levels=1:2 keys_zone=docs_cache:30m inactive=30d max_size=10g use_temp_path=off;含义是：
- 缓存键使用 docs_cache 共享内存区（30MB，支持约 24 万 key）
- 任意缓存条目连续 30 天未被命中，就会被标记为待清理
- 总磁盘占用超过 10GB 时，Nginx 会优先淘汰 last_access_time 最早的条目
