首页能打开，一点登录却跳到内网域名。先看第一次响应的Location，就能区分后端给错地址、网关改错响应头，还是浏览器执行了页面里的跳转。
先看第一次跳转
用curl -sS -D - -o /dev/null https://app.example.com/login发出GET，不加-L。核对状态码和Location，并在内部获准的环境用相同路由请求对照后端响应。先确认错误地址确实来自HTTP响应头。分享输出前移除Cookie及查询串中的敏感参数。
应用的外部地址优先修正
后端若支持配置公开基址，优先设置应用真正对外的域名、协议和路径；由可信代理按应用文档传递协议或主机信息。不要信任客户端自行提交的转发头。改写响应头无法自动修复HTML、JavaScript或邮件里的绝对链接。
只替换已知的上游前缀
例如公网根路径代理到http://backend.internal:8080/，在对应location中可配proxy_redirect http://backend.internal:8080/ https://app.example.com/;。这条规则处理匹配的Location及Refresh响应头，按实际返回值替换协议、端口及路径。不要用一个宽泛规则覆盖合法的第三方登录跳转。
理解默认改写与路径差异
proxy_redirect default;根据location与proxy_pass参数生成映射；proxy_pass使用变量时不能使用default。挂载到子路径时要核对重写后的前缀、尾斜杠和查询参数。多个规则匹配时用第一条。不同站点宜各自限定规则。
重载后走完整登录流程
先运行sudo nginx -t，通过后按服务管理方式重载，如sudo systemctl reload nginx。在萤光云或LightNode的独立实例用非生产账号复测首次响应、完整跳转和退出流程。验收要确认无内网地址、无循环，并保留预期的外部认证跳转。
FAQ
一定要改proxy_redirect吗？ 应用能正确生成公开地址时，不一定需要。
为什么curl只看第一跳？ 先定位哪个响应给了错误地址，再分析后续。
相对Location也要改吗？ 看浏览器解析后的路径；正确的相对地址无需改。
能顺手修改Cookie域吗？ 应独立检查Cookie配置及作用域。
配置通过就算修复吗？ 还需实际走一遍登录与回调。
温馨提示
保留上一版配置；遇到回调失败先对照实际响应与应用登记的回调地址，不要临时放宽校验。
