Nginx故障转移怎么排查故障转移后静态缓存未命中的穿透-Nginx-PHP中文网

故障转移后静态缓存未命中本质是新节点缓存环境不一致或请求标识隐性变化，导致缓存键失效、未建立或被绕过；需聚焦请求路径、缓存写入、响应可缓存性三环节，通过$upstream_cache_status日志、cache_key稳定性、配置同步及静态文件路径准确性逐项排查。

nginx故障转移怎么排查故障转移后静态缓存未命中的穿透

故障转移后静态缓存未命中、请求穿透到后端，本质不是“缓存丢了”，而是新节点的缓存环境与原节点不一致，或请求路径/标识在切换后发生了隐性变化，导致缓存键失效、缓存未建立、或直接被绕过。排查需聚焦“请求是否还走缓存路径”“缓存是否真被写入”“响应是否允许缓存”三个环节。

主备切换后，常因配置未同步、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 状态

这是最直接的判断依据——不要只看配置，要看运行时状态：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

在 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 缺失导致响应头阻断缓存

同一 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，自然也不会进缓存