ip hash增减节点会失效，因其采用静态取模哈希，模数随server数量或顺序变动而改变，导致全量重散列；ipv6仅取前64位哈希、注释/调整配置等操作亦会触发映射刷新。
IP Hash 算法本身无法优雅应对后端节点增减变化，它会直接触发全量重散列，导致大量客户端请求被重新分配到不同后端节点。
为什么增减节点会让 IP Hash 失效
IP Hash 是一种静态取模哈希：Nginx 对客户端 IP 做哈希后，用结果对当前 upstream 中 server 的数量取模，得到目标索引。只要 server 数量或顺序变动，模数就变了，所有哈希值的映射关系都会刷新。
- 新增一台 server → 模数变大 → 原本落在第 0 号节点的请求，可能变成第 2 号或第 1 号
- 下线一台 server → 模数变小 → 大量原本稳定的 IP 映射突然跳转，会话中断、缓存失效
- 调整 server 行顺序（哪怕只是换行）→ Nginx 内部按配置顺序编号，索引错位，等效于重排节点
哪些操作会意外触发重散列
不只是显式增删，一些看似无害的操作也会破坏映射稳定性：
- 临时注释掉某行 server 配置再 reload
- 把 backup 节点取消注释并启用
- 在 server 行之间插入空行或调整缩进（部分旧版本 Nginx 会误判顺序）
- IPv6 用户地址因只取前 64 位参与哈希，若业务依赖完整地址，也可能出现“伪漂移”
如何降低节点变动带来的影响
IP Hash 没有内置漂移控制能力，但可通过组合策略缓解风险：
- 使用 backup 标识预留备用节点，扩容时先启用 backup，避免直接修改活跃列表
- 为每台 server 配置 max_fails=3 fail_timeout=30s，让异常节点自动临时屏蔽（注意：屏蔽期间对应 IP 请求会返回 502）
- 日志中加入 $upstream_addr 字段，便于快速验证某 IP 是否长期落在同一后端，及时发现异常漂移
- 若必须动态扩缩容，建议改用 hash $remote_addr consistent; 替代 ip_hash，它基于 ketama 环，节点变动时仅影响少量请求
什么情况下仍可谨慎使用 IP Hash
当后端规模稳定、扩缩容频率极低，且业务能容忍短时会话中断时，IP Hash 仍有价值：
- 老旧系统未做无状态改造，购物车或登录态存在内存中
- 内部管理后台，用户 IP 相对固定、NAT 场景少
- 配合前端重试机制或客户端自动续登逻辑，弱化单次跳转影响
