ip hash 策略本质是用客户端 ip 做固定路由，解决会话保持但带来业务约束：后端变更导致会话批量失效、nat 场景易失衡、不支持权重与健康检查、需日志验证生效情况。
IP Hash 策略本质是用客户端 IP 做固定路由，不是通用负载均衡方案，它解决的是会话保持问题，但会带来明确的业务约束。用之前得先确认你的场景是否真的适合。
后端节点变更会导致会话大规模失效
IP Hash 的哈希结果依赖于 upstream 中 server 列表的顺序和数量。只要增删一台 server，或调整顺序，整个哈希映射关系就会重算——原来访问 A 服务器的用户，可能全部被重新分配到 B 或 C。这不是渐进式漂移，而是批量打乱。
- 运维中要扩容或下线节点时，不能直接删配置，应改用
down标记临时屏蔽 - 如必须调整列表，需配合前端强制刷新、会话同步机制，或提前通知用户可能短暂登出
- 不建议在频繁扩缩容的云原生环境中直接使用
公网 IP 不等于真实用户，NAT 场景下极易失衡
企业内网、校园网、4G/5G 运营商出口普遍使用 NAT，成百上千用户共用一个公网 IP。IP Hash 会把所有这些请求全部打到同一台后端，造成单点过载，其他机器空闲。
- 若用户主要来自办公网络或移动网络，需优先考虑 cookie_hash 或 JWT + 服务端 session 共享
- 无法规避 NAT 时，可结合
$http_x_forwarded_for提取真实 IP（但需确保上游可信，否则易伪造） - IPv6 环境要注意：Nginx 默认只取前 64 位哈希，若内网 IPv6 分配粒度更细，可能导致散列不均
无法与权重、健康检查精细协同
IP Hash 和 weight 参数互斥，加了 weight 就启动失败；它本身也不支持自动剔除故障节点——某台 server 挂了，对应 IP 的请求会持续超时，直到手动干预。
- 可用
max_fails=1 fail_timeout=30s配合，让 Nginx 临时屏蔽故障节点（注意：屏蔽期间该 IP 请求直接返回 502） - backup 节点仅在所有非 backup server 全挂时才启用，不能承接部分 IP 流量
- 若需动态权重或精细化容错，建议改用第三方模块如
nginx-upstream-consistent-hash或接入 Service Mesh
日志与验证必须前置，否则难以定位问题
IP Hash 表面简单，但实际运行中是否生效、是否均匀、是否稳定，全靠日志佐证。没有日志，等于盲调。
- 务必在 log_format 中加入
$upstream_addr和$remote_addr，例如：log_format main '$remote_addr → $upstream_addr [$time_local]'; - 测试阶段用不同公网 IP（或代理工具如 curl -x）模拟多客户端，避免本地反复刷新误判为“始终打到同一台”
- 上线后定期抽样检查日志，确认相同 IP 是否长期落在同一地址，且各后端流量分布大致合理
