ip_hash本身不重新分配请求，仅固定映射；后端宕机后需依赖健康检查（max_fails/fail_timeout）、proxy_next_upstream重试、down标记或backup节点协同实现平滑转移，并辅以redis共享session兜底。
ip_hash 本身不负责重新路由，它只做固定映射。后端动态下线时能否平滑转移请求，取决于健康检查、故障剔除机制和 upstream 配置协同是否到位。
ip_hash 不会自动跳过宕机节点
同一客户端 IP 的哈希结果始终指向同一个 server 指令行——哪怕那台机器已停止响应。Nginx 不会因为某节点不可达就改变哈希逻辑或重算目标。所以：
- 若没配健康检查，请求仍发往宕机地址，最终返回 502 或超时
- 即使配置了 max_fails 和 fail_timeout，也只是临时屏蔽该节点；屏蔽期一过，只要 upstream 列表没变，哈希结果不变，流量还会回到原节点
- 增删或调整 server 行顺序，会触发全量 IP 映射重散列，导致大量用户会话中断
靠健康检查 + proxy_next_upstream 实现有限重试
真正起作用的是 Nginx 的失败重试机制，而非 ip_hash 自身：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 启用 max_fails=2 fail_timeout=5s，让 Nginx 在连续两次失败后将节点标记为不可用（持续 5 秒）
- 配合 proxy_next_upstream error timeout http_502 http_504，使首次失败即触发重试
- 设置 proxy_next_upstream_tries 2，限制最多尝试两个节点，防止单点故障引发雪崩
- 重试不是“重新哈希”，而是按 upstream 中 server 的声明顺序，线性查找下一个健康节点
主动下线要配合 weight=0 或 down 标记
运维人员可控的最稳妥方式是提前干预：
- 将待下线节点设为 server 192.168.1.10:8080 weight=0;，Nginx 立即停止派发新请求，已有连接继续处理
- 在 ip_hash 场景中更推荐用 down：如 server 192.168.1.10:8080 down;，哈希计算会自动跳过该节点，无需 reload 即可生效
- 修改后执行 nginx -s reload，配置热更新不中断服务
兜底与验证不能少
仅靠 ip_hash + 基础配置难以保障高可用，还需补充关键措施：
- 加 backup 节点：当所有主节点都不可用时，流量才转向备用服务器
- 日志中记录 $upstream_addr，通过 access log 确认实际转发目标是否符合预期
- 后端配合返回 503（如 /health 接口），配合第三方模块 nginx_upstream_check_module 实现自动识别下线意图
- 会话层解耦：用 Redis 共享 Session，降低对 ip_hash 的强依赖，避免单节点故障导致登录态丢失
