反向代理不处理多级重定向，而是确保每级301/302响应的location头对客户端有效；需用curl -iv逐级追踪、配置proxy_redirect规则或透传x-forwarded-*头让后端生成正确跳转地址。
反向代理本身不“处理”多级重定向，而是确保每一级重定向响应中的 Location 头都对客户端有效。关键在于：Nginx 不会自动跟随后端跳转，它只负责把后端返回的 301/302 响应原样（或按规则改写后）交给浏览器；所谓“多级跳转”，其实是浏览器依次执行多个 Location 跳转的过程。真正要解决的，是让**每一级**返回的 Location 都指向公网可访问地址，而不是内网、错误端口或丢失路径前缀。
确认每级跳转的实际 Location 响应头
多级重定向是否出问题，第一步永远是看真实响应链。用 curl -Iv 模拟浏览器行为，逐级追踪：
-
curl -Iv https://your.com/login—— 看第一跳 Location 是什么 - 若返回
Location: /auth?next=/dashboard，再请求该路径：curl -Iv https://your.com/auth?next=/dashboard - 持续直到得到 200 或发现某一级跳到了
http://10.0.1.5:8000/...这类不可达地址
为每级跳转配置对应的 proxy_redirect 规则
proxy_redirect 只作用于当前 location 块中 proxy_pass 返回的响应，且仅对 301/302/307/308 生效。如果多级跳转涉及不同路径（如 /login → /auth → /dashboard），而它们由同一后端服务返回，一条通用规则通常足够；但如果跳转跨了不同后端或子路径，需分 location 配置：
- 后端返回绝对地址（如
http://internal:8080/callback）→ 统一替换协议+域名：proxy_redirect http://internal:8080/ $scheme://$host/; - 后端返回相对路径但 Nginx 代理带子路径（如
location /admin/ { proxy_pass http://backend/; }）→ 补全上下文：proxy_redirect / /admin/; - 需兼容多种内网地址（如 Docker 容器名、私有 IP、localhost）→ 正则动态匹配：
proxy_redirect ~^https?://[^/]+(/.*)$ $scheme://$host$1;
让后端自己生成正确的跳转地址（治本）
依赖 proxy_redirect 是兜底手段。如果后端持续返回错误 Location，说明它没感知到代理层的存在。必须透传关键头并确保后端启用解析：
- 在 location 中加：
proxy_set_header Host $host;<br>proxy_set_header X-Forwarded-Proto $scheme;<br>proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
- 后端需据此构造跳转 URL：Spring Boot 设
server.forward-headers-strategy=framework；Django 配SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')；Next.js 使用getServerSideProps读取x-forwarded-proto - 避免后端硬编码跳转地址（如
return redirect("http://localhost:3000/login")）
验证与调试要点
改完配置别急着重载，先检查逻辑闭环：
- 确保
proxy_redirect写在proxy_pass之后、同级，且未被if或嵌套 location 错误包裹 - 开启调试日志：
error_log /var/log/nginx/error.log info;，日志中会出现proxy_redirect: ... rewritten to ...记录 - 用
curl -I检查最终响应头，确认 Location 已变为https://your.com/xxx，不含内网 IP、端口或多余路径片段 - 若某级跳转仍失败，检查该跳转是否由前端 JS 发起（如
window.location.href），这类跳转不受 Nginx 控制，需从前端修复
