多级代理故障转移需确保各层健康状态独立维护、不跨层污染，严格隔离upstream定义，显式配置proxy_next_upstream，精准定位error log失败源头，并验证backup启用逻辑。
排查多级代理嵌套下故障转移状态传递错乱，核心是确认“健康状态”和“失败判定”是否在各层之间被准确识别、独立维护、不跨层污染。不是看某一层是否 down，而是看每一层是否把上游的失败当成自己的失败、是否把下游的异常误判为自身超时、是否因配置混用导致 backup 提前启用或永不启用。
查 upstream 状态是否被错误继承
多层 Nginx 共用同一 upstream 名称（如都叫 backend），但实际指向不同后端，会导致健康检查标记混乱：入口层标记某个 IP 为 down，中间层却仍把它当 healthy 用。必须做到：
- 每台 Nginx 的 upstream 块只定义直连目标，例如入口层 upstream mid-gw { server 10.1.2.10:80; }，中间层 upstream app-svc { server 10.2.3.5:8080; }；
- 禁用跨层引用，如入口层不能写 proxy_pass http://mid-gw/app/，然后让 mid-gw 自己再定义一个同名 upstream app-svc —— 这会切断健康状态链路；
- 用 nginx -T | grep -A 5 "upstream backend" 检查实际生效的 upstream 定义，确认没有重复或覆盖。
验 proxy_next_upstream 是否与实际响应匹配
故障转移触发依赖于单次请求失败后是否重试，而这个“失败”由 proxy_next_upstream 显式定义。常见错乱是：后端返回 502，但配置里没写 http_502，结果请求直接失败，backup 根本不参与。
- 在每一层的 location 中检查该指令，例如：proxy_next_upstream error timeout http_502 http_503 http_504;；
- 去掉 timeout 后再测试：若此时 502 请求不再重试，说明此前是靠 timeout 间接触发，掩盖了状态码未显式声明的问题；
- 配合 proxy_next_upstream_tries 3 和 proxy_next_upstream_timeout 10s，确保重试轮次和总窗口可控，避免无限兜底。
盯 error log 中的 fail 标记源头
真正决定节点是否被踢出的是日志里那句 "upstream temporarily disabled"。但要注意它出自哪一层、因何而起：
- 在入口层日志中搜 "max_fails=3 fail_timeout=30s" 对应的报错，确认是连接拒绝（connection refused）还是读超时（read timeout）；
- 如果中间层日志出现大量 "no live upstreams"，说明它的 upstream 已全被标记为 down，但入口层却还在往它发流量——说明入口层 health check 未开启，或探测路径（如 /healthz）在中间层被 rewrite 错误拦截；
- 对比各层 access log 的响应状态码与 error log 的失败记录：若某请求返回 504，但 error log 里只有中间层报 connect() failed，说明入口层未收到真实失败信号，问题卡在中间层建连阶段。
测 backup 启用逻辑是否符合预期
backup 节点是否启用，只取决于“当前是否有可用的非 backup 节点”。看似简单，实则极易被误判：
- 临时注释掉所有非 backup server 行，重启 Nginx，确认 backup 能正常承接流量；
- 恢复非 backup 配置，手动 curl 触发一次 502（比如停掉一个后端），观察 error log 是否出现对应节点的 "max_fails exceeded" 记录；
- 若 backup 仍未启用，检查该非 backup 节点是否被 max_fails 标记为 down 后，又在 fail_timeout 内自动恢复了（即“刚踢又拉回”），可通过 fail_timeout 设为 60s 并等待观察；
- 注意：backup 不受 weight 影响，删掉所有 weight=xx backup 的写法，避免干扰判断。
