nginx缓存实际过期需四层验证：响应头x-cache-status切换（hit→expired）、age头推算剩余时间、缓存文件mtime更新、后端请求数突增；任一环节异常均表明缓存未真实失效。
测试 Nginx 缓存有效期的实际过期表现，关键不是看配置写了多久，而是验证缓存是否真在设定时间点失效、是否按预期回源、是否引发后端压力变化。需要把“时间判断”“状态反馈”“物理落地”和“后端响应”四层信号交叉比对，才能确认有效期是否真实生效。
用响应头实时观察缓存状态切换
在 Nginx 配置中加入调试头，让每次响应明确告诉你当前缓存处于什么阶段：
- 添加 add_header X-Cache-Status $upstream_cache_status; 到 location 块中
- 用 curl -I 反复请求目标接口，观察 X-Cache-Status 字段变化：从 HIT → EXPIRED（或 STALE/UPDATING）的切换时刻，就是实际过期发生的信号
- 注意：若始终是 HIT，可能是 proxy_cache_valid 被后端响应头中的 Cache-Control 或 Expires 覆盖了；可临时加 proxy_ignore_headers Cache-Control Expires; 排除干扰
通过 Age 头计算剩余缓存时间
Age 响应头由 Nginx 自动注入，表示该响应已缓存多少秒，结合 proxy_cache_valid 设置可反推剩余有效期：
- 首次请求得到 Age: 0 和 X-Cache-Status: MISS，说明新缓存刚生成
- 稍后再次请求，若返回 Age: 58 且 proxy_cache_valid 200 60s，说明还剩约 2 秒就过期
- 在 Age 接近 TTL 时持续轮询（如每 0.5 秒一次），精准捕获从 HIT 切换为 EXPIRED 的毫秒级瞬间
检查缓存文件的磁盘修改时间
缓存是否真正过期，最终会反映在磁盘文件上。Nginx 不会删除旧文件，但会在过期后写入新内容，mtime 就是关键证据：
- 进入 proxy_cache_path 目录（如 /var/cache/nginx），用 find . -name "*your_key_hash*" -exec stat -c "%n %y" {} \; 查找对应缓存文件
- 在预期过期前后每秒执行一次，观察 Modify 时间是否在设定 TTL 后批量更新
- 如果文件 mtime 长期不变，或只个别更新，说明缓存未真正过期——可能被 inactive 参数延迟清理，或 key 设计导致分裂
压测对比后端请求数突变
最硬核的验证方式：看后端是否在缓存过期那一刻被真实击中：
- 关闭 proxy_cache_use_stale updating，确保过期即回源
- 设 proxy_cache_valid 200 10s，用 wrk 或 ab 在第 9 秒发起并发请求（如 wrk -t4 -c100 -d1s http://host/api）
- 同步监控后端 access.log：过期窗口内请求数应从接近 0 突增至接近并发数（如 100 QPS），且数据库连接、CPU 使用率同步出现尖峰
- 若后端无明显波动，说明缓存未失效，或被 proxy_cache_lock 拦截（此时应看到 UPDATING 状态，而非 EXPIRED）
