最高效方式是直接分析nginx access.log中的$status、$upstream_status和$upstream_http_location三字段，结合error.log排查连接失败、超时或连接重置等底层问题，并用curl -v实测proxy_redirect是否生效。
直接看 Nginx 日志是定位反向代理路径重定向异常最高效的方式。关键不是泛泛地扫日志，而是聚焦几个核心字段和响应行为，快速锁定是 Nginx 没转发对、后端返回错、还是浏览器跳错了。
重点看 access.log 里的三个字段
打开你的 /var/log/nginx/access.log，每一行都包含一次请求的完整记录。重点关注以下三项：
- $status：Nginx 最终返回给客户端的状态码。如果是 302/301，说明发生了重定向；如果是 404，要区分是 Nginx 自己返回的（路径没匹配到 location），还是后端返回后再被 proxy_pass 转发过来的。
-
$upstream_status：后端真实返回的状态码。比如你看到
302 502，代表 Nginx 收到了后端的 302，但自己又返回了 502——这说明重定向前连接就断了；如果看到302 302，说明后端确实返回了重定向，问题出在 Location 头怎么处理上。 -
$upstream_http_location：这是最关键的字段，它记录了后端响应头中原始的 Location 值。例如：
http://192.168.1.100:8080/dashboard或/dashboard。只要这个值是内网地址或不带域名的相对路径，基本就能确认是重定向地址没被 Nginx 修正。
用命令快速抓取可疑请求
不用翻几百行日志，用一条命令就能筛出最近的重定向异常：
- 查所有返回 302 且 upstream 返回也是 302 的请求：
awk '$9==302 && $12==302 {print $0}' /var/log/nginx/access.log | tail -20 - 专门看 Location 头是否泄露内网地址：
awk '$9==302 {print $13}' /var/log/nginx/access.log | grep -E "(192\.|10\.|172\.)|:[0-9]{4}" | tail -10 - 对比正常与异常请求的差异（比如登录前后）：
grep "/login" /var/log/nginx/access.log | tail -5和grep "/dashboard" /var/log/nginx/access.log | tail -5对着看 $upstream_http_location 是否一致。
结合 error.log 看底层通信问题
access.log 只告诉你“发生了什么”，error.log 才解释“为什么发生”。当重定向跳 404 时，error.log 往往藏着真相：
- 出现 connect() failed (111: Connection refused) → 后端服务根本没起来，302 是假象（其实是 Nginx 自己生成的错误页）。
- 出现 upstream timed out → 后端返回太慢，Nginx 在等 Location 头时超时，可能返回 504 而不是预期的 302。
- 出现 recv() failed (104: Connection reset by peer) → 后端主动断开连接，常见于 Go/Java 应用未正确处理 X-Forwarded-* 头导致拒绝请求，重定向根本没发出来。
验证 Location 头是否被 proxy_redirect 修正
如果你已配置了 proxy_redirect，别只信配置文件，要实测它有没有生效：
- 用 curl 模拟请求，带上 -v 参数：
curl -v https://example.com/login - 观察响应头中的 Location 字段。如果配置了
proxy_redirect http://backend:8080/ https://example.com/;，那么原始 Locationhttp://backend:8080/dashboard应该变成https://example.com/dashboard。 - 如果没变，检查是否写了
proxy_redirect off;，或者正则规则写反了（比如把旧地址写成新地址）。
