ip_hash 部分用户频繁“断开”实为粘滞失效，本质是请求被路由至不同后端导致会话丢失；需围绕客户端ip稳定性、哈希源真实性（$remote_addr是否为真实ip）、upstream配置合规性（ip_hash位置、server参数、节点变更）及后端状态共享四方面排查。
ip_hash 配置后部分用户频繁断开，本质不是连接被主动“断开”，而是请求被路由到不同后端节点，导致会话状态丢失、登录态失效、WebSocket 中断等现象——看起来像断开，实则是粘滞失效。排查需围绕“IP 是否稳定”“哈希源是否真实”“后端是否可用”三个核心展开。
检查客户端 IP 是否实际变动
移动端、NAT 环境、代理切换都会让 $remote_addr 突然变化，这是最常见原因：
- 抓取用户访问日志，添加 $remote_addr 和 $upstream_addr 字段，观察同一用户短时间内是否出现多个不同 IP 或多个不同后端地址
- 重点排查：4G/5G 与 Wi-Fi 切换、企业内网出口 NAT、运营商 CGNAT（如 IP 段从 112.68.x.x 跳到 218.202.x.x）、CDN 回源 IP 集中
- 若日志中同一用户 IP 频繁变更，说明 ip_hash 失效是网络侧问题，不是 Nginx 配置错误
确认哈希所用的 IP 是否为真实客户端 IP
多层代理下 $remote_addr 默认是上一跳地址（如 CDN 或 LB 的内网 IP），所有请求会被哈希到同一台后端，看似“不跳”，实则负载严重倾斜，且任意节点故障就会触发批量漂移：
- 在 Nginx 配置中启用 real_ip_module：set_real_ip_from 声明可信代理网段（如 CDN 回源段、前置 LB 内网段）
- 设置 real_ip_header X-Forwarded-For，并开启 real_ip_recursive on（防伪造时慎用）
- 验证是否生效：在 access_log 中打印 $remote_addr，确认其为公网或内网真实终端 IP，而非 10.x、172.16.x、192.168.x 等私有地址
检查 upstream 配置与节点状态是否合规
ip_hash 对配置极其敏感，一处不合规就会退化为轮询，导致请求随机分发：
- 确保 ip_hash 位于 upstream 块第一行，无缩进、无注释、不与其他 hash 指令共存
- 所有 server 行不能带 weight、backup、down（临时下线要用 max_fails=0 + fail_timeout=0 替代）
- 检查健康检查是否误判：某台后端短暂超时被标记为不可用，ip_hash 会将对应 IP 段流量重分配到剩余节点，恢复后不会自动切回
- 若近期增删过 server，哈希环已重计算，必然引发大规模漂移——这是设计行为，非故障
验证后端是否真正支持会话保持
即使路由固定，若后端未共享 Session 或未持久化状态，用户仍会感知为“断开”：
- 确认后端 Session 存储方式：若用内存 Session，节点宕机即丢失；应改用 Redis / JetCache 等集中式存储
- 检查 Cookie Path 和 Domain 是否匹配：proxy_cookie_path / "/; Path=/; Secure; HttpOnly" 可避免跨路径丢失 ROUTE 或 JSESSIONID
- WebSocket 场景需额外透传 Upgrade 头，并延长 proxy_read_timeout（建议 ≥ 86400），否则 Nginx 会在空闲 60 秒后主动关闭连接
