网站被DDoS攻击了怎么快速恢复访问？5步应急恢复顺序

网站被打瘫的时候，最容易浪费时间的不是不会配置，而是顺序错了要返工。最典型的一种：先急着改DNS解析切到防护节点，但源站公网IP还明着挂在那儿，攻击者根本不看域名，照着IP继续打，切完还是不通。

先把顺序记住，再逐步展开：

判断被打的是网络层还是应用层（2分钟内能看出来）
隔离源站——关闭公网直连端口，IP已暴露或已进黑洞就立刻换IP
DNS切流到清洗节点，生效快慢取决于TTL
应用层攻击在边缘压制：应急模式、按路径限速、ACL
清理源站残留连接，再确认恢复

按带宽与CPU表现区分网络层攻击和应用层CC攻击的判断流程图

第一步：先分清是带宽被打满，还是进程被打死

这一步决定了后面是换IP还是配规则，不要跳过。

网络层（L3/L4）流量攻击，比如SYN Flood、UDP反射放大：机房网卡带宽被打满，丢包率极高，严重时连SSH都登不上去。云厂商通常会直接对这个IP触发黑洞策略，把所有公网流量阻断——这时候你的服务器本身是好的，但从公网谁也访问不到，包括你自己。黑洞是按IP生效的，所以在黑洞里改DNS指向同一个源站IP没有任何意义。

应用层（L7）攻击，也就是常说的CC、HTTP Flood：带宽看着不高，但服务器CPU飙到100%，Nginx/Apache连接池耗尽，502/504大量出现，数据库连接数打满。

怎么快速看：云控制台的带宽和包量曲线、有没有黑洞通知，是判断第一类的最快依据；服务器上 top、ss -s、Web服务状态页和 access.log 里的高频路径、异常UA和集中来源，是判断第二类的依据。慢速CC的特征更隐蔽，连接数高但请求速率不高，只看access.log容易漏判，可以参考怎么判断是不是慢速CC攻击。

实际情况里混合攻击很常见（大流量掩护下夹着CC），判断出主要矛盾就往下走，两条线可以并行处理。

第二步：先把源站藏起来，再谈切流

顺序上，源站隔离必须在DNS切流之前或同时完成，否则第三步是白做的。

关闭源站的公网直连。 在云安全组或系统防火墙上，把80/443等业务端口对全网的放行去掉，只放行清洗节点/CDN的回源IP段。管理端口（SSH、远程桌面、数据库）只放行你自己的办公IP，攻击期间尤其不要图省事开着。

IP已经暴露或已经进黑洞，就必须换IP。 判断标准很直接：攻击流量是直接打在IP上的（改了解析仍然被打）、或者这个IP已经被黑洞封了。这种情况下换一个弹性公网IP，然后有一条硬规矩——新IP不要做任何DNS解析记录，只作为防护节点的回源地址存在。很多网站换完IP第二天又被打，就是因为顺手把新IP解析到了某个子域名上。

换IP之后还要顺手清一遍旧IP的泄露面：历史DNS解析记录、MX邮件记录、没走防护的子域名（如 test、admin、api）、证书透明日志、以及网站自身对外发起请求时暴露的出口。这几个口子不堵，攻击者重新找到源站只是时间问题，具体核对方法见源站隐藏怎么做和源站IP泄露后的应急处理与修复步骤。

第三步：DNS切流，生效时间取决于你之前设的TTL

把域名的解析记录改成防护节点提供的CNAME（或高防IP的A记录），攻击流量就会被牵引到清洗集群，恶意包在边缘被丢弃，合规请求回源。

这里最影响心态的是生效时间：

如果域名TTL本来就是60～300秒，通常几分钟内大部分访客就切过来了；
如果TTL是3600甚至86400秒，部分递归DNS会在缓存过期前继续解析到旧IP，可能持续几十分钟到几小时。此时应立刻把TTL调小，但调小只对尚未缓存的解析器起作用，已经缓存的仍要等它自然过期——这就是为什么TTL属于平时就要设好的东西。

几个容易踩的点：

改完解析别忘了回源配置。 回源地址要指向新的、未公开的源站IP，并在源站放行回源IP段，否则切完解析全站502。
HTTPS要能正常握手。 防护节点侧需要有可用证书，自动签发的免费SSL在应急时能省掉一步手工上传。
有客户端硬编码IP的业务（部分App、游戏客户端、支付回调对端）不吃DNS切换这一套，要么改用高防IP直接替换，要么走需要发版的路径，应急阶段先保住Web和API。

如果手头没有可用的防护接入、现在就要把流量牵走，可以直接走正在被攻击的应急通道说明域名、业务类型和当前现象（带宽打满还是CPU打满、是否已进黑洞），接入方式和回源配置在同一条链路上完成；具体防护能力和接入方式见 DDoS 防御。RockCloud 的加速和防御走同一条链路、一份费用，防护不需要另外再买一层，按固定峰值计费、不限流量，这一点在被攻击期间比较重要——流量被打上去不会额外产生带宽账单。

第四步：应用层攻击要在边缘压住，别指望源站扛

流量牵引生效后，如果还在502，多半是CC没被压住。在防护/WAF控制台上做三件事：

开应急防护模式（人机验证/质询模式）。这是最快的止血手段，代价是误伤率上升，适合先开着把服务救回来，稳定后再降级。
对高频路径做速率限制：登录、注册、搜索、下单、动态API这些消耗数据库的接口，按IP或按会话限速，阈值先按正常业务峰值的2～3倍设，宁可紧一点。
ACL拦截明显特征：异常UA、空Referer、非业务地区、集中的ASN来源。这类规则见效快但要写清楚生效路径，避免全站误封。

必须留意的例外：纯API接口和App客户端不能挂JS质询或验证码，一挂上正常调用全部失败。这些路径要用Token校验、签名校验或客户端白名单，与浏览器路径分开配置。支付、直播这类不能中断的业务，规则先小范围灰度、看错误率再全量。

另外把能缓存的静态资源尽量缓存在边缘，回源请求数降下来，源站压力会明显缓解——这一步在攻击期间的收益比平时大得多，缓存策略的具体配置见高防CDN缓存策略优化。

第五步：源站残留连接不清，服务还是时好时坏

很常见的情况：清洗已经生效、攻击流量到不了源站了，但网站仍然间歇性超时。原因往往是攻击期间堆积的大量未关闭连接——ss -s 或 netstat 里能看到成片的 TIME_WAIT / CLOSE_WAIT，端口和内存被占满，新连接分配不出来。

处理动作：

重启Web服务进程和PHP-FPM/应用进程，释放僵死连接；
调整TCP内核参数，缩短 tcp_fin_timeout、开启 tcp_tw_reuse 加快端口回收（注意 tcp_tw_recycle 在NAT环境下会导致连接异常，新内核已移除，不要照抄老教程）；
检查数据库连接数是否还挂着、慢查询是否堆积、磁盘是否被暴涨的访问日志写满。

怎么算真的恢复了

别以为自己能打开首页就结束了。至少核对四项：

多地访问正常：不同运营商、不同地区都能打开，而不是只有你的网络能打开（这往往说明只是本地DNS缓存到了新记录）；
错误率回落：5xx比例回到日常水平，接口响应时间正常；
攻击是否仍在进行：看清洗侧的攻击流量曲线和拦截日志，攻击还在但被清掉了，和攻击已经停了，是两种处境——后者意味着你的规则还没真正被验证过；
没有残留暴露：确认没有子域名还解析在旧IP上。

同时把这段时间的日志、攻击特征和处置时间点留下来，事后要做溯源和规则调优，分层取证的做法见DDoS攻击日志分析与溯源排查方法。

高防CDN接入前后源站暴露与流量清洗回源的路径对比

攻击停了之后，把几件事固化下来

应急能救一次，但下一次能不能几分钟恢复，取决于平时：

TTL常态设成60～300秒，切流才有意义；
源站IP永久不对外暴露，回源做鉴权（回源IP白名单或回源密钥），换过的IP别再解析出去；
限速和ACL规则保留一份宽松的常态版本，攻击来了只需要调阈值、开质询，而不是从零写规则；
告警要送到人手上：带宽、5xx、攻击事件推到即时通讯（如Telegram推送）比等用户投诉快得多；
提前跑一次演练：用免费测试环境把接入、回源、证书、缓存这条链路走通一遍，真出事时就不是第一次操作。RockCloud 支持免费测试与按峰值计费的套餐，需要国内访客加速的业务还可以走免备案的CN2链路，和防护在同一条链路上。

最后提醒一句顺序上的老问题：先隔离源站，再切流量，最后调规则。这三步反过来做，多半要返工一遍。