ip_hash不提供会话恢复能力，仅基于客户端IP做固定路由；IP变更、后端宕机或重启均会导致Session丢失，需依赖共享存储、cookie_hash等方案降低依赖。
ip_hash 本身不提供“会话恢复”能力，它只做请求路由绑定——客户端 IP 不变，就继续打到同一台后端；IP 一变（比如弱网下 4G 切 WiFi），哈希结果就变，路由立刻切换，原后端上的 Session 状态也就丢了。所以测试重点不是“它能不能恢复”，而是“它在什么条件下会断、断得多快、有没有补救空间”。
明确测试边界：ip_hash 不负责 Session 存活
它只是把请求固定发给某台机器，Session 是否还在、能否续上，完全取决于那台后端是否还存着该用户的内存 Session，以及应用层有没有做持久化或共享。Nginx 层面无法感知 Session 内容，也无法主动拉取或迁移。
- 弱网重连导致 IP 改变 → ip_hash 路由跳转 → 新后端查不到旧 Session → 用户需重新登录或丢失购物车
- 后端宕机触发自动剔除 → upstream 列表变化 → 全量重散列 → 大量用户路由漂移 → 连带 Session 断开
- 即使 IP 没变，若后端进程重启或 Session 过期，照样丢失状态 —— 这和 ip_hash 无关
可实操的验证步骤
用 curl + 本地 hosts + 多后端模拟，快速验证路由行为是否符合预期：
- 在 upstream 中配置 3 台后端，并开启 ip_hash：注意删掉所有 weight、backup、down 等修饰符
- 用 curl 发起请求，加 -v 查看响应头中的 X-Upstream-Addr（需在 log_format 中定义并记录），确认相同 IP 始终命中同一台
- 手动改本机 IP（如禁用 WiFi 后启用手机热点），再发请求，观察 X-Upstream-Addr 是否变化
- 临时注释掉 upstream 中一台 server 行，reload Nginx，再用原 IP 请求 —— 此时会看到大部分原 IP 请求已落到新节点，证明重散列生效
真正影响弱网体验的关键点
不是 ip_hash 配对准不准，而是它暴露了架构短板。以下情况会让“断连感”更明显：
- 前端没做请求重试或防抖，一次超时就直接报错，用户感知为“闪退”
- 后端 Session 存内存且无过期续期机制，弱网重连时 Session 已被清理
- CDN 或代理未透传真实 IP，$remote_addr 是统一出口地址，所有用户被 hash 到同一台，故障时全量中断
- 没配 real_ip_module，日志和哈希都基于错误 IP，调试时误判为“策略失效”
比测试更重要的事：降低对 ip_hash 的依赖
弱网场景本就是 IP 不稳定高发区，硬靠 ip_hash 抗是反模式。建议同步推进：
- 后端接入 Redis 或其他共享 Session 存储，让任意节点都能读写用户状态
- 前端在关键操作（如提交订单）前主动校验登录态，失败则静默刷新 token
- 用 cookie_hash 替代 ip_hash：hash $cookie_sessionid consistent;，只要 Cookie 没丢，路由就不随 IP 变
- 对核心接口加幂等性控制，避免弱网重发导致重复下单等副作用
