多地域网络监控的证据链：从告警到根因定位的实战方法

很多监控系统只能告诉我们“某个地区访问失败”，但这句话还不足以回答真正的问题：是 DNS 返回错了地址，还是 TCP 没有建立连接？是 TLS 握手失败，还是 HTTP 被 WAF 或源站拒绝？如果没有分层证据，排障很容易变成反复刷新、切换线路和猜测。

下面整理一套与具体云厂商无关的排查流程，适用于 Linux 服务器、网站、API、CDN 回源以及跨地区探测节点。

1. 先固定故障窗口和观测条件

先记录故障开始和恢复时间，并注明时区。每个探测样本至少保留：

• 探测地区、运营商和出口网络；
• 域名、端口、IPv4/IPv6 及使用的解析器；
• 原始命令、完整输出、状态码和请求时间；
• 节点本地时间、探测程序版本和重试次数。

同一故障窗口内尽量使用相同参数。否则不同地区、不同解析器和不同超时时间混在一起，最后只能得到“偶尔失败”这种无法复核的结论。

2. DNS：先确认解析结果，再谈线路问题

分别查询 A 和 AAAA，并用至少两个递归解析器做对照：

dig +short A example.com
dig +short AAAA example.com

如果只有某一个解析器异常，优先检查缓存、TTL、权威 DNS、DNSSEC 和区域线路策略；如果多个解析器都返回相同地址，就不要继续反复修改 DNS，应进入连接层排查。

还要注意：解析正常不等于客户端一定会访问同一台机器。CDN、Anycast、智能解析和 IPv6 优先级都可能让不同地区得到不同的实际路径。

3. TCP：把 IPv4、IPv6 和端口分开测试

可以先用 curl 观察连接阶段：

curl -4svI --connect-timeout 10 https://example.com/
curl -6svI --connect-timeout 10 https://example.com/

如果 IPv4 成功而 IPv6 失败，重点检查 AAAA、路由、监听地址和防火墙；如果 DNS 正常但两种地址都无法建立连接，再查看安全组、源站监听和中间网络。

不要只看 Ping。ICMP 被限速或禁用很常见，TCP 443 能否建立连接才更接近真实业务路径。

4. TLS：TCP 成功后再判断证书和 SNI

TCP 三次握手完成后，使用带 SNI 的握手检查：

openssl s_client -connect example.com:443 -servername example.com -brief

重点核对握手是否完成、证书链是否完整、主机名是否匹配、有效期是否过期，以及协商出的协议和密码套件。浏览器显示的“证书错误”只是最终结果，不能替代握手日志。

5. HTTP：记录完整响应，而不是只看状态码

建议保存响应头和错误信息：

curl -sv -D response.headers -o /dev/null https://example.com/

需要区分 301/302 跳转、403/WAF 拒绝、源站 5xx、连接超时和空响应。对 API 还应记录请求 ID、Host、Location、缓存状态以及上游耗时，这些字段往往能帮助定位到底是边缘节点还是源站返回了结果。

6. 用“地区 × 协议 × 层级”建立探测矩阵

单个节点失败只能说明一个观测点异常。更可靠的方式是把结果按矩阵保存：

如果只有某一地区的 DNS 地址不同，优先看智能解析；如果 DNS 相同但 TCP 失败，优先看路由或防火墙；如果 TCP 成功而 TLS 失败，重点看证书链和 SNI；如果 TLS 成功而 HTTP 异常，再检查 WAF、反代和应用日志。

7. 减少误判的几个细节

• MTR 或 traceroute 中间某一跳丢包，不代表端到端丢包；要结合最后一跳和应用层结果。
• 多个探测节点同时失败，才更像公共依赖或源站问题；单节点失败可能是节点自身故障。
• CDN 的边缘响应和源站直连响应要分开记录，不能用其中一方替代另一方。
• 重试必须有上限，并保留第一次失败和最后一次成功，避免只留下“恢复后”的漂亮结果。
• 监控程序、探测节点和日志接收端要分离，单台节点故障不应让所有历史证据一起消失。

8. 一份可复用的故障记录模板

incident_start: 2026-10-07T08:30:00+08:00
incident_end: 2026-10-07T08:46:00+08:00
region: 华东 / 电信
hostname: example.com
resolver: 运营商递归 DNS
addresses:
  ipv4: [203.0.113.10]
  ipv6: [2001:db8::10]
checks:
  dns: ok
  tcp4: ok
  tcp6: timeout
  tls: ok
  http: 200
raw_logs: /path/to/incident-20261007/
conclusion: IPv6 路径异常，业务 IPv4 正常

这份记录的价值在于：即使故障已经恢复，之后仍能复盘当时究竟是哪一层出了问题，而不是凭记忆修改配置。

结语

网络故障排查的核心不是收集更多“看起来有用”的指标，而是让每一个结论都能由下一层证据验证。先固定观测条件，再按 DNS、TCP、TLS、HTTP 的顺序逐层排查，最后用多个地区和多个协议做交叉对照，通常比盲目切换 DNS 或 CDN 更快得到可复现的答案。无论使用现成平台还是自建探测 Agent，都建议保留原始输出和统一的记录格式，这样监控才真正能服务于定位和复盘。

本作品采用《CC 协议》，转载必须注明作者和本文链接