境外主机访问变慢或连接失败，先要分清问题是“服务不可达”，还是“经过的网络路径异常”。境外主机供应商的网络连通性测试方法，通常不是在主动探测和路由追踪之间二选一，而是先确认目标端口，再按需要追查路径。前者回答能不能连、表现如何；后者帮助判断流量在哪一段可能受阻。
两种测试回答的问题不同
| 方法 | 能观察什么 | 适用情况与局限 |
|---|---|---|
| 主动探测 | 目标主机或服务是否响应，以及往返时延、丢包率等表现。 | 适合做基础可用性检查和定时监测；结果受探测协议、目标服务状态和本地网络影响。 |
| 路由追踪 | 数据包经过的路由节点及各段响应情况。 | 适合进一步排查路径变化或疑似中间链路问题；部分路由器不回应探测，显示超时不等于该处转发故障。 |
主动探测可以使用 ICMP 回显，也可以直接检测实际业务端口，例如网站常用的 TCP 443。若主机禁止 ICMP，ping 没有回应并不能证明网站无法访问；应再检查 TCP 连接或实际页面。路由追踪则可使用 traceroute 类工具或 MTR，观察多个探测周期里的路径和响应变化。两者测量对象不同，不能把某一跳的高延迟直接当作最终用户的实际延迟。
先做主动探测：从业务入口开始
- 选对目标。使用实际访问的域名或服务地址，并确认检测端口与业务一致。测试网站时，检查 TCP 443 比只 ping 主机更贴近用户访问。
- 分时段、换网络测试。在问题发生时和正常时各测几轮；条件允许时，分别从办公室网络、移动网络或另一处云网络发起探测。这样能初步区分本地出口问题与目标侧问题。
- 记录指标。记录是否建立连接、往返时延和丢包率，并保留时间、探测协议、源网络等信息。单次超时可能是偶发现象；不同工具的统计口径也可能不同。
- 核对服务响应。如果端口可连接但应用仍失败，检查应用返回内容、证书或服务日志。网络连通不等于业务功能正常。
例如，用户反馈页面间歇打不开时，先从反馈用户所在网络测试目标域名的 TCP 443，再从另一条网络重复。若后一处稳定、前一处持续失败，应优先检查用户侧出口或两地之间的路径；若两处都能连通但页面报错，则继续看应用层，而不是仅凭 ping 下结论。
再做路由追踪：把异常放回路径中看
- 从出现问题的网络，对同一个目标地址运行路由追踪；域名解析到不同地址时，记录实际测试的地址，避免前后比较对象不同。
- 连续进行数次观察，关注从哪一段开始出现持续的时延升高或丢包，而不是依据单个节点的星号作判断。
- 换一个源网络重复测试，并与主动探测结果对照。如果目标端口探测失败，且多次追踪在相近区段之后持续无响应，可将时间、源网络、目标地址和结果提供给网络服务方协助核查。
- 若中间节点不回应，但末端服务探测正常，通常不必把该节点的超时视为故障。路由设备可能限制或降低对探测报文的响应优先级。
路由追踪显示的是探测报文所见路径，不一定与业务流量完全相同；路由还可能随时间或流量方向变化。因此，追踪结果适合作为定位线索，不能单独证明某个供应商节点存在故障。
怎么选：日常监测与故障排查分开
如果目标是判断服务是否持续可用，优先部署主动探测，探测频率可按业务要求设置；对普通排查，可每隔几十秒到数分钟取样并观察一段时间，但高频探测可能增加请求量，需遵守目标系统的使用规范。若问题是时好时坏、不同网络体验差异明显，或需要了解可能的网络路径，再补充路由追踪。
因此，境外主机供应商的网络连通性测试方法可按“先服务、后路径”的顺序执行：用主动探测确认用户实际依赖的主机和端口，再用路由追踪寻找值得核实的区段。保存多次结果并标注测试环境，比截取一张单次追踪图更有助于判断。
常见问题
路由追踪某一跳显示超时，是否说明网络中断？
不一定。中间设备可能不回应探测报文；若后续节点或目标服务仍有响应，单独一跳超时通常不足以认定故障。
ping 不通，但网站能打开，正常吗？
正常。目标可能屏蔽 ICMP，同时允许 TCP 443 等业务连接。应按实际使用的协议和端口检测。
主动探测和路由追踪哪个更适合持续监测？
通常主动探测更适合持续检查服务可用性和时延；路由追踪更适合在异常发生后辅助定位路径问题。
把结果交给供应商时应提供什么？
提供故障时间、目标地址或端口、测试来源网络、主动探测记录及多次路由追踪结果，并说明问题是否能在其他网络复现。
