ip hash 不直接导致重定向循环，但会因后端重定向+代理ip识别错误/会话状态依赖等叠加问题，使请求持续打到同一后端并反复跳转；需排查真实客户端ip传递、后端重定向逻辑及ip_hash稳定性。
IP hash 本身不会直接导致重定向循环，但常因后端服务返回 301/302 重定向 + Cookie 或 Location 头未适配负载均衡拓扑，与 IP hash 机制叠加后表现出“请求总打到同一台后端、该后端又不断跳转”的假象。排查需聚焦三点：确认是否真为 IP hash 引起、检查后端重定向逻辑是否依赖客户端 IP 或会话状态、验证 Nginx 配置与真实客户端 IP 传递是否一致。
确认真实客户端 IP 是否被正确识别
IP hash 使用的是 $remote_addr 变量，默认是直接连接 Nginx 的上一跳地址。如果前端有 CDN、WAF、四层 LB（如 AWS NLB、阿里云 SLB），$remote_addr 就是这些中间设备的 IP，大量用户共用同一个出口 IP，会被哈希到同一台后端，触发后端基于 IP 的跳转逻辑（例如地域重定向、未登录跳转登录页后再跳回原路径失败）。
- 在 Nginx 日志中添加 $remote_addr 和 $http_x_forwarded_for 记录，对比两者差异
- 若使用了反向代理，确保已配置 real_ip 模块，并正确设置 set_real_ip_from 和 real_ip_header X-Forwarded-For
- 测试时用 curl -H "X-Forwarded-For: 1.2.3.4" 直连 Nginx，观察日志中 $remote_addr 是否更新
检查后端服务是否主动发起重定向
IP hash 只决定请求分发，不产生重定向。真正跳转来自后端应用（如 PHP、Node.js、Java）。常见诱因包括：
- 登录态校验失败后重定向到 /login，而登录页又因缺少 referer 或 session 不一致再次跳转
- HTTP 请求被后端强制 301 跳转 HTTPS，但 Nginx 与后端间用 HTTP 通信，后端无法感知外部是否 HTTPS，持续跳转
- 后端根据 $remote_addr 做灰度或地域判断，而该 IP 是代理 IP，判断失准，反复跳转到“不匹配”的节点
建议在后端加日志，记录每次重定向前的 request URI、Host、X-Forwarded-Proto、X-Real-IP，并比对 Nginx access log 中对应请求的 upstream_addr 和响应状态码。
验证 ip_hash 是否真的生效且稳定
IP hash 并非绝对“固定”，当某台 upstream server 被标记为 down、或配置了 weight=0、或健康检查失败时，Nginx 会临时剔除该节点，导致哈希结果重算，用户可能被切到另一台——若新后端也执行相同重定向逻辑，就会形成“A→B→A→B…”循环（尤其配合 302 + 浏览器缓存）。
- 用 nginx -T | grep ip_hash 确认配置已加载且无语法错误
- 检查 upstream 块中是否有 down、backup 或 max_fails 导致节点频繁上下线
- 临时停掉一台后端，用多个不同真实 IP 请求，观察 access log 中 upstream_addr 是否发生批量切换
快速验证：临时关闭 ip_hash 观察行为变化
将 ip_hash; 注释掉，改用默认轮询（或 least_conn），重启 Nginx。如果重定向循环立即消失，说明问题确实与 IP hash 的“粘性”放大了后端缺陷有关；如果依旧循环，则基本可排除 IP hash，重点查后端重定向逻辑或浏览器缓存（如 301 被本地缓存）。
- 注意：测试期间清空浏览器缓存或使用隐身窗口，避免 301 缓存干扰判断
- 用 curl -I 反复请求，观察 Location 响应头是否在两个 URL 之间来回交替
- 结合 tcpdump 或 nginx stub_status 查看连接分布，辅助确认分发模式
