DDoS攻击近年来呈现出流量越来越大、成本越来越低的趋势，花几十块钱就能在网上买到一次上百G的攻击流量。面对这种威胁，把网站接入CDN是最常见的应对手段之一。但CDN的抗DDoS能力到底有多强，哪些攻击它能扛，哪些它扛不住，很多人并没有清晰的认识。盲目相信CDN的防护能力，或者在配置上留下漏洞导致源站IP暴露，都可能让防护形同虚设。这篇文章就从原理到实践，把CDN抗DDoS这件事彻底讲清楚。
CDN为什么能缓解DDoS攻击：分散与吸收的原理
CDN的核心能力是内容分发，它通过在全球部署大量边缘节点，让用户就近获取内容。这个架构天然具备了对抗DDoS的三个特性。第一是流量分散。攻击流量打向域名时，DNS解析会把流量调度到不同的边缘节点上，攻击压力不会集中落在某一台服务器上，而是被摊薄到几十甚至上百个节点。第二是带宽冗余。大型CDN服务商的骨干网络和边缘节点储备了海量带宽，几百G的攻击流量在其整体带宽池中占比很小，可以被直接吸收掉。第三是缓存卸载。静态内容命中缓存后，请求根本不会回源，即使攻击者发送海量请求，只要大部分被缓存拦截在边缘，源站依然可以安然无恙。
除了架构层面的天然优势，主流CDN厂商还在边缘节点上叠加了专门的防护能力。比如基于特征 signature 的过滤规则，可以识别SYN Flood、UDP反射攻击等常见攻击向量；基于行为分析的速率限制，可以识别高频请求的异常客户端；还有针对HTTP层的CC攻击识别，通过检测请求频率、请求头特征、Cookie校验等手段区分真人和机器。
举个典型场景：一个网站平时带宽100Mbps，遭受5Gbps的流量攻击时如果直连源站，线路必然被打满。但如果套上了CDN，攻击流量先到达CDN边缘节点，节点带宽动辄几十G，5G的攻击在边缘就被消化掉了，源站真实带宽完全不受影响。这就是CDN抗DDoS最直观的价值。
CDN能扛什么攻击，扛不住什么攻击
DDoS攻击大致可以分为三类：网络层攻击（SYN Flood、UDP反射放大、ICMP Flood等）、传输层攻击（TCP连接耗尽）和应用层攻击（HTTP Flood、CC攻击、慢速攻击等）。CDN对这三类的防御效果差异很大。
对于网络层的大流量攻击，CDN的吸收能力最强。因为这类攻击就是拼带宽和资源，CDN的分布式架构恰好是带宽堆积的最佳载体。只要攻击流量没有超过CDN服务商承诺的防护阈值，源站基本无感。需要注意的是，几乎所有CDN厂商对免费或基础套餐用户的防护上限都很低，可能只有几个G，超出部分要么直接把域名下线，要么放行攻击，这一点在选购时务必看清条款。
对于应用层的CC攻击，CDN的能力取决于其防护引擎的智能程度。简单的HTTP Flood可以通过JS挑战、人机验证、速率限制来挡住。但慢速攻击（如Slowloris，攻击者建立连接后缓慢发送不完整的请求，长期占用连接资源）对CDN就比较棘手，因为它模拟的是慢速用户的正常行为，特征不明显。此外，如果攻击者构造的请求全部绕过缓存直接回源，CDN反而会把攻击流量忠实地转发给源站，形成放大通道。
最危险的情况是源站IP直接暴露。CDN防护有一个根本前提：攻击流量必须先经过CDN才能被拦截。一旦攻击者拿到了源站真实IP，就可以直接对源站发起攻击，CDN的所有防护形同虚设。历史解析记录、子域名泄露、邮件服务器头信息、SSL证书查询等都是常见的源站IP暴露途径，后文会讲如何防范。
CDN防护与专业高防的对比：什么时候CDN不够用
CDN的抗DDoS能力是架构的副产品，而专业的高防IP或高防服务器是专门为抗攻击设计的。两者的差异体现在几个方面。防护容量上，普通CDN的单节点防护能力有限，遇到超大流量攻击时CDN可能会直接把你的域名调度下线以保护其他客户，而高防服务的清洗中心专门设计来承接T级攻击。防护深度上，高防服务通常提供可定制的清洗策略、七层防护规则、甚至人工值守，CDN的防护策略则相对标准化。成本模型上，CDN按流量或带宽计费，遭遇攻击时产生的额外流量费用可能非常惊人，有的用户一次攻击就收到了天价账单；高防服务按防护能力包月计费，成本更可控。
比较合理的实践是分层组合：网站先接入CDN做日常加速和第一层防护，同时配置好回源到高防IP或云防火墙，形成CDN挡应用层攻击、高防挡网络层大流量的纵深防御。对于游戏、金融等持续遭受攻击的行业，这种组合几乎是标配。
另外要提醒一点，不要把CDN当成万能盾。如果你的业务是长连接（如WebSocket推送、游戏对战），很多CDN对这类协议的支持和防护都很弱，攻击者只需打瘫长连接服务即可，此时应该考虑专门的防护方案。
实战配置要点：让CDN防护真正生效
很多攻击绕过CDN得手，不是因为CDN不行，而是配置有漏洞。以下几个要点需要逐一落实。
第一，隐藏源站IP。接入CDN前，先用新的IP部署源站，避免历史DNS解析记录泄露旧IP。检查所有子域名是否都套了CDN，任何一个直连的子域名都可能泄露源站。服务器上不要用源站IP直接对外提供Web服务，可以用防火墙限制只允许CDN的回源网段访问，配置示例如下：
# iptables 只允许CDN回源网段访问80端口 iptables -A INPUT -p tcp --dport 80 -s 203.0.113.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j DROP # 同时屏蔽常见探测手段 iptables -A INPUT -p icmp --icmp-type timestamp-request -j DROP
这样即使攻击者知道了源站IP，直接打过来的流量也会被防火墙丢弃。第二，不要在服务器上用源站IP发送邮件，邮件头会暴露发件IP；网站源码里也不要写死包含源站IP的接口地址。第三，在CDN控制台开启全站HTTPS，避免攻击者通过HTTP明文回源探测；开启HSTS防止协议降级。
第四，优化缓存策略，尽量提高缓存命中率。静态资源设置较长的缓存时间，动态接口做好分类，能缓存的尽量缓存。命中率越高，回源流量越少，CC攻击打到源站的压力就越小。第五，配置速率限制和CC防护规则，对单IP的高频请求触发验证码挑战，对异常User-Agent直接拦截。最后，务必开启CDN的回源保护或设置回源鉴权，防止攻击者拿到回源地址后绕过CDN直接请求。
总结：理性看待CDN的抗DDoS能力
CDN确实具备实用的抗DDoS能力，尤其对中小规模的流量型攻击和常见的CC攻击，性价比远高于自建防护。但它的防护边界也很明确：防护阈值受套餐限制、对长连接和慢速攻击支持弱、一旦源站IP暴露就全面失效。正确的做法是把CDN当作纵深防御的第一层，配合源站防火墙、高防服务组成完整体系，同时在配置上不留死角。安全从来不是买一个产品就能一劳永逸的事情，理解原理、持续检查，才能在真正的攻击到来时立于不败之地。