核心是确认客户端是否在相同URL反复跳转且由不同后端重复返回相同Location；需用curl -v抓跳转链、检查X-Request-ID日志关联、验证X-Upstream标识、排查后端硬编码Location、确保proxy_set_header和proxy_redirect正确配置，并排除Session不一致干扰。
排查负载均衡接入后端返回的重定向死循环，核心是确认客户端是否在相同 URL 上反复跳转，且每次跳转都由不同后端节点重复生成相同的 Location 响应头。问题不在轮询机制本身，而在重定向响应未适配代理上下文，导致闭环无法收敛。
抓取真实跳转链路
用 curl -v 模拟客户端请求，观察完整响应过程：
- 执行
curl -v https://yourdomain.com/login，重点关注每一步的HTTP/1.1 302和Location:响应头 - 若连续出现多个
Location: https://yourdomain.com/login（目标不变），基本确认死循环 - 加
-H "X-Request-ID: debug123"并在 Nginx access_log 中启用$request_id，可串联同一请求在多个 upstream 节点的日志行 - 检查响应头中是否有
X-Upstream: node1类标识，验证是否真的轮到了不同后端
查 Location 是否硬编码
死循环大多源于后端返回了不随代理环境变化的绝对跳转地址：
-
Location: http://example.com/dashboard（写死 HTTP 协议） -
Location: https://backend.internal/login（暴露内网地址） -
Location: //example.com/next（协议相对，但前端或中间层解析异常） - 这类响应经 Nginx 转发后，浏览器按绝对地址重发请求，Nginx 又轮询到另一节点，该节点照例返回同样
Location，形成闭环 - 后端必须基于
X-Forwarded-Proto和X-Forwarded-Host动态构造跳转 URL
验 Nginx 透传与重写配置
确保关键头信息正确传递，并对后端返回的 Location 做必要修正：
- 在
proxy_pass所在 location 块中，必须有：proxy_set_header X-Forwarded-Proto $scheme;proxy_set_header X-Forwarded-Host $host; - 添加
proxy_redirect ~^http://[^/]+(/.*)$ $1;，剥离后端返回的绝对域名，只保留路径 - 临时加
add_header X-Debug-Location "$upstream_http_location" always;，把后端原始Location透出到响应头，便于比对 - 避免
proxy_redirect off;或遗漏配置，否则重写不生效
排除会话与 Cookie 干扰
登录态不一致也会触发表象相似的反复跳转：
- 用户访问
/admin→ 后端 A 返回 302 到/login→ 用户带 Cookie 访问/login→ Nginx 轮询到后端 B → B 查不到 Session → 再次 302 到/login - 检查
Set-Cookie是否含Domain=yourdomain.com，是否漏设Secure（HTTPS 场景下必须） - 启用会话保持：
ip_hash或hash $cookie_session_id consistent; - 更可靠的方式是使用 Redis 等集中式 session 存储，确保所有后端节点读写一致
