先别急着改配置：先判断故障影响了谁
海外系统突然打不开，常见动作是检查本机、出口和应用配置。
但如果一个国家的多个客户在同一时间集中反馈异常，故障点就未必在企业自己的网络里。供电、互联互通设施、运营商和数据中心，都可能影响最终访问体验。
Cloudflare 于 2026 年 10 月 27 日发布的第三季度断网回顾显示，2026 年 7—9 月，Cloudflare Radar 共记录 49 起断网事件。其中主动断网 19 起、停电 14 起、自然灾害 5 起，另有 11 起未归入前三类。
这些数据来自 Cloudflare 的流量观测，并非全球所有网络故障的完整统计。
第一步：看外部观测平台
先打开 Cloudflare Radar 断网中心：
radar.cloudflare.com/outage-cent…
查看目标国家或运营商在故障时段是否出现流量异常。不要只看事件列表，也要查看相应时间段的流量曲线。
再用 IODA 交叉验证：
IODA 综合 BGP 路由可见性、主动探测和网络望远镜等信号。多类指标在同一时间窗口内共同下降，更能支持“大范围异常”的判断。
不过，不同指标的观测对象和测量方式不同。指标没有同步变化，不代表故障一定不存在；单一指标下降，也不能直接认定整个地区断网。
还有一个容易忽略的细节：Radar 使用 UTC 时间，北京时间需要加 8 小时。
第二步：查目标 IP 对应的 AS
如果只有某个合作方或目标服务无法访问，可以先查询目标 IP 对应的自治系统（AS），再回到 Radar 或 IODA 检查该 AS 在同一时段的变化。
whois -h whois.cymru.com " -v 203.0.113.10"
这里的 203.0.113.10 是文档专用保留地址，实际使用时需要替换为目标 IP。
查询得到 AS 编号后，可以结合外部观测进一步判断：
- 如果国家整体流量下降，优先考虑区域性异常。
- 如果国家整体正常，但某个 AS 流量明显下降，可以重点核查对应运营商。
- 如果外部观测没有明显异常，则需要继续检查路径、DNS 和服务端状态。
AS 信息提供的是网络归属线索，不是故障根因的直接证明。
第三步：用 mtr 看异常是否持续到目标
基础命令：
mtr -rwzc 50 203.0.113.10
如果目标不回应 ICMP，可以尝试 TCP 443 模式：
sudo mtr -rwzc 50 -T -P 443 203.0.113.10
第二条命令适用于目标不回应 ICMP 的场景，通常需要管理员权限；具体参数支持情况取决于 mtr 版本。
读结果时，最容易出现的误判是：中间某一跳丢包，就认定链路出了问题。
实际上，中间路由器可能限制探测包回应。如果某一跳显示丢包，而后续节点和最终目标正常，不能直接认定存在端到端丢包。
更值得关注的是，丢包是否从某一跳开始，并持续影响后续节点直到最终目标。即便如此，也仍需结合其他观测进行确认。
三层结果如何组合？
| 现象 | 优先判断 | 下一步 |
|---|---|---|
| 国家整体流量下沉 | 区域性异常 | 留存时间点，观察恢复并通知业务方 |
| 国家正常，某个 AS 异常 | 单一运营商故障 | 联系对方确认运营商状态 |
| 外部观测正常，mtr 在本地出口附近持续异常 | 本地出口或上游路径 | 用多个目标、多个时段交叉测试 |
| 外部观测和 mtr 基本正常，单个系统不可用 | 应用、DNS、主机或托管设施 | 检查服务端状态和服务商公告 |
这张表的作用是帮助确定下一步调查方向，而不是仅凭某个信号直接定责。
报告中的案例提醒我们：故障不只是链路问题
洪都拉斯： 2026 年 9 月 10 日，一处互联互通设施停电，至少 11 家主要运营商受影响，全国流量下降 63%，持续约 3 小时。
美国凤凰城： 2026 年 8 月 13 日，一处数据中心冷却系统故障后，Namecheap 流量几乎归零。
日本熊本： 地震期间，桌面端流量受到影响，而移动端流量基本正常。
这三个案例分别提醒我们：共享基础设施、托管机房和接入类型，都可能影响故障的表现形式。
报告没有单独统计光缆损伤次数。正文提到圭亚那、俄罗斯远东和哥伦比亚地震中的光缆或光纤损坏，但不能据此推导光缆故障的独立总数。
两个常见误判
误判一：中间一跳丢包，就是链路断了
不一定。路由器可能降低对探测包的回应优先级。
如果中间节点丢包，但后续节点和最终目标正常，就不能仅凭这一跳判定端到端故障。mtr 用于缩小排查范围，不是独立的根因判定器。
误判二：平台没有标注，就说明没有大范围故障
短时故障可能早于平台标注，或者在标注前已经恢复。
应查看同一时段的流量曲线，并使用不同数据源交叉验证。排查时也要统一时区，避免将监控时间差误认为故障开始或结束时间不一致。
间歇性故障怎么留证？
如果问题时有时无，建议在故障时段每 5 分钟采样一次 mtr，并记录：
- 目标 IP 和探测方式。
- 执行时间及使用的时区。
- 每次命令输出。
- Radar、IODA 同一时段的观测结果。
- 业务端实际出现异常的时间。
单次 mtr 只反映某个时刻的路径状态，重复采样更有利于识别间歇性异常。日志中可能包含业务网络信息，应按照内部规范保存和管理。
结论
海外网络故障排查，可以记成一条路径：
国家或运营商流量 → 目标 AS → mtr 路径 → 服务与托管设施。
先确定影响范围，再定位网络层级，最后决定是否需要调整本地配置。工具提供的是证据，不是自动给出根因的裁决器。
