ip_hash不支持自动故障转移，同一IP请求始终绑定固定后端；backup仅在所有主节点全部失效时启用，无法分担单点故障，且不继承哈希逻辑。
ip_hash 本身不支持自动故障转移，同一 IP 的请求永远绑定固定后端；但可以配合 backup 节点实现有限的应急承接能力——不是“自动漂移”，而是靠人工预置 + 健康检查协同工作。
backup 节点在 ip_hash 中的实际作用
当某台主 server 宕机时，ip_hash 不会把原属于它的用户流量重新分配给其他主节点，而是直接返回 502（除非配置了 proxy_next_upstream）。backup 节点此时不会被自动启用。它只在所有非 backup 的 server 全部失效时才参与调度。
- 也就是说：一台主节点挂了，其余主节点仍在线 → backup 不接管
- 所有主节点都不可用（max_fails 触发且未恢复）→ backup 开始接收所有 IP 的请求
让 backup 在部分故障时也能起作用的实用做法
不能依赖 backup 自动分担单点故障，但可通过以下方式增强可用性：
- 手动将故障主节点临时改为 backup：比如把
server 192.168.1.101:8080;改成server 192.168.1.101:8080 backup;，再 reload Nginx，这样它就退为备用，原 IP 流量仍走其余主节点，不会中断 - 提前部署一个常驻 backup 节点，配置为高可用实例（如共享 session 存储），确保它能承载突发流量
- 搭配
max_fails=2 fail_timeout=30s使用，让 Nginx 快速识别并临时屏蔽故障节点，减少 502 暴露时间
必须避开的典型误区
很多人误以为加了 backup 就能“无缝接管某台宕机机器的用户”，但在 ip_hash 下这不成立：
- ip_hash 和 weight 不能共存：加了 weight 参数会导致 nginx 启动失败，所以无法通过调权把流量导给 backup
- backup 不继承哈希逻辑：一旦 fallback 到 backup，所有 IP 都打到同一个地址，失去会话一致性
- 不建议在 NAT 环境下依赖 backup 补救：企业出口 IP 集中，backup 承载压力会远超预期
验证与观察建议
上线前务必确认行为是否符合预期：
- 日志里加
$upstream_addr字段，看故障前后 IP 分配是否稳定、backup 是否只在全主节点失效时出现 - 用不同公网 IP（或代理工具）模拟多客户端，避免本地测试误判为“始终打到同一台”
- 灰度阶段主动 kill 一台主服务，观察 error log 和响应状态码，确认是 502 还是已切到 backup
