inactive参数专为清理“高频未被访问”的冷数据而设，仅依据最后一次命中后的闲置时长由cache manager每200ms扫描并异步清理，需配合max_size、keys_zone、use_temp_path=off及proxy_cache_valid协同配置。
配置 proxy_cache 的 inactive 参数清理不活跃缓存，关键不是“设个值就完事”，而是理解它只看最后一次命中后的闲置时长，并配合其他参数形成闭环。它不按响应头过期时间删，也不管你请求多勤快，只盯住一个事实：这个缓存项多久没被访问了。
inactive 的真实作用机制
它不是缓存有效期，而是缓存驻留容忍期：
- 每次成功命中（包括正常 HIT 或启用
proxy_cache_use_stale的 STALE 命中），都会重置该缓存项的last_access_time - cache manager 进程默认每 200ms 扫描一次共享内存，检查
last_access_time + inactive是否已过去 - 只有同时满足“超时”和“当前无活跃请求占用”，才真正触发清理
- 清理是异步的：先移除共享内存中的 key 索引，再在磁盘空间压力（如
max_size触发）或后续扫描中物理删除文件
必须配套的关键参数
单独写 inactive=1h 几乎无效，必须协同设置：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
keys_zone：大小要够用。每 1MB 共享内存约支持 8000 个 key。例如预计缓存 50 万个条目，keys_zone=my_cache:64m是底线 -
max_size：必须显式设置（如max_size=10g）。否则 cache manager 不会启动磁盘级回收，inactive 标记的冷数据可能长期滞留 -
use_temp_path=off：避免临时文件干扰缓存一致性，推荐始终关闭 -
proxy_cache_valid：定义哪些状态码缓存多久。它控制“是否返回缓存”，而inactive控制“是否还能被找到”。两者独立又互补
按场景选值才真正管用
不要统一设成 10m 或 7d，得匹配资源的实际访问衰减节奏：
- 静态资源（JS/CSS/图片）：
inactive=1h～6h—— 热门常驻，冷门几小时不访就释放 - API 列表页、详情页：
inactive=12h～24h—— 覆盖夜间低谷，兼顾次日复用 - 文档页、旧博客、PDF 归档：
inactive=7d～30d—— 长尾内容月均访问几次，设太短等于白缓 - 灰度页、活动页、测试接口：
inactive=10m～30m—— 快速回收，防残留干扰
避免常见误配
这些配置会让 inactive 失效或反效果：
- 不设
max_size：冷数据只标记不删除，磁盘越积越多 -
keys_zone过小：key 元信息被挤出共享内存，nginx 无法更新last_access_time，导致误删或漏删 -
proxy_cache_key过细（含$cookie_session、$arg_ts等易变变量）：同一资源生成多个 key，每个都要单独满足inactive才删，清理效率极低 -
inactive=1y或更大：共享内存长期占满，cache loader 启动变慢，磁盘空间难释放
