rrc_inactive状态是5g新增的中间态，通过上下文保留、寻呼优化和rna移动性增强，在极低功耗下实现毫秒级唤醒，显著延长iot设备电池寿命。
要让 inactive 真正帮上忙，不能只靠“设个值就完事”，得用监控反馈效果、验证逻辑、反向校准配置。它不是静态开关，而是需要持续观察的动态策略。
看缓存状态码分布，判断是否误删热数据
在 log_format 中加入 $upstream_cache_status，重点关注 MISS 和 EXPIRED 的比例变化：
- 如果某类资源（如
/static/js/下文件）MISS突然升高，但后端响应稳定、proxy_cache_valid未过期，大概率是inactive设得太短，刚缓存就被清掉 - 若
STALE出现频繁，说明inactive和proxy_cache_use_stale配合得当，系统正在主动降级保命，这是健康信号 -
BYPASS或UPDATING异常增多，可能和proxy_cache_lock冲突，需检查inactive是否短于锁等待窗口
查缓存元数据存活情况，确认 keys_zone 是否够用
inactive 能否生效，取决于 key 元信息是否还在共享内存里。可用以下方式验证：
- 用
nginx -T | grep 'keys_zone='查当前keys_zone大小，结合业务预估总 key 数（含冷数据）套用公式：建议 ≥ ⌈总 key 数 ÷ 8000⌉ × 1.2 MB - 开启
error_log的notice级别，留意是否有keys_zone is full或key not found in shared memory类警告 - 通过
curl -s 'http://127.0.0.1/nginx_status' | grep cache（需启用 stub_status）或 Prometheus 暴露的nginx_http_proxy_caches指标，观察cache_misses与cache_expired的增速比——若前者远高于后者，提示 key 元信息丢失，inactive失效
观察磁盘缓存年龄分布，验证清理节奏是否合理
inactive 是懒清理机制，物理删除往往滞后。可做轻量级抽样验证：
- 执行
find /path/to/cache -type f -mmin +60 | wc -l（以inactive=1h为例），若结果远大于预期残留量，说明清理滞后或未触发 - 注意：
-mmin看的是文件修改时间，Nginx 不实时更新 mtime，仅作粗略参考；更准的方式是配合日志中cache_status和访问时间戳交叉分析 - 长期运行后，用
du -sh /path/to/cache/*查二级目录大小分布，若大量空目录或极小目录堆积，可能是 key 元信息失效导致无法归类清理
结合 max_size 触发行为，确认两级回收是否联动
inactive 是软标记，max_size 是硬门槛。二者协同才构成完整空间控制：
- 确保
max_size明确设置（如max_size=5g），否则即使inactive标记了大量条目，也不会触发磁盘级清理 - 当磁盘使用率接近
max_size时，Nginx 会优先按inactive时间倒序清理——此时观察df -h和缓存目录du变化是否同步、延迟是否可控 - 若空间逼近
max_size后仍不释放，检查proxy_cache_path路径权限、磁盘 inode 是否耗尽、或是否存在被进程占用未释放的缓存文件（lsof +D /path/to/cache）
