CDN某个地域节点访问异常
问题症状
问题1:某地区客户ping不通CDN的加速域名。
原因:用户本地网络异常;节点网络异常或者被攻击;用户本地到运营商中间链路某路由节点故障。
问题2:源站更改文件之后,某个地区的用户从CDN节点上拿到的还是更改之前的文件。
原因:刷新未生效;读取的是本地浏览器缓存;被本地运营商劫持。
问题3:某个地区用户访问CDN加速域名上拿到的非其站点文件内容。
原因:访问的非CDN节点;被劫持。
解决方案
问题1:某地区用户ping不通CDN的加速域名
排查用户的加速域名是否在沙箱节点中(目前可以在CDN控制台得知其加速域名是否在CDN沙箱节点)。以ycc.pier39.cn为例,域名在沙箱中,则控制台域名状态
沙箱中的域名无法保证服务稳定性,所以会存在ping不通的情况,此时可能沙箱正在受到攻击。
根据提交的Ping截图,拿到所访问的节点IP,核实该IP是否是CDN节点IP,以IP:1.2.3.4,域名zihu-live.pier39.cn为例,请按照这里的方法核查是否该IP为CDN节点。
如果用户的访问节点不是CDN节点IP,需要用户核实几个情况:
用户本地是否有开启代理软件(有些代理软件会强制更改访问域名的解析情况)。
用户是否有绑定Host文件,将加速域名强制解析到了某个IP。
用户本地存在DNS劫持,这种情况,让用户本地开启杀毒安全软件,并且固定本地所使用的DNS为阿里的223或者电信的114或者其他知名的DNS,如果劫持情况比较严重,并且无法解决,则需要向你的网络服务提供商投诉要求解决劫持。
自己本地实际ping该节点IP,以及使用站长工具(比如17ce.com或者听云平台)在全国探测该节点IP,是否存在问题(问题现象:各个地区访问该节点均延迟均较大或者不通,自己本地也Ping该节点不通),这种情况该节点存在问题的可能性较大(结合步骤1确认好域名确实没有在沙箱中)。
让用户本地使用tracert(win主机)或者traceroute(linux主机)到该IP进行探测并提供完整探测截图,根据得到的截图确定整个网络链路的问题点。MTR信息判断方法:目的节点丢包率为100%,并且从目的节点往前一直找到第一个开始丢包的节点(中间不能有丢包率为0%的路由节点),则第一个开始丢包的路由节点是问题路由的可能性较大。详细排查步骤可以参考这篇文章。
也可以给阿里云技术同学进行排查。在此期间缓解用户问题的方法:让用户更改本地所使用的localDNS为其他DNS(比如电信的114或者阿里的223)并且刷新本地的DNS缓存,使其调度到其他正常的节点,走另外一条线路,则该问题可能得到缓解。
问题2:源站更改文件之后,某个地区的用户从CDN节点上拿到的还是更改之前的文件
让客户提交ping CDN加速域名的截图,拿到客户访问的节点IP。
判断该节点是否是CDN的节点,判断方法请看问题1的步骤2。
根据CDN的配置,绑定客户提供的CDN节点,以及CDN的源站(绑定用户源站测试的时候,注意一下用户CDN的回源Host配置,举例:如果用户CDN加速域名为A,源站域名为B,回源Host配置的为A,那么测试源站的时候,以curl来说,命令应该为curl -H “Host: A” “B”;如果是绑定Host文件,那么应该将用户的CDN加速域名绑定Host到源站域名所解析出来的IP上),绑定源站测试的时候,还要注意一下源站回源端口的设置,不同的回源端口得到的访问结果也可能是不一样的;分别测试得到response header相关信息,判断是否如客户所说访问的文件会是不一致。
这里判断是否一致,着重看几点:
content-length大小是否一致
last-modified(如果有):修改时间是否一致
Etag/Content-Md5(如果有)是否一致
上述三点只要有任何一个是不一致的,那么均可认为源站和节点上文件的确是不一致的,上述三点中,条件允许(意思是几个信息都有的情况下)其中第三点是最具备判断依据的点。
image.png | center | 848x544
上述步骤确认都OK,并且最终还是拿到节点上文件的确和源站文件不一致的情况下,那么建议用户刷新该URL,等待约10分钟之后再去测试(刷新生效时间约为5~10分钟),如果多次刷新之后问题仍未解决,请提交工单。
如果您有其他问题,可以联系北京优胜智连阿里云代理商,为您提供一对一专业全面的技术服务,同时新/老阿里云会员,均可享受我公司代理商价格,欢迎咨询!