nginx负载均衡中重定向循环主因是后端硬编码location头，应通过动态生成跳转url、proxy_redirect重写响应头、会话保持及集中式session等手段解决。
在 Nginx 负载均衡环境中出现重定向循环，通常是因为后端服务返回的 301 或 302 响应中携带了不匹配的 Location 头（比如写死为 http://example.com），而客户端再次请求时又被转发到另一个后端节点，该节点又返回同样的重定向，形成死循环。
检查并修正后端应用的重定向逻辑
这是最根本的解决方式。后端服务不应硬编码跳转地址，而应基于请求头动态生成 Location：
- 读取
X-Forwarded-Proto和X-Forwarded-Host（或X-Real-IP+ 自定义 Host）来构造跳转 URL - Spring Boot 可配置
server.forward-headers-strategy=framework并启用RemoteIpFilter - Node.js（Express）可用
app.set('trust proxy', true)，再通过req.protocol和req.get('host')拼接
在 Nginx 中重写响应头中的 Location
若无法修改后端，可在 Nginx 的 upstream 或 location 块中用 proxy_redirect 修正跳转地址：
-
proxy_redirect http://backend.example.com/ /;—— 将后端返回的绝对路径重写为相对路径 -
proxy_redirect ~^http://[^/]+(/.*)$ $1;—— 正则匹配并剥离域名，保留路径 - 配合
proxy_set_header X-Forwarded-Proto $scheme;和X-Forwarded-Host $host;确保后端能感知真实协议和域名
避免因 Cookie 或会话导致的误判循环
某些重定向由登录态触发（如未登录跳转到 /login），若 session 未共享或 sticky 未生效，用户可能在不同节点间反复跳转：
- 启用
ip_hash或hash $cookie_session_id consistent;实现会话保持 - 使用 Redis 等集中式 session 存储，确保所有后端节点读写一致
- 检查
Set-Cookie是否带Secure、HttpOnly和正确Domain，避免浏览器不携带 Cookie 导致重复鉴权
快速定位是否为重定向循环
用 curl -v 观察响应链：
- 连续看到多个
Location: https://xxx且跳转目标不变，基本可确认循环 - 查看
Server或自定义响应头（如X-Upstream），确认是否轮询到了不同后端 - 临时在 Nginx 中添加
add_header X-Redirect-Check "$upstream_http_location" always;，把原始 Location 透出便于调试
不复杂但容易忽略：重定向循环往往不是 Nginx 配置本身的问题，而是前后端协作中协议感知缺失造成的。重点盯住 Location 值来源和 proxy_redirect 是否生效，多数情况都能快速收敛。
