网站正在被大流量攻击：快速挂载CDN的接入顺序与收口要点

攻击已经打进来的时候，挂 CDN 最容易出的错不是配错参数，而是顺序错：有人先把 DNS 切了才发现边缘回不了源，网站从"卡"变成"全白"；有人 CDN 挂上了却没动源站防火墙，攻击继续按原来的 IP 打，清洗节点形同虚设。

下面按实际动手的顺序走一遍。

六步顺序，先看全貌

1. 在 CDN 侧添加域名、配好源站 IP 与端口、回源协议、回源 Host、证书 —— 这一步不碰线上解析，做错了也不影响现状
2. 用本地 hosts 把域名指到边缘节点，确认边缘能正常回源、页面能打开
3. 改 DNS：把 A 记录换成 CDN 给的 CNAME，或整域改 NS
4. 收口源站：防火墙只放行回源 IP 段，必要时更换源站公网 IP
5. 开边缘紧急防护：质询模式、CC 频次限制、静态缓存兜底
6. 看日志验证：回源请求量、边缘拦截量、源站连接数三个数对不对得上

第 3 步和第 4 步的先后，取决于源站现在还活着没有，后面单独讲。

第一步：CDN 侧配置，别漏掉回源 Host 和证书

添加域名时要填的几项，攻击状态下最容易填错的是这三个：

源站地址和端口。填源站的真实公网 IP 和实际监听端口。如果源站前面还有一层负载均衡或反代，填那一层的地址，不要填后端。

回源协议。源站只开了 80 就选 HTTP 回源，源站强制跳 HTTPS 就选 HTTPS 回源。选错的典型症状是无限 301 重定向循环，或者边缘报 502。

回源 Host。默认一般是用户访问的域名，如果源站用的是基于 Host 的虚拟主机配置（Nginx server_name / Apache VirtualHost），回源 Host 必须和源站配置里的域名一致，否则会命中默认站点，返回一个不相干的页面或 404。

证书。HTTPS 站点必须在边缘节点完成证书部署，边缘要在这里终止 TLS 才能看到七层明文、做 CC 过滤。要么把现有证书上传上去，要么启用平台的免费证书自动签发。攻击期间时间紧，自动签发通常更快，但要注意签发过程可能需要验证域名归属，而 DNS 验证方式在你还没切解析时是可以先做的。

第二步：切 DNS 之前，先用 hosts 验一遍

这一步花不了两分钟，却能挡掉一大半事故。

在自己电脑的 hosts 文件里把域名手动指向 CDN 给的某个边缘节点 IP（控制台一般能查到，或者 ping 那个 CNAME 拿到解析结果），然后浏览器访问：

• 首页能打开、静态资源没有混合内容报错
• HTTPS 握手正常，证书链完整
• 登录一次、提交一次表单，确认 POST 和 Cookie 没被吃掉
• 后台或管理路径能正常进

验证通过再动解析。没通过就在 CDN 侧改，反正线上还没切，改多少次都不影响。

第三步：改 DNS，并接受它不会立刻全量生效

把源站的 A/AAAA 记录改成 CDN 分配的 CNAME，或者按平台要求整域改 NS。

这里必须说清一件事：解析切换的生效速度受原记录 TTL 约束。公网上成千上万个递归解析器缓存着你之前那条记录，缓存不过期就不会回来问新值。如果原来的 TTL 是 86400 秒，最坏情况下接下来一整天仍有相当比例的公网请求直奔旧地址。攻击期间你能做的，是立刻把 TTL 调到最小值（很多平台支持 60 秒），但这个新 TTL 本身也要等旧缓存过期后才开始起作用。

所以别指望靠改解析把攻击流量"引走"。改解析只解决正常用户的访问路径，攻击者手上握着的是 IP，不看你的 DNS。

CNAME 还是 NS：CNAME 是逐条记录切换，粒度细、影响面可控，适合只想保护 www 和主站、其他子域保持原样的情况；NS 接入是把整个域的权威解析交给平台，全域一次生效、后续调度更灵活，但切换受父区/注册局层面的缓存影响，且邮件、验证类 TXT 这些记录都要一并迁过去，漏一条就是一次新故障。两者的取舍可以看接入高防CDN要不要改NS。

第四步：收口源站，这一步决定 CDN 挂了有没有用

大流量攻击发生时，默认攻击者已经知道你源站的真实 IP。DNS 改了，直连源站 IP 的泛洪一点不会少。只有在源站侧把入口关上，清洗节点才真正成为唯一入口。

具体做两件事之一，或者两件都做：

收紧访问控制。在云安全组或本机 iptables 上，把 80/443 的来源限制为 CDN 厂商提供的回源 IP 段，其余公网来源一律 DROP。管理端口（SSH/RDP/数据库）单独只放行自己的办公出口 IP。回源段厂商一般会给一份清单，也可能不定期更新，接入后记得订阅变更。

更换源站公网 IP。如果源站已经被打到网络完全堵死，或者被上游云厂商打了黑洞路由，光收口来不及了——流量在到你机器之前就已经把链路占满。这种情况直接换一个弹性公网 IP（EIP），换完之后新 IP 只写进 CDN 的回源配置，任何公开解析记录里都不能出现它。

换 IP 后顺手排查几个常见的泄露口：历史解析记录（很多查询站会留档）、邮件 MX 和 SPF 指向的主机、后台/测试/API 等没走 CDN 的子域、证书透明日志里暴露出来的内部域名。这些地方漏一个，换 IP 就白换了。隐藏源站的完整排查顺序可以参考棋牌游戏服务器被攻击怎么隐藏源站IP，思路对 Web 站同样适用。

关于第 3、4 步的顺序：源站还能扛住、页面时快时慢的，先切 DNS，等边缘开始有回源流量再收口，损失最小；源站已经完全打不开、SSH 都连不上的，没有等的必要，直接换 IP + 只放行回源段，然后再改解析。

还有一种情况要提前有预期：源站已经被云厂商黑洞的，在解封之前回源是不通的，挂 CDN 也救不回来。各家的黑洞触发阈值和解封时长策略不一样，这时候唯一的快路径通常是换 IP 或换实例，具体得看你用的云商怎么规定。

第五步：边缘紧急防护，注意别把自己的 API 也拦了

通路恢复之后再开防护，顺序反了容易把"打不开"误判成攻击没挡住。

七层质询。对异常来源启用浏览器环境验证或托管质询，把无法执行 JS、没有正常 TLS 指纹的请求挡在边缘。这是应付 CC 最直接的一招。

速率限制。按 IP 或按会话对高成本路径设阈值：登录、搜索、下单、验证码发送、任何会打数据库的接口。静态资源不用设。

缓存兜底。把静态资源的缓存级别调高，必要时对图片、JS/CSS 忽略 Query String 参数，让带随机参数的洪水请求也能命中缓存，不穿透到源站。但要把登录态页面、购物车、个人中心这些路径明确排除在缓存之外，否则会串用户数据——攻击期间出这种事比宕机还麻烦。

这里有个必须留的例外：如果你的域名下有对外的 Web API、App 客户端接口、小程序后端或第三方回调（支付通知、Webhook），全站强制 JS 质询或验证码会直接把它们打死——这些客户端不跑浏览器，过不了质询。正确做法是按路径分区：页面路径上质询，/api/*、回调路径改用速率限制加特征规则（UA、签名头、来源 IP 段白名单）。支付回调被误拦的排查方式见WAF把支付回调拦了怎么加白名单。

第六步：验证，看三个数

接入完成后不要凭"能打开了"就收工，去日志面板看：

• 边缘请求量 vs 回源请求量：差值就是缓存和拦截挡下的部分。如果回源量几乎等于边缘量，说明缓存基本没生效
• 拦截/质询计数：确认防护规则真的在命中，而不是配了没生效
• 源站侧连接数：收口成功的话，源站的连接来源应该只剩回源 IP 段。还能看到大量陌生 IP，说明防火墙规则没生效或有其他端口暴露

怎么从看板异常点下钻到单条请求，可以看CDN控制台怎么看流量和网络日志。

如果你手上还没有可用的高防账号

以上流程的前提是你已经有一个能立刻添加域名的平台。攻击进行中现注册、走试用审批、等工单，时间成本往往比技术操作本身高得多。RockCloud 的加速和防护走同一条链路、按固定峰值计费不限流量，支持攻击中直接开通接入；正在被打的话从这里联系接入，把域名、源站 IP、是否 HTTPS、业务类型（网页/API/游戏）四项信息准备好，能省掉一轮来回。

事后复盘时再回头处理这几件事：把 TTL 长期保持在较低值，方便下次快速切换；整理一份不走 CDN 的子域清单并逐个收掉；把源站真实 IP 从所有可公开查询的位置清理干净。这些事平时做要十分钟，攻击时做要付出宕机时长。整体的止血优先级可以对照网站被DDoS攻击了怎么快速恢复访问。