互联网中断并不只有一种形态。自然灾害可能同时破坏供电、移动基站和海底光缆；政府要求的网络关闭往往在行政边界内迅速生效；DNSSEC 密钥轮换失误则可能让服务器仍然在线，却让启用验证的用户无法解析域名。Cloudflare Radar 对 2026 年第二季度流量遥测的分析，展示了这些事件如何以不同方式影响全球连接。
对运维团队而言，关键问题不是只确认“流量下降了”，而是尽快判断下降发生在哪一层、影响哪些网络，以及应该联系基础设施提供商、DNS 团队还是业务负责人。
三类中断，三种不同的遥测特征
自然灾害：连接能力随基础设施一起退化
地震、洪水、风暴等灾害可能影响电力、传输线路、数据中心和接入网络。流量曲线通常会出现突降，但实际形态取决于受损基础设施：核心链路中断可能造成明显断崖，局部停电则可能表现为多个地区或运营商依次下降。
判断这类事件时，需要把网络流量与地理范围、自治系统（ASN）、供电状态和已知灾害时间线对齐。单看国家级总流量容易掩盖局部故障，也可能把用户主动避险导致的使用模式变化误判为基础设施损坏。
政府要求关闭网络：边界往往更加清晰
政府要求的网络关闭可能覆盖全国，也可能只影响特定地区、移动网络、社交平台或协议。与物理灾害相比，这类中断常具有更明确的生效时间和行政边界。如果多个互不依赖的运营商在相近时刻同步下降，而境外服务和基础设施没有相应故障，就需要考虑政策干预这一解释。
不过，遥测只能显示“发生了什么”，不能单独证明“是谁下达了指令”。可靠归因仍需要结合运营商公告、监管文件、当地报道和多个独立测量平台，避免把路由事故或大规模停电直接标记为人为关闭。
DNSSEC 密钥轮换：服务在线，但域名看起来消失了
DNSSEC 使用数字签名保护 DNS 数据。密钥轮换时，如果新的 DNSKEY、DS 记录和区域签名没有按正确顺序发布，验证解析器可能返回 SERVFAIL。这时源站、网络路由甚至权威 DNS 服务器都可能保持在线，但用户仍然无法通过域名访问服务。
这种故障最容易被误诊为应用宕机。其典型信号是：IP 直连或已有连接仍然工作，权威服务器可以返回记录，但启用 DNSSEC 验证的递归解析器拒绝接受答案。
不要只看一条流量曲线
一次可信的中断调查至少应对比四类信号：
- 请求和字节流量：确认下降幅度、开始时间和恢复过程。
- 网络维度：按国家、地区、ASN 和接入类型拆分，判断边界是否一致。
- 路由可达性：检查 BGP 前缀是否撤回，以及路径是否异常变化。
- DNS 行为：比较权威查询、递归解析和 DNSSEC 验证结果。
时间粒度也会改变结论。按天聚合的数据可能看不见持续 20 分钟的中断；按分钟观察又容易被正常流量波动干扰。实际告警可以同时使用短窗口和历史基线，例如比较最近 10 分钟流量与过去四周同一星期、同一时段的中位数。
可以这样实践：建立最小化排障流程
下面的命令可用于检查一个疑似 DNSSEC 故障的域名。运行前把 example.com 替换成目标域名，并确保本机安装了 dig。
DOMAIN=example.com
# 通过本地递归解析器查询，并请求 DNSSEC 数据
dig "$DOMAIN" A +dnssec
# 使用公共验证解析器交叉检查
dig @1.1.1.1 "$DOMAIN" A +dnssec
dig @8.8.8.8 "$DOMAIN" A +dnssec
# 查看父区发布的 DS 和域名自身的 DNSKEY
dig "$DOMAIN" DS +dnssec
dig "$DOMAIN" DNSKEY +dnssec
# 沿委派链逐级检查解析过程
dig "$DOMAIN" A +trace +dnssec
重点观察状态码是否为 SERVFAIL、响应中是否存在 ad 标志，以及 DS 记录能否与当前 DNSKEY 建立有效信任链。不同解析器结果不一致，可能意味着缓存尚未更新、轮换仍在传播，或者只有部分验证路径失败。
还可以用一个简单脚本从按分钟导出的 CSV 中标记异常下降。下面假设文件包含 timestamp、scope、requests 和 baseline_requests 四列；字段设计是一个可改造的实践示例，并非特定遥测平台的固定导出格式。
#!/usr/bin/env python3
import csv
import sys
if len(sys.argv) != 2:
raise SystemExit(f"Usage: {sys.argv[0]} telemetry.csv")
with open(sys.argv[1], newline="", encoding="utf-8") as source:
rows = csv.DictReader(source)
required = {"timestamp", "scope", "requests", "baseline_requests"}
if not required.issubset(rows.fieldnames or []):
raise SystemExit(f"CSV must contain: {', '.join(sorted(required))}")
for row in rows:
current = float(row["requests"])
baseline = float(row["baseline_requests"])
if baseline <= 0:
continue
change = (current - baseline) / baseline
if change <= -0.50:
print(
f'{row["timestamp"]} scope={row["scope"]} '
f'drop={abs(change):.1%} requests={current:g}'
)
保存脚本后可这样运行：
python3 detect_drop.py telemetry.csv
50% 阈值只能作为调查入口，不能直接用于归因。生产环境还应要求异常持续多个采样周期，并按地区和 ASN 比较同步性，避免把夜间低谷、节假日或单一大客户离线当作重大中断。
从检测走向可靠归因
面对重大互联网中断，可以采用一份简短检查表：确认异常是否超出历史基线；拆分地理区域和网络；检查 BGP 与 DNSSEC；寻找电力、灾害或政策事件的独立证据；记录恢复是瞬时完成还是分阶段发生。
自然灾害、政府干预和 DNSSEC 轮换可能产生相似的用户表象，却需要完全不同的响应。流量遥测最有价值的地方，不是提供一个过早的结论，而是缩小故障范围、验证时间线，并指导团队获取下一组证据。