DDoS 与 CDN：如何用边缘网络把攻击流量挡在源站之外
为什么「ddos cdn」值得单独拿出来讲
很多站点第一次遭遇 DDoS，第一反应是「买个高防 IP」。但在真实的生产环境里，最先接住攻击流量的往往不是高防，而是 CDN。原因很简单：攻击者拿不到你的源站 IP，他只能打域名，而域名解析指向的是 CDN 的边缘节点。于是 CDN 从「加速工具」变成了「第一道接触面」，这也是 ddos cdn 这个话题真正的价值所在——它讨论的不是两个孤立的技术名词，而是一套把攻击流量摊薄、过滤、消化掉的边缘架构。
需要先厘清一个常见误解：CDN 不是「防 DDoS 的开关」。它默认提供的是分布式的入口和缓存能力，防护效果取决于你如何配置回源策略、如何区分静态与动态请求、如何设置限速与清洗规则。同样接入一家 CDN，有的站点被打到源站宕机，有的站点几乎没有感知，差别几乎全在架构细节上。
CDN 在 DDoS 防护中到底扮演什么角色
第一层：把单点压力变成多点压力
DDoS 的本质是「用远超目标承载能力的流量或请求压垮它」。CDN 改变的第一件事，是目标的形状。攻击者解析域名得到的是边缘节点地址，同一份攻击流量会被分散到不同地区、不同机房的多台节点上。配合 Anycast 寻址，同一个 IP 在全球多地同时宣告，攻击流量会就近进入网络并被分摊，单个节点承受的压力被大幅削薄。对于 SYN Flood、UDP Flood、DNS 反射这类流量型攻击，这种「摊薄」本身就是最有效的缓解手段之一。
第二层：边缘节点的流量清洗
流量到达边缘后，CDN 会做一轮基础过滤：异常包结构、明显伪造的源地址、超出协议规范的握手、单 IP 的超高频请求，都会在离攻击源最近的位置被丢弃。规模较大的攻击则会被牵引到清洗中心，清洗后再回注到正常链路。这一层的关键指标是清洗容量和牵引速度——容量不足时，节点带宽会先被打满，防护就退化成「一起宕机」。
第三层：缓存吸收重复请求
很多攻击（尤其是工具化、低成本的请求洪泛）打的是首页、图片、静态资源这类可以缓存的内容。CDN 命中缓存后直接在边缘返回，请求根本不会到达源站。命中率越高，源站承受的放大倍数就越小。这也是为什么「优化缓存」在抗 D 场景下不是性能话题，而是安全问题：一个缓存命中率从 60% 提到 95% 的站点，面对同一波攻击时回源流量可能相差一个数量级。
第四层：源站隐藏与回源收敛
防护的最后一道保险是让源站「不可直连」。源站只接受来自 CDN 回源地址的连接，安全组或防火墙做白名单，其他来源一律拒绝。这样即便攻击者知道你的真实 IP，也无法直接打穿。回源链路本身也要收敛：限制回源并发、设置回源超时、对回源请求做速率控制，避免 CDN 在攻击期间变成一台高效的回源放大器。
上了 CDN 还被打穿，通常是这几个原因
源站真实 IP 泄露
这是最常见也最致命的漏洞。历史 DNS 解析记录、邮件服务器返回头、未被 CDN 代理的子域名、直接通过 IP 访问的旧入口、证书透明日志里暴露的域名、甚至代码仓库中硬编码的配置，都可能把源站 IP 交到攻击者手上。解决办法不是「藏」，而是「换」：更换源站 IP，所有子域名统一走 CDN 代理，源站只放行回源网段，并对源站的直接访问做兜底限速。
回源没有限速，动态接口成了靶心
攻击者并不傻，他们会专门打不可缓存的路径：搜索接口、登录接口、带随机参数的详情页。这些请求 CDN 无法用缓存挡住，如果回源并发没有上限，攻击请求会被原样转发到源站，CDN 反而提高了攻击的投递效率。正确做法是对回源连接数、回源速率设上限，并给源站留出降级空间——比如攻击期间对非核心接口直接返回排队页或静态兜底内容。
缓存规则和业务逻辑打架
把带用户 Cookie 的响应缓存出去，会造成串号；把该缓存的静态资源设成不缓存，则等于自愿放弃防护。比较稳妥的做法是按路径拆分策略：静态资源长缓存并忽略无关查询参数，HTML 短缓存或按需缓存，API 明确不缓存并单独做限速与鉴权。
只防了流量，没防应用层
CC 攻击模拟的是正常请求，握手完整、请求头正常，甚至带着真实的浏览器指纹。这类攻击不会触发流量层的规则，只能靠行为分析：单 IP 与单会话的请求频率、访问路径的连贯性、UA 与指纹的一致性、人机校验与挑战。很多 CDN 产品把这些能力放在 WAF 或 Bot 管理模块里，需要单独开启并调优，默认往往是宽松模式。
CDN 自身也会成为攻击对象和成本来源
把防护交给 CDN，不代表风险转移了，只是风险换了形态。第一种形态是账单：多数 CDN 采用按流量、按请求计费，攻击产生的流量和请求同样会计费。一次持续的大流量攻击，可能让当月账单出现数量级的跳升。选型时要看清计费模式，是否提供攻击期间的流量减免、是否有保底加弹性的阶梯方案、是否对异常流量单独计价，这些条款比「清洗容量」更直接地影响成本。
第二种形态是回源费用。不少服务商对回源流量单独收费，而攻击恰恰会让缓存命中率骤降、回源比例飙升。前面提到的缓存优化和回源限速，在这里同时也是成本控制手段。
第三种形态是误封与共享信誉。使用共享 IP 的边缘节点时，同一 IP 上其他站点的恶意行为可能牵连你的域名信誉；反过来，过于激进的自定义规则也容易把正常用户挡在门外。上线任何拦截规则前，先用观察模式跑一段时间，确认误杀率再转为拦截。
不同攻击类型，CDN 上的应对重点不一样
流量型攻击（L3/L4）
SYN Flood、UDP Flood、ICMP Flood 以及各种反射放大攻击，特征是包量大、协议异常。应对重点是清洗容量和入口分散度，同时确认业务是否真的需要暴露非 HTTP 端口。把源站的非必要端口全部关闭，能直接消灭一大类攻击面。
应用层洪泛（L7）
特征是请求「看起来很正常」，但频率和分布异常。应对重点是分层限速：按 IP、按会话、按 URI、按参数组合分别设阈值；对可疑请求先给挑战而不是直接拒绝；对登录、下单、发短信这类高价值接口单独加验证码和频率锁。这里没有一劳永逸的规则，需要结合访问日志持续调整。
慢速与连接耗尽型攻击
Slowloris 之类的攻击用极慢的请求占住连接池，流量很小但破坏力不弱。应对方式是收紧各类超时（请求头超时、body 读取超时、空闲连接超时），并限制单 IP 的并发连接数。这些参数在 CDN 控制台里通常都有，但默认值偏宽松。
一份可以直接照着做的配置清单
把上面这些落到操作层面，大致是这些动作：源站防火墙只放行 CDN 回源网段，其他一律丢弃；所有子域名统一接入 CDN，清理历史解析记录；按路径拆分缓存策略，静态资源长缓存、动态接口不缓存；为回源设置并发与速率上限；开启边缘速率限制与 Bot 管理，先用观察模式校准阈值；对登录、注册、短信、搜索等接口单独加固；关闭源站不必要的端口与服务；配置流量与回源量的告警阈值，账单异常时能第一时间收到通知；准备一份降级预案，明确攻击期间哪些功能可以先关掉。真正被攻击时，能救命的往往不是某个高级功能，而是这些提前做好的收口动作。
选型时该看什么
市面上的选择不少，思路比品牌更重要。看清洗容量与节点分布是否覆盖你的主要用户区域；看是否支持自定义回源 Host、回源协议和回源白名单；看限速与 WAF 规则能否按路径精细配置，而不是只有全局开关；看日志是否可导出、是否支持实时查询，否则事后无法定位攻击特征；看计费是否透明，攻击流量如何计价；看是否提供 API 化的配置能力，方便把规则纳入版本管理。国际厂商如 Cloudflare、Akamai、AWS Shield 在边缘网络和清洗能力上积累较深；国内场景可以重点评估 阿里云 CDN、腾讯云 CDN 这类同时提供 CDN 与高防产品的服务商，回源链路和备案合规上会更顺一些。
结语：CDN 是纵深防御的一层，不是全部
回到 ddos cdn 这个主题，真正需要建立的认知是：CDN 把攻击的接触面从一台服务器扩展成一张网络，用分布式入口摊薄流量、用缓存吸收重复请求、用边缘规则过滤异常、用回源收敛保护源站。这套机制有效，但它的有效性建立在配置正确的前提上。源站 IP 藏不住、回源不限速、缓存策略混乱，CDN 就只是一层昂贵的代理。反过来，把这些细节做扎实，大部分中小规模的攻击在到达源站之前就已经被消化掉了。
