ip_hash不支持backup参数，带backup的server会被忽略；容错依赖节点自动失效与恢复机制，而非手动标记备用；需主备分离时应改用consistent hash、服务发现或应用层会话共享。
ip_hash 本身不支持 backup 参数，配置了 backup 的 server 在启用 ip_hash 的 upstream 中会被忽略，也不会作为故障转移节点参与调度。
ip_hash 不允许使用 backup
这是 Nginx 的硬性限制：一旦 upstream 块中声明了 ip_hash，所有带 backup、weight、max_fails、fail_timeout 等参数的 server 行都会被静默跳过，甚至可能导致 reload 失败。官方文档明确要求：ip_hash 模式下只允许纯 server 地址行（IP:PORT 或域名:PORT），且必须顶格书写。
那怎么实现“备用机”效果？
真正可行的方式是利用 ip_hash 的自动剔除机制，而非手动标记 backup：
- 当某台后端服务器不可达（连接超时、拒绝连接等），Nginx 会将其临时标记为“失效”，后续对该 IP 的哈希请求会自动重试分配到其他可用节点
- 这个过程无需配置 backup，只要该 server 行没加任何修饰参数，它就在哈希环中；一旦恢复健康（满足 fail_timeout 后再次探测成功），就会重新纳入哈希计算
- 你可以在上游列表里多加一台真实服务器，比如三台正常服务 + 一台低配或专用灾备机，它天然参与哈希，只是流量按 IP 分布自然落到它身上——这不是“备用”，而是“同权参与”
想严格控制备用逻辑？换策略
如果业务需要明确区分主备（例如：90% 流量走 A/B，仅当 A&B 全挂才切 C），ip_hash 就不适合。应改用：
-
hash $remote_addr consistent;（需 nginx ≥ 1.7.2）+ 自定义健康检查 + 主动摘流脚本 - 外部服务发现（如 Consul + nginx-plus 或 OpenResty）动态更新 upstream
- 在应用层做会话复制或接入 Redis Session 存储，回归轮询或加权轮询，释放负载均衡层的绑定压力
简单说：ip_hash 没有传统意义的“备用机”，它的容错靠的是节点自动进出哈希环，不是靠 backup 标签。
