Nginx需用proxy_redirect重写后端302响应中的Location头，将内网地址（如http://192.168.1.10:8080/）替换为$scheme://$host/等公网可访问地址，并配合proxy_set_header传递Host、X-Forwarded-Proto等头，确保后端生成正确跳转。
这个问题本质不是负载均衡本身的问题，而是反向代理场景下后端返回的 302 响应中 Location 头含内网地址（如 http://192.168.1.10:8080/login），导致浏览器跳转失败或访问不到。负载均衡只是把请求分发给多个后端节点，但每个节点都可能返回同样的内网重定向地址——所以必须在 Nginx 代理层统一修正。
确保 proxy_redirect 正确匹配并替换内网绝对路径
这是最直接有效的解法。关键在于：后端返回的是哪种格式的 Location？常见为绝对 URL，需用完整前缀匹配替换：
- 如果后端固定返回
http://192.168.1.10:8080/xxx，就写：proxy_redirect http://192.168.1.10:8080/ $scheme://$host/; - 如果后端 IP 不固定（比如多台机器、Docker 动态分配），推荐用正则动态捕获：
proxy_redirect ~^http://[^/]+(/.*)$ $scheme://$host$1;
（Nginx ≥ 1.11.8 才支持） - 若用了子路径代理（如
location /app/ { proxy_pass http://backend/; }），后端返回/dashboard，但用户实际应跳到/app/dashboard，则加：proxy_redirect / /app/;
必须同步设置 proxy_set_header 让后端生成正确重定向
只改响应头不够，后端下次生成新 Location 还可能出错。要让它“知道”用户是通过什么协议、域名访问的：
-
proxy_set_header Host $host;—— 避免后端硬写localhost或内网域名 -
proxy_set_header X-Forwarded-Proto $scheme;—— 告诉后端当前是 HTTP 还是 HTTPS，防止它生成http://跳转而被浏览器拦截 -
proxy_set_header X-Real-IP $remote_addr;和X-Forwarded-For $proxy_add_x_forwarded_for;—— 辅助后端日志和权限判断
在 upstream + proxy_pass 场景下验证每台后端行为一致
负载均衡时，不同后端实例可能配置不一致，有的返回 http://，有的返回 https://，有的带端口、有的不带。建议：
- 先用
curl -I http://nginx-ip/path检查实际返回的Location值，确认是否统一 - 若后端是 Spring Boot，检查
server.forward-headers-strategy=framework并启用ForwardedHeaderFilter - 若后端是 Node.js（如 Express），需手动读取
X-Forwarded-Proto和Host构建跳转地址
HTTPS 入口下尤其注意协议一致性
用户访问 https://example.com，但后端返回 Location: http://example.com/admin，现代浏览器会拒绝跳转或降级失败：
- 确保
proxy_set_header X-Forwarded-Proto $scheme;已启用 - 后端应用必须信任该 header，并据此生成
https://开头的重定向地址 - 必要时可在 Nginx 层强制统一协议：
proxy_redirect http:// $scheme://;（慎用，仅当后端无法改造时）
