ip hash 的核心作用是实现客户端 ip 到后端服务器的固定映射，确保同一 ip 始终路由至同一节点；但其不支持权重、nat 下易倾斜、节点变更导致全量重哈希，无法兼顾算力平衡。
IP Hash 的核心作用就是避免客户端请求反复跳转节点——它通过固定哈希算法，让同一客户端 IP 始终被路由到同一台后端服务器。
ip_hash 的工作原理必须清楚
nginx 对客户端 $remote_addr（即真实源IP）做一致性哈希计算，结果映射到 upstream 中某台 server。只要该 server 在线且未被手动 down，后续相同 IP 的请求就永远落在同一节点上。
- 哈希过程不依赖会话、Cookie 或其他动态变量，只认 IP
- 当某台 server 被标记为 down 或健康检查失败时，nginx 会临时剔除它，并对剩余节点重新哈希分配，此时部分 IP 可能迁移——这是唯一合法的“跳转”原因
- 如果后端服务器增减（如从3台变4台），哈希环变化，IP 分配必然重分布，导致跳转
确保真实客户端 IP 不被掩盖
若用户经过 CDN、代理或 NAT 网关，$remote_addr 可能变成中间设备的 IP（比如全是 10.0.0.1），导致大量用户被哈希到同一台后端，失去负载均衡意义，也看似“跳转异常”。
- 在 proxy_pass 前配置 proxy_set_header X-Real-IP $remote_addr 和 X-Forwarded-For，但 ip_hash 本身不读取这些头
- 真正要用真实 IP 做哈希，需配合 set_real_ip_from + real_ip_header 指令，把可信代理传来的 X-Forwarded-For 最左有效IP 覆盖 $remote_addr
- 例如：设 CDN 回源网段为 192.168.100.0/24，则加 set_real_ip_from 192.168.100.0/24; real_ip_header X-Forwarded-For;
upstream 配置有硬性约束
ip_hash 生效的前提是配置合规，否则会被忽略，退化为轮询，自然出现跳转。
- ip_hash 必须紧接在 upstream 块首行，不能缩进，不能和其它 hash 指令（如 hash $cookie_sessionid）共存
- 所有 server 行不能带 down、backup 或 weight 参数（ip_hash 不支持权重与备份节点）
- 若某 server 后加了 max_fails=0 或 fail_timeout=0，可能干扰健康检查逻辑，间接影响稳定性
注意 NAT 和移动网络带来的 IP 变动
技术上 ip_hash 是可靠的，但现实中的“跳转感”常来自客户端自身 IP 不稳定：
- 企业内网出口统一 NAT，几十人共用一个公网 IP，全部哈希到同一后端，容易过载并误判为“跳转”
- 4G/5G 用户切换基站、Wi-Fi 切换移动数据时，IP 可能秒级变更，哈希目标随之切换
- 某些运营商使用私有 CGNAT，用户每次拨号获得不同外网 IP，ip_hash 失效属正常现象
不复杂但容易忽略
