proxy_redirect用于重写后端返回的301/302响应中Location和Refresh头，将内网地址或错误路径替换为公网可访问URL；需严格匹配返回头前缀，配合curl验证与error_log info调试。
proxy_redirect 的作用很明确：它不改请求，只在后端返回 301/302/307 等重定向响应时，精准重写其中的 Location 和 Refresh 响应头，把内网地址、错误协议或不匹配路径替换成用户实际可访问的公网 URL。
先看清后端到底返回了什么
这是所有配置的前提。别猜，用 curl 直接抓响应头：
- curl -I https://your-app.com/login —— 关注返回里的 Location: 字段
- 常见真实值包括：Location: http://172.18.0.5:8080/callback、Location: https://backend.local:8443/logout、Location: /auth
- proxy_redirect 只做字符串前缀匹配，协议、主机、端口、末尾斜杠必须和返回值完全一致，差一个字符都不生效
三类典型场景对应三种写法
根据你看到的 Location 格式，选最匹配的配置方式：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
后端返回绝对内网地址（最常见）：如 Location: http://127.0.0.1:3000/dashboard
写法：proxy_redirect http://127.0.0.1:3000/ https://your-app.com/;
注意：前后都带斜杠，且目标域名建议用硬编码，避免 $host 在多域名下出错 -
后端返回相对路径，但你用了子路径代理：如 Nginx 配置 location /api/ { proxy_pass http://backend/; }，后端却返回 Location: /login
写法：proxy_redirect / /api/;
含义：把以 / 开头的跳转路径，统一补上前缀 /api/ -
后端地址不固定（Docker/测试环境常见）：可能返回 http://localhost:3000/、http://app-dev:8080/、http://10.0.1.20:3001/
写法：proxy_redirect ~^http://[^/]+(?::\d+)?/(.*)$ https://your-app.com/$1;
正则提取路径部分 $1，丢弃所有原始 host、端口、协议，确保最终跳转干净统一
必须同步配好的请求头
只靠 proxy_redirect 是“兜底”，真正治本要让后端自己生成正确跳转：
- proxy_set_header X-Forwarded-Proto $scheme; —— 告诉后端当前是 HTTP 还是 HTTPS，防止它硬写 http://
- proxy_set_header Host $host; —— 避免后端从原始请求里读到 127.0.0.1:8080 这类地址
- proxy_set_header X-Real-IP $remote_addr; 和 X-Forwarded-For $proxy_add_x_forwarded_for; —— 支持后端日志与安全策略
验证是否真的生效
别只看配置文件，动手验证才可靠：
- 用 curl -I 再次请求触发重定向的接口，确认响应头中 Location: 已变成预期的公网地址，协议、域名、路径都对
- 临时开启 Nginx 错误日志到 info 级：error_log /var/log/nginx/error.log info;，触发重定向后查看日志是否有 “proxyredirect …→…” 成功记录，或 “no matching redirect rule” 提示未命中
- 检查 proxy_redirect 是否写在和 proxy_pass 同级的 location 块里——写在 server 或 http 块下不会对当前代理生效
