CDN防护选高防还是WAF？先看攻击落在哪层

带宽被瞬间跑满、连接数往上蹿到几万，服务器连 ping 都费劲，这是一种病。网站还能打开，但每个请求都慢得像在泥里走，数据库 CPU 顶到跑满，这是另一种病。cdn防护要选高防还是 WAF，先别比产品参数，先问一句：攻击落在哪一层。

cdn防护到底在拦哪一层

把网络想成一条快递链路就明白了。四层看的是包裹多大、从哪个地址来、发得有多密；七层拆开包裹看里面装了什么，URL 长什么样、参数有没有塞注入语句、请求头像不像正常浏览器。高防主要干前者的活，WAF 干后者的活，而 CDN 自己站在中间，靠一堆分布式节点把量摊薄。三者不是替代关系，是不同楼层的保安。

所以那种「哪个更安全」的问法本身就不成立。你的站被人拿 UDP 反射怼，WAF 规则写得再漂亮也没用，因为流量压根没走到 HTTP 那一步；反过来，人家拿脚本慢慢刷你的登录接口，每个请求都合规得像真人，高防看着流量曲线平平的，也不会替你拦。

高防顶的是流量，不是业务逻辑

高防的套路是流量牵引：把域名解析指到清洗中心，按阈值和特征把异常流量滤掉，剩下的干净流量回源。它值钱的地方在带宽储备和抗 SYN flood、抗反射放大这类硬碰硬的活。但它基本不关心你业务层发生了什么，你的验证码接口被刷、商品接口被爬价格，它照单放行。

这里有个很常见的翻车：有人买了高防，觉得万事大吉，结果一个 CC 攻击就把源站打瘫了。因为那些请求在四层看来完全合法，只是一秒钟来了几千次。清洗中心把它当正常流量放过去，源站的 PHP-FPM 进程池直接被吃光。花了钱，问题还在。

WAF 看的是请求长得像不像人

WAF 的价值在于它懂 HTTP。它能看到请求路径、参数、Cookie、body，能按 OWASP 那套规则拦 SQL 注入、XSS、命令执行，也能做频率控制、JS 挑战、人机校验，还能给还没打补丁的漏洞先挂个虚拟补丁挡一挡。云 WAF 接入一般改 DNS 或加一条 CNAME，顺带把源站 IP 藏起来，这部分和 CDN 的思路是一路的。

但 WAF 不是万能的，最常见的两个麻烦：一是误杀。后台上传接口、富文本编辑器、嵌套很深的 JSON 参数，经常被规则当成攻击掐掉，用户投诉说保存不了，你查半天才发现是 WAF 拦的。二是它不扛大流量，几百 G 的洪水冲过来，先垮的是入口带宽，规则引擎再聪明也没机会执行。

源站 IP 藏没藏住，先查这一个

这一步比选产品重要得多，而且几乎不花钱。上了 CDN 或者云 WAF，如果源站真实 IP 还能被直接访问，攻击者就绕开你所有防护，直奔老家。泄露的路子太多了：历史 DNS 解析记录、证书透明度日志、mail 子域名、测试环境用的二级域名、甚至论坛里贴过的一张截图。

动手查的顺序：翻一遍历史解析记录看有没有暴露过；搜证书透明度日志里给这个域名签过证的记录；把常用子域名挨个解析一遍；最后在源站防火墙上只放行 CDN 回源段的 IP，其他一律拒绝。这一圈走完，比多买一个防护产品管用。

CC 攻击最容易让两边都尴尬

CC 属于七层，但它的目的不是偷数据，是耗你的资源。高防那边靠频率阈值判断，阈值调低了误伤真实用户，调高了等于没开；WAF 那边靠 JS 挑战和指纹，遇上真人肉鸡或者分布式代理池也会被绕过。更尴尬的是限频策略：同一个出口 IP 后面可能是一整栋写字楼或者一个校园网，一封就是一片人打不开。

比较稳的做法是按路径分级。静态页交给 CDN 缓存，让它根本碰不到源站；搜索、列表这类查询接口单独限速；登录、下单、验证码这种高价值接口上最严的策略，配合人机校验。别全站一刀切，那是给自己找事。

预算有限时的组合顺序

如果钱不多，顺序大概是这么个顺序：先把源站 IP 藏好、防火墙白名单配好，这是地基；然后让 CDN 把静态资源吃掉一大块，缓存命中率高的时候，同样的攻击量落到源站可能只剩一小截；接着看日志，如果确实是七层特征明显——注入尝试、恶意爬虫、异常 UA、单 IP 高频打接口——再上 WAF；最后，如果已经被大流量怼过、或者业务本身招黑（游戏、金融、活动页），才轮到高防。

反过来，先砸钱买高防、源站 IP 却挂在外面，等于装了防盗门却把钥匙插在锁上。

最后留几个自查的点：源站防火墙是不是只允许 CDN 回源段进来；域名有没有历史解析把 IP 漏出去；被攻击时先看的是带宽曲线还是应用日志；限频策略有没有考虑 NAT 后面的一片用户；WAF 规则动过之后有没有回归测过上传和富文本。这几条对上号了，再谈买哪个产品，方向基本不会跑偏。