摘要：# 自建高防CDN，防御阈值怎么定？别让机器全说了算 我前两天帮一个做游戏的朋友看他们自建的高防CDN配置，好家伙，阈值设置那叫一个“奔放”——攻击流量一过10Gbps，清洗系统就自动全开，结果平时搞个活动，正常用户一拥而上，也被当成攻击给“洗”了。客服…

自建高防CDN，防御阈值怎么定？别让机器全说了算

我前两天帮一个做游戏的朋友看他们自建的高防CDN配置，好家伙，阈值设置那叫一个“奔放”——攻击流量一过10Gbps，清洗系统就自动全开，结果平时搞个活动，正常用户一拥而上，也被当成攻击给“洗”了。客服电话直接被打爆。

这场景你熟吧？很多团队在自建高防CDN时，都卡在防御阈值设定这个坎上。设低了，真被打时扛不住；设高了，误杀正常用户，业务照样瘫痪。说白了，这根本不是个纯技术问题，而是个平衡艺术：机器自动响应的速度，和人脑判断的精度，到底该怎么配比？

今天咱们就抛开那些云厂商华丽的方案书，聊聊自建体系里，那些真实、纠结，甚至有点“土”的实战经验。

一、阈值不是数字游戏：先想清楚你要防的是什么

别一上来就纠结“500Mbps还是1Gbps触发”。先问自己几个问题：

• 你的业务峰值流量是多少？ 这不是看监控面板的历史最高，而是得算上搞促销、发新版本、上热搜时的正常峰值。我见过最离谱的，是把日常平均流量当基准，阈值就设在高出50%的位置——这不叫防御，这叫一搞活动就自杀。
• 你最怕哪种攻击？ 是耗带宽的DDoS洪水，还是耗连接数的CC攻击？这两种的阈值设定逻辑完全不一样。前者看流量大小（bps），后者看请求频率（QPS）和连接数。很多自建系统只盯着带宽阈值，结果被一波低流量、高并发的CC打得找不着北。
• 你的“源站”有多脆？ 这是最核心，却最容易被忽略的。你的后端服务器、数据库，真实能承受的极限是多少？高防CDN前面挡得再猛，如果清洗后回源的流量还是把源站压垮了，那就成了笑话。阈值设定，必须低于源站的崩溃临界点，留出足够的安全缓冲。

说白了，阈值设定的第一步，是给你的业务画一张“体检报告”和“攻击假想图”。没这个底子，所有数字都是瞎蒙。

二、自动触发：快，但要“聪明地快”

自建的优势就是控制权在自己手里。自动化触发规则，可以做得非常精细，远不止一个总流量开关。

1. 分层阈值，别一根筋 别只设一个“总攻击流量”阈值。好的策略应该是这样的：

• 第一层（预警线）： 针对单个IP的异常QPS（比如，每秒请求数突然飙升50倍）。这时，不急着清洗，可能先自动触发一个“验证码挑战”或者访问延迟，把疑似机器人的请求筛掉。很多CC攻击就这么被化解在萌芽状态。
• 第二层（清洗线）： 针对特定业务端口或API路径的流量突增。比如，你的登录接口突然收到海量请求。这时候可以自动启动针对该路径的流量清洗规则，而不影响网站其他正常页面的访问。
• 第三层（总攻线）： 最后才是基于总入向带宽的阈值。这个值要设得比较保守，因为它一旦触发，影响面最大。

2. 给自动化加上“状态记忆” 机器傻就傻在它没有“上下文”。上周搞活动，同样的流量曲线是正常的；这周同样的曲线，可能就是被打了。怎么办？ 可以在系统里引入一个简单的“学习”机制：比如，在计划内的活动期间，自动调高某些阈值；或者在非业务高峰时段（比如凌晨），降低阈值，提高敏感度。再比如，如果系统识别出流量来自已知的云服务器IP段（黑客常用），可以更早触发防御动作。

自动化不是为了“图省事”，而是为了在正确的时机，做出标准化的快速反应。

三、人工介入：那个不能撤的“保险栓”

但千万别迷信自动化。把所有决策权交给机器，等于在战场上蒙着眼睛冲锋。人工介入的核心价值，在于处理“异常”和“模糊”。

什么时候必须有人工盯着？

1. 首次触发高级别阈值时： 系统第一次触发总清洗，无论是否误判，都必须告警到人。人需要去确认：这是真的攻击，还是我们某个没报备的推广爆了？
2. 攻击模式发生突变时： 比如，流量从UDP洪水突然变成针对API的慢速攻击。机器可能只会根据既定规则应对，但人需要判断这是否意味着攻击者改变了策略，是否需要临时调整整个防御重心。
3. 业务敏感时期： 比如游戏开服、电商大促、在线直播。这时候，宁可误杀，不可错放的激进策略可能不适用。因为误杀一个真实用户，损失可能比放掉一些垃圾流量更大。这时需要安全人员坐在监控前，随时准备手动调整阈值，甚至临时关闭某些过于粗暴的规则。

我自己的经验是，一个成熟的运维或安全负责人，在攻击发生时，一半时间在看监控图，另一半时间在打电话——打给市场部：“你们是不是在推哪个链接？”打给研发：“这个时间点的数据库慢查询正常吗？”很多“攻击”，其实是内部“乌龙”。

四、找到那个平衡点：几条“血泪”经验

理论说完，上点干的。怎么找到自动和手动的平衡点？没有标准答案，但有几条可以避坑的路径：

• 从“宽松”开始，逐步收紧： 自建系统上线初期，自动阈值设得保守一些（即触发门槛高一些），同时加强监控告警。观察一段时间，记录下所有告警，分析哪些是误报。然后像拧螺丝一样，一圈一圈地收紧策略。这比一开始就设得太严，导致业务频繁中断要好得多。
• 建立你的“攻击剧本”： 把历史上遇到过的真实攻击，以及处理过程，写成详细的“剧本”。比如：“当出现针对/api/login的CC攻击时，第一步自动启用验证码，第二步……如果10分钟内无效，则通知值班人员手动介入。”这样，新人也知道该怎么处理，而不是瞎操作。
• 定期进行“压力测试”和“预案演练”： 别等真被打的那天才检验你的阈值。定期用工具模拟攻击，看看你的自动化规则是否按预期工作，人工响应流程是否顺畅。演练后，一定要复盘，调整阈值和流程。
• 接受“不完美”： 没有能100%防住所有攻击、同时100%不误杀的方案。你得根据业务特性做取舍。是做金融的，对误杀零容忍？还是做内容资讯的，对可用性要求极高？这个选择，只能你自己做。

写在最后

自建高防CDN的阈值设定，像给自家院子装一套智能安防。你不能把灵敏度调到最高，不然风吹草动就警铃大作，迟早把自己搞疯；你也不能调到最低，真来了贼都发现不了。

最好的状态是：让机器当好那个不知疲倦的哨兵，处理所有它能识别的、常规的威胁；而人，则作为指挥官，坐在后方，处理那些复杂的、狡猾的、机器无法理解的“非常规”情况。

别追求一劳永逸的“完美数字”。把它当成一个需要持续喂养、观察和调整的活系统。你的业务在变，攻击手段在变，这个平衡点，自然也得跟着变。

行了，如果你正在为自建系统的阈值头疼，希望这些大实话能给你一点不一样的思路。毕竟，防护这东西，纸上谈兵永远简单，真到烽火连天的时候，手里有谱，心里才不慌。