ip hash 在 nginx 中仅在客户端 ip 稳定、nginx 直收真实 ip、后端列表不变三者同时满足时才可靠；否则易因 ip 变更、代理覆盖或节点增删导致会话中断，本质是用网络层绑定替代状态治理，非长久之策。
IP Hash 在 Nginx 中确实能实现“同一 IP 总打同一台后端”，但它对业务请求调度的稳定性，不是绝对可靠，而是高度依赖网络环境和架构设计。它表面稳定，实则脆弱——稳定只在理想条件下成立。
IP Hash 的稳定性建立在三个刚性假设上
它的调度逻辑本身是确定性的（IP → 哈希 → 取模 → 固定 server），但这个链条一旦任一环节偏离预期，稳定性就立即瓦解：
- 客户端 IP 必须长期不变：4G 切 WiFi、家庭宽带动态拨号、企业 NAT 网关出口复用多个用户 IP，都会导致用户真实 IP 频繁跳变，Nginx 会将其识别为新客户端，重新哈希分配，会话中断
- Nginx 必须直收真实客户端 IP：前面有 CDN、WAF、云负载均衡（如腾讯 CLB、阿里 SLB）或反向代理时，$remote_addr 拿到的是中间层 IP（比如 100.64.x.x 或 10.0.x.x），所有用户被 hash 到同一台后端，造成严重倾斜甚至单点压垮
- 后端服务器列表不能轻易变更：增减节点会改变取模基数，原有哈希结果全部失效，大量用户被重分配；即使只是临时下线一台机器，Nginx 默认会将原属该节点的流量轮询分给其余节点，但状态已丢失，业务感知为“登录失效”或“表单提交失败”
看似稳定，实则掩盖了状态管理缺陷
IP Hash 解决的只是“路由一致性”，不是“状态一致性”。它把会话稳定性错误地寄托在网络层，而没碰真正的问题：
- 后端若用内存存储 Session（如 Tomcat 默认 session），那被 hash 到的那台机器一宕机，所有会话即刻清零，用户需重新登录
- 即便机器正常，用户切换网络后 IP 改变，仍会落到新机器，而新机器没有旧 session，业务报错“未登录”或“权限异常”
- 它无法区分合法重连（如手机休眠唤醒）和真实新会话，缺乏业务语义判断能力
什么情况下 IP Hash 才真能稳住请求调度？
只有满足以下全部条件时，IP Hash 才可作为短期、低风险场景的可行方案：
- 用户全部来自固定公网 IP（如内部办公网、专线接入客户）
- Nginx 是最前端入口，无任何代理/CDN 层，且启用了 real-ip 模块并正确配置 proxy_set_header X-Real-IP
- 后端服务无状态，或所有节点共享外部 Session 存储（Redis / 数据库），IP Hash 仅作辅助优化而非强依赖
- 集群规模小、扩缩容极少，且允许少量用户在变更期间短暂失联
更可持续的稳定性替代路径
真正的调度稳定性，不靠绑定 IP，而靠解耦路由与状态：
- 后端无状态化：Session、用户上下文、临时数据全部外置到 Redis 或集中式数据库，Nginx 回归轮询或 least_conn，故障自动转移不影响业务连续性
- 应用层会话标识路由：用 Cookie 中的 session_id 或 JWT 里的 user_id 做 hash（Nginx 的 hash 指令支持 $cookie_xxx 变量），比 IP 更精准反映用户身份
- 前端配合做连接保持：SPA 应用通过长连接或 token 续期机制减少重连频次，降低 IP 变动影响
