proxy_redirect是唯一能稳定改写后端3xx响应Location头的Nginx指令；常见跳转到:8080是因为缺失proxy_set_header Host、X-Forwarded-Proto等关键头，导致后端生成错误绝对URL，proxy_redirect被迫反复或漏匹配。
proxy_redirect 是唯一能稳定拦截并改写后端 3xx 响应中 Location 头的 Nginx 指令，不依赖后端配合，也不修改请求路径——它只在响应发出前动那一条头。
为什么直接配 proxy_redirect 还是跳转到 :8080
常见错误是只写了 proxy_redirect，却没传关键上下文给后端，导致它持续生成带私有端口的绝对 URL，Nginx 被迫反复替换甚至漏替换。
-
proxy_set_header Host $host;缺失 → 后端request.getHeader("Host")拿到的是127.0.0.1:8080，不是api.example.com -
proxy_set_header X-Forwarded-Proto $scheme;缺失 → 后端判断协议出错，返回http://而非https://，proxy_redirect http:// https://可能匹配失败（因后端实际返回https://127.0.0.1:8080/） -
proxy_set_header X-Forwarded-Port $server_port;缺失 → 当 Nginx 监听非标准 HTTPS 端口（如:7443），后端无法知道该用哪个端口拼接 URL
proxy_redirect 的三种写法怎么选
匹配逻辑严格依赖后端实际返回的 Location 值。先用 curl -I 看清原始响应，再决定写法：
- 后端返回固定格式，如
http://10.0.1.100:8080/login→ 用精确替换：proxy_redirect http://10.0.1.100:8080/ https://api.example.com/;（注意末尾斜杠必须一致） - 后端地址多变（
localhost、127.0.0.1、容器名、不同端口混用）→ 用正则提取路径：proxy_redirect ~^http://[^/]+(?::\d+)?/(.*)$ https://api.example.com/$1; - 后端已返回相对路径
/login，但你代理路径是/api/→ 用路径前缀修正：proxy_redirect / /api/;（此时proxy_pass末尾不能带斜杠，否则路径会被剥离）
调试时 curl 看不到生效？检查这三点
proxy_redirect 不生效，90% 是因为匹配失败。验证步骤要闭环：
- 确认是否命中：在
nginx.conf中加error_log /var/log/nginx/error.log info;，然后触发重定向，日志里会明确打出 “proxy redirect … → …” 或 “no matching redirect rule” - 确认返回值：用
curl -I https://api.example.com/auth，看Location:行是否已变成预期公网地址；若仍是内网地址，说明规则没匹配上 - 确认作用域：
proxy_redirect必须写在和proxy_pass同级的location块里，不能只放在server或http块（除非你真想全局生效）
真正容易被忽略的是：后端框架（比如 Spring Boot 的 server.forward-headers-strategy=framework）默认不信任 X-Forwarded-* 头，即使你全配了 proxy_set_header，它也可能直接 ignore。这时候 proxy_redirect 就成了最后一道不可绕过的兜底——但它只修结果，不修源头。所以线上环境务必同时做两件事：传对头 + 改对 Location。
