DDoS流量打穿高防阈值，被黑洞之后，业务恢复要先分清“哪一层死了”

高防被打到黑洞，现场最容易乱。客户看到的是网站打不开、游戏掉线、接口超时；机房看到的是入口流量超过清洗阈值，触发BGP黑洞；运维看到的是服务器CPU、内存可能都正常，但公网IP已经不可达。

这里要先把问题拆开：黑洞不是服务器宕机，也不一定是高防清洗失败，而是运营商或高防节点为了保护上游网络，把目标IP的路由丢掉了。简单理解就是“这个IP暂时不让进网”。所以黑洞之后，重启业务、重启Nginx、重启机器，大多数情况下没用。

实际使用中发现，黑洞恢复速度主要取决于三件事：攻击是否还在持续、是否有备用入口、业务是否允许快速换IP或换域名解析。没有备用入口，只能等黑洞时间结束；有备用入口，恢复可以从小时级压到分钟级。

先确认黑洞类型：高防黑洞、运营商黑洞、上游封堵不是一回事

高防IP被黑洞后，不能只看控制台上的“黑洞中”三个字。要确认是哪一级触发的。

高防平台自身黑洞

这种情况一般出现在购买的高防阈值是100G、300G、500G，但实际攻击峰值超过阈值，比如800G UDP Flood打进来，高防平台为了保护集群，会把这个IP拉黑洞。常见表现是：高防控制台显示黑洞状态，源站仍然能通过内网或其他公网IP访问。

这种黑洞相对好处理，联系服务商确认攻击峰值和黑洞剩余时间，同时准备切换到更高防御段或备用高防IP。

运营商侧黑洞

这种更麻烦。攻击流量已经影响到运营商链路，运营商直接对目标IP做路由黑洞。控制台可能显示不完整，甚至服务商也需要向上游确认。表现通常是：全国多地traceroute到中间节点就断，BGP路由撤销，清洗节点也无法正常接入。

运营商黑洞的恢复时间通常更固定，30分钟、2小时、24小时都有，具体看机房策略。攻击如果持续，黑洞时间还可能刷新。

源站IP暴露后被绕过高防打死

这是高防场景里很常见的坑。表面看是“高防没挡住”，实际是攻击者拿到了源站IP，直接绕过高防打源站。高防IP还活着，源站IP已经被黑洞或带宽打满。

这种恢复不能只换高防，要立刻处理源站暴露问题：安全组只允许高防回源IP访问，源站公网入口关闭或换IP，数据库、Redis、管理后台不要和业务公网混在一起。

黑洞后最短恢复路径：别等，先切入口

黑洞触发后，最短恢复路径不是“等解封”，而是把用户流量引到还活着的入口。这个入口可以是备用高防IP、备用机房、备用线路，或者临时降级页面。

如果业务前面有DNS调度，恢复动作会快很多。把被黑洞的A记录摘掉，把解析切到备用高防IP，TTL提前设置在60秒到300秒之间，实际生效会比较快。但如果平时TTL是3600秒甚至更长，现场再改就会比较被动，很多用户本地DNS缓存还在。

多说一句，DNS切换不是万能的。App、游戏客户端、SDK里如果写死IP，DNS切换救不了。游戏行业经常遇到这个问题：登录服域名能切，网关服IP写死，攻击一来只能发公告换包或者临时热更新，这个恢复时间就不是运维能单独决定的了。

有备用高防IP时怎么切

备用高防IP平时不要闲置到完全没配置。证书、回源端口、转发规则、健康检查、源站白名单都要提前配好。黑洞发生后，只做两件事：确认备用高防IP未被攻击，切DNS或负载均衡入口。

这里有个现场经验：不要把主备高防IP放在完全相同的防护集群、相同运营商入口上。攻击流量特别大的时候，同组资源可能一起受影响。主备至少要拉开线路或地域，比如主入口走BGP高防，备入口走电信高防或海外清洗，业务能接受的情况下再加一条香港CN2/GIA方向的备用访问链路。

没有备用高防IP时怎么撑住

没有备用高防IP，就只能临时买、临时迁、临时降级。这个时候要看业务类型。

官网、后台、下载站这类业务，可以先切静态页，把核心通知、下载链接、客服入口保住。动态接口可以临时关闭部分非核心功能，比如排行榜、搜索、统计上报。

游戏、交易、支付类业务就要谨慎，不能简单切静态页。可以先保登录、保支付回调、保核心API，把非关键接口限流或摘除。实际处理时，应用层降级比网络层更考验平时准备。

如果临时需要新机器、新线路或备用节点，可以看129云这类提供高防服务器、G口大带宽服务器和海外云计算资源的服务商。比如临时放一个香港CN2直连节点做状态页、更新源、客服入口，或者用内蒙电信优化线路承接建站类业务备份访问。遇到攻击正在持续的场景，直接联系人工确认防御、带宽和开通时间会更快，客服热线400-9177118。

切换前要确认源站没有继续暴露

很多业务黑洞后换了新高防IP，十分钟后又被打黑洞。原因不是攻击者“太厉害”，而是源站IP、新入口、备用IP暴露得太明显。

常见暴露来源包括：历史DNS解析记录、邮件服务器头信息、SSL证书透明日志、接口返回里的IP、Git配置、运维文档泄露、第三方监控探测记录、对象存储回源地址、CDN回源配置不严。

恢复前至少要做一次源站访问控制：源站安全组只允许高防回源IP段访问业务端口；SSH、RDP、数据库端口只允许固定办公IP或堡垒机；源站如果必须保留公网IP，也不要和业务域名直接绑定。

这里补充一点，源站防护不要只依赖系统防火墙。Linux上iptables、nftables能挡一部分，但流量已经打到网卡或上游带宽时，系统防火墙处理不了带宽耗尽。该在云防火墙、安全组、机房ACL处拦的，要尽量前置。

DNS切换要提前设计，不要黑洞后才想起来改TTL

DNS在DDoS恢复里非常关键，但它不是现场临时发挥的工具。TTL、解析层级、权威DNS稳定性、是否支持按线路调度，都会影响恢复。

比较常见的配置是：业务域名CNAME到调度域名，调度域名再指向高防IP。这样切换时不用改所有业务域名，只改调度层。比如www、api、static都CNAME到不同调度记录，攻击发生时可以按业务模块切，不至于全站一起漂移。

TTL建议平时就控制在60秒到300秒。太低会增加DNS查询压力，但对大多数业务来说300秒以内是可以接受的。关键业务可以配合健康检查和智能解析，不同线路返回不同入口。

但要注意，部分Local DNS不完全尊重TTL，移动网络、校园网、企业内网缓存都可能拖慢切换。所以实际恢复时，不要只盯着权威DNS是否更新，还要从电信、联通、移动、海外多点dig和curl验证。

不同业务的恢复优先级不一样，别把所有流量都拉回来

黑洞刚解除或刚切到备用入口时，最忌讳把所有业务一次性拉满。攻击可能还在，用户重连也会形成瞬时洪峰。尤其是游戏、直播、下载类业务，恢复动作本身就可能造成二次压力。

网站类业务

网站类业务优先恢复首页、登录、支付、核心接口。图片、视频、下载包尽量走对象存储或CDN，不要直接压高防回源。后台管理可以临时限制IP访问，搜索、评论、统计这类接口可以延迟恢复。

游戏类业务

游戏业务重点看登录服、网关服、匹配服。登录服恢复后，不要立刻放开所有区服入口，可以按区服、按地域、按用户批次放量。客户端重连间隔要做随机抖动，不然全量玩家同时重连，会把刚恢复的入口打出异常。

API类业务

API业务要先保核心交易链路，非核心接口直接限流。比如查询类、报表类、埋点类，可以返回缓存或降级结果。网关层要开启连接数限制、QPS限制、单IP频率限制，不然DDoS刚过去，CC攻击可能接着来。

实际使用中发现，很多攻击不是单纯的UDP Flood或SYN Flood，后半段会混HTTP Flood、TLS握手耗尽、慢连接。网络层清洗只能解决一部分，应用层限流必须跟上。

黑洞解除后不要马上撤备用入口

黑洞解除只是IP重新可达，不代表攻击结束。很多攻击会盯着路由恢复时间继续打，IP刚放出来又被打进去。处理时要先小流量验证，再逐步恢复解析权重。

如果使用DNS权重，可以先让10%流量回主入口，观察5到10分钟：入向流量、清洗日志、源站连接数、5xx比例、延迟、丢包。稳定后再提到30%、50%、100%。

如果没有权重能力，只能一次性切回，那至少要选低峰期，并保持备用入口可用。不要看到主IP通了就把临时高防、临时机器释放掉，攻击回扫的时候会很难看。

高防阈值怎么选，要看峰值和攻击类型，不只看标称G数

很多人买高防只看“多少G防御”，但DDoS里面还要看pps、连接数、协议类型、清洗策略、回源带宽。100G UDP和100G SYN对设备压力不一样，HTTP Flood更不能只用带宽衡量。

可以按下面这种方式粗算：

普通企业站、品牌官网，历史没有大攻击，50G到100G高防通常够用，但要有备用解析和静态降级页。

游戏开服、活动营销、金融类接口，攻击峰值可能从几十G突然上到数百G，建议主入口至少300G起，同时准备备用高防IP。

被持续勒索、同行恶意竞争、私服/棋牌/语音房这类场景，单点高防很容易被打穿，需要多入口调度，必要时拆分登录、网关、下载、官网，不要共用一个IP。

选择服务商时要问清楚：黑洞阈值是多少，超过阈值后黑洞多久，黑洞期间是否能换IP，是否支持临时升级防御，回源IP段是否固定，是否有BGP、CN2、GIA等线路可选，攻击报表能不能看到峰值和类型。

如果业务需要国内访问低延迟，可以关注电信优化线路、BGP高防线路；如果需要海外或跨境访问，香港CN2、GIA线路更适合做加速入口或备用入口。129云的香港CN2直连、香港精品线路、内蒙电信优化线路这类产品，适合按业务拆分做入口、备份节点或临时承接页面，真正承接高强度DDoS时再搭配高防服务器和清洗策略。

黑洞期间能做的排查动作

黑洞等待时间不要空耗。这个阶段可以把恢复后的风险先处理掉。

检查源站安全组：业务端口只允许高防回源IP，管理端口只允许固定IP。

检查DNS历史记录：确认没有旧A记录指向源站，能删的删，不能删的下线。

检查证书和配置文件：不要在前端代码、App配置、接口返回里暴露源站IP。

检查日志：看攻击前是否有扫描、探测、异常404、异常Host请求。有些攻击会先探测真实源站，再发起大流量。

检查监控：黑洞前后的入流量、pps、连接数、5xx、CPU、负载、Nginx active connections都要留存。后面和服务商沟通升级防御时，这些数据比一句“被打了”有用得多。

临时迁移业务时，数据库和状态服务不要跟着公网裸奔

黑洞后临时迁移，最容易把安全边界搞乱。业务机迁到新节点后，为了快，把数据库公网白名单放开，把Redis临时开放，把管理后台挂公网。这种恢复看起来快，后面风险很大。

更稳的方式是：前端入口迁移，源站和数据库尽量不动，通过专线、VPN、内网隧道或受控白名单回源。确实要迁数据库，也要先做只读同步或备份恢复，不要在攻击现场直接做大规模主从切换，除非平时已经演练过。

对于静态资源，可以优先迁。HTML、JS、CSS、图片、安装包这些内容放到对象存储或备用服务器，DNS切走即可。动态业务迁移成本高，静态资源先走，能明显降低主入口压力。

黑洞恢复后的监控要盯细一点

IP恢复可达后，至少要盯这些指标：清洗前流量、清洗后流量、pps、SYN包比例、UDP协议分布、HTTP状态码、TLS握手失败率、源站回源带宽、源站连接数、业务接口P95/P99延迟。

只看服务器CPU是不够的。DDoS很多时候服务器CPU不高，但链路已经丢包，或者连接表被打满，用户一样访问不了。

还要看地区差异。电信正常、移动异常，可能是某条线路被影响；国内正常、海外异常，可能是跨境链路波动；高防入口正常、源站异常，可能是回源链路或源站白名单配置有问题。

平时预案里要把“黑洞后谁来切”写清楚

现场最怕权限不清。DNS在一个人手里，云控制台在另一个人手里，服务商工单账号没人知道，证书文件找不到，备用IP没配置转发规则。攻击来时每耽误一分钟，用户侧感知都很明显。

比较实在的做法是把切换动作文档化：哪个域名切到哪个备用IP，TTL是多少，回源端口是什么，源站白名单加哪些IP，服务商联系人是谁，升级防御需要谁确认费用，回切要观察哪些指标。

还要定期做一次小流量演练。不是等真被打时才验证备用入口能不能通。演练时可以只切测试域名或内部Host，确认高防转发、证书、源站ACL、日志、监控都正常。

黑洞后快速恢复的关键动作顺序

确认黑洞范围：是高防IP黑洞、源站IP黑洞，还是上游线路异常。

保住可用入口：有备用高防就切备用高防，没有就临时开新入口，网站类业务先静态降级。

封住源站：安全组、ACL、回源白名单马上收紧，避免新入口上线后再次暴露。

切DNS或调度：按业务模块切，不要所有服务一起拉回，客户端写死IP的业务要走热更新或备用配置。

观察攻击是否跟随：新入口上线后看流量是否转移，攻击如果跟随，说明域名、源站或业务特征已经被盯上，需要继续拆分入口。

等黑洞解除后小流量回切：不要立刻撤备用，主备并行观察一段时间。

几个容易被忽略的细节

高防回源带宽也会成为瓶颈。入口能抗500G，不代表回源有500G。正常业务回源如果只有50Mbps，攻击被清洗后剩下的恶意HTTP请求仍可能把回源打满。

CC攻击和DDoS要分开处理。大流量靠清洗，HTTP Flood要靠WAF、限频、验证码、JS挑战、业务风控。只买大带宽高防，不处理应用层，接口照样会挂。

不要把所有域名解析到同一个高防IP。官网、API、下载、管理后台最好拆开。一个IP黑洞时，至少还有其他业务入口能用。

备用节点配置不要太低。比如只放一个2C2G小机器承接全站动态请求，攻击时即使网络通了，应用也会被正常用户重连压垮。香港活动型2C2G适合放状态页、轻量站点、跳转页；8C8G香港精品线路更适合承接一部分动态业务或跨境访问入口；国内建站类业务可以用内蒙电信优化线路做备用展示站或后台运维入口。

攻击报表要留档。峰值多少G、持续多久、主要协议是什么、来源分布如何、是否有CC混合攻击，这些数据决定下一次买多少防御、怎么拆入口、要不要上多线路调度。

黑洞不是结束，真正要处理的是下一次攻击会怎么来

一次黑洞后，攻击者通常已经验证了阈值、业务入口和恢复速度。后面可能继续打同一个IP，也可能打备用IP、源站IP、DNS服务商、登录接口、支付回调接口。

所以恢复业务之后，动作不要停在“网站能打开”。要把入口拆分、源站隐藏、DNS调度、应用限流、备用高防、监控告警补上。能提前放到预案里的，就不要留到下次攻击现场再临时处理。

如果业务已经出现多次被打穿高防阈值的情况，单纯升级一个更大的防御包不一定够。更适合把业务拆成多个入口：主站一个高防，API一个高防，下载走独立线路，后台只允许固定IP访问，海外用户走香港CN2/GIA或其他优化线路。这样即使某个入口被黑洞，其他模块还有恢复空间。

黑洞期间不要反复重启机器，不要频繁换解析又马上切回，不要把源站公网直接暴露给所有用户。先让业务有入口，再让入口可控，再逐步恢复流量。