故障转移后静态缓存未命中本质是新节点缓存环境不一致或请求标识隐性变化，导致缓存键失效、未建立或被绕过；需聚焦请求路径、缓存写入、响应可缓存性三环节，通过$upstream_cache_status日志、cache_key稳定性、配置同步及静态文件路径准确性逐项排查。
故障转移后静态缓存未命中、请求穿透到后端，本质不是“缓存丢了”，而是新节点的缓存环境与原节点不一致，或请求路径/标识在切换后发生了隐性变化，导致缓存键失效、缓存未建立、或直接被绕过。排查需聚焦“请求是否还走缓存路径”“缓存是否真被写入”“响应是否允许缓存”三个环节。
确认故障转移后缓存配置是否生效
主备切换后，常因配置未同步、reload 不彻底或作用域错误，导致 proxy_cache 未启用：
- 检查新节点的 location 块中是否明确启用了 proxy_cache 和对应 keys_zone（如
proxy_cache static_cache;），不能只依赖 http 块定义而漏写 location 内启用项 - 验证 proxy_cache_path 路径是否存在、权限可写（如
/var/cache/nginx/static），用stat /var/cache/nginx/static确认属主为 nginx 用户，且磁盘未满 - 注意：Nginx reload 不会清空已有缓存，但若新配置中
keys_zone名称变更或proxy_cache off被误加，会导致所有请求 fallback 到 BYPASS 状态
比对故障前后 $upstream_cache_status 日志行为
这是最直接的判断依据——不要只看配置，要看运行时状态：
- 在 access_log 中加入
$upstream_cache_status，对比切换前后日志中 HIT / MISS / BYPASS / EXPIRED 的分布突变 - 若切换后大量出现 BYPASS：说明请求被规则跳过，重点查是否新增了 Cookie、Authorization 头，或后端返回了
Cache-Control: no-cache、Set-Cookie等禁止缓存头 - 若大量是 MISS 且持续不转 HIT：说明缓存未成功写入，可能是
proxy_cache_valid未覆盖响应状态码（如后端返回 206 或 302）、或proxy_ignore_headers缺失导致响应头阻断缓存
检查缓存键（proxy_cache_key）是否因故障转移产生不一致
同一 URL 在主备节点生成不同 cache_key，就会各自建缓存、互相不可见，等于没共享：
- 确认 key 中是否含易变字段：比如用了
$host但 DNS 解析在故障转移后指向了不同域名；或用了$cookie_session但新节点 session 机制不同 - 静态资源应使用稳定标识：推荐
proxy_cache_key "$scheme$host$uri";（去掉$args和所有 cookie 变量），对带哈希的文件（如 app.a1b2c3.js），确保前端请求 URL 与实际文件名一致，而非用app.js?v=a1b2c3这类参数式引用 - 用
curl -I对比主备节点响应头中的X-Cache（需配置add_header X-Cache $upstream_cache_status;），确认相同 URI 是否在两边都返回 HIT
验证静态文件查找逻辑是否因路径/别名配置错位而穿透
很多“缓存未命中”其实是静态文件根本没被 Nginx 找到，直接 fallback 到后端代理，压根没进缓存流程：
- 检查
location是否精确匹配静态扩展名（如location ~* \.(js|css|png)$），避免被更宽泛的location /拦截并转发给后端 - 确认
root或alias路径是否正确：用ls -l /path/to/static/css/app.css手动验证文件存在性；若用alias，注意它会截去 location 前缀，容易配错目录层级 - 检查
try_files行为：例如try_files $uri =404;中若$uri对应路径不存在，就直接 404，不会触发 proxy_pass，自然也不会进缓存
