排查负载均衡转发循环的核心是确认请求是否在代理节点或后端间形成闭环跳转；需检查日志中高频301/302、Location头反复跳转、X-Forwarded-Proto/Host透传缺失、proxy_pass路径拼接错误及后端未适配代理头等问题。
排查负载均衡转发循环或重定向死循环，核心是确认请求是否在多个代理节点或后端服务之间形成闭环跳转。这不是配置堆叠问题，而是链路中某处协议、头信息或跳转逻辑失控导致的路径回绕。
看日志和响应链，快速识别循环迹象
死循环最直接的表现是：同一请求在 access.log 中高频重复出现，或连续返回多个 301/302 响应，且 Location 头目标不变或在有限几个地址间来回跳转。
- 用 curl -v https://your-domain.com/path 观察完整响应头，重点关注 Location 字段是否反复指向相同 URL 或在 http/https 间切换
- 在 Nginx 配置中临时加一行：add_header X-Upstream "$upstream_addr" always; 和 add_header X-Redirect-Check "$upstream_http_location" always;，把实际转发目标和后端返回的跳转地址透出，方便比对
- 检查 access.log 中是否出现大量 302 + 同一 URI + 不同 $upstream_addr 的组合，说明请求被轮询打到不同后端，但每个都返回相同跳转，极可能是后端硬编码 Location
查 Nginx 配置关键点，堵住常见回环源头
多数循环源于 Nginx 未正确透传协议与 Host，或 proxy_pass 路径拼接出错，导致请求又绕回自身。
- 必须设置 proxy_set_header X-Forwarded-Proto $scheme; —— 否则后端无法识别原始是 HTTPS，可能强制跳转到 HTTP，而 Nginx 又配置了 HTTP→HTTPS 强制跳转，形成闭环
- proxy_set_header Host 必须显式指定后端真实域名，不要用 $host；若后端依赖 Host 判断租户或路由，而收到的是负载均衡器自身域名，就可能触发自跳转
- 检查 proxy_pass URL 尾部斜杠是否与 location 匹配：location /api/ 对应 proxy_pass http://backend/api/（带尾斜杠），否则 Nginx 会错误拼接路径，导致 404 后被 error_page 重定向，间接促成循环
验后端行为，确认跳转逻辑是否可控
很多循环不是 Nginx 的问题，而是后端应用未适配代理环境，硬编码跳转地址或忽略转发头。
- 绕过 Nginx，直连后端 IP+端口（如 curl http://192.168.1.10:8080/login）测试是否仍重定向——若不跳，说明问题出在头信息透传或协议感知上
- 确认后端是否启用对 X-Forwarded-Proto 和 X-Forwarded-Host 的信任：Django 要设 SECURE_PROXY_SSL_HEADER，Spring Boot 要开 server.forward-headers-strategy=framework，Node.js 要设 app.set('trust proxy', true)
- 检查后端生成的 Location 是否动态构造：应基于 req.protocol + req.get('host') + path，而非写死为 http://example.com
加兜底防护，避免单次配置失误拖垮整条链路
即使配置正确，网络抖动或后端异常也可能偶然触发一次循环。需设置安全边界防止雪崩。
- 对敏感路径（如 /login、/oauth）启用限流：limit_req zone=redirect_burst=3 nodelay;，防止单个客户端高频跳转耗尽资源
- 配置 error_page 503 = @loop_guard;，并在 @loop_guard 中返回 429 或静态提示页，切断无限重试链路
- 在 upstream 中启用 proxy_next_upstream error timeout http_500 http_502 http_503 http_504; 并设 proxy_next_upstream_tries 2;，避免反复冲击已异常节点
