ip hash 通过哈希客户端ip地址并取模后端服务器数量实现固定映射，保障请求粘性；其稳定性依赖ip不变与后端配置静态，增删/调整server顺序或nat共享ip会导致会话漂移。
IP Hash 策略通过将同一客户端的请求始终路由到同一台后端服务器，直接保障用户体验一致性——比如购物车不丢、登录态不中断、页面跳转不重登。它不依赖 cookie 或 session 共享，而是靠 IP 地址哈希映射实现“粘性”，适合改造成本高或状态存于内存的老系统。
IP Hash 是怎么绑定用户和服务器的
它对客户端 IPv4 地址（取前 3 段）或 IPv6 地址（取完整 128 位）做哈希运算，再对当前 upstream 中可用 server 数量取模，结果决定转发目标。只要 IP 不变、后端列表不变，映射关系就固定不变。
- 例如：192.168.1.100 → hash 值为 172 → 3 台服务器时，172 % 3 = 1 → 固定打到第 2 台（索引从 0 开始）
- 该过程在 Nginx worker 进程内完成，无额外延迟，也不依赖外部存储
- 仅作用于 HTTP upstream，stream 模块需改用 hash $remote_addr consistent
哪些情况会让用户“突然换机器”
IP Hash 的稳定性高度依赖配置静态性和网络透明性。以下操作会触发全量重散列，导致大量用户请求跳转：
- 增删任意一台后端 server（哪怕只是临时注释掉一行）
- 调整 server 行顺序（如把第三行移到第一行）
- 客户端经过 NAT 或运营商共享出口，多个真实用户共用一个公网 IP，全部压到同一台后端，造成局部过载
- 未正确配置 set_real_ip_from 和 real_ip_header，导致代理层覆盖了真实 IP，Nginx 对着 X-Forwarded-For 的第一个地址哈希，结果失真
如何验证和加固一致性效果
上线前必须实测 IP 分配是否稳定，同时预留容错手段：
- 用固定公网出口（如手机热点）发起 20+ 次请求，检查 access log 中 $upstream_addr 字段是否始终指向同一台 server
- 手动停掉一台后端，观察原属该节点的 IP 请求是否不再到达（而非堆积 502），确认屏蔽机制生效
- 为每台 server 配置 max_fails=3 fail_timeout=30s，让 Nginx 自动临时剔除故障节点（注意：剔除期间对应 IP 请求会失败）
- 日志中加入 $remote_addr 和 $upstream_addr，便于事后比对 IP 路由轨迹
替代方案：什么时候该考虑一致性哈希
当集群需要频繁扩缩容，或存在大量 NAT 用户，IP Hash 易引发大规模会话漂移时，建议升级为一致性哈希：
- 使用第三方模块 ngx_http_upstream_consistent_hash，支持 consistent_hash $remote_addr
- 扩容/缩容时仅影响少量客户端（顺时针找最近节点），避免全量重映射
- 配合虚拟节点机制，缓解两台服务器时的负载倾斜问题
