问题描述
某客户反馈使用CDN以后下载时间很慢，TTFB很长，需要定位原因。
排查过程
1. 分析CDN日志
根据Network下的信息后台查到CDN的日志信息，发现访问慢是因为中间有过504重试，具体过程如下
（1）客户端请求到L1（cn2620），L1回源到cache18.l2cn2635以后，cache18.l2cn2635回源504，RT时间是5182ms
（2）cache18.l2cn2635响应504以后，触发L1重试到cache12.l2cn2641，回源成功，RT时间是137ms
所以虽然最终现象看起来是访问成功了，只是速度比较慢，实际的过程中是因为有504并发生了重试，耗时主要是第一次回源504的耗时。同时查看但是客户端提供的Network下的响应头也可以进一步确认此问题，当时虽然响应了httpcode 200，但是响应头里响应了x-swift-error：orig response 5xx error
2. 错误日志分析
日志服务SLS查看L2的错误日志分析，504错误基本就是聚焦在l2cn2635节点，且rt时间是5s左右。
3. 听云探测
根据前面的分析，其他L2节点到源站首字节都正常，日志也正常，唯独这个L2节点到源站会504，而且首字节时间是5k ms，因此怀疑是源站做了相关安全策略，或者该节点到源站的网络问题。但是用户的源站是阿里云的SLB，且用户反馈SLB层面并没有做安全策略。由于该L2是唐山的一个L2节点，因此想到用听云到唐山地区用三大运营商探测下源站，发现也一切正常。
4. 为什么会504？
CDN回源源站的时候产生了504，但是客户源站SLB的日志并没有查到504的日志，看起来这个504日志不是源站响应的，那么就有可能CDN回源超时导致的。但是根据rt时间看5s就504了，看起来并没有达到默认CDN约定的回源超时时间，默认CDN回源的超时时间是：建联超时10s （也就是说tcp连接10s超时），读客户端请求头超时时间：30s （也就是说应用层30s超时）。至此，一共有如下几个疑问需要确认：（1）看起来rt时间5s并没有达到超时时间，看起来不是超时导致，那么有可能是源站直接响应504。
（2）回源504日志显示的错误码是"0"，也就是CDN认为是正常请求，并不认为是连接不上或超时断开这种情况，这也进一步印证了源站直接响应504的情况。
（3）但是现在的问题是源站查不到504日志，那么有没有可能是客户反馈的源站日志排查的结果不可靠？
5. 源站抓包
为了验证到底是不是源站吐的504，因此考虑让用户在源站侧抓包，然后客户端去访问复现，出现问题以后提供chrome的har文件和源站的抓包文件。根据日志分析，第一次是cache18.l2cn2635回源504，回源的IP是101.x.xx.xx；然后L1重试到cache12.l2cn2641回源成功，回源的IP是115.xx.xx.xx。从源站的抓包文件看，可以看到来自115.xx.xx.xx的报文，但是过滤不到来自101.xx.xx.xx的报文，看起来就是101.xx.xx.xx的请求没有到源站。
6. CDN抓包
目前情况看起来有点复杂了，源站SLB上没有抓到来自CDN回源IP的报文，且源站日志没有记录该504请求的CDN回源IP的日志，看现象就是CDN回源源站的回源链路有问题。为了进一步验证这个问题，只能到发生504的cache18.l2cn2635这台机器上去抓包。从抓包结果来看，的确是源站直接响应了504，而且看响应504的报文里，TTL和SYN握手报文的TTL一致，看起来也不是被劫持导致，也不像是网络问题。而且只有两台CDN机器回源有504问题，其他机器回源一切正常。
7. 源站配置检查
各种证据表明，越来越像是源站有安全策略拦截了，但是源站是SLB，看SLB的一些访问控制的策略，比如IP黑白名单，即使拦截了应该也能查到403的日志，而不会是504。检查配置发现SLB开启了"透明WAF"功能。进一步了解该功能原理，SLB开启透明WAF功能以后不需要更改DNS解析，请求SLB的流量都先走TWAF（透明WAF），TWAF在CDN和SLB之间充当了一个透明代理。TWAF和client建连时借用了SLB的IP，TWAF和SLB建连时借用了client的IP。那么根据这个现象看，极有可能是CDN的请求被TWAF拦截了（在下图中，CDN的回源IP就是client）。
8. TWAF拦截记录
去查了TWAF的拦截记录，发现果然有拦截记录，CDN的tproxy IP（回源IP）被WAF识别成攻击IP，被用户的访问控制策略加入到了WAF的黑名单里。致此，终于可以结案！
问题原因
由于业务请求走了CDN，CDN又通过汇聚式的L2节点回源，而源站配置了透明WAF，WAF配置的安全规则认为这些频繁回源的CDN节点IP是攻击IP，被访问控制策略加入到黑名单，而TWAF通过响应504的形式拒绝了来自CDN的回源请求。根据上面的TWAF实现原理图可以知道，这个504的请求对于SLB来说完全是没有感知的，所以SLB上肯定没有日志，需要查WAF的拦截日志才能发现。
解决方案
从黑名单里移除该CDN的回源IP即可。但是由于目前配置的策略，很有可能还会继续把CDN的回源IP当成攻击IP处理，因此需要调整WAF拦截策略，或者把CDN的回源IP加入到白名单。但是这也有风险，因为CDN回源时会智能分配节点访问源站，回源的节点IP是不固定的，因此不建议将源站的回源策略白名单设置为固定的节点IP列表，这样有可能因为CDN回源IP变更，新增IP由于未在白名单导致被拦截继而发生回源失败的情况。
如果有强诉求，也可以通过调用CDN的DescribeL2VipsByDomain接口获取CDN回源的节点IP列表并添加到源站服务器的白名单中。该接口仅支持日峰值带宽为1Gbps以上的用户调用，如果符合该条件，可以提交工单，申请该接口的调用权限。
适用于
- CDN
- 全站加速
