验证Nginx缓存过期需主动构造可观察行为：查缓存文件Modify时间对比proxy_cache_valid，用curl观测X-Cache状态变化，验证inactive清理与stale降级，并通过日志分析缓存决策逻辑。
验证生产环境中 Nginx 缓存是否按预期过期，关键不是“等它过期再看”，而是主动构造可观察、可复现的缓存生命周期行为。重点在于确认 缓存写入时间、失效触发条件、降级响应逻辑 三者是否协同生效。
检查缓存键与写入时间戳
Nginx 不直接暴露缓存文件的写入时间，但可通过缓存路径结构和文件系统信息间接验证：
- 确认
proxy_cache_path中配置了levels=1:2（或其他层级），缓存文件实际落盘路径由哈希决定，例如/tmp/nginxcache/c/5a/xxxxxx - 用
stat /tmp/nginxcache/c/5a/xxxxxx查看文件的Modify时间，即内容写入缓存的时间点 - 对比该时间与
proxy_cache_valid设置的时长（如200 1h），计算理论过期时刻 - 注意：
inactive参数（如inactive=60m）是“最后访问后未被再命中”的清理阈值，与valid的“首次写入后固定有效期”不同，需分开验证
用 curl 触发并观测缓存状态变化
绕过浏览器缓存干扰，用命令行精确控制请求与观察响应头：
- 首次请求（应穿透缓存，返回后端真实响应）：
curl -I https://api.example.com/data.json
观察响应中是否有X-Cache: MISS（需在 Nginx 配置中添加add_header X-Cache $upstream_cache_status;） - 立即再次请求（应命中缓存）：
curl -I https://api.example.com/data.json
确认X-Cache: HIT，且Date头时间早于当前时间（说明是缓存响应） - 等待超过
proxy_cache_valid设定时间后重试：
若仍为HIT，说明未过期；若变为MISS或UPDATING，说明缓存已失效并触发回源 - 加
-H "Cache-Control: no-cache"强制跳过本地缓存，确保测的是 Nginx 层
验证 inactive 清理与 stale 降级行为
这两项常被忽略，却是生产稳定性关键：
- 设置
proxy_cache_use_stale error timeout updating后，模拟后端故障：
停掉上游服务，再发起请求 —— 若仍返回旧缓存内容且状态码为 200，并带X-Cache: STALE，说明降级生效 - 验证
inactive效果：对某接口持续请求 10 分钟后停止，等待超过设定的inactive时间（如 30m），再发起新请求
若此时变为MISS，说明该缓存条目已被自动清理 - 通过
nginx -T | grep proxy_cache确认配置已加载，避免 reload 后未生效
配合日志定位缓存决策逻辑
在 log_format 中加入缓存相关变量，让每次请求都留下决策痕迹：
- 扩展日志格式：
log_format cache '$remote_addr - $remote_user [$time_local] "$request" '$status $body_bytes_sent "$http_referer" "$http_user_agent" '$upstream_cache_status $upstream_http_last_modified'; - 查看日志片段：
tail -f /var/log/nginx/access.log | grep HIT
可清晰看到哪些请求走了缓存、对应后端返回的Last-Modified时间，辅助判断缓存新鲜度逻辑 - 特别关注
REVALIDATED状态（配合proxy_cache_revalidate使用时），表示 Nginx 主动向后端校验了 ETag 或 Last-Modified
