最终的结论很清楚, 那就是在给权重比较高的域名部署CDN服务, 这种做法本身并不会导致权重的下降, 但必须有一个前提条件, 就是DNS解析、TLS证书、URL一致性这三项配置必须全部设置正确, 下面将会提供一份完整的部署清单作为参考。
部署前必须确认的三项配置
1. DNS解析切换
先把那个域名的A记录或者CNAME记录指向给由CDN提供的那些节点地址, 在去执行切换操作之前, 把这个TTL设置成300秒, 这么做的目的是为了把因为解析切换窗口期所带来的那种延迟影响减少到一个比较低的程度, 等这个切换的动作完成之后, 需要一直去观察至少72个小时的时间长度, 以此来确认在全球的所有不同区域里面看到的解析结果都是一致的。
2. TLS证书同步
我们需要在CDN控制台把证书配置好, 让它与原站完全匹配。这里说的匹配，是包括SAN子域名在内的整个情况。如果是一个权重很高的高Https站点, 就必须用和源站一样的完整证书链。
这么做是为了避免浏览器跳出那种中间人告警的提示语。等到证书快过期的时候, 提前30天就要把这个续期工作做完。然后还要把这个新的证书同步到那些CDN节点上面去, 这样才行。
3. 回源URL一致性
CDN回源后响应中的URL必须与用户访问的原始URL完全一致, 禁止在CDN层做二次重定向或改写Host头。验证方法: 通过curl -I分别请求CDN节点与源站, 对比Location字段是否相同。
高频踩坑场景及解决方案
坑1：回源协议不匹配
现象表现为CDN使用HTTP协议去源站回源, 而源站会强制执行301跳转指向HTTPS, 这样就导致了重定向环的情况发生。对于解决问题的方法, 需要将CDN的回源协议修改为HTTPS, 并且在填写回源SNI的时候, 直接写入域名本身。
坑2：缓存策略误覆盖权重页
现象是这样的, 就是首页还有核心的栏目位置, 因为它们被那个CDN给长时间缓存着了, 结果导致搜索引擎在抓取的时候, 抓到的都是过期的副本, 那么内容的更新就很慢, 会有延迟的情况。
解决方案则是, 对于那些权重比较高的页面, 要把TTL设置成小于或者等于60秒, 或者是直接写上no-cache这个指令, 然后呢, 只针对图片、CSS样式表、JS脚本这些静态资源, 去设置那种长时间的缓存期。
坑3：源站IP暴露导致CDN被绕过
出现了一种现象, 就是历史的DNS解析信息泄露了源站的IP地址, 导致流量绕过了CDN网络直接连接到了源站, 这使得安全防护功能和加速功能全部都失去了效力, 为了解决这个问题, 需要在源站的防火墙上进行设置, 只允许来自CDN回源IP白名单的流量通过, 而且要把这个白名单每三个月就更换一次。
上线后验证清单
请根据下述所列的先后顺序, 依次逐项地进行核实检查。
1. 分别地采用dig命令并且指定8.8.8.8作为目标服务器执行一次查询, 同时另外采用dig命令并且指定1.1.1.1作为目标服务器执行另一次查询, 通过这两种不同配置的交叉验证方式, 来确认全球的域名解析结果是否统统都指向了CDN节点。
2. 在主流的搜索引擎里面去执行site:这个命令, 好确认一下CDN切换完之后页面还是可以正常地被索引起来。
3. 大家可以用站长工具去监控, 看7天时间的索引量还有核心关键词的排名状况, 要求把波动的幅度控制在5%的范围里面。
4. 检查CDN回源日志中Host字段是否与原站请求头完全一致。
补充说明
就拿 gname.xin 这个域名的情况来做分析, 它的服务器IP地址是在海外那边存放着的。因为这个原因, 当数据源返回的时候, 平均所需的等待时间大概会是120毫秒。
所以如果我们要把这个域名当作是内容分发网络的回源测试节点来使用, 那么比较合适的做法是只让它去负责那些并不是很关键的非核心静态资源的加速工作。绝对不能把它用在主要是站点的权重页面所需要的那条回源链路上去。
这样做的最主要目的就是为了避免出现一些不好的情况, 也就是说不会影响国内普通用户在访问网站时的用户体验, 同时也不能影响到搜索引擎在抓取相关内容时所需要的时间效率。
总结
在高权重域名上使用内容分发网络的核心原则, 就是对用户保持透明, 也要对搜索引擎保持透明。只要网址不会发生变化, 证书能够保持一致, 回源设置正确无误, 那么内容分发网络这一层就不会稀释权重的数值, 反而是通过降低首字节时间来改善用户的体验, 进而给搜索排名带来间接的好处。
