在 nginx 的 ip_hash 负载均衡策略中，backup 参数可以正常配置在 upstream 块内，但它的生效逻辑与默认的轮询或加权轮询不同。当使用 ip_hash 时，nginx 会优先将请求分配给状态为 active 的后端服务器；只有当所有非 backup 的后端服务器都不可用时，流量才会被转发到标记为 backup 的备用节点。这意味着 backup 节点在 ip_hash 模式下仅作为故障转移（failover）手段，而不会参与正常的哈希计算和负载分担。
如何正确配置 ip_hash 与 backup 节点
要实现这一功能，只需在 upstream 块中同时声明主服务器和带有 backup 标志的备用服务器即可。Nginx 的配置语法并不排斥这种组合，关键在于理解其调度行为：只要有一台主服务器存活，backup 节点就处于静默状态。以下是一个标准的配置示例，其中 server1 和 server2 为主力节点，server3 为备用节点。
upstream backend {
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080 backup;
}
在上述配置中，客户端 IP 会被哈希映射到 192.168.1.10 或 192.168.1.11。如果这两台服务器均正常运行，192.168.1.12 不会接收任何流量。只有当 192.168.1.10 和 192.168.1.11 同时宕机或无法响应时，Nginx 才会将请求路由至 192.168.1.12。此时，由于 ip_hash 机制依然生效，来自同一 IP 的请求会持续指向 192.168.1.12，直到主服务器恢复。这种设计确保了在主集群故障时，备用节点能接管流量并保持会话一致性，但同时也意味着备用节点在平时是闲置的，资源利用率较低。
ip_hash 下 backup 节点的故障转移行为验证
为了验证上述行为，我们可以模拟主服务器全部宕机的场景。假设当前有两个主服务器 A 和 B，以及一个备用服务器 C。当 A 和 B 都不可用时，来自特定 IP 的请求将被重定向到 C。此时，如果 A 恢复上线，Nginx 的 ip_hash 算法会重新计算该 IP 的目标服务器。由于 A 和 B 已恢复，哈希值通常会再次指向 A 或 B，导致流量从 C 切回主集群。这种切换是自动的，且依赖于哈希计算的稳定性。
# 模拟测试脚本 (Python)
import requests
# 假设 Nginx 监听在 localhost:80
url = "http://localhost/"
headers = {"Host": "backend"}
# 测试 1: 主服务器在线
try:
resp = requests.get(url, headers=headers)
print(f"Status: {resp.status_code}, Server: {resp.headers.get('X-Backend-Server', 'Unknown')}")
except Exception as e:
print(f"Error: {e}")
# 测试 2: 模拟主服务器宕机后，请求流向 backup
# 注意：实际环境中需手动停止 A 和 B 服务
print("Stop servers A and B manually, then send request...")
try:
resp = requests.get(url, headers=headers)
print(f"Status: {resp.status_code}, Server: {resp.headers.get('X-Backend-Server', 'Unknown')}")
except Exception as e:
print(f"Error: {e}")
在实际操作中，可以通过检查 Nginx 的错误日志或后端服务器的访问日志来确认流量是否确实流向了 backup 节点。例如，在 C 服务器上查看日志，如果在 A 和 B 宕机期间出现了来自客户端 IP 的请求记录，则证明 backup 机制生效。此外，需要注意的是，ip_hash 的哈希计算基于客户端 IP 地址，如果客户端位于 NAT 之后或使用移动网络，IP 可能会变化，导致会话丢失。因此，在混合使用 ip_hash 和 backup 时，应确保客户端 IP 的稳定性，或在必要时结合其他会话保持机制。
基于程序中某个输入、条件或结果的具体问题
在 ip_hash 模式下，如果所有主服务器都不可用，而 backup 节点也恰好不可用，Nginx 会返回 502 Bad Gateway 错误。这是因为 ip_hash 要求必须有一个可用的目标服务器来计算哈希映射，如果没有可用服务器，它无法完成请求转发。这种情况下，系统不会尝试其他负载均衡策略，而是直接报错。开发者在处理此类问题时，应确保至少有一个备用节点始终可用，或者配置健康检查机制以快速检测并隔离故障节点，避免雪崩效应。
