CDN防CC，关键不在防护开关

面板上那个CC防护开关点成绿色，不代表你的站就稳了。有人买完CDN第一件事就是把防护拉满、阈值压到最严，结果该被刷还是被刷，页面该卡还是卡。CDN防CC这件事，开关只是入场券，真正决定扛不扛得住的是开关后面那套识别规则，以及你对自己业务到底有多少了解。

CDN防CC，真正干活的是识别层

CC攻击的原理不复杂——用一大堆看起来正常的请求，把你动态页面的资源耗光。它不像DDoS那样傻乎乎地砸带宽，而是专挑数据库查询多、CPU吃得厉害的那几个入口，比如搜索页、登录接口、分页列表。CDN节点挡在前面，靠什么判断哪个是人、哪个是脚本？常见的就是请求频率、请求特征、能不能执行JS、有没有带Cookie。这几项凑在一起才叫识别层。只开了开关、阈值用的还是默认值，等于让CDN拿一把通用尺子去量所有人。

频率阈值，最容易设错的一项

默认阈值一般按“每IP每秒多少请求”来算。麻烦在于，正常浏览器加载一个页面会并发好几个请求，图片、CSS、JS都算次数。阈值压低了，用户刷新两次就被拦；调高了，攻击者把速度放慢一点照样绕过去。所以真正要看的不该是“总共多少次”，而是“哪个URL被打了多少次”。动态接口单独设规则，静态资源放宽，这才叫有针对性。

别把自己人挡在门外

误杀这事，开过严格模式的人基本都遇到过。公司出口就一个IP，几十号人共用，一旦被判定异常，全公司都打不开自家站。后台登录、接口调试、搜索引擎爬虫，也都容易中枪。上线防护之前先把白名单列出来：办公出口IP、监控节点、合作方的回调IP，还有后台地址。白名单不做，出事的时候你连后台都进不去，只能干看着。

回源才是命门

很多人以为CDN挡住了，源站就安全了。这个不成立。攻击者只要拿到你的真实IP，前面那层就白搭，他直接打源站，CDN一点忙帮不上。真实IP怎么漏出去的？历史解析记录、邮件头、某些第三方扫描服务都可能扒出来。所以源站侧至少得有点基本动作：安全组只放行CDN回源段的IP，别把80和443对全网敞开；有条件的回源走固定端口，别跟公网共用一个入口。

静态和动态，处理方式完全不同

静态资源是CDN的强项，缓存一开，请求压根到不了源站，攻击者刷它性价比很低。真正要盯的是动态请求——带参数的搜索、表单提交、登录验证。这些不能缓存，每一个都得落到源站。能做的无非几件事：把没必要的动态接口改成静态或者加一层缓存、给表单加验证、高频查询加个短时缓存、明显是空参数的搜索直接拒掉。说白了这些都是代码层面的事，指望CDN一个人全扛，不现实。

JS挑战和验证码，别全场开

有些CDN会提供JS挑战、等待跳转、滑块验证这类手段，效果确实猛，副作用也不小。搜索引擎的爬虫可能被挡在外面，收录受影响；老旧设备、老浏览器的用户可能直接卡住；真正被误伤的往往是那些“看起来可疑、其实是真人”的访问。比较稳的做法是分层：正常流量放行，疑似流量做个JS挑战，明确异常的才封。封IP也得留一手，别一上来封整个C段，邻居用户全跟着遭殃。

日志不看，等于没开

这条听着像废话，但确实有人防护开了很久，日志一次没翻过。日志里的信息不少：被刷的是哪个URL、来源IP集中在哪几个段、请求头长什么样、User-Agent有没有明显伪造的痕迹。看几次心里就有数了，也能反过来把阈值调准。还有个细节——CDN日志里的客户端IP是从X-Forwarded-For这个头里取的，源站如果没做对应处理，记下来的全是CDN节点的IP，这种日志翻半天也找不出攻击源。

小站先把这三件事做了

站点不大、预算也紧的话，别一上来就追全套方案。先把这三件事落地：一，动态接口单独设规则，别和静态资源混在一起；二，白名单列清楚，尤其是自己的出口IP和后台地址；三，源站安全组只放行回源段IP。这三步花不了多少成本，却能挡掉大部分自动化的扫描脚本。剩下的等真被盯上再加也不迟。

防护这东西没有一劳永逸的配置，攻击手法在变，你的业务也在变。隔一段时间翻翻日志、看看被拦下的请求长什么样，比直接买个更贵的套餐管用。至于具体参数怎么填、支持哪些识别方式，各家CDN差别挺大，以服务商控制台里的说明和官方文档为准。