问题症状

问题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分钟），如果多次刷新之后问题仍未解决，请提交工单。

如果您有其他问题，可以联系北京志远天辰阿里云代理商，为您提供一对一专业全面的技术服务，同时新/老阿里云会员，均可享受我公司代理商价格，欢迎咨询！