ip_hash因依赖客户端IP稳定性而无法应对移动端网络切换，IP变更即导致会话丢失；根本解法是改用cookie、设备指纹或JWT等业务层稳定标识做一致性哈希。
移动端网络切换（比如从 Wi-Fi 切到 4G/5G，或在不同基站间漫游）会导致客户端公网 IP 变化，而 ip_hash 正是基于 $remote_addr 做哈希路由的，所以 IP 一变，后端服务器就很可能改变——这正是需要测试的关键点。
为什么移动端切换网络会影响 ip_hash 路由
ip_hash 把用户请求按客户端真实 IP 的哈希值固定分发到某台后端服务器。但移动端在以下情况会更换出口 IP：
- Wi-Fi → 移动数据：运营商分配新公网 IP（常见于 NAT 网关池）
- 跨地域移动（如高铁场景）：接入不同地市出口网关，IP 段变化
- 某些运营商使用 CGNAT：同一用户多次连接可能拿到不同端口+IP 组合
一旦 $remote_addr 改变，Nginx 重新计算哈希，大概率落到另一台后端，导致 session 丢失、登录态失效、缓存不命中等问题。
实测方法：模拟 IP 变更并观察路由行为
不依赖真实手机反复开关网络（效率低、难复现），推荐组合使用以下方式：
-
本地 hosts + 多个测试域名：在手机浏览器中访问不同子域名（如
a.test.com、b.test.com），并在 Nginx 配置中为每个域名设置独立upstream并开启ip_hash，再通过修改手机 DNS 或配合代理工具强制解析到不同源 IP（需配合抓包确认） -
抓包验证真实 remote_addr：在 Nginx 日志中添加
$remote_addr和$upstream_addr字段，用 Charles/Fiddler 或手机 Wireshark（需 root）捕获请求，对比每次切换网络后的请求头和日志中的 IP 与后端地址 -
服务端埋点打标：在每台后端服务返回 HTTP 响应头中加入唯一标识（如
X-Backend-ID: node-01），前端 JS 记录每次响应的该字段，网络切换前后对比是否变化
进阶验证：一致性哈希能否缓解这个问题
原生 ip_hash 对节点增减敏感，且无法应对 IP 频繁变动。若业务允许，可尝试升级为带 consistent 的哈希策略：
- 配置示例：
hash $remote_addr consistent;（要求 Nginx ≥ 1.7.2，部分发行版需启用ngx_http_upstream_hash_module） - 优势：IP 微小变化（如最后一位不同）仍大概率映射到同一节点，比原生
ip_hash更稳定 - 注意：不能完全消除切换影响，只是降低重散列概率；建议搭配
$http_user_agent等字段增强键多样性，例如：hash "$remote_addr$http_user_agent" consistent;
规避建议：别只靠 ip_hash 做会话保持
对移动端友好的方案应减少对客户端 IP 的强依赖：
- 改用 token-based 会话：登录后下发 JWT 或加密 session ID，后端统一查 Redis，无需绑定特定机器
- 启用 sticky cookie（
sticky cookie指令，Nginx Plus 功能；开源版可用proxy_cookie_path+ 自定义 Set-Cookie 实现类似效果） - 前端主动感知网络变化：监听
navigator.onLine或Network Information API，切换时触发登出重登录或刷新会话凭证
