CDN防御全解析：从流量清洗到边缘WAF的实战思路
源站暴露的那一刻，防护就已经输了一半
很多团队第一次认真研究 CDN 防御，是在源站被打瘫之后。攻击流量的规模未必夸张，问题往往出在结构上：源站 IP 直接暴露在公网，攻击者不需要绕过任何东西，只要把请求对准那一台机器，带宽、连接数、CPU 总有一个先撑不住。更麻烦的是，这类暴露常常不是偶然——早期做邮件服务、测试环境、第三方监控回调时留下的解析记录，都可能成为被扫描到的入口。
CDN 的价值原本就建立在“把用户挡在离源站更远的地方”这个前提上，防御只是把这个前提用得更彻底。当所有流量必须先经过边缘节点，源站才有机会从“必须亲自处理每一个请求”变成“只处理被判定为正常的回源请求”。这个转变听起来简单，实际决定了后面所有防护手段是否成立。源站一旦能被直连，再强的清洗能力也只是绕过去的摆设。
CDN 防御到底在防什么
把 CDN 防御理解成“抗 DDoS”远远不够。它面对的是一组层次不同、手法不同、应对逻辑也不同的威胁，把它们混在一起谈，配置就一定会出错。
以量取胜的流量型攻击
SYN Flood、UDP 反射放大、DNS 与水印类查询滥用，这类攻击的目标不是你的应用，而是链路和网络设备。它们的特征是包量大、单包信息少，用传统防火墙逐条匹配规则几乎没有意义。CDN 的应对方式是把流量分散到大量边缘节点，在靠近攻击源的位置丢弃异常包，只把合法的连接放行回源。真正关键的不是“能扛多少 G”，而是清洗是否在骨干网之外完成——如果攻击流量已经打到源站所在机房的上游，清洗能力再强也救不了那条链路。
伪装成正常用户的 CC 攻击
CC 攻击是 CDN 防御里最考验细节的一类。它不追求带宽，而是用大量看似合规的 HTTP 请求消耗应用资源：反复请求最耗数据库的搜索接口、把分页参数调到极大、或者干脆用慢速连接把工作线程一个个占住。这类请求在四层看起来完全正常，只有把七层的 URL、Header、Cookie、访问频率、会话特征串起来看，才能分辨出异常。所以真正有效的 CC 防护通常不是单一阈值，而是多层策略叠加：频率限制兜底，人机挑战过滤掉脚本，行为指纹识别出同一批工具发起的请求，最后再对可疑来源做降级处理而不是直接拒绝。
针对业务逻辑与应用漏洞的攻击
SQL 注入、XSS、命令执行、恶意文件上传、越权访问，这些属于应用层问题，但边缘节点完全可以提前拦下一部分。把 WAF 规则下沉到 CDN，好处是攻击请求在到达源站之前就被处理掉，源站日志里不会堆满垃圾数据，业务代码也不必为每一个入口重复写校验。代价是误杀风险——规则越严，越容易把正常的富文本提交、含特殊字符的搜索词一起挡掉。
盗链、爬虫与资源滥用
还有一类不爆量却持续失血的威胁：图片和视频被别站直接引用，价格页被竞品高频抓取，接口被第三方工具轮询。它们不属于传统意义上的攻击，但消耗的带宽和计算资源一样真实。CDN 侧可以通过 Referer 白名单、签名 URL、时效性 Token、UA 与行为特征组合识别来处理，既要挡住滥用，又不能误伤搜索引擎抓取和正常分享。
边缘节点凭什么能扛住攻击
任播把攻击面摊薄
任播（Anycast）让同一个 IP 在世界多地同时宣告，用户的请求会被路由到最近的一个节点。对防御来说，这意味着攻击流量也被自然拆散，落在几十上百个节点上，单个节点承受的压力远小于集中打到一处。配合 BGP 层面的黑洞与牵引，大规模流量攻击可以在离源站很远的网络位置被消化掉。
缓存本身就是一层防御
被缓存的内容不需要回源，也就不会消耗源站资源。静态资源命中率高的站点，在遭遇突发流量时天然更从容。反过来，如果把大量动态接口也强行缓存，或者缓存键设计不合理导致命中率极低，CDN 就只是个昂贵的中转站，防御效果大打折扣。做 CDN 防御时先看缓存命中率，往往比先调防护阈值更有用。
边缘 WAF 与规则下沉
把 OWASP 核心规则集、自定义规则、IP 与地域黑白名单放在边缘执行，能让拦截发生在离攻击者最近的一跳。实践中更推荐“观察—灰度和—全量拦截”的路径：新规则先只记录不阻断，确认误杀率可接受后再放开。像 Cloudflare、Akamai 这类厂商在规则运营上积累较深，而 阿里云 CDN、腾讯云 CDN 在国内链路上更贴近本地业务，选择时更该看规则的可控粒度，而不是宣传页上的峰值数字。
行为分析与挑战机制
现代 CDN 防御越来越依赖“让可疑者自证清白”，而不是简单地封 IP。JS 挑战、验证码、Cookie 下发、TLS 指纹与请求头顺序识别，都能在不影响真实用户的前提下拦住大部分脚本工具。这套机制的难点在于策略分级：正常用户不该看到验证码，被误判的移动端网络也不该被反复挑战。分级放行、按路径设置不同强度，比一刀切更实用。
配置层面最容易漏掉的几件事
第一是隐藏源站。接入 CDN 后仍要检查历史 DNS 记录、证书透明度日志、第三方服务的回调地址，把可能泄露源站 IP 的痕迹清理干净；源站安全组只放行 CDN 回源网段，必要时启用私有回源或回源鉴权，让“绕过 CDN 直连”变得不可行。第二是回源带宽与连接数要有上限，否则攻击者一旦找到未被缓存的动态路径，压力会原样传导到源站。第三是把限速做在正确的维度上：按 IP 限速容易被代理池绕过，按会话、按 URL、按用户标识组合限速更稳。第四是保留完整的边缘日志，攻击过后能否复盘、能否提取特征更新规则，全靠这些数据。
几个常见的认知误区
“上了 CDN 就安全了”是最普遍的一个。CDN 提供的是能力和位置，具体挡不挡得住取决于规则怎么配、缓存怎么分、源站怎么收紧。另一个误区是只盯四层防护，把 CC 攻击当成带宽问题处理，结果清洗设备毫无反应，应用却已经排队超时。还有人把防护阈值调得极低以求安心，最后误杀真实用户，转化率下降带来的损失比攻击本身更大。反过来，也有团队把 WAF 设成全放行观察模式后再没回头看，规则形同虚设。
怎么判断防御是否真的有效
看三个指标就够了：源站实际承受的回源请求量与连接数是否可控，攻击期间正常用户的成功率和首字节时间是否稳定，以及误杀率是否在可接受范围内。定期做压测和演练能提前发现问题——很多配置缺陷只有在真实流量冲击下才会暴露。把防护策略当成需要持续运营的东西，而不是一次性的开关，CDN 防御才算真正落了地。
写在最后
CDN 防御的本质，是把“必须由源站亲自面对的一切”尽可能往外推：推到边缘节点、推到缓存层、推到离攻击者最近的那一跳。技术手段并不神秘，难的是把隐藏源站、缓存策略、七层规则、限速分级、日志复盘这几件事串成一套连贯的方案，并且在业务体验和安全强度之间找到那个合适的平衡点。做到这一步，攻击来的时候你才有余裕去看日志，而不是先去重启服务器。
