nginx配置语法正确不等于重定向正常，需通过access.log中$status、$upstream_status和$upstream_http_location三字段确认后端是否返回302及location是否被proxy_redirect正确改写，并结合curl -v实测与header透传（host、x-forwarded-proto）确保上下文一致。
配置文件 nginx -t 通过，不代表反向代理能正常工作。重定向失败往往不是语法问题，而是语义或行为逻辑错配——比如后端返回了 302，但 Location 头没被正确改写，导致浏览器跳转到内网地址或错误路径。排查要绕过“语法正确”的假象，直击请求流转过程。
看 access.log 里的三个关键字段
启用带 $upstream_status 和 $upstream_http_location 的日志格式，这是判断重定向是否“发出去”和“改对了”的第一手证据：
- $status = 302：Nginx 给客户端返回了重定向，说明它收到了响应并做了转发
- $upstream_status = 302：确认是后端主动返回的，不是 Nginx 自己生成的错误页
-
$upstream_http_location：直接看到后端原始的跳转地址。如果值是
http://192.168.1.100:8080/login或/dashboard，就说明没做proxy_redirect或规则不匹配
验证 proxy_redirect 是否生效
后端返回相对路径（如 /login）或绝对内网地址时，必须靠 proxy_redirect 重写 Location 头。常见错误包括：
- 没配
proxy_redirect，只写了proxy_pass - 写成了
proxy_redirect / http://example.com/;，但后端返回的是https://，协议不匹配导致失效 - 用了
proxy_redirect default;，但后端返回的Location域名与server_name不一致，无法自动替换
建议显式配置：proxy_redirect http://backend/ https://$host/; 或 proxy_redirect ~^http://[^/]+(/.*)$ $1;（用于抹掉上游域名）
检查后端是否依赖 Host 或 X-Forwarded 头
很多应用（尤其是 Spring Boot、Django、Node.js 框架）会根据 Host 或 X-Forwarded-Proto 动态生成 Location。若 Nginx 没透传，后端可能拼出错误跳转地址：
- 确保有：
proxy_set_header Host $host;和proxy_set_header X-Forwarded-Proto $scheme; - 若用 HTTPS 反代 HTTP 后端，
X-Forwarded-Proto必须设为https，否则后端可能生成http://开头的跳转链接 - 部分服务还依赖
X-Forwarded-Host或X-Forwarded-Port，按需补充
用 curl -v 实测完整链路
绕过浏览器缓存和前端干扰，直接观察 Nginx 是否转发、后端是否返回、Location 是否被改写：
-
curl -v http://your-domain.com/login→ 看响应头中Location:是什么 -
curl -v http://127.0.0.1:8080/login（直连 upstream）→ 对比后端原始Location - 两者不一致，且 Nginx 返回的
Location仍含内网地址，说明proxy_redirect未命中或配置错误
