域名跳转的这个设置到底对还是不对, 它会直接影响到用户来访问的时候的感觉好不好, 还有搜索引擎在传递权重的这个过程里会怎么样。要是你使用了那种很专业的去检查域名跳转的工具, 那么大概30秒的时间, 你就可以把从原来那个域名一直到后来的那个目标域名的整个线路都检测一遍了。
这样做能够非常快地找到到底是哪个地方出了毛病, 导致跳转不正确了。在下面这些内容里面, 包含了关于301、302、307、308这四种不同的跳转方式, 它们完整的怎么去测试, 还有出现问题以后该怎么去排查的方法。
跳转类型与测试重点
301（永久重定向）: 这个东西是用在域名更换, 或者路径迁移的场合, 需要去确认一下, 搜索引擎是否已经把索引更新好了。
302, 它是“临时重定向”的意思, 一般是用在活动页面或者是A测试这样的暂时性场合里面, 不能把它当作长期的解决办法来一直留着不用改。
307/308: 这两个状态码分别对应临时重定向以及永久重定向, 它们会保留那个原始请求方法, 打个比方说就是像POST这样的方法, 所以它们特别适用于API接口进行跳转的场景。
在测试的时候, 需要一个个地去进行验证, 看看返回的响应码是不是正确的, 还有跳转的目标地址是否准确, 同时要检查在中间环节里有没有出现多余的节点, 因为如果跳转的链路过长, 会导致权重出现逐层递减的情况。
五步检测流程
第一步,输入源域名。 把要检测的那个完整的网址粘贴到跳转测试工具里面, 比如是https://example.com这种包含了协议的链接, 然后发起请求。
第2步:读取响应头, 工具返回了HTTP的状态码, 并且也返回了Location这个字段的值, 如果返回结果是200, 这说明没有发生跳转操作, 如果返回结果是301或者302, 又或者返回的是307、308, 那么就进入下一步骤。
第3步:追踪跳转链。 那个工具会自动去跟着重定向走, 然后把每一次跳转所使用的域名、返回的状态码以及所花的时间都记录下来。正常的链接路径应该是一跳就直接到达目标地址, 如果超过三跳的话, 就认为这是异常情况。
第四步骤需要做的是校验目标网页是否可以正常使用。 具体就是要确认最后那个落脚的页面返回的结果是两百, 而且里面的内容是齐全的, 以此来排除那种虽然跳转操作完成了、但是目标页面却呈现为不存在的四百错误的情况。
第五步是输出检测报告。 工具会生成结构化的结果, 该结果里包含每一跳的响应码、耗时以及最终的目标地址, 这些东西是直接可以用来排查问题或者归档保存的。
高频问题与排查
跳转成环: 就是说, A跳到了B, 然后B又跳回到了A。这种情况可以查看Location字段, 看它们是不是互相指向对方, 只要修改其中一方那方的跳转规则, 就可以把这个环路给打破了。
协议不一致: 也就是从http跳转到https之后, 又再次通过301转向跳转回了http这个问题存在。我们需要在服务器的层面进行统一的配置, 来实施强制启用https的措施。通过这个办法把这种双向相互跳跃的情况给彻底消除掉。
跳转链过长, 就是经过了多个中间域名这样一个情况, 我们要把那些中间的节点给合并一下, 要让源域名直接通过301的方式跳转到最终目标去。
本地域名解析服务器的缓存部分或者内容分发网络的缓存部分出现了干扰, 导致这些存储旧跳转记录的地方, 把以前保存的过期路径信息给返回出来了, 所以在做测试的时候需要打开没有缓存功能的模式，或者是先把网络上的那个地址解析记录给清理掉然后再重新试一次。
批量检测与补充说明
对于有需要同时去验证多个域名的跳转规则的情况, 运维人员可以在测试工具里面提供的批量输入框那里, 粘贴进去很多条URL地址。这个时候, 这个工具就会把这些请求并行地发出去, 然后汇总出一个对比表来展示结果。如果我们拿gname.xin这个例子来说, 它已经配置成了301跳转到主站。
当使用测试工具进行操作的时候, 它会完全显示出响应头的内容、Location值是多少, 还有每一跳所花费的时间是多长。这样, 运维人员就可以根据这些信息, 非常快地理清楚状况去确认跳转的这个动作是不是已经生效了。
注意事项
在开始执行测试之前, 需要确认服务器已经将最新的配置数据进行保存操作, 并且这些新配置已经实现了生效状态, 这样做的目的是为了避免因为读取了旧的规则内容而导致出现错误的结论情况。
建议你先把在生产环境里面可能要做的改变, 拿到测试环境里去进行验证, 并且确认是可以通过的情况下, 然后再把这个东西上线到生产环境中去。
301跳转一旦被搜索引擎收录便难以回退, 在变更前务必反复确认目标地址准确无误。
