缓存未按预期过期，本质是nginx未按配置判定过期时机，需验证proxy_cache_valid是否覆盖实际状态码、排除响应头干扰（如cache-control、set-cookie）、通过x-cache-status和缓存文件mtime确认真实过期行为，并检查cache_key是否因动态参数导致伪未命中。
缓存未按预期时间过期，问题不在“删没删”，而在于“该不该过期、什么时候判定过期、依据哪条规则过期”。关键要验证 Nginx 实际采用的过期策略是否与配置一致，同时排除响应头、状态码、缓存键等干扰因素。
确认 proxy_cache_valid 是否真正生效
这条指令是代理缓存过期的核心控制项，但容易被忽略细节导致失效：
- 必须显式覆盖实际返回的状态码——例如后端返回的是 200，但配置只写了
proxy_cache_valid 404 1m，那 200 响应根本不会设过期时间，可能沿用默认（或不缓存） - 检查是否被其他指令覆盖：如 location 中误配了
expires或add_header Cache-Control，它们只影响浏览器，但若和proxy_cache_valid混用，易造成逻辑混淆 - 确保
proxy_cache_valid出现在启用缓存的 context 下（即有proxy_cache的 location 或 server 块中），否则不生效
排查响应头对缓存行为的干扰
上游响应头可直接覆盖 Nginx 缓存策略，尤其当后端主动控制缓存时：
- 若后端返回
Cache-Control: no-cache、private或no-store，Nginx 默认不缓存该响应；需加proxy_ignore_headers Cache-Control显式忽略 - 响应含
Set-Cookie头时，Nginx 默认 bypass 缓存；可用proxy_hide_header Set-Cookie隐藏，再配合proxy_cache_valid强制缓存 - 注意
Expires响应头优先级低于Cache-Control，但若两者冲突且未忽略，可能触发意外行为
验证缓存实际过期行为是否符合预期
不能只看配置，必须通过运行时证据判断：
- 在配置中添加
add_header X-Cache-Status $upstream_cache_status;，用curl -I观察响应头：看到X-Cache-Status: EXPIRED表示缓存存在但已过期，Nginx 正在回源；若一直是MISS，说明压根没缓存成功 - 开启日志变量
$upstream_cache_status，记录到 access_log，观察一段时间内EXPIRED出现频率是否与设置的过期时间吻合（如设了 10m，但 2 分钟就大量 EXPIRED，说明有更短的策略在起作用） - 进入缓存目录（如
/var/cache/nginx/），用stat查看缓存文件的Modify时间，对比其与当前时间差值，确认是否真按设定时长保留
检查 cache_key 是否导致“伪过期”假象
缓存键变化会让 Nginx 认为这是全新请求，旧缓存还在，新请求却无法命中——看起来像“不过期”，实则是“换了个 key”：
- 典型情况：URL 带随机参数（
?v=123、&t=1727776440），而proxy_cache_key包含了$request_uri - 解决方法：用
set和if对 URI 标准化，剔除变动参数，再构造 key；例如只保留$scheme$host$uri，忽略所有 query string - 也可用
proxy_cache_bypass控制哪些请求绕过缓存（如带nocache参数的请求），避免污染缓存池
