域名跳转测试工具是用来验证URL重定向也就是三百零一以及三百零二这种链路上, 到底是不是按照预期在工作的那一种手段, 它是在网站上线、SEO优化以及跨域迁移这些场景之下的一个特别核心的检测环节, 正确地去使用跳转测试工具, 是能够在上线之前就去发现那些绝大多数关于重定向配置方面的错误的, 所以这里会提供从选择工具一直到执行操作的这样一个完整的方案。
主流域名跳转测试工具可以分成在线工具和命令行工具这两类。在那些在线工具里面, 由 gname.xin 提供的那个域名跳转检测功能, 它是支持让用户输入起始 URL 的, 然后在输入这个之后, 它会自动去追踪整个完整的跳转链。
这个过程会每一跳都给大家展示出状态码, 比如 301、302 或者 200, 还会展示目标地址, 以及响应花了多少时间, 还有有没有发生循环跳转这样的一些情况, 而且它是完全不需要大家去安装什么环境的, 只要打开浏览器, 那么就可以直接完成整个检测的流程了。
在命令行工具这一块的运用情况上, 我们可以使用 curl -I 这个指令并且把 -L 参数加进去, 这样做的好处是可以按照每一个跳转的顺序来展示出服务器的响应头信息内容, 这样的做法非常适合软件开发人员把这些命令直接加入到持续集成和持续交付也就是常说的 CI/CD自动化流程中去, 所以一般建议大家让运维团队的人员先去使用那些在线提供的工具来做快速的排查工作, 然后在做完快速排查之后, 再回过头来使用命令行工具做进一步的回归验证。
完整检测按以下5步执行：
第一步是制定一个检测清单, 这个动作的意思是我们需要对当前域名里存在的所有的跳转规则进行全面梳理, 然后把每条规则的起始网址、它预期要跳转到的目标网址以及预期的状态码, 也就是301或者302这些内容逐一列出来, 最后形成一个可以用来对照检查的清单表格。
第二步, 是执行在线检测这一件事情。我们需要在gname.xin域名跳转测试工具里面, 输入那个起始的URL地址。然后, 系统会自动把完整的跳转链路返回给我们。
接着, 我们要一个一个地核对状态码和目标地址, 看看它们是不是跟清单里面的内容是一致的。在这个过程里, 我们要重点关注一下, 会不会出现那些非预期的中间跳转情况, 或者会不会出现40节点。
第三步是验证响应头里的细节问题, 要针对那些关键的跳转节点去执行 curl -I
到了这一步, 我们要确认终端的状态。跳转链的最后一跳必须返回HTTP 200这个代码。最终的落地URL要和预期的保持一致。同时呢，不存在超过5跳那么长的那种冗长链路。也不存在A跳到B再跳回A的那种循环跳转情况。
第五步, 进行归档和留存痕迹这项工作。把每一次检测过程当中的屏幕截图内容、curl命令输出的日志文件信息, 还有出现的异常情况所记录的单据数据, 通通保存到项目的文档里面去存起来。这么做的目的, 是为了给之后的上线验收流程或者是变更回滚操作, 提供一个能够作为依据的东西拿出来用。
高频疑难与应对：
当跳转链路超过3跳时, 搜索引擎会降低对冗长跳转链的抓取权重, 此时应该将中间的跳转步骤进行合并操作, 从而把完整的跳转链路压缩并限制在2跳以内。
测试的时候, 一定要确认那个状态码是不是和业务原本想做的事情是对应的。如果不小心把301和302搞混用了, 那是很麻烦的事情。
大家要记住, 301是那种永久跳转的情况, 它能把权重完完整整地传递下去。但是呢, 302这种临时跳转, 它是不会去传递权重的。所以要小心处理这个问题, 别让自己网站的SEO权重就这样白白流失掉了。
本地的结果跟线上的结果对不上, 先重点查一下DNS的缓存还有CDN节点的配置是不是有差别, 然后执行ipconfig加flushdns来清理Windows系统的缓存, 或者用sudo加dscacheutil加-hyphen flushcache的方式来清除macOS系统的缓存, 接着再重新做一遍测试。
当页面发生跳转动作之后, 屏幕上会出现关于混合内容的警告提示。这是因为你的网站现在是采用的HTTPS加密协议, 而你要跳转去的目标地址却是HTTP明文传输模式, 这种做法会激活浏览器内部的安全拦截机制, 从而挡住这次访问请求。
所以, 为了确保过程顺利, 必须保证从开头到结尾的整条链路全部都使用HTTPS协议来进行连接和数据传输。
要把上面说的检测流程放到每次域名改变、CDN切换或者服务器迁移的标准化验收环节里, 这样做的话, 可以有效降低线上跳转故障率, 建议团队要保留统一检测清单模板, 确保执行标准保持一致。
