标签： 网络排障、mtr、BGP、Cloudflare、运维、故障分析
一、为什么要先判断影响范围？
海外系统突然不可用时，运维人员通常会先检查本地 DNS、出口设备、路由策略和应用配置。但如果同一国家的多个用户在相近时间集中反馈异常，故障点就可能位于企业控制范围之外。
先判断是不是区域性异常，可以避免过早修改配置，也有利于保留现场证据。
Cloudflare 于 2026 年 10 月 27 日发布第三季度断网回顾。2026 年 7---9 月，Cloudflare Radar 共记录 49 起断网事件。需要注意，这些数据来自流向 Cloudflare 客户的流量观测，并不是全球所有网络故障的完整统计。
二、49 起断网事件如何分类？
| 分类 | 次数 | 说明 |
|---|---|---|
| 主动断网 | 19 起 | 其中 18 起为伊拉克考试期间的定时断网，每次约 15---90 分钟；另 1 起情况不同 |
| 停电 | 14 起 | 分布在 10 个国家，可能影响基站、路由器、数据中心及互联互通设施 |
| 自然灾害 | 5 起 | 包括台风、地震、山洪等 |
| 其他未归类事件 | 11 起 | 报告还提及光缆中断、网络攻击和原因不明的单一运营商故障 |
报告没有单独统计光缆损伤次数。正文提到圭亚那运营商因光缆中断断网、俄罗斯远东骨干光缆受损，以及哥伦比亚地震造成光纤设施损坏并引发约四天半断网，但不能据此推导光缆故障的独立总数。
报告还提到，14 起事件在 1 小时内恢复，16 起在 3 小时内恢复。原文没有说明两组是否重叠，因此不能简单相加。
三、三个案例说明故障可能发生在哪些层面
1. 洪都拉斯：互联互通设施停电
2026 年 9 月 10 日，一处网络互联互通设施停电，至少 11 家主要运营商受到影响，全国流量下降 63%，持续约 3 小时。
这个案例说明，关键网络设施的共同依赖可能扩大故障影响范围。即使运营商各自拥有网络设备，也可能受到共享设施的影响。
2. 美国凤凰城：数据中心冷却系统故障
2026 年 8 月 13 日，一处数据中心冷却系统故障，Namecheap 流量几乎归零。
服务不可用并不一定意味着公共网络路径发生中断。托管设施、供电、冷却系统或服务端运行状态，同样可能成为故障源头。
3. 日本熊本：不同接入类型表现不同
地震期间，桌面端流量受到影响，而移动端流量基本未受影响。
这说明，同一地区不同接入类型的表现可能存在差异。排查时需要区分固定网络、移动网络和具体运营商，不能只凭单一用户的结果推断整个地区的网络状态。
四、分层排查：外部观测、AS 查询与 mtr
第一步：查看外部观测平台
先查看 Cloudflare Radar 断网中心：
https://radar.cloudflare.com/outage-center
重点关注目标国家或运营商在故障时段是否出现流量异常。
随后可以使用 IODA 进行交叉验证：
IODA 结合 BGP 路由可见性、主动探测和网络望远镜等数据，提供国家、地区和自治系统等粒度的观测。
如果多个信号在同一时段共同下降，可以增强对区域性异常的判断。但单条曲线异常并不能直接证明整个地区断网。
还要注意时区：Radar 使用 UTC 时间，与北京时间对照时需要加 8 小时。
第二步：查询目标 IP 对应的自治系统
自治系统（AS）可以理解为互联网路由体系中由一个网络主体管理的一组路由资源。
可以使用 Team Cymru 的 whois 服务查询目标 IP：
whois -h whois.cymru.com " -v 203.0.113.10"示例地址 203.0.113.10 是文档专用保留地址，不是实际业务目标。排查时需要替换为真实目标 IP。
获取 AS 编号后，可以回到 Radar 或 IODA 检查该 AS 在相同时间段的流量变化。
例如：
-
国家整体流量明显下降：优先检查区域性异常。
-
国家整体正常，但某个 AS 出现明显异常：进一步核查对应运营商及其上游网络。
-
只有单个服务不可用：还需要排查服务端、DNS 和托管设施。
第三步：使用 mtr 观察网络路径
基本命令：
mtr -rwzc 50 203.0.113.10其中，-r 表示报告模式，-w 使用宽输出，-z 显示 AS 信息（具体支持情况取决于版本），-c 50 表示发送 50 轮探测。
如果目标不回应 ICMP，可以尝试 TCP 443 模式：
sudo mtr -rwzc 50 -T -P 443 203.0.113.10TCP 模式在 Linux 和 macOS 上通常需要管理员权限，且具体参数支持情况取决于 mtr 版本。
判断 mtr 结果时，不要只看某一跳的丢包百分比。
中间路由器可能限制对探测包的回应。如果某一跳显示丢包，但后续节点和最终目标正常，不能据此认定链路存在端到端丢包。
更值得关注的是：丢包是否从某一跳开始，并持续影响后续节点直到最终目标。
五、如何根据结果确定下一步？
| 观测结果 | 优先判断 | 下一步 |
|---|---|---|
| 目标国家整体流量明显下降 | 区域性异常或基础设施故障 | 留存时间点，持续观察恢复并通知业务方 |
| 国家整体正常，但某个 AS 异常 | 单一运营商问题 | 联系对方核实运营商状态 |
| 外部平台正常，mtr 在本地出口附近持续异常 | 本地出口或上游路径 | 使用多个目标和多个时段交叉测试 |
| 外部平台和 mtr 基本正常，单个系统不可用 | DNS、应用、主机或托管设施 | 检查服务端状态、域名解析及服务商公告 |
这张表用于缩小排查范围，而不是直接给出根因结论。实际定位仍需要结合业务监控、运营商反馈和服务端日志。
六、间歇性故障如何留存证据？
单次 mtr 只能反映某个时刻的路径状态。如果故障间歇出现，建议在异常时段定时采样，将结果与 Radar、IODA 的曲线进行对照。
下面是一个简单的 Bash 示例，每隔 5 分钟执行一次 mtr，默认采样 12 次：
#!/usr/bin/env bash
# 用法：bash mtr_log.sh <目标IP> [采样次数]
target="$1"
times="${2:-12}"
if [[ -z "$target" ]]; then
echo "用法：bash mtr_log.sh <目标IP> [采样次数]"
exit 1
fi
for i in $(seq 1 "$times"); do
ts=$(TZ=Asia/Shanghai date +%Y%m%d_%H%M%S)
mtr -rwzc 20 "$target" \
> "mtr_${target}_${ts}.txt" 2>&1
sleep 300
done使用前需要确认：
-
本机已安装 mtr。
-
目标 IP 参数有效。
-
当前用户具有必要的执行权限。
-
输出目录可写，且日志文件符合内部数据管理规范。
脚本记录的是路径观测结果，并不等于完整的网络日志。
另外，脚本文件名使用北京时间，而 Radar 使用 UTC。对照数据时，需要将北京时间减去 8 小时。
七、排查时需要注意的局限
-
外部观测存在覆盖边界。 Radar 主要观察流向 Cloudflare 客户的流量，不代表整个互联网。
-
平台没有标注，不等于没有故障。 短时异常可能尚未出现在事件列表中，或在标注前已经恢复。
-
中间节点丢包不等于端到端丢包。 需要结合后续节点、最终目标和其他观测数据。
-
网络路径正常不代表应用正常。 DNS、证书、应用进程、主机资源和托管设施都可能影响访问。
-
单次测试可能错过短时故障。 重复采样和统一时区有助于建立完整的证据链。
结语
排查海外网络故障，可以按照"外部观测 → 目标 AS → mtr 路径 → 目标服务与托管设施"的顺序推进。
重点不是尽快修改配置，而是先建立足够的证据，确认故障影响范围，再逐层缩小故障域，避免将区域性异常误判为本地网络问题。