登录失效本质是ip_hash哈希对象错误：$remote_addr被中间代理覆盖，导致所有请求哈希到同一后端；须通过real_ip_module还原真实ip、严格校验upstream配置、确保后端正确读取x-real-ip并共享session。
登录失效不是 ip_hash 配错了，而是它“起作用了但起错了”——哈希对象不是用户，而是某个中间节点的 IP。排查要从请求链路最末端倒推：先确认 Nginx 看到的真实源 IP 是什么，再验证这个 IP 是否被正确哈希，最后检查后端是否真能复用 Session。
第一步：确认 $remote_addr 是不是用户真实 IP
ip_hash 默认只认 $remote_addr。如果前面有 CDN、WAF、F5、云 LB 或另一层 Nginx，$remote_addr 就是那个代理的内网地址（比如 10.0.0.5），所有请求哈希结果完全一致，全打到同一台后端，其他机器收不到登录请求，自然“登录失效”。
- 在 Nginx access log 中加字段：$remote_addr $http_x_forwarded_for，看日志里这两列是否相同
- 如果 $http_x_forwarded_for 有值（如 203.208.60.1, 10.1.2.3），而 $remote_addr 是内网段，说明真实 IP 被压在 XFF 里了
- 必须启用 real_ip_module：在 http 块中配置 set_real_ip_from（填你实际可信代理段，如 10.0.0.0/8）、real_ip_header X-Forwarded-For、real_ip_recursive on
第二步：验证 ip_hash 是否真在生效
即使 IP 正确了，配置写错也等于没配。ip_hash 极其敏感，几个硬性规则不满足就会静默退化为轮询。
- ip_hash 必须顶格写在 upstream 块第一行，不能缩进，不能换行，不能和 hash / least_conn / weight 共存
- upstream 中 server 行不能带 weight、backup、down 等参数，否则 Nginx 启动失败或直接忽略 ip_hash
- 临时删掉一台 server？哈希映射会整体偏移，大量用户 Session 突然丢失——这不是 bug，是算法特性
- IPv4 地址只取前三段哈希：192.168.1.100 和 192.168.1.200 会被视为同一个 IP，在企业 NAT 出口下必然集中打到一台后端
第三步：检查后端是否真的能命中 Session
ip_hash 只解决“请求去哪”，不解决“去了之后有没有 Session”。常见断点在这里：
- 后端 Tomcat/Spring Boot 没配 proxy_cookie_path：Nginx 路径重写后 Cookie Path 不匹配，浏览器不带 JSESSIONID 上来
- 多台后端未共享 Session：ip_hash 把用户“钉”在 A 服务器，但 A 刚重启过，Session 没恢复；或者 A 机器磁盘故障，Session 文件丢了
- 前端发请求时没带 Cookie：检查浏览器开发者工具 Network → 请求头是否有 Cookie: JSESSIONID=xxx；没有的话可能是路径、域名或 Secure/HttpOnly 属性导致未发送
- 后端代码读 IP 仍用 request.getRemoteAddr()：它返回的是 Nginx 的 $remote_addr（即代理 IP），应改用 X-Real-IP 或 X-Forwarded-For 头获取真实 IP（需确保 Nginx 已 proxy_set_header）
第四步：快速验证与替代方案
如果时间紧，可用两个低成本方式交叉验证：
- 临时把 upstream 改成 hash $cookie_jsessionid consistent;：只要 Cookie 存在，就能绑定用户；若此时登录正常，说明原问题就是源 IP 错误或 NAT 冲突
- 用 curl 模拟固定 IP 请求：curl -H "X-Forwarded-For: 203.208.60.100" http://your-domain/login，观察是否稳定落到同一台后端（需配合 log 查看 upstream server IP）
- 真正治本：引入 Redis + Spring Session 或 JWT Token，让登录态彻底脱离单机内存，ip_hash 就不再是刚需
