CDN常见问题-Trouble Shooting（二）

CDN 常见问题分析思路

1. 访问CDN加速的资源返回状态码403，遇到该问题，可参照以下方法排查：

Chrome 按F12 打开进行cdn加速的一个具体URL链接

1）排查是否开启鉴权

鉴权报错 X-Tengine-Error:denied by req auth: no url arg auth_key

解决：关闭鉴权就可以了的

2）报错The website is under attack, You have requested too frequently

咨询用户是否开启了cc防护

其中cc防护的规则如下：

每分钟访问 150 次，URL 非常集中，认为是攻击

每分钟访问 500 次，不考虑URL，认为是攻击

携带验证码 Cookie，每分钟访问 100 次，认为是攻击

解决：用户可以将自己的IP加入IP白名单，就可以了的

3）源站是oss，报错AccessDenied

昆仑上查看源站，找到源bucket

解决：该bucket是否设置了私有或者不允许refer为空，

私有：提供签名URL（不能开启cdn的过滤参数）

在获取地址中获取地址：获取到的为签名URL

不允许refer为空：允许为空

4）打开URL链接不是cdn域名，但这里面应用了cdn的资源

排查是否是refer调用

Response头中带

X-Tengine-Error:denied by Referer ACL

那么说明refer规则设置不正确

解决：先取消cdn的refer配置，可以使用的话

可以排查cdn日志，找到对应的访问日志，找到refer头，加白

5）绑定源站测试也是403

http response头中

一二级cdn缓存都是不命中，这个说明是源站抛出的403

解决：客户可以，绑定host测试，看看是否是403

定位下源站的问题

2. CDN下载文件不一致的解决方案

通过CDN访问其上的缓存在没有过期之前是会直接反馈给用户CDN上的缓存，而如果用户在这期间源站做了同名更新后访问的时候会发现请求到的资源仍然是旧的资源而导致网站内容错乱。这种问题建议从以下几个方面解决：

（1）源站不做同名更新或增加版本号：源站做了同名更新后CDN并不会知晓该事情，因此建议用户在源站尽量不要做同名更新，或者通过给URL增加版本参数的方式来使CDN请求新资源的时候会回源拿数据（这种方式在CDN的控制台上不能开启过滤参数按钮，否则失效）。

（2）用户在进行同名刷新后可通过控制台/API来手动刷新对应的资源URL，刷新方式可以分为目录刷新和URL刷新。其中URL刷新主要适合于单个资源，刷新速度较快，而目录刷新则会刷下该目录下的所有文件、刷新速度较慢并且由于该目录下所有资源下次请求都会回源可能会对源站带宽所负载情况。

3.CDN如何处理源站的302跳转

对网站的前端界面根据客户终端的设备来决定提供对应的界面样式是常见的网站设计需求。该需求的常见设计思路是源站根据用户的请求然后在源站对用户的请求做302的跳转到对应的页面上进行服务。

在对网站部署CDN后由于CDN的产品性质，CDN会对用户的访问资源缓存到CDN的节点上以便后续可以加快用户的访问，这种情况下就可能会出现第一个用户访问后会对对应的302的请求进行缓存。而其他不同终端设备的用户通过该URL进行访问的时候就会出现访问到的页面情况仍然是第一个用户缓存的302的请求到的页面上。这就会造成用户源站设置的对不同终端的适配功能失效。

要解决这种问题的思路就是设置对第一个请求的URL不缓存，而对302跳转后的页面进行缓存。这样设置就可保证用户源站的终端配置功能可以生效的同时也可以实现CDN对于页面的加速。CDN对于缓存的配置暂时支持两种：目录和后缀名，用户可以结合这两种的缓存配置以及其优先级来根据自己的站点目录结构定义初始URL不缓存，而对于其他的URL缓存；另外更为方便的方法是用户可以在源站对于初始页面设置不缓存，因为源站的不缓存策略对于CDN是具有最高优先级的。只要该页面的response中带有下述头信息就保证该页面不缓存：

Cache-control:no-cache,no-store,private

Cache-control:s-maxage=0,max-age=0

pragma:no-cache

4. CDN某个地域节点访问异常

问题症状

问题1：某地区客户ping不通CDN的加速域名。
原因：用户本地网络异常；节点网络异常或者被攻击；用户本地到运营商中间链路某路由节点故障。
问题2：源站更改文件之后，某个地区的用户从CDN节点上拿到的还是更改之前的文件。
原因：刷新未生效；读取的是本地浏览器缓存；被本地运营商劫持。
问题3：某个地区用户访问CDN加速域名上拿到的非其站点文件内容。
原因：访问的非CDN节点；被劫持。

解决方案

问题1：某地区用户ping不通CDN的加速域名

根据提交的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该节点不通），这种情况该节点存在问题的可能性较大。
让用户本地使用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（如果有）是否一致
上述三点只要有任何一个是不一致的，那么均可认为源站和节点上文件的确是不一致的，上述三点中，条件允许（意思是几个信息都有的情况下）其中第三点是最具备判断依据的点。
上述步骤确认都OK，并且最终还是拿到节点上文件的确和源站文件不一致的情况下，那么建议用户刷新该URL，等待约10分钟之后再去测试（刷新生效时间约为5~10分钟）。

某个地区用户访问CDN加速域名上拿到的非其站点文件内容。

判断用户访问的IP是否CDN的节点IP，方法看问题1的步骤2。
排查是否CDN节点本身缓存了非用户站点上的文件，思路可以按照问题2系列步骤进行，下面针对用户客户端到CDN L1这一段链路进行方法排查用户在能够复现问题的情况下，使其使用浏览器开发者工具，切到network标签下，浏览器地址栏键入访问URL然后回车访问，network标签下，点击用户访问的那个URL，截图general /request header，看看用户实际的访问情况，报错request URl、remote ip、requestUrl主要看访问形式是否如http://x.x.x.x/cache/CDN的访问URL或者remote IP非CDN节点IP，如下图这种则是劫持：
需要联系其本地运营商投诉处理，解除劫持。