CDN防DDoS安全配置实战教程：从接入到策略落地
为什么单靠源站扛不住 DDoS：先把痛点看明白
很多站长第一次遭遇攻击时，反应都是"服务器配置不低，应该没事"。等到监控面板上流量曲线拉成一条竖线，才意识到问题的严重性：带宽被灌满、CPU 跑到 100%、数据库连接数爆掉，正常用户连首页都打不开，而攻击流量往往只有几十 Gbps，却足以让一台中小型服务器彻底瘫痪。
更麻烦的是，攻击者盯上的通常不是你的服务器本身，而是你暴露在公网上的那个真实 IP。只要这个 IP 被扫出来，后面就是无休止的 SYN Flood、UDP 反射、HTTP 洪水以及针对接口的 CC 攻击。CDN 的价值恰恰在这里：它把用户请求先引到分布式的边缘节点上，让源站 IP 从公网视野里消失，同时在边缘完成一轮流量清洗和请求过滤。换句话说，CDN 不只是一个加速工具，它本身就是第一道安全防线。
不过，CDN 默认开启并不等于安全配置到位。很多站点接入了 CDN，源站 IP 却依然能被直连，防护规则全是默认值，缓存策略也没调过。这篇文章就把「CDN 防 DDoS 安全配置」这件事拆成可执行的步骤，一步步带你把它配好。
动手前的准备工作与前置条件
配置之前，有几件事必须先确认，否则后面的步骤很容易白做。
- 域名与解析权限：你需要拿到域名所在的 DNS 管理后台权限，因为接入 CDN 通常要添加 CNAME 记录。如果域名托管在第三方，提前确认能改解析。
- 已备案的域名与可用的 CDN 账号：国内节点通常要求域名完成备案，海外业务可以直接用国际节点。
- 源站的完整信息：回源 IP、回源端口、回源协议（HTTP 还是 HTTPS）、是否需要带 Host 头，这些都记清楚。
- 源站防火墙的控制权：不管是云安全组、iptables 还是主机防火墙，你都要能改规则，因为后面要把源站锁成"只允许 CDN 回源"。
- 一份业务流量基线：记录正常情况下的 QPS、带宽峰值、主要接口的响应时间。没有基线，你就无法判断告警是不是误报。
- 回滚方案：DNS 解析改回源站、关闭某条防护规则的操作路径，提前写下来。
分步骤操作指南
第一步：接入 CDN，让源站从公网上"隐身"
在 CDN 控制台添加加速域名，填写源站地址，选择回源协议和端口，然后按提示到 DNS 服务商处添加 CNAME 记录。这一步本身不难，真正的关键是隐藏源站 IP。只要有人能通过历史 DNS 记录、扫描工具或者邮件头拿到你的真实 IP，CDN 就成了摆设，攻击者完全可以绕过节点直接打源站。
所以接入之后，尽量把源站迁移到新的 IP，或者在源站前再套一层高防 IP。域名解析只保留指向 CDN 的 CNAME，不要留任何 A 记录直连源站。
第二步：把源站锁死，只放行 CDN 回源
这一步最容易被忽略，却最能救命。CDN 服务商一般会公布回源节点网段，你需要在源站防火墙上只放行这些网段，其余一律拒绝。以 iptables 为例，思路大致是这样：
# 只允许 CDN 回源网段访问 443 端口
iptables -A INPUT -p tcp --dport 443 -s 198.51.100.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP
云服务器上更推荐用安全组来实现，规则更直观，也方便后续维护。配置完成后，用一台不在白名单里的机器直接访问源站 IP，如果连不上，说明隔离生效了。
有些业务需要保留直连入口，比如后台管理系统或运维通道。这类入口建议单独绑一个域名，不要和面向公众的业务共用源站端口，更不要把后台放在和主站同一台机器上暴露。
第三步：开启 DDoS 清洗与 CC 防护
主流 CDN 控制台里通常有两类开关：一类是流量型的 DDoS 防护（应对 SYN Flood、UDP Flood、DNS 放大等），另一类是应用层的 CC 防护（应对高频 HTTP 请求）。前者一般只需要选择防护等级和清洗阈值，后者需要你配置得更细。
CC 防护的核心是判断"什么算异常"。可以按下面几个维度组合：
- 单 IP 在单位时间内的请求数阈值；
- 单 URL 的访问频率阈值；
- 请求特征，比如是否携带正常的 Referer、User-Agent、Cookie；
- 是否存在高频访问同一接口、且参数高度相似的行为。
阈值设置不能凭感觉。先看流量基线，把阈值放在正常峰值的三到五倍，再逐步收紧。如果一上来就设得很严，结果往往是正常用户被挡在门外，攻击者反而没受多大影响。
第四步：用 WAF 规则拦住应用层攻击
DDoS 只是敲门砖，很多攻击者的真实目的是拿数据或者植入后门。CDN 自带的 WAF 通常能覆盖 OWASP 常见威胁，比如 SQL 注入、跨站脚本、命令执行、恶意文件上传等。配置时建议开启"观察模式"先跑一段时间，看日志里哪些请求被标记，确认没有误伤后再切换成拦截模式。
同时可以加上几类自定义规则：
- 屏蔽空 User-Agent 或明显伪造的 UA；
- 拒绝来自高风险地区或非业务覆盖地区的访问；
- 对管理后台路径、接口路径设置更严格的访问控制；
- 对上传接口限制文件类型与大小。
第五步：精细化频率限制与人机校验
频率限制是性价比最高的一招。对登录、注册、短信验证码、订单提交这类敏感接口，单独设置更低的频率阈值，并叠加人机校验（滑块、验证码、JS 挑战）。正常用户几乎无感，脚本化的攻击流量却会被大量消耗在验证环节上。
需要注意的是，验证策略要分级。全部请求都弹验证码，用户体验会很差；更好的做法是"平时宽松，触发阈值后升级校验"，让大部分真实用户走无感通道。
第六步：把缓存策略调对，减少回源压力
缓存配置看着像性能问题，其实直接影响抗攻击能力。静态资源（图片、CSS、JS、字体、视频切片）缓存时间可以设得长一些，命中率越高，回源请求越少，源站在攻击期间就越轻松。动态接口则要谨慎，带用户身份的响应绝对不能缓存，否则会出现串号这类严重问题。
建议按后缀和目录分别设置缓存规则，并在源站响应头里显式声明 Cache-Control。同时开启缓存预热和忽略 URL 参数缓存（如果参数不影响内容），能进一步提升命中率。
第七步：回源鉴权与端口收敛
为了确认请求确实来自 CDN 节点，而不是有人伪造回源，建议开启回源鉴权。常见做法是 CDN 回源时带上一个自定义请求头或签名串，源站校验通过才返回内容。Nginx 里可以这样简单判断：
if ($http_x_cdn_token != "your-secret-token") {
return 403;
}
同时把源站对外开放的端口收敛到最少，只保留回源必需的 80/443，数据库、Redis、管理端口一律不对外暴露。端口越少，攻击面越小。
第八步：监控、告警与应急预案
配置完成不代表万事大吉。至少要把这几项接入告警：带宽突增、QPS 异常、回源失败率上升、5xx 错误率上升、CDN 节点命中率骤降。告警要能在几分钟内推送到手机上。
再准备一份应急预案，写清楚：攻击发生时先看哪几个指标、什么情况下降防护等级、什么情况下切换备用源站或开启高防 IP、联系服务商的安全支持通道。真出事的时候，照着单子做远比现场拍脑袋靠谱。
常见问题与避坑提示
- 只接 CDN 不改防火墙：最常见的问题。源站 IP 仍可直连，攻击者绕开 CDN 直打源站，防护形同虚设。
- 阈值一刀切设太严：误封正常用户、影响搜索引擎抓取，反而造成业务损失。建议先在观察模式跑数据，再逐步收紧。
- 缓存规则过于激进：把带登录态的接口也缓存了，导致用户看到别人的数据，属于严重的安全与合规事故。
- 忽略回源带宽：CDN 挡住的是入站攻击流量，但回源流量依然会打到源站。缓存命中率和源站带宽要一起看。
- HTTPS 配置不完整：回源证书过期、SNI 不匹配会让回源失败，防护规则再强也没用。证书到期提醒要提前设好。
- 日志不看：CDN 提供的访问日志和攻击报表是优化规则的第一手资料，定期分析才能发现慢速攻击、爬虫这类隐蔽威胁。
- 忘记应对慢速攻击：Slowloris 之类的低速攻击不会触发流量告警，需要靠连接数限制和超时设置来应对。
总结
CDN 防 DDoS 安全配置可以归纳成三层：最外层靠 DNS 和 CDN 节点引流清洗，中间层靠 WAF、频率限制和人机校验过滤恶意请求，最内层靠源站防火墙、回源鉴权和端口收敛兜底。三层缺一层，防护就有缺口。
配置的过程不必一步到位。先把"隐藏源站 IP + 源站只放行 CDN 回源"这两件事做到位，就能挡掉相当一部分攻击；再逐步补上清洗、WAF、缓存和监控，防护能力会稳步提升。真正有效的安全配置从来不是买一个开关，而是持续观察流量、调整规则、复盘事件的过程。