inactive参数是按“最后访问时间”清理冷缓存的核心机制，不依赖响应头过期时间，只在cache manager周期扫描时删除超时未被命中的缓存条目。
nginx 的 proxy_cache_path 中的 inactive 参数，是自动清理冷缓存的核心机制——它不看内容是否过期，只看缓存项**最后一次被访问距今是否超过设定时长**；一旦超时，该缓存文件就会在后续的 cache manager 循环中被无条件删除。
inactive 的真实作用：按“最后访问时间”而非“生成时间”判断冷热
inactive 定义的是缓存条目在缓存区中**未被任何请求命中（即未被读取）的最大存活时间**。注意以下关键点：
- 它与
proxy_cache_valid独立：即使响应头声明缓存有效期为 1 小时，只要inactive=10m，且这 10 分钟内没人再访问该 URL，该缓存仍会被删 - 它不依赖于文件修改时间或响应头中的
Expires/Cache-Control，只依赖 nginx 内部记录的last_access_time - 触发清理的不是即时操作，而是由后台的 cache manager 进程周期性扫描（默认每秒一次），找出所有
last_access_time + inactive 的文件并移除
配置示例与冷数据剔除效果验证
典型配置如下：
proxy_cache_path /var/cache/nginx/proxy levels=1:2 keys_zone=mysite:10m inactive=30m max_size=1g;
含义是：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 缓存键使用
mysite共享内存区（10MB，可存约 8 万 key） - 任意缓存条目若连续 30 分钟没被
proxy_cache_use_stale或正常请求命中，就标记为待清理 - cache manager 每次扫描会实际删除这些条目，并释放磁盘与共享内存中的索引
验证方式：用 curl 访问某资源一次，等待超时后再次访问，会发现 nginx 重新回源（查看 nginx -s reload后的 access log 或用 $upstream_cache_status 变量确认为 MISSED）。
配合其他参数避免误删或堆积
仅靠 inactive 不足以构建稳健缓存策略，需协同控制：
-
必须设置
keys_zone大小合理：若共享内存不足，旧 key 会被踢出，导致即使文件还在磁盘，nginx 也认为“未缓存”，进而无法更新last_access_time，加速误删 -
慎用
proxy_cache_lock：开启后首次未命中会锁住回源，但若此时有大量并发冷请求，可能因锁等待导致last_access_time未及时刷新，间接缩短实际存活时间 -
搭配
max_size：当磁盘空间逼近上限，nginx 会优先删除last_access_time最早的条目（不管是否超inactive），形成双重淘汰逻辑
常见误区与调试建议
遇到冷数据未如期清理，可检查：
- 确认
proxy_cache已在 server 或 location 块中启用，且请求实际进入缓存流程（可用$upstream_cache_status打印日志） - 检查系统时间是否稳定：cache manager 依赖系统时钟，若发生跳变（如 NTP 校正），可能导致批量误删或延迟清理
- 观察
/var/cache/nginx/proxy目录下文件的atime（访问时间）通常不准确，nginx 自维护时间戳，应以日志和proxy_cache_valid行为为准 - 临时调高
error_log级别到info，可看到 cache manager 的扫描与清理日志（如cache manager process XXX exited或cache file ... is inactive）
