如何通过 proxy_cache_path 的 inactive 参数自动剔除长期无人访问的冷数据-Nginx-PHP中文网

inactive参数是按“最后访问时间”清理冷缓存的核心机制，不依赖响应头过期时间，只在cache manager周期扫描时删除超时未被命中的缓存条目。

如何通过 proxy_cache_path 的 inactive 参数自动剔除长期无人访问的冷数据

nginx 的 proxy_cache_path 中的 inactive 参数，是自动清理冷缓存的核心机制——它不看内容是否过期，只看缓存项**最后一次被访问距今是否超过设定时长**；一旦超时，该缓存文件就会在后续的 cache manager 循环中被无条件删除。

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（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

验证方式：用 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）