CDN 如何防御 DDoS 攻击：原理、实践与常见误区

很多站长第一次接触 DDoS，是在网站突然打不开的那天。监控面板上流量曲线笔直冲向天花板，服务器 CPU 和带宽双双打满，重启、加配置全都无济于事。这时候去问解决办法，十有八九会听到同一个答案：上 CDN。但 CDN 究竟凭什么能挡住攻击？它在哪些场景下有效、哪些场景下形同虚设？如果只把「套个 CDN」当成万能药，往往会在真正的攻击面前吃大亏。

一、先看清 DDoS 攻击到底在打什么

DDoS 的本质是让目标资源被无效请求耗尽。攻击者并不需要攻破你的程序，只要让你的带宽、连接数、CPU 或者数据库连接池先撑不住就够了。按攻击层次拆开，大致可以分成三类。

流量型攻击

UDP Flood、ICMP Flood、DNS 反射、NTP 反射、Memcached 反射等都属于这一类。特点是包大、量大，目标是把出口带宽灌满。反射放大的可怕之处在于攻击者可以伪造源 IP，用小流量撬动几十倍甚至上千倍的响应流量，受害者看到的全是来自四面八方的「正常」回包，追查极其困难。

协议型攻击

典型代表是 SYN Flood，以及各种畸形包、连接耗尽型攻击。攻击者不完全建立三次握手，把服务器的半连接队列占满，导致真正的用户连不进来。这类攻击的流量未必很大，但对防火墙和内核参数的考验很直接。

应用层攻击

CC 攻击、慢速连接攻击、高频接口请求都属于这个范畴。它们模拟真实用户行为，握手完整、请求合法，只是一秒钟来几十万次。这类攻击最难识别，因为从单个请求看几乎挑不出毛病，防不住的话数据库和 PHP/Java 进程会被瞬间拖垮。

理解了这三层，才能理解 CDN 的作用边界：它在流量层和协议层能承担相当大的压力，在应用层则需要配合行为分析和策略规则，而最终决定成败的，往往是源站本身是否足够「抗揍」。

二、CDN 防御 DDoS 的底层逻辑

分布式节点天然分摊流量

CDN 的核心资产是遍布各地的边缘节点。用户访问域名时，DNS 会把它解析到离得最近、状态最好的节点，请求先在边缘被处理。攻击流量同样遵循这个规则，会被拆散到大量节点上。单点承受的攻击，被一张网络稀释之后，往往就落在每个节点的清洗能力之内。攻击者要打瘫整个 CDN 网络，需要的量级和打瘫一台源站完全不是一个概念。

Anycast 与就近接入

不少 CDN 服务商使用 Anycast 技术，让同一个 IP 在全球多地同时宣告。攻击流量会被路由协议自动分散到最近的多个清洗中心，而不是全部涌向某一个点。这相当于在运营商层面就完成了一次天然的分流，对突发的大流量攻击尤其有效。

源站隐藏是最容易被忽视的价值

很多攻击之所以致命，是因为源站 IP 早就泄露了——可能来自历史 DNS 记录、邮件头、子域名、第三方扫描，甚至 SSL 证书的透明日志。接入 CDN 后，域名对外解析的是节点 IP，源站只接受来自 CDN 回源节点的连接。攻击者找不到真实 IP，再大的流量也只能打在 CDN 节点上，而那里有清洗设备和带宽储备。这一点，比任何单点的防护设备都更根本。

缓存减负与动静分离

图片、CSS、JS、视频切片这些静态资源命中缓存后，请求根本不会回到源站。攻击者反复请求同一个静态 URL，消耗的是 CDN 的缓存带宽，源站几乎无感。合理设置缓存规则、把可静态化的接口结果也缓存起来，等于把源站的抗压能力放大了一个数量级。

边缘清洗与 WAF 联动

流量到达边缘节点后，会经过一层层的检测：异常包过滤、连接数限制、频率控制、指纹识别、人机校验、规则匹配。对 CC 攻击，常见做法是对可疑 IP 下发 JavaScript 挑战或验证码，正常浏览器能自动通过，脚本则被拦在门外。这些能力叠加起来，构成了 CDN 的「清洗」环节。

三、不同攻击在 CDN 上的应对方式

SYN Flood 与连接层攻击

边缘节点通常部署了 SYN Cookie 等机制，在没有完成握手前不占用完整的连接资源。攻击包在节点就被丢弃，源站的半连接队列几乎不会被触碰。这也是为什么开启了 CDN 之后，很多站长发现服务器上的连接数异常消失了。

UDP 反射放大

这类攻击的目标通常是带宽。CDN 服务商会在骨干网入口做流量牵引，把可疑流量导入清洗中心，按协议特征丢弃伪造包。需要注意的是，如果你的业务本身依赖非标准 UDP 端口（比如游戏、音视频私有协议），要先确认服务商是否支持这些端口的防护，否则可能连正常业务一起被拦。

CC 攻击与爬虫

这是最考验策略的一类。有效的做法是组合拳：对登录、搜索、下单这类动态接口做频率限制；对可疑 UA 和空 Referer 的请求提高验证等级；对短时间内大量访问同一路径的 IP 段做封禁；同时把页面中可以直接缓存的片段尽量缓存，减少回源次数。有条件的话，接入具备行为分析能力的 WAF，比单纯堆规则更省心。

慢速攻击

Slowloris 之类的攻击通过极慢的请求拖住连接。CDN 节点一般会设置连接超时和最小传输速率，异常慢的连接会被主动断开，源站不必为此长期占用工作进程。

四、部署时的几个关键配置

同样是接 CDN，配置得当和配置随意，防护效果可能差出好几倍。

• 回源保护：源站防火墙只放行 CDN 回源节点的 IP 段，其余一律拒绝。有条件时使用回源鉴权或私有协议，避免有人绕过 CDN 直连源站。
• 更换源站 IP：接入前被攻击过的站，建议直接换一个干净的 IP，并清理历史解析记录，否则隐藏源站只是心理安慰。
• 获取真实访客 IP：通过 X-Forwarded-For 或服务商提供的真实 IP 头还原客户端地址，否则日志里全是节点 IP，封禁和统计都会失真。
• 缓存规则要区分场景：静态资源长缓存，动态接口不缓存或短缓存，带用户信息的响应务必设置为不缓存，避免 A 用户看到 B 用户的数据。
• 限速与并发控制：针对单 IP 的请求频率、并发连接数设置阈值，宁可误伤少量异常用户，也别让源站被打穿。
• 灰度切换：先把图片或某个子域名切到 CDN，观察回源率和命中率，再逐步扩大范围，避免一次性切换带来的排障困难。

五、CDN 不是万能的：几个常见误区

误区一：套了 CDN 就万事大吉。大部分 CDN 的防护能力有套餐上限，超大流量的持续攻击仍然可能触发服务商的封禁或清洗策略调整。而且一旦源站 IP 泄露，攻击者完全可以绕开 CDN 直打源站，这时候 CDN 一点忙都帮不上。

误区二：所有业务都能靠 CDN 兜底。非 HTTP/HTTPS 协议、自定义端口的服务、需要长连接的实时通讯，往往不能直接用普通 CDN 承接，需要专门的加速或高防产品。

误区三：防护越严越好。过于激进的频率限制和验证策略会误杀正常用户，尤其是移动网络下大量用户共享出口 IP 的场景，一封就是一片。策略需要根据业务日志持续调优，而不是一次设置完就放着不管。

误区四：忽视源站本身的安全。CDN 只挡住网络层和应用层的异常流量，挡不住代码漏洞、弱口令、数据库被拖库。源站的补丁、权限、备份，仍然是最后一道防线。

六、CDN 与高防服务器如何配合

成熟的架构通常不是单点依赖，而是分层。第一层是 CDN，负责分发、缓存、隐藏源站和吸收大部分流量型攻击；第二层是高防 IP 或高防服务器，作为回源入口，在 CDN 被绕过或攻击超出 CDN 承载能力时接住流量；第三层是源站自身的加固，包括系统参数调优、连接数限制、应用层限流和数据库保护。

这样设计的好处是成本可控：CDN 的带宽单价低、节点多，适合扛量；高防资源的保底带宽贵，但清洗能力强，放在关键位置作为兜底。只买高防不用 CDN，日常正常流量也得走清洗设备，成本高且体验差；只用 CDN 不设高防，一旦被打穿就毫无退路。

在选择服务商时，可以对比几家主流方案的能力边界。国际上 Cloudflare 的免费与按量套餐对中小站点比较友好，Akamai 在大流量清洗和企业级 SLA 上有优势；国内则常见 阿里云、腾讯云等厂商的 CDN 加高防组合，节点覆盖和备案合规上更贴合本地业务。选型时重点看三件事：节点与清洗中心的分布是否覆盖你的主要用户群，清洗能力是否有明确的保底与弹性说明，以及是否提供足够细的攻击日志和报表。

七、怎么验证防护是否真的生效

配置完成后不要等攻击来了才验证。可以在低峰期做小流量压测，观察回源率、响应时间和节点命中情况；查看 CDN 控制台的攻击报表，确认清洗事件是否被正确记录；用第三方拨测工具从多地访问，确认解析结果落在预期节点。同时把源站防火墙规则、回源 IP 白名单、真实 IP 还原这几项逐条核对一遍，这些细节往往决定了攻击真正到来时的表现。

另外，把应急流程写下来：谁负责切换解析、什么条件下启用高防、如何判断是误杀还是真攻击、回滚步骤是什么。攻击发生时人是慌的，事先有一份清单，比临场讨论有效得多。

结语

CDN 防御 DDoS 的价值，不在于某一个神奇的功能，而在于它把「单点承受」变成了「网络分摊」，把暴露在公网上的源站藏到了层层节点之后。理解它的分摊、隐藏、清洗和缓存四条主线，再根据自身业务补齐高防兜底与源站加固，才能搭出一套真正扛得住打的架构。防护从来不是买一个产品就结束的事，它更像是一种持续的运维习惯。