CDN节点攻击，被拖垮的往往不是源站

源站被打挂，这听上去才像攻击方赢了。可实际情况大多是：源站那边 CPU 没怎么动、磁盘 IO 也正常，先出问题的反而是前面那层——解析、调度、回源、账单，一个接一个跟着崩。CDN节点攻击这个词，不少人第一次听到都以为重点是”往源站招呼”，真碰上才知道，被盯上的往往是边缘节点，以及节点后面那串平时没人看的链条。

CDN节点攻击先崩的是边缘那层，不是机房深处

边缘节点是共享的，一台物理机上可能挂着好几家客户的实例。挨打的时候，先撑不住的是节点上的连接表和限流策略，不是你的源站。你打开监控看源站，曲线平平的，日志里也没几个请求，心里还挺踏实；结果用户那边全是 502、504，或者干脆转圈。原因是请求根本没走到源站，在边缘就被打回去了，或者节点自己先趴了。所以判断方向的第一步不是查源站负载，是查”请求到底停在哪一层”——节点日志和回源日志对不上，基本就能定位。

回源比例一上来，源站才开始真疼

缓存命中率是这条链的命门。平时命中多高，被打的时候就多脆。攻击流量里要是掺了大量带随机参数、随机路径的请求，缓存全部失效，每个请求都往源站穿。回源带宽打满、数据库连接数飙升，这才是常见的”被打挂”剧本。所以看到命中率断崖式往下掉、回源请求占比往上翻，别犹豫，先在回源侧限速、给动态接口做频控、把能合并的请求合并掉，优先护住源站。这套动作平时做一遍，出事的时候能省很多慌。

一个 CNAME 出岔子，全站跟着抖

调度这块最容易被忽略。域名解析到 CNAME，CNAME 后面挂着多个节点，某个节点被下线或者被打进黑洞，正常情况下调度会把流量切走。可如果 TTL 设得太长，客户端和 Local DNS 还攥着旧记录不肯松手，切换就得等半天。还有些接入方式直接把 CNAME 指到一个固定地址，没有多节点冗余，那个地址一哑，全站跟着哑。这些细节平时没人翻，出事的时候全是事故点。具体调度规则和切换机制，以服务商控制台或官方页面说明为准，别凭印象拍脑袋。

计费这张脸，挨打的时候最不好看

按流量计费的，挨打就是白烧钱；按请求数计费的，刷接口比刷页面更狠。见过有人一晚上盯着源站加固，第二天看账单才发现跑掉的是流量包。这里不给具体数字，各家的计费口径、免费额度、防刷策略差别很大，以服务商计费说明为准。能提前做的是：设好流量阈值告警、把按量带宽的上限卡住、静态资源单独走一套缓存和限速策略，别让一个刷子把你的额度当成免费自助餐。

面板上比源站 CPU 更早报警的几个信号

一是缓存命中率突然掉；二是回源带宽或回源请求比例跳升；三是单个节点的 5xx 比例明显高于其他节点；四是某一小撮 IP 或者某个 UA 占了很大请求比例；五是 403、429 这类状态码突然变多，说明限流已经在动手了。这几个指标比盯着源站负载有用得多。很多事故里源站还睡着，边缘那边已经在流血。

真遇上了，先干这几件事

别一上来就往源站加机器加带宽。顺序大概是：先确认请求停在哪一层，节点日志和回源日志一对就清楚；把出问题节点的解析切走或者临时摘掉；回源侧加上限速和频控，动态接口单独拎出来限；静态资源的缓存时间临时拉长一些；日志全都留着，事后才有得查。这一套动作本身不难，难的是事前有没有人知道 CNAME 在哪改、切走之后怎么切回来。

有个做下载的站点，源站一整晚都没醒

大概就是上面那种情况：看到用户说打不开，第一反应是给源站升配置，带宽、CPU 一顿加，第二天复盘才发现源站那几天的负载跟平时差不多，真正被打满的是某个节点的出向带宽，还有回源的并发连接。后来他们把下载文件挪到另一个域名上、单独一套缓存规则，把几个热点包提前预热到边缘，才慢慢稳下来。钱花在源站上，等于花错了地方。

平时的功夫，别等挨打才想起来

备用 CNAME、多节点冗余、缓存预热、限流规则、日志留存、告警阈值，这几样平时花不了多少时间。尤其是缓存预热，很多人只在上线那天做一次，后面更新内容就不管了，真被打的时候冷缓存全往源站穿，源站那点带宽根本接不住。还有告警，阈值定得太松等于没有，定得太紧天天狼来了，自己看着办，先跑几天观察基线再调。

下次再看到”网站打不开”，先别急着给源站加配置。把节点状态、命中率、回源比、账单这四样摆在一起看一眼，方向基本就出来了。平时把切流量的路径演练一遍，比事后补多少台机器都顶用。