ip hash 仅保障请求路由一致性，不提升业务逻辑完整性；其核心价值在于通过固定客户端到服务器的映射，支撑依赖本地状态的关键流程，如登录态延续、多步操作连贯性及本地限流，但需正确配置真实ip提取，并警惕扩容/故障导致的会话丢失风险。
IP Hash 策略本身不提升业务逻辑完整性，它只解决“请求路由一致性”问题。真正保障业务逻辑完整性的，是后端服务在单节点上能稳定维持状态（比如会话、事务上下文、临时缓存），而 IP Hash 只是让这个前提成为可能。
为什么 IP Hash 能支撑关键业务流程
当业务依赖本地状态时——例如用户登录后生成的 session 存储在内存里、购物车数据未同步到中心化存储、表单提交需跨多步校验且中间状态保留在某台机器上——若请求被轮询打散到不同后端，状态就断了。IP Hash 把同一客户端始终导向同一台服务器，相当于为无共享架构“模拟”出一个稳定的执行上下文。
- 登录态延续：用户首次登录成功后，后续所有带 Cookie 的请求都落在同一台机器，session 不丢失
- 多步操作连贯性：比如订单填写分地址、支付、确认三步，每步都需读写本地临时数据，IP Hash 避免跳机导致数据错乱
- 限流/频控本地生效：基于 IP 或用户 ID 的计数器放在单机内存里，固定路由才能保证统计准确
配置时必须对齐业务真实入口 IP
如果用户经过 CDN、WAF 或多层 Nginx 代理，$remote_addr 拿到的是上一跳的地址（比如 CDN 节点 IP），不是用户真实 IP。这时哈希结果完全失效，大量用户被错误聚到少数几台后端。
- 用 set_real_ip_from 明确声明可信代理网段（如 CDN 的出口 IP 段）
- 配合 real_ip_header X-Forwarded-For 或 X-Real-IP 提取原始 IP
- 验证方式：在日志中加 $http_x_forwarded_for 和 $upstream_addr 字段，比对是否稳定映射
扩容和故障场景下的业务连续性风险
IP Hash 的映射关系是静态的：哈希值 % 服务器数量。只要 upstream 列表增删节点，所有已有 IP 的分配都会重算。这意味着一次扩缩容，可能让 70% 以上用户的请求落到新机器，session 全丢。
- 避免滚动扩容：新增节点前，先在 upstream 中用 down 标记旧节点，再逐步替换，而非直接增删
- 搭配健康检查：设置 max_fails=2 fail_timeout=30s，让故障机器自动临时剔除，不破坏哈希结构
- 关键业务建议加兜底机制：比如 session 异步落 Redis，IP Hash 失效时仍可恢复上下文
不适合用 IP Hash 的典型业务场景
不是所有“需要一致性”的业务都适合 IP Hash。它本质是用负载不均换状态稳定，代价明确。
- 企业内网或运营商 NAT 环境：成百上千用户共用一个公网 IP，全部压到一台后端，瞬间过载
- 移动端频繁切换网络：4G 切 WiFi、WiFi 切热点，IP 变更导致会话中断，体验比轮询还差
- 已具备分布式 session 能力：如 Spring Session + Redis、JWT 无状态鉴权，就没必要牺牲负载均衡性
不复杂但容易忽略。
