CDN能防御DDoS吗？原理、能挡住的攻击类型与失效场景全解析
「CDN能防御DDoS吗」这个问题，在运维群里的出场频率大概仅次于「网站为什么又打不开了」。有意思的是，同一个问题往往能听到两种截然相反的答案：有人说自家站点接入CDN之后，几轮攻击下来源站连告警都没响过；也有人抱怨花了不少预算买的加速服务，攻击一来照样502、照样超时，服务商还反过来劝他升级套餐。到底谁说得对？其实两边都没撒谎，只是他们遇到的攻击类型、接入方式和防护配置完全不在一个层面上。
这篇文章不打算给一个「能」或者「不能」的痛快答案，而是把CDN在DDoS防御这件事上到底做了什么、做到什么程度、什么时候会失灵，一层一层拆开讲清楚。看完之后，你应该能判断自己手上的这套CDN配置，究竟是在真防护，还是只在心理上给了你一点安慰。
先说结论：能防，但「能防」和「防得住」是两码事
CDN天生具备一定的DDoS防御能力，这不是因为它被设计成防火墙，而是因为它的工作方式恰好把攻击面切碎了。但它能扛住多少、扛不扛得住你这一波，取决于三个变量：攻击的类型和量级、CDN服务商本身的清洗能力、以及你的源站有没有被正确地藏起来。任何一个环节掉链子，防御效果都会大打折扣。
一、CDN的防御能力，是从「代理」这个身份里长出来的
CDN的本质是一个反向代理。用户访问你的域名时，DNS解析指向的是离他最近的边缘节点，而不是你的机房。所有请求先落到节点上，由节点决定是直接返回缓存内容，还是转发回源站。正是这个「中间人」的身份，让CDN顺带产生了三层防御效果。
第一层是源站IP的隐藏。域名对外只暴露CDN的节点地址，攻击者拿不到你的真实服务器IP，就没法绕过CDN直接打源站。对于那些只会用现成工具扫端口、发流量的低门槛攻击者来说，这一层就已经劝退了大部分人。
第二层是流量的分散。一次攻击打过来，流量会被分摊到几十甚至上百个节点上，单个节点承受的只是其中一小部分。源站看到的回源请求量，往往只是攻击总量里很小的一块。
第三层是缓存的拦截。命中缓存的请求在边缘节点就直接返回了，根本不会触达源站。攻击者反复请求同一张图片、同一个JS文件，对源站来说等于什么都没发生。
除此之外，正规的CDN服务商手里握着大量带宽资源，骨干网层面通常也具备流量清洗能力，能把明显的异常包在边缘丢弃。但这些能力是「顺带」具备的，不是专门为抗攻击设计的，所以它有上限，也有条件。
二、这些攻击，CDN确实能挡住很大一部分
流量型攻击：靠带宽储备和节点分散硬扛
UDP Flood、ICMP Flood、DNS/NTP反射放大这类攻击，特点就是量大管饱，动辄几百G甚至上T的流量砸过来。这类攻击如果直接打到源站，基本只有一条路：机房封IP。而走CDN的话，流量会被分散到各个节点，服务商在骨干层做清洗，把异常包拦在边缘。源站这边往往感知不到任何异常，最多看到回源带宽有一点点波动。
但要清楚一点：节点的带宽是共享的。如果同一节点上的其他客户也在被打，或者攻击量级超过了服务商在该区域的清洗阈值，就可能出现「清洗不过来」的情况。这时候服务商的常见做法是暂时把你的域名解析摘掉，也就是俗称的「黑洞」。网站确实不卡了，因为它直接打不开了。
协议型攻击：把连接终结在边缘
SYN Flood、ACK Flood、连接耗尽这类攻击，打的是服务器的连接表。因为TCP握手是在边缘节点完成的，攻击者耗尽的是节点的连接资源，源站的连接数并不会被撑爆。成熟的CDN节点通常还有专门的抗协议攻击模块，能对半连接、异常标志位做识别和限速。这一层的防御，CDN做得相当扎实。
应用层CC攻击：靠缓存、频控和风控组合出拳
CC攻击模拟的是正常用户请求，流量不大但请求频率极高，专门打动态页面。CDN在这一层能做的事情不少：静态资源长缓存，让攻击请求不产生回源；对同一IP、同一UA、同一设备指纹做频率限制；对可疑请求下发人机校验；配合WAF规则匹配恶意特征。效果好不好，取决于攻击者的模拟精度和你规则的细致程度。粗糙的CC脚本很容易被拦，而高度拟人化的攻击就需要更复杂的策略组合。
三、这些情况，CDN也救不了你
源站IP已经暴露
这是最典型也最常见的事故。攻击者通过历史DNS记录、未被CDN覆盖的子域名、扫描全网IP段、甚至邮件头里的Received字段，都能反查出你的真实服务器地址。一旦源站IP暴露，攻击者直接打源站，CDN在这场攻防里完全缺席。你以为自己有一层防护，实际上对方走的是后门。
应对方式并不复杂但很考验细致程度：更换源站IP、在防火墙上只放行CDN官方公布的回源IP段、逐个检查子域名和邮件服务记录、清理历史解析。任何一处遗漏，前面的工作都白做。
回源链路被打
CDN和源站之间那条链路同样可能成为攻击目标。如果攻击者伪造回源头、或者利用CDN节点作为跳板向源站发起请求，部分清洗规则未必能准确识别，流量还是会灌进源站。这时候可以启用回源鉴权、私有回源、源站白名单之类的机制，把「只接受来自可信节点的请求」这件事落实到协议层。
完全不缓存的动态接口
登录、下单、支付、搜索这类接口，每次请求都必须回源，缓存帮不上忙。攻击者专挑这些路径打，CDN能做的只有限速、验证和拦截，扛不住的那部分量，最终还是要源站自己吃下去。这也是为什么电商、金融类业务在CDN之外，通常还会再叠一层高防或业务风控。
攻击量级超出服务商的清洗上限
每家CDN服务商在不同区域、不同线路上能清洗的带宽都是有数的。攻击量级一旦超过这个阈值，防御就会从「拦截」退化成「丢弃」，再退化成「下线」。所以在选型的时候，别只看宣传页上的节点数量和覆盖国家，要问清楚清洗带宽、清洗触发条件、以及被攻击时会不会单方面停服务。
业务逻辑层面的攻击
慢速攻击、批量注册、薅羊毛、恶意爬虫，这些请求在流量和协议层面全都「正常」，看不出任何攻击特征。CDN的规则引擎很难精准识别，只能靠业务风控和行为分析来兜底。指望CDN解决这类问题，基本是使错了力。
四、想让CDN真正防住，配置上有几件事必须做
同样的CDN服务，配置得好和配置得差，防御效果可能差出几个数量级。下面这几件事，是实际部署中最容易被忽略、又最影响效果的。
彻底隐藏源站。换掉已经暴露的IP，防火墙只允许CDN回源段访问，关掉不需要的端口，检查所有子域名、测试环境、API入口是否都走了CDN。这一条是所有防护的地基，地基没打好，上面修得再漂亮也没用。
把缓存策略做细。静态资源设置长缓存，动态接口明确区分可缓存和不可缓存的部分。动静分离做得越彻底，能被打到源站的请求就越少。
打开CC防护并调好阈值。默认阈值基本是按通用场景设的，套到你的业务上不是太松就是太紧。要结合真实业务的访问曲线去调，既要拦住异常，也别把正常用户误伤。
叠上WAF。CDN解决的是流量和连接层的问题，SQL注入、XSS、恶意爬虫这类应用层攻击，需要WAF规则来补位。两者配合，防护才完整。
保留源站的兜底能力。CDN不是保险箱。源站至少要有基础抗D、限流和快速扩容的预案，避免CDN一失效，源站立刻被压垮。
做好监控和切换预案。回源带宽、5xx比例、节点健康状态都要盯住。一旦出现异常，能快速切到备用线路或者高防清洗，而不是等用户打电话来投诉。
五、CDN、高防IP、云清洗，到底是什么关系
很多人把这三者当成互相替代的方案，其实它们是互补的。CDN负责加速和流量分散，顺便挡掉大部分常见攻击；高防IP负责把大流量牵引到专业清洗中心，过滤后再回源；云清洗则是按需触发的弹性清洗服务，平时不占资源，被打的时候才顶上。
常见的组合是「CDN + 高防源站」，正常访问走CDN加速，攻击量级超出CDN清洗能力时自动切换到高防线路。也可以选择自带清洗能力的CDN产品，比如 Cloudflare 的 DDoS 防护、阿里云 DDoS 高防、Akamai 的 DDoS 缓解方案 等，具体怎么选，还是要看你业务的攻击画像和预算结构。
六、几个常见的认知误区
「上了CDN就等于有了DDoS防护」。不成立。很多普通加速型CDN并不包含清洗能力，被打的时候照样会回源或者直接拒绝服务。买之前一定要确认产品是否包含DDoS防护和CC防护模块。
「节点越多越抗打」。节点数量反映的是覆盖范围，不等于清洗带宽。一个在核心区域有大规模清洗中心的CDN，可能比节点铺得满地都是但清洗能力有限的服务商更抗打。
「缓存全开就万事大吉」。动态业务没法全缓存，强行缓存又会带来数据一致性问题。缓存只是防御的一部分，不是全部。
「攻击结束就没事了」。攻击期间暴露的源站IP、被打满的带宽、被拖垮的数据库，都需要时间恢复。攻击结束后的排查和加固，往往比攻击本身更值得花精力。
结语
回到最初的问题：CDN能防御DDoS吗？答案是能，但它防的是「经过它的流量」，防的是常见类型的攻击，防的是一个有明确上限的量级。它不是一堵墙，而是一张网——网眼有多大、有没有破洞、源站是不是藏在网后面，决定了这张网到底能兜住多少东西。
真正靠得住的防护，从来不是某一个产品单打独斗，而是把源站隐藏、缓存策略、频率控制、WAF规则、高防兜底和监控预案串成一条完整的链路。CDN是这条链路上很重要的一环，但也只是一环。搞清楚它在哪一环、能力边界在哪，比纠结「能不能防」这个问题本身更有价值。
