proxy_redirect用于重写后端重定向响应中的Location和Refresh头，将内网地址（如http://10.0.2.5:8080/login）替换为公网可访问地址（如https://app.example.com/login），仅作用于301/302/307等重定向响应，不处理普通请求或响应体。
proxy_redirect 是 Nginx 专用于改写后端响应中 Location 和 Refresh 头的指令，只在后端返回 301/302/307 等重定向响应时起作用。它不处理普通请求路径，也不修改请求体或其它响应内容，核心任务是把后端生成的、面向内网或私有端口的跳转地址（如 http://10.0.2.5:8080/login），替换成用户实际访问的公网可访问地址（如 https://app.example.com/login）。
为什么必须用 proxy_redirect
后端应用（Spring Boot、Flask、Node.js 等）执行重定向时，通常基于自身监听地址构造 Location 值。例如：
- 后端监听
http://192.168.1.20:3000，返回Location: http://192.168.1.20:3000/dashboard - 用户通过
https://app.example.com访问，Nginx 代理后若不干预，浏览器将直接尝试打开该内网地址——连接失败或暴露架构 - 即使后端返回相对路径
/login，若 Nginx 配置了子路径代理（如location /api/），浏览器也会跳到根路径/login而非预期的/api/login，导致 404
三种常用配置方式及适用场景
精确前缀替换（推荐初学者）
语法：proxy_redirect http://192.168.1.20:3000/ https://app.example.com/;
要求前后缀完全一致：协议、主机、端口、末尾斜杠缺一不可。适用于后端地址固定、部署环境单一的生产环境。
正则提取路径（应对多变内网地址）
语法：proxy_redirect ~^http://[^/]+(?::\d+)?/(.*)$ https://app.example.com/$1;
忽略原始协议、主机、端口，仅捕获路径部分 $1 并拼接到目标域名后。适配 http://localhost:3000/、http://backend-svc:8000/callback、http://172.19.0.3/ 等多种格式。
相对路径替换（配合 X-Forwarded-Proto 使用）
语法：proxy_redirect http://127.0.0.1:8000/ /;
将绝对 URL 的 host 部分剥离，输出为 /dashboard 这类相对路径。浏览器自动按当前页面协议、域名、端口补全。需同步配置：proxy_set_header X-Forwarded-Proto $scheme;，否则后端可能仍生成 http:// 开头的跳转。
关键细节与易错点
-
proxy_redirect必须放在和proxy_pass同级的location块中，不能仅写在server或http块里 -
proxy_pass末尾是否带斜杠，直接影响后端收到的路径和返回的Location格式，进而决定proxy_redirect的匹配逻辑 - HTTPS 场景下，replacement 必须用
https://开头；若 Nginx 监听 443 但未设server_name，建议硬编码域名而非依赖$host - 后端若读取
X-Forwarded-Proto判断协议，必须配置proxy_set_header X-Forwarded-Proto $scheme;，否则它可能持续返回错误协议的Location，导致proxy_redirect匹配失败
调试与验证方法
启用 info 级别日志可查看匹配过程：error_log /var/log/nginx/error.log info;。触发重定向后，日志中会出现 “proxyredirect … → …” 或 “no matching redirect rule” 提示。
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
用 curl 直接检查响应头：curl -I https://app.example.com/auth，观察 Location: 行是否已变为预期的公网地址。若仍是内网 IP 或旧路径，说明规则未命中，需核对前后缀是否完全一致（包括协议、端口、斜杠）。
不复杂但容易忽略
