高防CDN能防CC攻击吗？拦截原理、失效原因与配置自查

能防，但有两个前提。第一，这家高防CDN要在边缘节点上真正做七层（HTTP/HTTPS）清洗，比如频率限制、人机挑战和WAF规则。第二，你的源站只能经过它被访问。缺了第一个，CDN只是在帮攻击者把请求更快地送到源站；缺了第二个，攻击者绕开CDN直接打源站IP，CDN上的规则配得再好也看不到这些流量。

如果还不确定自己遇到的是CC还是流量型DDoS，可以先看如何判断网站遭遇的是DDoS还是CC攻击。下面按照它靠什么拦、什么时候拦不住、接入后怎么查的顺序来说。

防CC靠的是七层能力，不是防御带宽

CC攻击发出的是看起来正常的HTTP请求，单个请求不大，靠数量拖垮源站的CPU、数据库或连接数。所以对它起作用的不是能扛多少G流量，而是能不能在边缘分辨出哪些请求该放行、哪些该拦截。

宣传中的防御带宽主要对应三四层的流量型攻击。选型时如果对方只讲带宽、讲不清七层规则能配到什么程度，防CC这件事就要打个问号。普通的纯加速CDN通常没有这层清洗，最多靠缓存挡掉一部分静态请求。

高防CDN拦截CC的四种手段

反向代理隐藏源站：域名解析指向CDN节点，外界看到的是节点IP。这是后面几种手段能生效的前提。
边缘缓存吸收：图片、JS、CSS和静态页面在节点上命中缓存，请求再多也不回源。针对静态资源的CC，大部分在这一步就被消化了。
速率限制：按单IP、单Cookie或其他标识，限制某个URI在一段时间内的请求次数，超过阈值就拦截或转入挑战。阿里云、华为云的CC防护规则也是围绕路径、统计维度、阈值和处置动作这几个要素来配置的。
人机挑战：JS挑战、Cookie校验、滑块验证码等。浏览器可以自动完成或由用户完成，大多数自动化脚本过不去。

高防CDN防CC的请求流程：缓存、限速、人机挑战三道关卡，以及源站只放行回源IP、阻断绕过CDN直连的路径

哪些情况下还是会被打穿

源站IP已经暴露

这是最常见、也最致命的一种。攻击者直接向源站IP发起HTTP请求，完全不经过CDN。IP泄露的途径很多：接入CDN之前的历史解析记录、邮件头、直接解析到源站的子域名、页面或接口里写死的源站地址等。

处理方法：

在源站防火墙或云安全组里，80/443端口只放行高防CDN的回源IP段，其他来源一律拒绝。
安全组只能阻止请求进入服务器，攻击流量依然会打到这个IP所在的线路上。如果源站IP以前暴露过，比如接入前就一直在用，或者已经被攻击过，建议换一个新IP再接入。
排查还有没有子域名、邮件服务或其他业务指向同一台服务器。

攻击打在不能缓存的动态接口上

应对方法：

给这些路径单独设置限速，阈值按正常用户的真实使用频率来定，通常要比全站阈值低得多。
如果代理IP池让单IP限速失效，可以改用Cookie、会话或请求特征（UA、Referer、参数格式等）作为统计维度，或者对这些路径开启更严格的人机挑战。
校验参数格式，明显不合法的随机参数直接在边缘拦截。

如果是API被批量调用，比如大模型接口被盗刷，可以参考大模型API接口被盗刷怎么限流中分层设置阈值的思路。

挑战方式和客户端类型不匹配

JS挑战和滑块验证依赖浏览器。App接口、服务器之间的调用、支付回调都无法完成这类挑战，一刀切地开启反而会误伤正常业务。这些路径应该改用限速、签名校验或来源IP白名单。支付回调被误拦的处理方法见WAF把支付回调拦了怎么加白名单。

业务本身不是HTTP

上面这些规则都作用在HTTP/HTTPS层。WebSocket长连接、App私有协议、游戏的TCP/UDP连接，高防CDN能做的有限，不同产品的支持范围差别也很大，需要单独确认，或者考虑四层代理、游戏盾等方案。具体可以看非网站业务能用高防CDN吗。

接入后按这个顺序自查

源站：安全组只放行回源IP段；确认没有子域名或其他服务仍然直连源站；IP暴露过的就更换。
缓存：静态资源全部走缓存，避免回源。
规则：列出登录、搜索、下单、支付和核心API等动态路径，逐个设置限速阈值和处置动作。
挑战：网页路径可以用JS挑战或验证码；API、App和回调路径改用限速、签名校验和白名单。
观察与收紧：如果产品支持仅记录模式，先用它或者较宽松的阈值跑一段时间，再从日志里看真实请求的分布，逐步收紧阈值。日志的查看方法见CDN控制台怎么看流量和网络日志。