ip_hash仅提供客户端ip到后端的固定映射，不处理会话转移；宕机后的请求转移依赖健康检查、proxy_next_upstream重试、backup兜底及共享session存储。
ip_hash 本身不负责会话转移，它只做固定映射。后端宕机后能否“转移”，取决于你是否配置了健康检查、故障剔除和兜底机制，而不是 ip_hash 自身行为。
ip_hash 遇到宕机不会自动重哈希
ip_hash 的核心是确定性：同一客户端 IP 永远算出同一个后端索引（只要 upstream 列表没变）。它不感知服务器死活，也不动态调整哈希结果。
- 某台 server 宕机后，该 IP 的请求仍会尝试发给它，直到触发失败逻辑
- 若没配健康检查，Nginx 直接返回 502 或超时，用户看到错误
- 即使配了 max_fails，也只是临时屏蔽该节点；屏蔽期一过，请求仍回到原 server——因为哈希值没变
靠 proxy_next_upstream + 健康检查实现有限重试
真正让请求“换机器”的，是 Nginx 的失败重试机制，不是 ip_hash 重分配。
- 在 upstream 中为每个 server 设置 max_fails=3 fail_timeout=30s，连续失败 3 次后标记为不可用 30 秒
- 配合 proxy_next_upstream error timeout（默认已启用），当连接失败时，Nginx 按 upstream 中 server 的声明顺序，线性查找下一个健康节点
- 注意：这不是重新哈希，而是“挨个试”，所以 server 顺序会影响实际转发路径
加 backup 节点提供兜底能力
仅靠重试还不够稳定，尤其当多数节点异常时，需要显式定义备用出口。
- 在 upstream 中添加带 backup 标记的 server：server 192.168.1.104:8080 backup;
- 只有当所有非 backup 节点都被标记为不可用时，流量才会转向 backup 节点
- 搭配 proxy_next_upstream_tries 3 可限制最多尝试次数，避免长尾延迟
会话层必须解耦，不能只靠 ip_hash
即便请求成功转到新节点，原服务器上的 Session 也丢了。生产环境必须从应用层规避这个问题。
- 用 Redis 或其他共享存储集中管理 Session，所有后端读写同一份数据
- 前端携带 token，后端统一鉴权并拉取用户状态，不再依赖本地内存 Session
- 如需更强路由稳定性，可改用 hash $cookie_session_id，比 IP 更抗网络切换
