ip hash 仅实现同一ip请求固定路由至同一后端，非高可用方案；其稳定性取决于真实ip透传、upstream配置一致性及主动健康检查等配套机制。
IP Hash 本身不直接保障大规模连接稳定性，它只负责把同一 IP 的请求固定打到同一台后端——真正影响稳定性的，是它在什么条件下生效、哪些环节容易出错，以及如何配合其他机制兜底。
IP Hash 的作用边界很明确
它不是“高可用方案”，而是一个会话绑定策略。核心逻辑是：对客户端真实 IP 做哈希运算，再对当前 upstream 中存活服务器数量取模，得出目标节点。这意味着：
- 只要 upstream 配置不变、服务器全部在线，同一个 IP 永远落在同一台后端
- 它不感知后端是否响应慢、是否返回错误码，只看连接是否能建立
- 没有自动剔除机制，宕机服务器若未标记为 down，请求仍会发过去，超时后才尝试下一台
大规模场景下最常破坏稳定的三类问题
不是算法失效，而是部署细节没对齐：
- 真实 IP 被代理覆盖：用户经过 CDN、WAF 或公司 NAT 后，$remote_addr 变成出口 IP，成百上千用户挤到同一台后端，造成单点过载
- upstream 动态变更：增删 server 行、调整顺序、重启 reload，都会触发全量重哈希，大量用户会话瞬间漂移
- IPv4/IPv6 混合处理不一致：IPv6 默认只取前 64 位哈希，若部分客户端 IPv6 地址变化频繁，会导致看似同一用户反复跳转
让 IP Hash 在大流量下更稳的实操要点
靠配置组合，而不是单靠 ip_hash 指令：
- 用
$http_x_forwarded_for或业务标识（如$cookie_user_id）替代$remote_addr，前提是反向代理链路能透传且可信 - 所有 server 行显式配置
max_fails=2 fail_timeout=15s，让 Nginx 主动屏蔽连续失败的节点，避免无效重试 - 临时下线机器时，写
server 192.168.1.10:8080 down;，而不是注释或删除，防止哈希环重算 - 日志中加入
$upstream_addr和$upstream_response_time，便于快速定位某 IP 是否长期卡在异常节点
什么时候该换更合适的方案
当出现以下情况，说明 IP Hash 已经不适合当前规模：
- 用户大量走移动网络或校园网，IP 频繁变化，会话无法维持
- 后端节点需弹性扩缩容，但每次扩容都导致大批用户路由变更
- 需要按用户 ID 或设备 ID 精准分流，而非粗粒度按 IP
此时应考虑一致性 Hash（需第三方模块支持），或改用带 session 同步的架构，IP Hash 只适合 IP 相对稳定、节点数长期固定的中等规模场景。
