背景
阿里云CDN结合WAF使用，WAF作为CDN的源站，是较为常见的使用方式，可以充分发挥CDN的分发加速以及WAF的安全防护能力，一般架构为CDN-->WAF-->SLB-->ECS
问题概述
某阿里云客户反馈2020年5月13日XX:XX分左右，部分CDN域名流量异常增长约400%；
客户内部排查一天，基本排除内部操作影响，请求阿里云协助查看问题原因。
业务架构：CDN-->WAF-->SLB-->ECS
排查过程
1、首先查看CDN域名监控，确认用户反馈时间点，CDN域名带宽出现突发式增长；
2、查看CDN域名QPS指标，趋势平滑无明显增长，判断不是由于请求量增多导致的带宽增长，进而判断是由于平均请求大小变大，导致带宽增长；
3、通过查看CDN回源带宽，发现源站响应的带宽明显增长，进一步确认上面的结论：请求量没有变化，源站响应内容变大；
4、基于上面的结论，做出判断：CDN的带宽突增，是由于源站(WAF)带宽突增导致的，进一步查看了WAF、SLB的流量监控，也都在对应时间突增，因此该问题变成了——为什么SLB在请求数量不变的情况下，带宽突增？
SLB带宽显著增长：
5、首先怀疑的是，源站有调整，响应的文件大小发生了变化，在和客户确认问题期间无任何发布后，暂时排除；
6、由于SLB带宽的变大是因为后端应用响应大小变大导致，因此着手和客户分析应用日志；
通过客户应用日志发现，同一个url，带宽突增后，响应大小明显变大，13k变为68k，响应内容无变化，进一步发现由响应内容由gzip压缩变成非压缩响应；
7、至此问题原因变得清晰：源站的http响应由gzip变成非压缩响应，因此源站流出流量增长，引发SLB、WAF、CDN同步增长；
8、分析源站响应由gzip压缩变为不压缩的原因：
<1>客户端更改逻辑，不再携带请求头Accept_Encoding: gzip（由于客户业务的客户端都是浏览器，排除该项）
<2>CDN丢了请求头Accept_Encoding: gzip
<3>WAF丢了请求头Accept_Encoding: gzip
<4>SLB丢了请求头Accept_Encoding: gzip
<5>源站关闭Gzip压缩（和客户了解后端应用未做发布，排除该项）
HTTP知识点：客户端通过Accept_Encoding请求头，声明可以接受的压缩方式，服务端收到请求后，如果支持的话，响应对应形式的压缩内容，例如gzip压缩；通过这种方式减小传输大小，节约流量同时提升传输速度；
9、下面要做的就是验证原因<2><3><4>，究竟是谁丢了请求头Accept_Encoding
通过携带'Accept-Encoding: gzip, deflate'直接指定WAF和SLB请求，发现:
• 直接请求CDN响应大小是68k
• 直接请求WAF，响应大小也是68k
• 直接请求SLB，响应大小是13k
CDN(68k)——>waf(68k)——>slb(13k)——>k8s(13k)
截止到这里可以判断问题出在了WAF ，即WAF丢了Accept_Encoding请求头;
工具知识点：
curl是一个命令行工具，可以发起http请求，通过如下方式指定IP请求，相当于PC的绑host操作，其中-H 指定请求头
❯ curl -voa "https://www.domain.com/xxx" -H 'Accept-Encoding: gzip, deflate' --resolve www.domain.com:443:1.1.1.1
10、问题定位到是WAF后，通过检查WAF配置，发现是由于客户自行开启了数据风控功能导致WAF回源过滤掉了Accept-Encoding头，客户评估关闭该功能后带宽下降到原有水位，问题恢复；
关于WAF数据风控：https://help.aliyun.com/document_detail/147834.html
总结
通过以上排查分析，CDN流量突增的原因明朗：
CDN-->WAF-->SLB-->ECS
由于客户开启了WAF数据风控功能，导致CDN经过WAF回源的时候，后者丢了Accept-Encoding请求头，因此源站应用不再响应压缩的内容，响应变大，从而导致域名整体流量突增，带宽上涨。
