蓝易云CDN:AI项目怎么防护DDOS?

蓝易云CDN:AI项目怎么防护DDoS?

一、AI项目挨打,为什么比普通网站更疼 💸

传统网站被打,扛住的是带宽和连接数;AI项目被打,烧掉的是GPU算力和真金白银

这里存在一个极其不对称的成本结构:攻击方发一个几KB的请求几乎零成本,而你这边可能要为它做一次上万token的预填充、占用一张卡好几秒。普通网页请求消耗以毫秒计,一次推理请求动辄几百毫秒到几十秒。同样一万QPS,静态站可能没感觉,推理服务已经彻底躺平。

如果后端接的是第三方模型接口,那更直接——账单被打爆,业内叫它EDoS(经济型拒绝服务)。所以AI项目的防护,不能只盯着流量图,还得盯着算力和成本。

二、先分清三种打法,别用错药 🎯

类型 表现 对应手段
网络层洪水(L3/L4) 带宽跑满、SYN堆积、反射放大 高防清洗、BGP分散
连接/请求层(L7 CC) 带宽不高但请求量暴涨、连接被占满 WAF、人机验证、限速
业务算力型 请求量不大,GPU却满载、队列排爆 配额、token限流、准入控制

第三类最阴,也最容易被忽略:每秒几十个请求就能把服务打死,因为每个请求都塞了超长上下文。传统阈值告警根本不会响。

三、第一步:把源站藏严实 🕵️

这是最基础的,也是最多人翻车的地方。接了高防和CDN,源站IP却从别处漏了出去:

  • 历史DNS解析记录还挂着真实IP
  • 邮件服务和主站同IP,一封退信就暴露了
  • 某个测试子域名没走代理,直接A记录指向源站
  • SSL证书透明日志里泄露了内部域名
  • 报错页面、探针页把内网信息吐了出来

必做项:源站防火墙只放行清洗节点/回源IP段,其余全丢;已暴露过的IP直接更换;所有子域名统一走代理;关闭默认站点的IP直接访问。

四、第二步:网络层清洗兜底 🛡️

大流量攻击靠单机是扛不住的,只能交给清洗中心:流量先进入具备大带宽储备的节点,识别出畸形包、反射放大流量后丢弃,把干净流量回送给源站。

配置上注意几点:回源走加密链路并做鉴权,别让人绕过清洗直连;多地区多线路部署,避免单点被打穿;提前确认好防护阈值和超限后的处置策略(是黑洞还是弹性扩容),别等出事才发现被拉黑洞了。

五、第三步:应用层识别真假用户 🤖

  • WAF规则:拦截明显的扫描特征、异常UA、畸形请求体。
  • 人机验证:对注册、免费试用、匿名对话入口做JS挑战或验证码,这是拦截脚本刷量最有效的一道。
  • TLS指纹识别:正常浏览器和自动化脚本的握手特征差别明显,可用于分层放行。
  • 连接层限制:单IP并发连接数、请求速率、慢速请求超时,都要设上限。流式接口(SSE/WebSocket)尤其要防慢读攻击——连接挂着不读数据,把并发槽位耗光。

六、第四步:业务层配额,这才是AI防护的核心 🔑

前面几层都是通用手段,真正决定AI服务生死的是这一层:

  1. 推理接口绝不裸奔。必须鉴权,API Key 或登录态二选一,匿名入口一律限死。
  2. 按token计费限流,而不是按请求数。用令牌桶限制单位时间的token消耗量,这样一个塞满上下文的请求会被正确计价,不会伪装成"一次普通请求"混进来。
  3. 硬性长度上限。输入token数、输出max_tokens、上传文件大小,全部设上限并在网关层校验,别等到模型侧才发现。
  4. 并发数限制。单用户/单Key同时进行中的任务数量必须封顶。
  5. 队列准入控制。队列满了要快速拒绝(返回429并带上重试建议),而不是无限堆积——堆积只会让所有人一起超时。
  6. 重活改异步。长任务走"提交→返回任务ID→轮询/回调"模式,HTTP层不长时间挂连接。
  7. 弹性扩容要设上限。自动扩容很爽,但没有封顶就是给攻击方开了张空白支票。

七、隔离与降级 🧯

  • 动静分离:前端页面、静态资源全部交给CDN缓存,只把推理请求放行到后端,攻击面立刻小一大截。
  • 资源池隔离:免费用户和付费用户用不同的GPU池,免费池被打满不影响付费业务。
  • 降级预案:压力超阈值时自动切换到更小的模型、缩短输出长度、关闭非核心功能,保住主链路可用。
  • 缓存复用:相同或高度相似的请求可复用已有结果;推理框架的前缀缓存也能明显降低重复上下文的开销。

八、监控要盯对指标 📊

普通站看QPS和带宽,AI项目还得盯这些:

  • 每分钟token消耗量(异常飙升往往先于GPU告警)
  • GPU利用率与显存占用、推理队列深度、等待时长
  • 单Key/单IP消耗排行榜(Top N突变基本就是异常)
  • 输入长度分布(突然全是超长prompt,说明被针对了)
  • 请求内容相似度(大量高度雷同的prompt是脚本特征)
  • 第三方接口调用费用的实时预算告警

九、应急预案要提前写好 📋

真出事时没人有空现想方案。提前准备一份开关清单:收紧全局限流 → 关闭匿名/免费入口 → 强制人机验证 → 切换备用IP → 提升清洗等级 → 降级到小模型。做成配置开关,一键可切,并且演练过


总结:AI项目的DDoS防护是分层工程——网络层靠清洗扛量,应用层靠WAF和验证筛人,业务层靠配额和准入守住算力。三层里最不能省的是第三层,因为对推理服务来说,耗尽算力比耗尽带宽容易得多。先把源站藏好、把鉴权和token配额做扎实,再谈防护带宽,顺序才不会错。😊

THE END