EXPIRED 状态不能直接反映资源冷热，真正冷门资源需满足“曾被缓存（HIT/EXPIRED）且长期无访问（持续MISS）”；应基于历史HIT间隔的P95分位数加20%缓冲设定inactive值，并检查keys_zone是否过载。
EXPIRED 状态高频出现本身不能直接说明资源冷热，反而可能掩盖真正的问题——它只反映缓存条目已过期（由 proxy_cache_valid 控制），但未必未被访问。要评估冷门资源的 inactive 时间，关键不是看 EXPIRED 多不多，而是看哪些资源“过期了却长期没人再访问”，即持续处于 EXPIRED + 未被 HIT 的状态。
先区分 EXPIRED 和 inactive 的作用边界
EXPIRED 是时间驱动的状态：响应一旦超过 proxy_cache_valid 设定的时限（比如 1h），就标记为过期，后续请求默认需回源，除非启用 proxy_cache_use_stale。
inactive 是行为驱动的清理阈值：只要某缓存文件在设定时间内（如 2h）完全没被任何请求命中（无论是否 EXPIRED），Nginx 就会把它从磁盘删掉。
二者正交——一个资源可以既是 EXPIRED，又因仍在被频繁访问而远未触发 inactive 清理；反之，一个资源可能还“在有效期内”，却因无人问津，在 inactive 到期后被提前清除。
用日志识别真正冷门的资源
单纯统计 EXPIRED 比例意义有限。应结合 $upstream_cache_status 日志字段，聚焦以下组合：
- EXPIRED + MISS：表示缓存已过期，且本次请求未命中（即没用上旧缓存，也没用上新缓存），大概率是首次访问或缓存已被清空
-
EXPIRED + STALE：说明启用了
proxy_cache_use_stale，系统正在降级使用过期缓存——这反而是“有访问但不想回源”的信号，不算冷资源 -
MISS（非 EXPIRED）：重点排查——如果某 URI 长期只出现 MISS，且无对应 HIT 或 EXPIRED 记录，说明它根本没被成功缓存过（可能被
proxy_ignore_headers拦截、或带 Cookie/认证头）
真正冷门资源的典型日志特征是：曾有 HIT 或 EXPIRED 记录，但此后数天内再无任何 HIT，且后续请求持续为 MISS。这类 URI 才值得纳入 inactive 时间调优范围。
基于访问间隔反推合理的 inactive 值
对确认冷门的 URI 组，可回溯其历史 HIT 时间戳，计算相邻两次 HIT 的间隔分布：
- 若 95% 的冷门 PDF 文档两次访问间隔 ≥ 7 天，
inactive=7d就能保证它们稳定驻留，避免反复回源 - 若某类旧 API 接口平均访问间隔为 48 小时，但存在少量 10 天以上长尾，设
inactive=5d可兼顾覆盖与空间效率 - 若某静态资源连续 30 天只有 1 次 HIT，之后再无记录，说明它实质已归档——此时
inactive应大于该周期（如设为 30d），否则刚缓存就删，失去意义
不建议用平均间隔直接设 inactive，而应取 P90 或 P95 分位数，并加 20% 缓冲。低于该值易误删，高于太多则冷数据堆积。
配合 keys_zone 观察元信息存活情况
若发现某些 URI 明明近期有 HIT，却频繁出现 MISS（疑似 inactive 生效），需检查 keys_zone 是否过载：
- 用
nginx -s reload后观察是否大量 URI 突然变 MISS：可能是 keys_zone 太小，key 元信息（含最后访问时间）被挤出，导致 inactive 无法准确计时 - 通过
curl -s http://127.0.0.1/nginx_status（需启用 stub_status）或ss -lnt | grep :80辅助判断 worker 连接压力，高并发下 keys_zone 竞争更明显 - 临时增大 keys_zone（如从 50m → 100m），对比冷资源 MISS 率变化——若显著下降，说明原配置已触及元信息容量瓶颈
