接入SCDN后跳转到源站地址：从Location到应用公网地址逐层核对

首页已经接入SCDN，点击登录后浏览器却跳到源站域名或内部端口，说明某个环节仍在按内部地址生成外部链接。问题不仅影响访问体验，还可能让后续请求离开原定入口。先找到地址是谁生成的，再决定修复位置。

把完整跳转链保存下来

用测试账号记录每一跳的请求URL、响应状态和Location，直到到达最终页面。分享记录前去掉令牌、授权码和个人参数。不要仅截图最后的地址栏，因为错误可能在前面某一跳已经发生。

Location字段说明指出，目标可以是绝对URL，也可以是相对请求URL的引用。因此看到一个相对路径并不意味着缺少域名；应结合当前请求地址计算实际目标。

按产生位置寻找配置

每一行都应由相应维护方提供证据。边缘返回了响应，并不能证明Location一定由边缘创建；它可能只是透传源站结果。

应用要知道自己的公共地址

某些应用使用固定公网地址生成登录、找回密码和通知链接，另一些根据当前请求及受信代理信息计算。部署时应选择与框架匹配的方式，并约束允许使用的域名，不能直接信任任意客户端提供的转发头。

内部访问使用HTTP、外部使用HTTPS的架构尤其需要核对协议识别。但不要为解决跳转就把所有来源都列为可信代理，否则外部请求可能影响应用对来源、协议或域名的判断。

响应头改写有明确覆盖范围

在代理层修正Location可以解决某些遗留系统问题，但正文里的绝对链接、邮件内容和后台生成的回调地址未必经过同一处理。应检查登录、退出、找回密码、下载及异步通知等真实功能。

如果应用同时服务多个客户域名，不能把所有响应统一替换成一个主域名。需要明确域名与租户、路径及证书的映射，并测试不同租户之间不会出现错误跳转或身份混用。

修复后的两组验证

第一组从正常公网入口完成完整业务，确认所有必要请求仍经过预定路径；第二组使用受控的异常Host或不允许的返回地址，确认系统不会生成任意外部跳转。后一组应在测试环境进行，避免将真实用户导向未授权地址。

最后检查旧配置与缓存中的重定向是否仍生效。涉及内部地址暴露时，可结合源站保护验收核对直连边界；涉及反复跳转时，再参考HTTPS循环跳转排查。两种现象可能同时存在，但需要分别验证。

资料核对日期：2026年10月30日。本文由AI辅助整理，技术事实依据文内原始资料核对。示例与操作清单供实施参考；产品配置和软件维护状态以实施时的官方资料为准。