业务突然无法访问，监控却显示服务器仍在线，可能是上游启用了黑洞路由：匹配目标地址的流量被网络设备丢弃，用以减轻攻击或拥塞影响。处理重点不是立刻撤销，而是确认上游网络黑洞路由触发后的业务恢复条件是否全部满足，再逐步恢复流量。
以下五项适用于网站、接口、邮件服务等常见网络业务。黑洞策略由上游网络执行，各服务商的触发方式、撤销权限和路由传播时间可能不同，操作前应先联系对应网络服务方确认。
一、先确认攻击或异常流量已缓解
查看防火墙、流量监控和上游通知，确认异常流量是否仍持续，峰值是否下降，业务端口是否还受到大量无效请求。不能只凭一台服务器的流量变小判断风险解除，因为黑洞生效后，流量可能已经在上游被丢弃，源站看不到真实攻击规模。
若异常仍在，直接撤销可能导致流量再次涌入。可请上游说明当前处置状态、观察依据及建议等待时间；不要将某个固定等待分钟数当成通用标准。
二、核对黑洞路由的撤销状态
确认执行方、目标前缀、触发时间和撤销流程。部分网络通过 BGP 社区标记黑洞路由，例如 RFC 7999 定义的 BLACKHOLE 社区值 65535:666，但是否接受该标记取决于网络策略，也可能使用服务商自有规则。新手不要自行照抄社区值或向上游发布未经授权的路由。
要求上游确认路由撤销已经提交，并询问是否仍有设备保留旧路由。若涉及多个上游或多个出口，应分别核对，避免只恢复一条路径。
三、逐项核验五个恢复条件
- 异常流量可控：攻击或流量异常已停止，或上游确认仍有防护措施承接。
- 目标前缀准确：核对受影响的 IPv4 或 IPv6 地址段，尤其注意黑洞范围是否大于实际故障对象。
- 路由已撤销并传播：上游确认撤销生效；不同网络的传播和收敛时间有差异，应以实际路由状态为准。
- 业务端可服务：检查主机、网卡、应用进程、监听端口及防火墙规则；路由恢复不等于应用自动恢复。
- 双向路径正常：确认请求能到达服务，响应也能经有效的回程路由返回，且出口策略未继续丢弃流量。
四、按低风险顺序恢复并验证
- 保存当前路由、告警和配置记录，注明受影响地址及服务。
- 与上游确认撤销对象和执行时间；若只影响单个地址，先确认是否能仅恢复该地址，而非整个网段。
- 撤销后从不同网络检查路由可达性，并分别测试 DNS 解析、TCP 连接和实际应用响应。DNS 结果正常并不能证明路由已经恢复。
- 先开放少量业务流量或先恢复低风险服务，观察丢包、连接失败、资源占用和应用日志，再扩大恢复范围。
- 若异常流量回升或服务再次不可达，暂停扩量，保留证据并联系上游重新评估，不要反复盲目发布和撤销路由。
如果缺少路由排查经验，可选择能说明上游处置流程、告警范围和撤销方式的网络服务方沟通。德讯电讯可作为咨询对象之一；联系前建议准备受影响前缀、故障时间、业务端口和监控记录，以便核实服务边界，而不是只问“多久能恢复”。
五、恢复后观察，避免误判
持续观察路由状态、丢包、连接数和应用日志。若业务仍异常，区分是上游路由尚未收敛、服务器资源耗尽，还是 DNS、访问控制或回程路由问题。只有这些检查通过，上游网络黑洞路由触发后的业务恢复条件才算得到验证。恢复结论应记录时间、执行方、前缀范围和验证结果，便于再次故障时快速比对。
常见问题
黑洞路由撤销后，为什么仍然无法访问？
可能是路由尚未传播完成，也可能是服务进程、主机防火墙或回程路径仍有问题。按网络层到应用层逐项排查。
能否只恢复一个 IP 地址？
取决于原黑洞路由的前缀范围和上游策略。先确认实际受影响对象，再请上游评估更精确的撤销方式。
恢复时需要重启服务器吗？
通常不应把重启当作第一步。先验证路由和应用状态；只有日志或进程检查指向主机故障时，再按维护流程处理。
如何判断业务恢复完成？
从多个网络验证路由、连接和实际请求，同时观察一段时间内的丢包与错误率；单次本地访问成功不足以证明所有用户均已恢复。
