排查网络连通性问题时，连通测试负责回答“通不通”，路径测试负责回答“断在哪”，两者不是替代关系，先做连通测试快速定位范围，再用路径测试逐跳找断点，通常更有效。
连通测试和路径测试各自在解决什么问题
网络故障排查最怕乱试,工具选错，时间翻倍，先搞清楚两类工具的本质区别，后面操作才有方向。
- 连通测试：典型代表是ping，它发送ICMP回显请求，目标主机收到后返回回显应答，只要收到应答，就说明IP层可达。
- 路径测试：典型代表是tracert或traceroute，它利用TTL逐跳递减机制，让路径上的每一台路由设备返回超时信息，从而画出完整转发路径。
用一句话概括：连通测试只关心终点是否可达，路径测试关心中间经过哪些节点。
两者输出信息差异明显,下表可以直观对比。
| 维度 | 连通测试 | 路径测试 |
|---|---|---|
| 回答的问题 | 通不通 | 断在哪一跳 |
| 典型命令 | ping | tracert、traceroute |
| 主要协议 | ICMP echo | ICMP TTL exceed |
| 输出信息 | 丢包率、延迟 | 每一跳IP、延迟 |
| 局限 | 看不到中间节点 | 部分节点可能不回应 |
理解这个区别后,选择工具就不难，接下来拆解具体场景。
ping和tracert哪个排查网络故障更准？场景决定工具
很多运维新手会问：ping和tracert哪个排查网络故障更准？这个问题本身把两类工具对立起来了，实际并不存在绝对的“更准”，只有场景匹配度更高。
先跑连通测试的三种典型场景
当你还不确定问题出在本地、局域网还是远端时，连通测试是成本最低的第一步。
服务器ping不通怎么解决
服务器突然失联,先不要急着上tracert。
- 先ping服务器公网IP,观察是否丢包。
- 如果丢包率接近100%，先登录云控制台检查安全组或防火墙是否禁用了ICMP。
- 同时确认服务器是否处于运行状态,公网带宽是否耗尽。
- 如果ping域名不通但ping IP通，说明DNS解析出问题，优先排查域名解析。
这类场景下,连通测试已经能排除掉一大半问题，路径测试反而会因为目标禁ping而显示最后几跳全超时，让判断更混乱。
局域网不通怎么排查
办公网里某台电脑上不了网,第一动作也是ping。
- ping网关地址,例如192.168.1.1。
- 如果ping不通,问题大概率在二层：网线松动、交换机端口故障、VLAN配置错误。
- 如果ping网关通但ping外网IP不通,问题在网关的上行链路或NAT。
- 如果ping外网IP通但ping域名不通,问题在DNS服务器。
局域网内设备通常只有一两跳,路径测试意义不大，连通测试足够快速锁定范围。
网络丢包怎么测试
网络时通时断、游戏卡顿、视频会议花屏，这类问题要测丢包。
- 单纯ping只能看到终点丢包率,看不到丢包发生在哪一段。
- 此时应该改用mtr或pathping,它们结合连通测试和路径测试，逐跳统计丢包率和延迟。
- 如果某一跳开始丢包率明显上升,故障点就在该跳与下一跳之间。
- 如果没有权限使用mtr,可以分段ping：分别ping网关、运营商接入IP、对端IP，缩小范围。
网络连通性测试命令有哪些？从基础到组合
很多人以为网络连通性测试只有ping,实际常用命令不止一个，按使用频率和功能分层如下。
基础连通测试
- ping：最常用，测试IP层可达性，Windows用
ping 目标地址 -t持续测试，Linux用ping -c 10 目标地址控制次数。 - telnet：测试TCP端口连通性，例如
telnet 目标IP 80，如果端口通，会进入黑屏或返回连接成功信息。 - nc：Linux下替代telnet，命令更简洁，
nc -zv 目标IP 端口号。
路径测试
- tracert：Windows自带，
tracert -d 目标地址，-d表示不解析主机名，速度更快。 - traceroute：Linux自带，
traceroute -n 目标地址
-n同样跳过域名反解。 - pathping：Windows下的组合工具，先做路径测试，再对每一跳做连通测试统计丢包。
- mtr：Linux下的组合工具，
mtr -r -c 100 目标地址可生成报告，适合长时间监测。
辅助定位命令
- arp -a：查看本机ARP表，判断局域网设备是否在同一二层网络。
- nslookup或dig：测试域名解析是否正常，属于连通性排查的前置步骤。
- ipconfig /all或ip addr：查看本机IP、掩码、网关、DNS配置。
这些命令不需要全部背下来,日常排查中，ping、tracert、mtr、telnet四个基本能覆盖大多数场景。
排查网络连通性问题的高效顺序：先连通后路径
行业共识认为,网络故障排查应遵循从近到远、从简单到复杂的原则，落实到操作上，就是先连通测试，再路径测试。
推荐执行顺序
- 第一步：ping 127.0.0.1，验证本机TCP/IP协议栈是否正常。
- 第二步：ping 本机IP，验证网卡驱动和IP配置。
- 第三步：ping 网关IP，验证局域网连通性。
- 第四步：ping 对端IP，验证跨网段连通性。
- 第五步：如果以上全通但业务端口不通，用telnet或nc测端口。
- 第六步：如果ping丢包或不通，再上tracert或mtr定位断点。
这套顺序每一步都能排除一个层级,比一上来就tracert更省时间。
为什么不要一上来就做路径测试
路径测试并非不好,只是启动成本高。
- 每一跳都要等超时,整条路径跑完可能需要几十秒甚至几分钟。
- 如果目标主机禁ping,路径测试最后几跳会显示超时，容易误判为故障。
- 路径测试会经过运营商骨干网,不同时间结果可能不同，需要多次采样才能下结论。
先把连通测试做完,拿到明确结果再决定是否做路径测试，这是多数运维人员的实际操作习惯。
北京机房网络故障排查工具怎么选？实际运维视角
地域场景下的网络故障往往更复杂,以北京机房托管服务器为例，跨地域访问慢或丢包时，工具选择有讲究。
北京到其他地域的链路问题
- 如果从北京访问上海、广州的服务器延迟突然升高，优先用mtr做路径测试。
- 路径测试能看到经过哪些骨干网节点,如果绕路到其他省份，说明运营商路由策略变化。
- 单纯ping只能看到延迟升高,看不到绕路的具体位置，无法推动运营商处理。
北京机房内部安全策略差异
- 相当一部分北京机房默认禁ping,尤其是金融、政务类机房。
- 此时连通测试会显示超时,但业务端口可能正常。
- 改用telnet测80、443端口，比反复ping更有效。
- 路径测试也可能因为机房防火墙丢弃ICMP而失去精确度,需要结合端口测试。
同城与跨城区别对待
- 北京同城机房之间,网络跳数少，路径测试价值有限。
- 跨城尤其是跨运营商访问,路径测试能定位到电信、联通、移动之间的互联瓶颈。
- 如果目标在海外,优先使用mtr并拉长采样时间，单次tracert结果参考意义不大。
网络故障排查没有万能工具,连通测试是快筛，路径测试是精确定位，先ping判断通不通，不通再用tracert或mtr找断点，端口问题交给telnet，把这套顺序变成肌肉记忆，比纠结哪个工具更有效要实际得多。
Q&A
排查网络连通性问题用连通测试还是路径测试更有效？
如果当前不知道网络是否通,先用连通测试，如果已经确认不通或时好时坏，再用路径测试看断在哪一跳，两者配合使用，比单独依赖某一种工具效率更高。
网络连通性测试中ping不通但tracert能通是什么原因？
目标主机可能开启了防火墙,禁用了ICMP回显应答，但路由设备仍然返回TTL超时信息，因此路径测试能看到每一跳，终点却一直超时，这说明网络路径本身是通的，问题出在目标主机的安全策略上。
局域网不通怎么排查时先ping还是先tracert？
先ping网关,局域网内一般只有一跳，tracert看不到更多有效信息，ping网关不通，优先检查网线、交换机端口、VLAN和本机IP配置。