域名跳转测试工具的核心作用体现在, 它能够对HTTP或者HTTPS的重定向链路进行逐跳的追踪。通过这种方式来验证在每一次跳转中所返回的状态码, 例如301、302、307或者308等情况到底是不是符合我们预期的结果。
其最终目标是确保用户在从输入原始域名到抵达目标页面这一整个完整的路径过程中, 不会出现任何中断的情况, 同时也不会遭遇环路的干扰。
在你选择工具的这个环节里面, 你要把优先关注点放在以下这三项能力上面, 第一项能力是这个工具要支持多跳链路可视化, 第二项能力是这个工具可以导出curl或者浏览器里面的原始响应头内容, 第三项能力是这个工具要支持批量域名并发检测这一件事情。
跳转状态码与业务含义
在开始测试的时候, 大家务必要重点关注这几个方面。首先得确认跳转链条有没有形成闭环的情况, 比如说从A跳转到B之后又回到了A这样的现象。其次要检查一下中间会不会出现状态码为4xx或者5xx这样的断点问题。最后还要看看Location那个响应头里面的协议和主机名是不是完全对应的、保持一致的。
选型核心标准
1. 链路深度是指系统能否对传输路径进行追踪, 追踪的过程中需要覆盖至少 10 个跳数节点, 并且在这个过程中能够及时发现或者识别出可能出现的网络环路情况。
2. 协议覆盖: 它既能支持HTTP, 又能支持HTTPS, 会检测那些由证书链异常所导致的跳转中断的情况。
3. 批量能力: 在一次导入百级域名列表的操作中, 输出统一报告（CSV/JSON）。
4. 把每一次的完整的响应标头全部给存留下来, 这样的好处就是方便去检查出来缓存的策略方面存在的冲突的情况。
5. CI集成这个功能, 它是能够提供API的, 它也是能够提供命令行接口的, 你可以用它们接入自动化的发布流水线。
用户可以在gname.xin这个平台上, 把域名列表直接提交上去。系统会自己干活, 搞定DNS解析这件事。然后还会把TLS握手这一步给完成。接着再做逐跳追踪这种验证动作。
整个流程包含三步。到了结果页面的时候，会给每一个跳点都标上耗时的数字。同时也会把最终落地的网址URL展示出来。这样的功能很适合运维团队在上线之前做回归测试的工作。
标准测试操作步骤
1. 打开目标工具的跳转检测模块, 然后输入起始的链接地址, 这个地址里面要带着完整的网络访问协议。
2. 设置那个最大的跳转次数, 这个东西建议默认值是5, 在异常的场景下面调到10。
3. 我们把指定User-Agent为桌面Chrome这一步做了处理, 以此来排除在移动端出现302重定向的差异情况, 这样就避免了对分析结果造成的干扰。
4. 我们执行那个检测的操作, 然后把链路图给查看一下, 对于里面的每一跳, 都需要标注上它的状态码是多少, 还有它耗时有多少, 最后还要把Location的值也标注出来。
5. 对于异常跳转的情况, 需要手动执行一条指令来进行交叉验证, 这条指令是 curl -sI -L , 以此来检查响应头信息。
6. 把导出出来的报告进行归档操作, 这样做的原因是把它们当作是变更发布阶段里面的验收凭证来使用。
高频疑难与排查
这个 302反复循环 的问题是, 它的出现大部分是因为 Cookie 的域不匹配, 或者是因为 Session 的验证被触发了, 我们需要去检查一下 Set-Cookie 这个响应 header 里面的 Domain 属性, 看看它有没有把跳转之后的那个主机也给覆盖掉。
HTTPS跳转后变HTTP：常见于CDN回源配置未强制HTTPS域名跳转测试工具域名跳转测试工具，需在边缘规则中补充X-Forwarded-Proto判断。
移动端与PC端跳转不一致: 服务端是通过分析User-Agent这个信息来决定走哪条分支处理的, 所以在做测试的时候, 一定要把这个事情分开来做, 分别用两组不同的UA去执行测试操作。
在完成上述的全链路验证步骤之后, 那么域名跳转的这个配置就可以看作是已经通过验收这个环节了, 所以它就能够进入正式发布的流程里面去了。
