ip_hash本身不自动重分配请求，需依赖Nginx健康检查（max_fails/fail_timeout）触发proxy_next_upstream线性重试，配合backup节点和Redis共享Session才能实现稳定会话保持。
后端服务器宕机后，ip_hash 本身不会自动把原属该节点的请求“重新分配”到其他节点——它只会继续尝试转发，直到触发失败重试机制或返回错误。真正的重新分配依赖于 Nginx 的健康检查与故障剔除逻辑，而非 ip_hash 算法本身。
ip_hash 不具备自动漂移能力
ip_hash 的核心行为是确定性哈希：同一客户端 IP 永远映射到固定 server（只要 upstream 列表不变）。它不感知后端是否存活，也不主动调整映射关系。所以当某台 server 宕机：
- 后续来自该 IP 的请求仍会打向已宕机的 server
- 若未配置健康检查，Nginx 会直接返回 502 或超时
- 即使配置了 max_fails/fail_timeout，也只是临时屏蔽该 server，但该 IP 的哈希结果没变，屏蔽期过后仍会回到原节点
靠健康检查实现有限故障规避
虽然 ip_hash 不支持自动重散列，但可通过以下参数让 Nginx 主动避开已知故障节点：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- max_fails=3 fail_timeout=30s：连续 3 次失败后，将该 server 标记为不可用 30 秒
- 在此期间，该 IP 的请求会触发
proxy_next_upstream逻辑（默认含 error、timeout），尝试下一个可用 server - 注意：这并非“重新哈希”，而是按 upstream 中 server 的声明顺序线性查找下一个健康节点
真正稳定的应对方式
仅靠 ip_hash + 健康检查仍存在会话中断风险。生产环境建议组合使用：
-
显式标记 backup 节点：在 upstream 中添加
server 192.168.1.104:8080 backup;，当所有非 backup 节点都不可用时，流量才转向 backup - 日志中记录 $upstream_addr：确认实际转发目标，验证故障期间是否命中 backup 或触发重试
- 避免频繁变更 upstream 列表：增删 server 会导致全量 IP 映射重散列，大量用户 session 丢失
- 会话层兜底方案：如 Redis 共享 Session，降低对 ip_hash 会话保持的强依赖
验证宕机后的实际行为
不要只看配置，要实测：
- 用不同公网 IP（或代理工具）发起请求，观察 access log 中
$upstream_addr字段变化 - 手动停掉某台后端服务，持续发请求，确认是否出现 502、是否跳转到其他节点、是否最终落到 backup
- 检查 error log 是否有
connect() failed或no live upstreams类报错
