缓存有效期提前结束主因是空间不足触发inactive淘汰，而非proxy_cache_valid生效；需检查du -sh缓存目录是否超max_size、error.log中cache manager频繁启停、keys_zone共享内存是否饱和、x-cache-status是否异常miss/expired及inactive值是否过短。
缓存有效期提前结束，不一定是配置的 proxy_cache_valid 生效了，更常见的情况是：缓存空间不足，Nginx 主动淘汰了“冷数据”，哪怕它还没过期。这种淘汰不是按时间走的，而是按 inactive 参数和磁盘/内存压力触发的。排查关键在于确认是不是空间机制在起作用，而不是时间策略。
看缓存目录实际使用率和清理日志
Nginx 不会主动告诉你“我因为满删了谁”，但会留下痕迹：
- 用
du -sh /data/nginx/cache查看缓存路径总大小，再对比配置里的max_size=10g—— 如果已接近或超过上限，说明空间已触顶； - 检查 Nginx 错误日志：
grep "cache manager" /var/log/nginx/error.log，你会看到类似cache manager process [xxx] exited on signal 15或cache manager process [xxx] started的记录，这是 Nginx 启动后台清理进程的标志； - 如果日志里频繁出现
cache manager process ... started（比如每分钟一次），大概率是缓存区持续处于高压状态，系统在反复扫描并踢出 inactive 条目。
查共享内存 keys_zone 是否被填满
keys_zone 是缓存的“索引簿”，它本身也占内存。即使磁盘还有空间，如果这块共享内存满了，Nginx 就无法注册新缓存项，老条目也会被强制淘汰：
- 运行
ipcs -m | grep nginx，找到对应 keys_zone 的共享内存段（名字通常含my_cache）； - 用
ipcs -m -i <shmid></shmid>查看该段详细信息，重点关注bytes（已用字节数）和lpid（最后操作进程）； - 如果
bytes接近你配置的keys_zone=my_cache:50m中的 50MB，说明索引已饱和——这时即使文件没过期、磁盘有空闲，新请求也无法缓存，旧缓存也可能被挤出。
观察缓存命中率与失效模式
空间压力导致的淘汰，行为特征明显：
- 加响应头
add_header X-Cache-Status $upstream_cache_status;，大量请求返回MISS或EXPIRED，但对应资源明明刚被访问过（比如同一页面刷新多次仍不 HIT）； - 用
find /data/nginx/cache -type f -mmin -5 | wc -l检查最近 5 分钟有没有新缓存文件生成，如果没有，说明缓存写入已停滞； - 对比不同资源的缓存表现：大文件（如 JS/CSS）比小文件（如图标）更容易被优先淘汰，因为它们单个占用空间大，Nginx 清理时倾向“删大放小”。
验证 inactive 设置是否过短
inactive=1d 这类参数看似宽松，但在高并发低频访问场景下可能很激进：
- 它表示“最后一次访问后 24 小时无访问就删”，但这个“访问”指的是被 Nginx 成功读取并返回，不是浏览器请求；
- 如果某资源一天只被访问 1 次，但每次都是并发 100 人同时请求，Nginx 可能因锁竞争或 I/O 延迟，导致部分请求未能及时更新“最后访问时间”，结果被误判为 inactive 而清除；
- 建议先临时调大 inactive（比如改为
inactive=7d），观察缓存稳定性是否提升，再结合业务访问规律逐步收敛。
