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 类报错