凌晨两点，一家做电商的小团队收到告警：网站打不开，后台连接大面积超时。运维同学登上控制台，看到公网IP的入流量曲线几乎垂直冲到顶。这种情况多半是遭遇了DDoS攻击，而他们在控制台里看到的第一个词，就是“黑洞”。
什么是阿里云盾黑洞
阿里云盾是阿里云的安全防护产品。其中的DDoS高防服务先在云端清洗攻击流量，再把正常请求转发回源站。黑洞是清洗能力之外的最后一层处理：攻击流量超过防护上限后，云端会丢弃发往这个IP的全部流量，攻击和正常请求一起被挡在外面。
这种处理很粗暴，但有它的道理。攻击流量如果继续压进来，可能拖垮机房的网络设备，连带影响同一区域的其他客户。黑洞把损失限制在被攻击的那个IP上。代价是这个IP对外完全不可用，正常用户也进不来。黑洞能保住基础设施，却解决不了问题。网站要恢复，还得等攻击停止，或者提升防护规格。
什么时候会触发
黑洞是否触发，取决于你买的防护规格。每个高防实例都有对应的防护峰值。流量或包速率超过这个值并持续一段时间，系统就可能切换到黑洞策略。具体阈值、判定时长和恢复规则，以阿里云控制台展示和官方文档为准。不同产品版本可能有差异，购买前逐项核对，别凭印象估。
常见的攻击大致有三类，触发黑洞的方式也各不相同：
- 流量型攻击：比如UDP反射放大、大量空连接，直接占满带宽。
- 协议型攻击：比如SYN Flood，耗尽服务器的连接资源。流量未必很大，但请求包数量极多，包速率会先顶上去。
- 应用层攻击：模拟正常页面请求，频率高、特征隐蔽。清洗时容易被当成正常访问放过，等量上来才暴露。
一个示例：凌晨的那次攻击
下面是一个虚构但符合常见情况的案例。
这家小电商买的是中等规格的高防IP，防护峰值远低于一次大规模UDP反射攻击的流量。攻击开始后的十几分钟，清洗中心还在工作，但攻击量一直往上涨。超过防护上限后，系统触发黑洞，该IP的流量全部被丢弃，网站整体离线约一个小时。
事后复盘，团队发现三个问题：
- 告警设得太晚。带宽超过八成才通知，运维只剩几分钟的反应时间。
- 域名只解析到一个IP，没有备用入口，黑洞一来全站瘫痪。
- 事先没确认过紧急联系渠道，黑洞期间只能排队等工单。
之后他们做了三件事：把告警阈值提前到六成左右；为核心业务准备了备用IP和解析切换方案；把运维联系方式和工单优先级确认写进应急手册。再遇到类似流量时，清洗正常运行，网站几乎没受影响。
黑洞的代价
最直接的代价是业务中断。对电商、支付或内容平台来说，哪怕离线一小时，也可能流失订单，用户对平台的信任也会下降。
其次是恢复时间。黑洞解除后，流量需要重新调度，部分用户会因为DNS缓存延迟回来。团队要预留这段恢复期，不能指望IP一恢复，流量就立刻回到正常水平。
第三是成本。高规格防护的费用明显高于普通带宽。防护规格长期低于实际需要，攻击来时就容易触发黑洞。可如果一味堆规格，预算又会白白浪费。规格应该按真实流量来定，历史峰值和促销期的数据都要算进去。
降低风险的几个做法
- 按业务峰值选规格：拉出过去几个月的流量曲线，把大促和活动日的峰值算进去，再留出余量。每次活动前后都复盘一次。
- 设置分级告警：带宽、包速率和连接数达到约六成时就提醒。告警要发到能立即响应的人手上，否则只是一条记录。
- 准备备用入口：核心域名配置多个IP或多条线路。切换解析前先确认备用入口可用，别等出事了才第一次测试。
- 隐藏源站并收紧策略：源站真实IP不要暴露在公网，限制用不到的来源地区和协议，减少无效流量进入清洗中心。
- 留存应急渠道：提前确认阿里云的工单优先级和技术支持联系方式，写进应急预案，并定期检查是否仍然有效。
黑洞是最后一道兜底。它保住了基础设施，代价是业务暂时中断。攻击发生前把规格、告警和备用方案准备好，才能少熬几次这样的凌晨。
