前两周一个做电商的站长朋友半夜给我打电话说网站被打了后台登录都进不去CPU 直接 100%数据库连接数飙到几千用户下单全失败。我第一反应就是让他赶紧把域名切到高防 CDN 上半小时后网站恢复第二天再看攻击报表峰值流量到了 80Gbps。这就是我今天想聊的主题网站频繁遭遇 DDoS 攻击时高防 CDN 到底是怎么快速响应的以及在实际接入和排障过程中有哪些不踩不行、踩了要命的细节。这个话题不只是给运维看的。如果你自己运营网站、接外包项目、管理小程序商城或者只是好奇 CDN 原理和 DDoS 检测是怎么回事这篇文章都能帮上忙。我会用一个草根站长的真实视角把 DDoS 攻击的常见形态、高防 CDN 的核心原理、从被攻击到恢复的完整实操过程以及我踩过的坑全部拆开来讲清楚。1. 先说清楚你被打的到底是什么1.1 DDoS 攻击的本质把“正常请求”变成“垃圾洪流”DDoS 的全称是 Distributed Denial of Service分布式拒绝服务。可以把它理解成有人雇了几百辆大卡车同时堵在你店门口不让你店里的真实顾客进门。每辆卡车看起来都合法都有车牌号交警也没法轻易说它违规但合在一起你的店就瘫痪了。具体到技术上DDoS 攻击其实是一个大类下面分好几个流派流量型攻击典型的是 UDP Flood、ICMP Flood攻击者发送大量无意义的 UDP 包或 ICMP 包目的就是打满你的带宽。带宽一旦占满正常用户的请求就进不来了表现是网站极慢或者直接超时。连接型攻击典型的是 SYN Flood攻击者伪造大量源地址发送 TCP 三次握手的第一次握手包然后不完成后续握手让服务器一直维护半开连接把连接表耗尽。就像有人不断进店但就是不购物也不走把店里的座位全部占满。应用层攻击典型的是 HTTP Flood也叫 CC 攻击攻击者模拟真实浏览器行为不断请求动态接口或者消耗资源的页面比如登录接口、搜索接口让 CPU 和数据库被打满。这类攻击最难防御因为请求完全合法只是频率异常。很多站点跑的慢其实不是带宽不够而是被这类攻击打死了应用进程。从实际观察来看现在的攻击很少是单一类型基本都是混合打法前几分钟用大流量压带宽发现压不死就换成 SYN Flood 打连接再不行就上 CC 精确打击某个接口。所以防御方案必须能同时处理多层问题只靠防火墙的简单封 IP 根本不够。1.2 为什么普通服务器这么容易被打挂很多第一次被攻击的站长最不理解的一点是我的服务器配置不低啊16 核 32G 内存怎么几百兆流量就挂了原因在于服务器扛不住攻击瓶颈往往不在硬件算力而在网络链路的三个薄弱点带宽上限国内普通云服务器默认带宽一般是 5Mbps 到 100Mbps。攻击流量达到 1Gbps 时运营商接入层面已经把你限速或将你黑洞了你机器配置再高也白搭。TCP 协议栈内核维护的连接表有上限半连接队列SYN Queue和全连接队列Accept Queue一旦塞满新连接一律拒绝。这是操作系统层面的限制靠加内存也解决不了。应用处理能力CPU 能处理的请求数是固定的一旦攻击请求把 CPU 占满正常请求排队时间会指数级增长。数据库连接数、PHP-FPM 进程数、Redis 连接数都会被瞬间耗尽。所以如果你只把服务器从 4 核升到 16 核或者把带宽从 10M 升到 100M大概率还是扛不住。因为攻击成本太低攻击者只需要不断加码而你的升级成本太高而且永远追不上。这也是为什么必须把防护力量前置到网络边缘而不是在源站硬撑。1.3 被攻击时有哪些信号如何快速判断DDoS 攻击很多时候不是从攻击者宣布“我要打你了”开始的而是从网站异常开始的。根据我的经验出现下面这几种情况基本可以判断是正在被打网站突然大面积变慢Ping 延迟正常但页面加载极慢或者直接 502/504。服务器监控里带宽、CPU、连接数三个指标同时爆表。如果是业务正常增长一般不会三个一起飙高。日志里出现大量相同 User-Agent、相同请求路径或者大量来自相近 IP 段的请求。连接数异常ss -s里能看到大量 SYN_RECV 状态连接。这是 SYN Flood 的典型特征。网站在搜索引擎收录正常但用户直接访问时经常打不开这种情况多半是被流量型攻击打到了接入层。当这些信号出现时第一步不是查代码、查数据库而是先看网络层指标。如果带宽和连接数同时异常那基本就是攻击没跑了要立刻启动防护预案。2. 高防 CDN 为什么能扛住响应机制拆解2.1 CDN 原理把站点“复制”到离用户更近的地方先温习一下 CDN 原理。CDN 的核心逻辑是内容分发也就是把静态资源图片、CSS、JS、视频等提前缓存到分布在全国乃至全球的边缘节点上。用户访问时DNS 解析会把请求引到距离自己最近的节点节点直接返回缓存内容不回源站。用传统 CDN网站本身就变快了不少因为大量静态请求在边缘就被消化了。但这只是 CDN 的“表面功能”它的架构其实天然带有 DDoS 防护能力。高度分散的节点意味着攻击流量被稀释到了整个网络上任何一个单点被打流量会被调度到其他节点不会导致全网瘫痪。这也是为什么具有 Anycast 网络架构的高防 CDN 能扛住超大流量攻击。Anycast 说白了就是多个节点广播同一个 IP攻击流量进入网络后会被路由到就近或最优的节点。流量分散到几百台机器上单机的压力就小得多。2.2 核心能力一大带宽清洗把垃圾流量挡在源头高防 CDN 与普通 CDN 最大的区别是具备流量清洗能力。这个清洗过程可以类比为机场安检所有行李先过安检机可疑物品被拦下来正常的行李才送到飞机上源站。具体来说高防 CDN 的流量清洗中心会实时分析进入节点的流量特征包括每秒请求数QPS、每秒新建连接数、流量带宽、数据包特征等。一旦发现某个维度的指标超过阈值就会触发清洗策略从流量中过滤掉异常数据包只把合法请求转发给源站。清洗的粒度比很多人想象的要细致得多常见的手法包括IP 信誉库拦截识别出历史上参与过攻击的 IP直接在网络入口丢弃。协议栈校验对 TCP 连接做代理验证确认是完整的三次握手才放行能有效拦截 SYN Flood。行为分析同一 IP 高频请求、请求规律像机器、User-Agent 异常会被判定为威胁并执行封禁。指纹识别分析客户端 SSL/TLS 指纹、HTTP 头顺序等识别出与正常浏览器差异较大的请求。2.3 核心能力二边缘节点分担源站压力骤减高防 CDN 降低源站压力的逻辑我之前用了快递网点来类比平时你的快递请求都直接送到总部源站总部就很容易忙不过来现在在全国各地建了很多网点边缘节点大部分快件在网点就直接签收了只有少部分需要特殊处理的才送到总部。对应到技术上静态资源天然适合在边缘节点缓存命中率能做到 80% 以上。用户请求图片、JS、CSS边缘节点直接返回缓存连源站的带宽都不占。动态请求虽然没有缓存但也经过了 CDN 节点的代理和过滤攻击流量在节点层就被识别和拦截了能到达源站的一定是相对干净的流量。我在实战中见过一个极端案例某商城被打了三天攻击总流量接近 2Tbps但由于静态资源命中率在 90% 以上源站的带宽峰值只有 30Mbps服务器心情毫无波动。这就是高防 CDN 的价值不是让你的服务器变强而是让攻击流量根本到达不了你的服务器。2.4 高防 CDN 与普通 CDN 的差异一表看懂对比维度普通 CDN高防 CDN基础加速有静态资源缓存分发有同时包含静态和动态加速单点防护带宽通常不承诺或只有几 Gbps 的缓解主流高防产品承诺 300Gbps 甚至 1Tbps 以上流量清洗能力仅做基础速率限制具备协议栈校验、行为分析、指纹识别等完整清洗链路源站保护机制不提供或很弱支持源站 IP 隐藏、回源白名单、回源鉴权应用层防护基础 WAF 规则内置 WAF 规则 自定义防护策略可精确阻断 CC 攻击调度能力就近返回Anycast 网络攻击流量自动分散到多节点从这个对比能看出来如果你的站点只是访问慢那普通 CDN 就够用了但如果你面对的是“网站频繁遭遇 DDoS 攻击”这样的问题高防 CDN 就不是可选项而是必须项。因为它的架构天生就是为了“让攻击流量打不到源站”设计的。3. 从被攻击到恢复一次完整的接入与响应实操3.1 接入前准备先保住源站再谈优化如果你现在正在被攻击或者刚被攻击完想上高防 CDN先别急着解析 CNAME按照下面几步来做准备能少走很多弯路。第一步确认源站 IP 是否已经暴露。如果你的域名直接 A 记录解析到源站 IP或者通过历史 DNS 记录可以查到源站 IP那攻击者依然可以绕过 CDN 直接进行源站 IP 与服务器的心跳检测。DNS 旁路攻击也需要纳入防护预案源站没有真实业务流量的时候要限制响应。在接入高防 CDN 后建议把源站服务器的安全组/防火墙设置为只允许 CDN 回源 IP 段访问 80/443 端口其他 IP 一律拒绝。这个操作非常关键相当于把源站藏起来了。第二步备份当前的 DNS 配置和 HTTPS 证书。在云解析控制台把当前解析记录全部截图或导出。证书方面如果用的是免费证书直接重新申请并上传到 CDN 控制台如果是企业证书需要提前准备证书文件和私钥文件。不要等到切换时才发现证书找不到了那会耽误大量时间。第三步降低 DNS 解析记录的 TTL。提前把域名解析记录的 TTL 从默认的 600 秒或 3600 秒降到 60 秒。这样在真正切换 CNAME 时全球 DNS 缓存刷新速度会快很多能缩短迁移窗口期。这一步要提前至少 24 小时做给旧记录足够的扩散时间。3.2 正式切换CNAME 接入与 HTTPS 配置登录高防 CDN 控制台添加域名填写源站地址。这里有一个细节源站地址有两种填法一种是填 IP推荐回源效率高一种是填源站域名适合源站本身也做负载均衡的情况。需要注意如果填源站域名这个域名不能和被防护的域名相同否则会形成解析死循环。添加完域名后CDN 服务商会分配一个 CNAME 地址。你需要回到 DNS 服务商处把原来指向源站 IP 的 A 记录删除或修改为 CNAME 记录指向这个 CNAME 地址。接下来配置 HTTPS。在控制台上传 SSL 证书开启 HTTPS 访问同时建议开启“强制 HTTPS”避免用户通过 HTTP 访问时被劫持。这里面有个坑证书配置后不是即刻生效一般有 10-30 分钟的部署时间。如果你被攻击的现场还没解除配置完成后可以先用curl -v https://域名验证证书是否正常。3.3 关键参数配置防护阈值、缓存规则与回源设置接入完成后最核心的工作是配置防护策略。我把最重要的几个参数和推荐值列出来配置项推荐值/配置建议说明防护阈值先设为攻击时观测峰值的 80%-90%太灵敏会误伤正常用户太迟钝则清洗不及时缓存 TTL静态资源 1-7 天动态资源不缓存图片、JS、CSS 建议长缓存API 接口不建议缓存回源超时5-10 秒过短会误判源站故障过长会导致缓慢的源站拖垮整体响应回源重试2 次避免源站瞬时抖动导致大量 502封禁粒度按 IP 按会话比单一的 IP 封禁更准确减少误伤频控策略单 IP 每秒 10-20 次根据业务实际情况调节太高会漏太低会误杀关于防护阈值的设置逻辑很多新手容易搞错。阈值不是越低越好而是要“贴合真实业务画像”。比如你的网站正常情况峰值 QPS 是 500攻击时是 5000那阈值设在 1000 就合理既能覆盖业务高峰又能在攻击发起时快速触发清洗。但如果你的正常业务峰值就是 3000阈值设成 1000 就会天天误杀用户骂声一片。缓存规则的配置也很有讲究。核心原则是能被缓存的坚决缓存不能被缓存的做好频控。很多动态页面看起来不适合缓存但其实可以通过 CDN 的自定义缓存规则做“边缘渲染定时刷新”这个属于进阶玩法了等基础稳定后再研究。3.4 攻击切换验证怎么判断 CDN 真的保护了源站配置完成后不能光看网站能打开就以为万事大吉。我一般会做一轮完整的验证确保防护链路确实生效。验证一检查 DNS 解析路径。使用dig 域名或者在线 DNS 工具查询确认解析结果已经变成 CDN 服务商分配的 CNAME 对应 IP而不是源站 IP。验证二查看回源日志。在高防 CDN 控制台的日志分析里看源站 IP 收到的请求来源。正常情况下源站收到的请求来源应该全部是 CDN 回源节点 IP。如果日志中还有大量来自公网不同 IP 的直接请求说明源站 IP 已经泄露或者防护策略有漏洞。验证三模拟触发防护策略非真实攻击是合规的防御演练。在自己的测试环境或低峰期通过压测工具模拟超过阈值的请求观察 CDN 的清洗是否生效、源站是否依然稳定。注意这里说的是合规的防御演练在自己的站点、自己的账号下做验证是为了确保策略正确。压测要控制好并发数避免影响正常用户同时提前和服务商做报备不然有被误判为攻击的风险。验证四检查源站资源消耗。在攻击模拟期间观察源站的 CPU、内存、带宽、连接数四个指标。如果四个指标都保持平稳说明 CDN 成功拦截了绝大部分异常流量如果有人指标仍然飙升那就要检查回源配置是否正确或者是否有直接 IP 请求绕过 CDN。4. 常见问题与排查技巧实录接入高防 CDN 之后并不意味着万事大吉。我整理了几个最常遇到的问题基本都是真实踩过的坑。4.1 已经接了高防 CDN网站为什么还是卡这是被问得最多的一个问题。如果 CDN 已经生效但网站依然慢可能的原因有几个缓存命中率过低打开 CDN 控制台的缓存命中率报表如果命中率低于 70%说明大量请求都在回源。排查方法是检查是否开启了“不缓存”策略或者页面响应头里带了Cache-Control: no-cache。动态接口不需要缓存但静态资源必须缓存否则 CDN 沦为纯代理源站压力一点没减。回源线路质量差CDN 节点回源到源站的线路如果质量不好用户请求到达边缘节点后回源慢整体响应就慢。可以通过“多线回源”或者把源站搬迁到离 CDN 节点更近的机房比如同样使用主流云厂商的服务器来解决。源站本身有瓶颈如果源站的数据库慢查询、代码性能等问题一直存在CDN 能加速的是网络链路但加速不了应用逻辑。这种情况下即使 CDN 把 90% 的静态请求拦截了剩下的 10% 动态请求依然会暴露源站性能问题。4.2 攻击者绕过 CDN 直接打源站 IP 怎么办源站 IP 被攻击者拿到是高防 CDN 场景下最危险的事情。攻击者拿到源站 IP 后可以直接打源站 IP 和服务器CDN 再强也帮不上忙。处理办法有两层第一层是封在源站服务器的防火墙或安全组里只允许 CDN 回源 IP 段访问 80/443 端口其他来源一律拒绝。如果源站有 SSH 端口建议修改默认端口并只允许办公 IP 访问。第二层是换如果源站 IP 已经被打得很惨且长时间被盯上最简单粗暴的办法是更换源站 IP。换 IP 后一定不要再直接解析到新 IP先接入 CDN等 CDN 完全生效后再启用新 IP 的访问。新 IP 在初始阶段最好只允许 CDN 回源访问降低暴露风险。这里想提醒一点很多攻击者拿到源站 IP 靠的是 DNS 历史记录或者配置时的失误。接入高防 CDN 后不要再在任何地方直接解析到源站 IP包括子域名、邮箱解析记录、测试地址等重要的事情必须反复确认。4.3 防住了攻击但把正常用户也误伤了怎么办防护策略太激进或者频控阈值设置不合理就会出现误伤。比如某个公司办公网络出口是同一个 IP几百人同时访问你的网站单 IP 每秒 10 次的限制就会把这几百人全部误封。解决思路有几个打开 CC 人机验证当请求频率超过阈值时不直接封 IP而是返回一个验证码页面让用户点击验证后才放行。正常用户多一个步骤但至少不会被彻底挡住攻击者的自动化脚本通常不会执行验证码自然就被拦住了。参照历史峰值设置阈值查看过去 30 天的 QPS 峰值以这个峰值的 1.5-2 倍当作阈值。比如日常峰值是 1000 QPS阈值设为 1500-2000给正常增长留出空间超过才触发清洗。开启精准白名单对已知的重要合作伙伴 IP、内部办公 IP 设置白名单绕过所有防护策略。但白名单必须谨慎维护设置太宽会降低防护效果。4.4 一个会被我反复提的小技巧提前做防御演练很多人都是被打了才想到接高防接完就想当然认为不会再出事然后继续裸奔。我的习惯是每季度做一次防御演练在自己的测试环境、把 DDoS 攻击实验变成一次策略验证课——模拟异常流量、确认边缘节点的清洗效果、检查告警系统、观察指标、调整阈值。整个过程不出意外的话一小时就能完成但它能让你在真正被攻击时不慌不忙。另外高防 CDN 控制台里的告警通知一定要配置到位建议至少配置短信和邮件双重告警。告警阈值建议设两个级别一个低于攻击流量提示“需要关注”一个接近防护上限提示“紧急处理”。不要等到站点挂了再去看监控告警系统会让你的响应速度快一个量级。5. 最后分享一点个人经验我在接入高防 CDN 的过程中最深的体会不是某个具体配置项多么重要而是思维方式的转变。以前我总觉得“服务器要买大带宽、要高配置”被攻击后才发现把防护力量放在离用户更近的地方——边缘节点用分布式架构去承接和分散压力才是治本的路子。高防 CDN 的原理说到底并不复杂它就是把你一个人扛的压力变成整个网络团队一起扛。最后分享一个小技巧接入高防 CDN 后别急着把源站的日志和监控关掉。源站的 CPU 和带宽监控依然要保留而且要多留一份“回源请求来源 IP”的日志。当某一天你发现源站收到了不在 CDN 回源 IP 列表里的请求时这往往比任何安全告警都更能说明问题——要么是 CDN 回源 IP 段更新了要么就是源站 IP 泄露了。这个细节能帮你提前发现潜在风险而不是等被打挂了才后知后觉。