必须分层验证ip_hash会话一致性：先确认Nginx正确识别真实客户端IP，再测试单节点哈希可复现性，接着模拟机房变更验证漂移边界，最后端到端验证业务会话可用性。
直接在真实多机房环境下测试 ip_hash 的会话一致性，容易受网络路径、代理层级和 IP 变化干扰，必须分层验证：先确认单节点哈希行为稳定，再模拟跨机房流量路径，最后用可控客户端打点比对。关键不是“能不能固定”，而是“在什么条件下会断”。
第一步：确认 Nginx 能正确识别真实客户端 IP
多机房架构中，请求通常经过 CDN、WAF 或前置 LB，$remote_addr 默认是最后一跳代理的地址，不是用户真实 IP。若没还原，ip_hash 就是在哈希一堆相同内网 IP，完全失效。
- 检查是否启用 real_ip_module：运行 nginx -V 2>&1 | grep -o with-http-realip-module，有输出才支持
- 配置必须包含 set_real_ip_from（填上游可信代理段）和 real_ip_header X-Forwarded-For（或 X-Real-IP，按实际 header 名）
- 加日志字段验证：log_format main '$remote_addr $http_x_forwarded_for — $upstream_addr';，访问后看日志里 $remote_addr 是否为真实公网 IP
第二步：隔离测试哈希映射是否可复现
避免用浏览器反复刷新——它可能带缓存、重用连接、甚至触发浏览器级 IP 切换（如 IPv4/IPv6 双栈自动降级）。应使用命令行工具构造纯净请求。
- 用 curl 指定不同出口 IP 测试：curl -x http://proxy1:8080 http://your-domain.com/api/test（proxy1 模拟机房 A 出口）
- 记录每次响应头中的 Set-Cookie 或返回体里的 server_id 字段（建议后端主动返回 hostname 或实例 ID）
- 同一出口 IP 发起 5 次请求，检查后端实例 ID 是否完全一致；换另一个出口 IP，再测 5 次，确认映射不重叠
第三步：模拟机房变更场景，验证漂移边界
ip_hash 对 upstream 变更极度敏感。多机房扩容缩容、某机房临时下线，都会导致哈希重算。不能只测“正常时稳”，更要测“异常时怎么崩”。
- 临时注释掉一台后端 server 行，reload Nginx，用同一 IP 再请求 3 次，观察是否全部落到新机器上（是则说明重散列已触发）
- 把两台 server 行顺序调换（如原为 A/B/C，改为 B/A/C），reload 后重测，对比前后映射结果——多数 IP 会跳转
- 特别关注 IPv6 用户：用 curl -6 请求，确认是否始终落在同一台（IPv6 仅取前 64 位哈希，若机房分配的 IPv6 前缀相近，可能意外聚堆）
第四步：结合业务链路做端到端会话验证
单纯看路由到哪台机器不够，要验证 Session 是否真正可用。例如登录后访问 /user/profile，看是否返回用户信息而非跳转登录页。
- 写一个简单脚本：先 POST 登录接口（带 -b cookie.txt 保存 session），再 GET 个人页（用 -b 复用 cookie），检查 HTTP 状态码和响应内容
- 在同一出口 IP 下连续跑 10 轮，全部成功才算通过；任一轮失败，就查对应请求的 $upstream_addr 日志，确认是否因后端宕机或路由跳变导致
- 如果某机房延迟高或丢包，Nginx 默认不会自动踢出节点（除非配了 max_fails），需手动模拟故障：iptables -A OUTPUT -d 192.168.1.101 -j DROP，再观察该 IP 请求是否转向其他机器并仍能维持会话
