backup节点仅在所有非backup节点不可用时启用，其weight无效；排查需聚焦error log中“no live upstreams”等提示，并验证proxy_next_upstream配置是否触发重试至backup。
weight 和 backup 混用本身没有语法错误，但容易引发预期外的流量行为——比如 backup 节点在非故障时被意外调用，或权重失效导致负载倾斜。排查重点不是“能不能用”，而是“是否按设计运行”。
确认 backup 节点是否被提前启用
backup 服务器默认完全不参与调度，哪怕它 weight 很高。只要有一个非 backup 节点健康，backup 就不会收任何请求。常见误判原因：
- 主节点被 max_fails 标记为不可用后未恢复：检查 fail_timeout 时间是否已过，Nginx 不会自动重试连接，只会在超时后首次新请求时试探一次
- 主节点实际健康但持续返回 5xx：如果 proxy_next_upstream 包含 http_500–504，每次失败都会计入 max_fails，加速下线
- 多个主节点同时异常：例如两个主节点都触发了 max_fails，backup 才会接管；此时看 error log 中是否有 “no live upstreams” 类提示
验证 weight 是否在主节点间正常生效
weight 只对当前健康的非 backup 节点起作用。一旦某个主节点被标记为 unavailable，它的 weight 就退出计算，剩余健康节点按比例重新分配流量。
- 用 nginx -T | grep -A5 "upstream backend" 确认配置已加载，且 weight 值未被覆盖或拼写错误（如写成 weigth）
- 观察 access log 中各后端 IP 的请求量比例：若配置 weight=3 和 weight=1，健康状态下应接近 75% : 25%，而非 50% : 50%
- 注意：backup 节点即使设了 weight（如 weight=10 backup），weight 也无效——它只在启用时承担全部剩余流量，不参与比例分配
检查 proxy_next_upstream 是否与 backup 协同工作
backup 是兜底角色，而 proxy_next_upstream 决定“单次请求失败后要不要换人”。二者必须配合才能实现平滑转移：
- proxy_next_upstream 至少要包含 error timeout http_502 http_503 http_504，否则连接失败或网关错误不会触发重试，请求直接报错，backup 根本没机会介入
- proxy_next_upstream_tries 应 ≥ 非 backup 节点数 + 1（例如 2 主 + 1 backup，建议设为 3），否则可能重试完所有主节点就返回错误，跳不过去
- 如果设置了 proxy_next_upstream_timeout，总耗时超限也会终止重试，backup 同样无法启用
抓取日志定位真实故障路径
Nginx error log 是最直接的判断依据，重点关注 upstream 相关记录：
- 出现 "upstream timed out" 或 "connection refused"：说明 proxy_pass 连接阶段失败，会触发 max_fails 计数
- 出现 "upstream prematurely closed connection"：后端主动断连，若 proxy_next_upstream 包含 error，也会计入失败并可能重试
- 出现 "no live upstreams while connecting to upstream"：所有非 backup 节点都被标记为不可用，backup 已启用——此时再查 backup 节点自身是否健康
