朋友前几天跟我吐槽说家里网络一到晚上就卡得不行视频会议断断续续我第一反应就是让他打开命令行敲一条命令tracert -d www.test.cn。不少人对ping很熟但一说到tracert就犯怵觉得输出密密麻麻看不懂也有人知道这命令能查路由却不知道为什么后面要跟个-d不加行不行。今天我就把tracert -d这件事彻底讲透。它会成为你排查网络问题、判断“卡在哪一跳”最顺手的工具之一而且非常适合以下这几类人经常被网络故障折腾的运维和开发、家里网络环境复杂想自己定位问题的普通用户以及正在学网络基础、想把抽象概念落到实操上的学生。全程以www.test.cn为例你拿到手就能照着跑一遍。1. 先搞懂 tracert 到底在做什么1.1 它和 ping 最大的不同沿途每一站都给你报一遍ping用来确认“目标通不通”但它只告诉你结果不告诉你路上发生了什么。数据包从你的电脑出发到目标服务器中间要经过很多台路由器就像一个包裹从北京寄到广州中途要经过好几个转运中心。tracert干的事情就是让数据包每路过一个转运中心都给你打一次卡并把打卡记录逐一列出来。这个“打卡”机制依赖的是IP协议里的TTLTime To Live字段。TTL是一个数字每经过一台路由器就减1减到0时路由器会丢弃这个包并给发送方回一条ICMP超时消息。tracert正是利用这一点先发一个TTL1的包第一台路由器收到后TTL变0回包于是你就知道了第一跳是谁再发TTL2的包第一台路由器正常转发第二台路由器TTL变0回包于是知道了第二跳。依此类推直到数据包到达目标主机或者TTL达到上限Windows默认30。注意理解一个容易混淆的点第一跳显示的是你本机的网关通常是家庭路由器或企业出口设备而不是你本机自己。所以如果你看到第1跳延迟就已经很高那问题很可能出在局域网内部而不是运营商。1.2 为什么说是 “最有性价比” 的网络排查工具排查网络问题很多人习惯先ping一下不通就重启路由器完全没有头绪。tracert的价值在于它把“整个网络路径”拆成了一段一段的帮你把故障范围缩小到“某一跳”甚至“某一段”。举个例子你访问某个网站很慢。ping通了说明链路是通的但到底慢在哪儿是家里Wi-Fi不稳是运营商出口拥塞还是目标服务器的机房带宽不足这些从ping的结果里很难看出来但tracert可以如果前两跳延迟正常到了第三跳延迟突然飙到几百毫秒那瓶颈大概率就在第三跳附近的设备或线路。这种“定位中间环节”的能力是ping不具备的。2. -d 参数到底值不值老手为什么默认带它2.1 不加 -d 的时候会发生什么tracert www.test.cn默认会在显示每一跳IP地址的同时尝试对这个IP做“反向域名解析”——把IP地址解析成一个域名。比如看到61.148.3.34它会尝试解析成类似61.148.3.34.broad.bj.bj.dynamic.163data.com.cn这样的名字。这个解析过程本身没有问题但在实际使用中很拖后腿慢每一跳都等反向解析如果某个IP没有配置PTR记录通常要等好几秒超时。本来几秒钟能跑完的追踪可能拖到一分钟。噪音大解析出来的域名又长又难记一多就把关键IP信息淹没了屏幕上一堆类似于123.123.123.123.broad.xxx.xxx.dynamic.cache.xxx的字符串看着头大。不稳定反向解析依赖DNS服务器DNS如果抽风整个tracert输出会变得奇慢无比甚至卡在某一行不动。所以-d参数的作用就一句话不要做反向域名解析直接显示IP。加了它输出干净利落速度也快得多。2.2 完整参数速查与适用时机在Windows的tracert命令里-d只是其中一个参数。我把日常会用到的几个整理成一张表方便直接对照参数作用我的使用建议-d不解析IP为域名直接显示IP日常排查默认带上速度快、输出干净-h指定最大跳数默认30追踪境外或跨洋链路时如果路径很长可以调大到50甚至更多-w指定超时时间毫秒默认4000网络差或跨运营商时建议调小到1000~2000不然等太久-j指定松散源路由仅IPv4特殊场景才会用一般不用碰-6强制使用IPv6进行追踪目标只有IPv6地址时用Linux和macOS上对应的命令叫traceroute参数差异比较大常用的反而是-n不做反向解析功能类似Windows的-d和-I改用ICMP探测。如果你换了环境别下意识以为tracert -d在Linux上也能用以下是我个人踩过的坑后文专门说。3. 手把手实操从命令到完整解读3.1 执行前你应该准备什么执行tracert -d www.test.cn之前我建议你先做两个小动作能让后面的结果更有参考价值第一先ping一下目标域名确认目标地址本身是通的。如果ping都不通tracert大概率会一路超时或在中途断掉但那本身就是有用的诊断信息。同时ping的结果也能给你一个“终点延迟”的参考值方便对比tracert最后几跳的数值。第二确认自己当前在哪个网络环境。同一个域名在公司光纤、家里宽带、手机热点三种环境下跑出来的tracert结果差异非常大。如果是在排查某个具体问题尽量在问题发生的那个网络环境里跑别在别的网络环境下排队否则容易误判。运行的时候没什么讲究直接在命令行里敲。Windows按WinR输入cmd回车然后执行tracert -d www.test.cn3.2 输出的每一行到底告诉了我们什么下面是一次典型的输出示例数据实际结果取决于你的网络环境通过最多 30 个跃点跟踪 到 www.test.cn [93.184.216.34] 的路由: 1 1 ms 1 ms 1 ms 192.168.1.1 2 12 ms 10 ms 11 ms 100.64.0.1 3 15 ms 14 ms 14 ms 61.148.3.113 4 * * * 请求超时 5 21 ms 20 ms 23 ms 202.97.35.69 6 28 ms 29 ms 28 ms 219.158.99.77 7 38 ms 37 ms 38 ms 93.184.216.34我们逐行拆解第一行是提示信息说明最多追踪30跳目标域名解析后的IP是93.184.216.34。这一步就已经完成了DNS解析所以加了-d只会影响后续每一跳的显示不影响目标地址的解析。每一行对应一跳路由器。每行后面跟的三个时间是tracert对同一跃点连续探测三次的往返延迟单位是毫秒。三个时间都短说明这一跳很健康三个时间忽大忽小说明这一跳设备负载高或者链路质量不稳定。192.168.1.1是家用路由器的典型IP即第1跳网关。延迟1毫秒说明局域网内部非常健康。100.64.0.1属于运营商级NAT地址说明你家宽带用了运营商的大内网IP这是在很多家庭宽带场景下的正常现象不代表有问题。到第4跳出现* * *说明这一跳没有响应ICMP超时消息。到底是不是故障要看后续是否恢复正常。如果后续跳数正常显示且延迟平稳那多半是这台路由器出于安全策略不响应探测属常见现象不必紧张。最后到达目标地址93.184.216.34延迟38毫秒对照前面ping的结果链路整体是健康的。3.3 出现星号*到底是不是坏事很多新手看到* * *就慌了以为网络断了。我的经验是星号必须结合上下文来看。如果只有某一跳是星号前后几跳都正常那大概率是这一跳的路由器配置了“不响应ICMP超时消息”的规则。很多骨干网设备出于性能和安全的考虑会丢弃这类探测包但不影响正常数据转发。这种情况我一般直接忽略。如果从某一跳开始后面全部是星号且最后的目标地址也一直超时那就要警惕了。可能是这一跳之后链路中断也可能是目标服务器屏蔽了探测请求。这时候我建议换个目标再测一次比如tracert -d 223.5.5.5阿里DNS如果到223.5.5.5能正常跑通说明是你访问目标的链路问题如果连223.5.5.5都卡在同一个位置说明问题出在中间某段骨干网络。4. 实战案例一次网页打不开的完整排查过程4.1 症状描述与初步判断场景是这样的我朋友反馈公司某个业务系统网页能打开但经常转圈圈图片加载特别慢而其他人访问同一个地址却很快。因为是同一栋楼同一个网络出口问题大概率不在公司出口而在他本机到出口之间或者路由路径上某一段不稳定。我先让他做两件事一是看网页最终能不能打开、要多久二是执行ping www.test.cn -t跑两分钟观察延迟和丢包。结果显示目标地址能通但延迟波动很大从30毫秒到400毫秒都有还伴随少量丢包。这说明链路确实有问题但不知道发生在哪一段。4.2 用 tracert -d 定位到具体故障段接下来我让他执行tracert -d www.test.cn输出关键部分如下1 1 ms 1 ms 1 ms 192.168.1.1 2 10 ms 9 ms 11 ms 100.64.0.1 3 15 ms 16 ms 14 ms 61.148.3.113 4 18 ms 17 ms 18 ms 202.97.35.69 5 * * * 请求超时 6 请求超时 7 320 ms 450 ms 380 ms 219.158.99.77 8 380 ms 410 ms 390 ms 93.184.216.34看第7跳延迟突然飙升到300毫秒以上而且第5、6跳完全无响应。这就非常典型了问题出在第4跳之后、第7跳之前的这一段网络。第5、6跳不响应可能只是设备策略但第7跳延迟剧增说明链路质量已经严重劣化。结合他当时用的是跨运营商网络基本可以判断是跨网互联的拥堵问题。这类问题往往不是终端用户能解决的但有了tracert的结果他在报障时能直接把具体跳数和时间点贴给运营商沟通效率完全不一样。4.3 判断结果并给出对策对于不同情况我给的建议也不一样如果问题出在本地网关第1跳检查家里路由器的Wi-Fi信道、连接设备数或者直接重启路由器通常能解决。如果问题出在运营商接入段第2~3跳先重启光猫不行就报宽带故障把这个跳数的延迟数据发给运营商。如果问题出在骨干网或跨网段第4跳以后个人用户通常只能等待运营商优化或者尝试换一个网络环境测试区分是普遍问题还是个别线路问题。如果问题出在目标服务器机房最后几跳检查服务器本身的负载、带宽、安全策略或者联系服务器提供商。5. 常见问题与排查技巧实录5.1 高频问题速查表我把平时被问得最多的几个问题和对应思路整理成表格方便你直接查阅现象常见原因排查方向某一跳延迟异常高该设备负载高或链路拥塞连续跑多次确认是否持续对比其他目标地址是否同样卡连续多跳超时但目标通路由器屏蔽探测包属正常情况重点看延迟数值和能否到达最终目标第1跳延迟就很高局域网内拥塞或无线干扰检查Wi-Fi信号、连接设备数、网线是否松动到中途某跳后全部超时链路中断或远端丢弃换目标地址再测确认是链路问题还是目标问题不同时间跑结果差异很大网络高峰期拥塞在闲时重测对比确认是否存在规律性劣化目标域名解析慢但tracert快DNS解析问题用nslookup www.test.cn单独查解析耗时5.2 几个能让你少走弯路的实操技巧第一个技巧不要只看一次结果。网络是动态的一次tracert跑出来延迟高可能是瞬间波动不一定是持续故障。我习惯连续跑三次或者隔几分钟再跑一次对比同一跳的延迟变化。如果每次都高或者呈现越来越高的趋势才说明真有稳定问题。第二个技巧用多目标交叉验证。怀疑某个中间节点有问题时分别追踪几个不同的知名地址比如223.5.5.5、114.114.114.114、8.8.8.8看路径中是否都经过同一个异常节点以及异常出现的位置是否一致。多个结果互相印证判断会靠谱得多。第三个技巧注意IPv6的情况。现在很多域名同时有A记录和AAAA记录Windows的tracert默认可能走IPv6。如果你发现第一跳地址是类似fe80::开头的地址说明你走的是IPv6链路此时可以用tracert -6 -d www.test.cn明确走IPv6或者用tracert -4 -d www.test.cn强迫走IPv4便于对比两条路径的差异。第四个技巧把延迟拆成三段来看。我自己在分析tracert输出时习惯把路径拆成三段局域网段第12跳、运营商接入段第23跳、骨干网与目标段第3跳之后。每一段内部的延迟正常范围不同局域网段应该是15毫秒接入段一般在1030毫秒骨干网在几十毫秒级别。数值一旦明显超出对应范围问题就出在这一段这样分析起来思路非常清晰。5.3 别把这些坑踩了不要用tracert的结果直接判断服务器好坏。最后几跳延迟高不一定是目标服务器的责任也可能是接近目标网络的中间链路劣化。要判断服务器的性能应该结合服务器本地的资源监控来看。不要以为tracert每跳显示的IP就是唯一的转发路径。互联网路由是动态的数据包可能走不同的路径到达同一个目标两次tracert看到不同的中间IP是正常的不一定代表路由坏了。不要在企业内网或生产环境频繁跑大流量tracert。虽然tracert本身流量不大但一次会发多个探测包反复跑多个目标时会对网络产生不必要的小压力。在生产环境注意控制频率。6. 一个小扩展把 tracert 和其他工具组合起来用很多人只把tracert当成一个单点工具用完就完了这是浪费。我自己的习惯是遇到问题先ping探活再用tracert -d定位段位最后用pathping看每一跳的丢包率三个命令组合起来基本能覆盖90%的网络链路排查场景。pathping是Windows自带的一个命令可以理解为“tracert ping的结合体”。它会先走一遍路由追踪然后对每一跳做一段时间的统计输出每一跳的丢包率和延迟平均值。这个信息比单独一次tracert更加结构化适合用来分析“某一跳是不是持续丢包”。pathping -d www.test.cn-d参数在这里同样有用表示不做反向解析。这个命令跑起来比较耗时因为它要对每一跳发100个探测包并统计建议耐心等待或者先跑别的排查。举个例子我遇到过一种情况tracert结果中第3跳偶尔超时但整体延迟正常单次tracert看起来好像没问题。用pathping一跑发现第3跳丢包率高达30%但后面的跳数丢包率是0这就直接暴露了问题所在中间某一段链路存在间歇性丢包影响了整体网页访问体验。如果你是Linux/macOS用户更推荐用mtr。它是traceroute的增强版持续刷新每一跳的丢包率和延迟交互界面一目了然。配合-n参数也能跳过反向解析效果和tracert -d异曲同工。我这里再提醒一句命令工具只是辅助最终要结合具体业务场景来下结论。永远别因为某一跳出现了一个星号就急着断定网络故障也别因为整条链路都通畅就觉得一定是服务器问题。多测几次、多对比几个目标、多结合业务现象判断才会越来越准。我个人用tracert -d这么多年最大的体会是它在所有网络排查工具里最“直观”——一眼就能看出流量拐弯去了哪里、卡在哪一段。网络上那些看起来高深莫测的故障很多时候用一条命令就能圈定方向。你也不妨现在就找个时间在命令行里敲一次tracert -d www.test.cn对照着上面的输出解读给自己家网络做一次“链路体检”。跑完你会觉得原来网络排查也没有那么玄乎。
朋友前几天跟我吐槽说家里网络一到晚上就卡得不行视频会议断断续续我第一反应就是让他打开命令行敲一条命令tracert -d www.test.cn。不少人对ping很熟但一说到tracert就犯怵觉得输出密密麻麻看不懂也有人知道这命令能查路由却不知道为什么后面要跟个-d不加行不行。今天我就把tracert -d这件事彻底讲透。它会成为你排查网络问题、判断“卡在哪一跳”最顺手的工具之一而且非常适合以下这几类人经常被网络故障折腾的运维和开发、家里网络环境复杂想自己定位问题的普通用户以及正在学网络基础、想把抽象概念落到实操上的学生。全程以www.test.cn为例你拿到手就能照着跑一遍。1. 先搞懂 tracert 到底在做什么1.1 它和 ping 最大的不同沿途每一站都给你报一遍ping用来确认“目标通不通”但它只告诉你结果不告诉你路上发生了什么。数据包从你的电脑出发到目标服务器中间要经过很多台路由器就像一个包裹从北京寄到广州中途要经过好几个转运中心。tracert干的事情就是让数据包每路过一个转运中心都给你打一次卡并把打卡记录逐一列出来。这个“打卡”机制依赖的是IP协议里的TTLTime To Live字段。TTL是一个数字每经过一台路由器就减1减到0时路由器会丢弃这个包并给发送方回一条ICMP超时消息。tracert正是利用这一点先发一个TTL1的包第一台路由器收到后TTL变0回包于是你就知道了第一跳是谁再发TTL2的包第一台路由器正常转发第二台路由器TTL变0回包于是知道了第二跳。依此类推直到数据包到达目标主机或者TTL达到上限Windows默认30。注意理解一个容易混淆的点第一跳显示的是你本机的网关通常是家庭路由器或企业出口设备而不是你本机自己。所以如果你看到第1跳延迟就已经很高那问题很可能出在局域网内部而不是运营商。1.2 为什么说是 “最有性价比” 的网络排查工具排查网络问题很多人习惯先ping一下不通就重启路由器完全没有头绪。tracert的价值在于它把“整个网络路径”拆成了一段一段的帮你把故障范围缩小到“某一跳”甚至“某一段”。举个例子你访问某个网站很慢。ping通了说明链路是通的但到底慢在哪儿是家里Wi-Fi不稳是运营商出口拥塞还是目标服务器的机房带宽不足这些从ping的结果里很难看出来但tracert可以如果前两跳延迟正常到了第三跳延迟突然飙到几百毫秒那瓶颈大概率就在第三跳附近的设备或线路。这种“定位中间环节”的能力是ping不具备的。2. -d 参数到底值不值老手为什么默认带它2.1 不加 -d 的时候会发生什么tracert www.test.cn默认会在显示每一跳IP地址的同时尝试对这个IP做“反向域名解析”——把IP地址解析成一个域名。比如看到61.148.3.34它会尝试解析成类似61.148.3.34.broad.bj.bj.dynamic.163data.com.cn这样的名字。这个解析过程本身没有问题但在实际使用中很拖后腿慢每一跳都等反向解析如果某个IP没有配置PTR记录通常要等好几秒超时。本来几秒钟能跑完的追踪可能拖到一分钟。噪音大解析出来的域名又长又难记一多就把关键IP信息淹没了屏幕上一堆类似于123.123.123.123.broad.xxx.xxx.dynamic.cache.xxx的字符串看着头大。不稳定反向解析依赖DNS服务器DNS如果抽风整个tracert输出会变得奇慢无比甚至卡在某一行不动。所以-d参数的作用就一句话不要做反向域名解析直接显示IP。加了它输出干净利落速度也快得多。2.2 完整参数速查与适用时机在Windows的tracert命令里-d只是其中一个参数。我把日常会用到的几个整理成一张表方便直接对照参数作用我的使用建议-d不解析IP为域名直接显示IP日常排查默认带上速度快、输出干净-h指定最大跳数默认30追踪境外或跨洋链路时如果路径很长可以调大到50甚至更多-w指定超时时间毫秒默认4000网络差或跨运营商时建议调小到1000~2000不然等太久-j指定松散源路由仅IPv4特殊场景才会用一般不用碰-6强制使用IPv6进行追踪目标只有IPv6地址时用Linux和macOS上对应的命令叫traceroute参数差异比较大常用的反而是-n不做反向解析功能类似Windows的-d和-I改用ICMP探测。如果你换了环境别下意识以为tracert -d在Linux上也能用以下是我个人踩过的坑后文专门说。3. 手把手实操从命令到完整解读3.1 执行前你应该准备什么执行tracert -d www.test.cn之前我建议你先做两个小动作能让后面的结果更有参考价值第一先ping一下目标域名确认目标地址本身是通的。如果ping都不通tracert大概率会一路超时或在中途断掉但那本身就是有用的诊断信息。同时ping的结果也能给你一个“终点延迟”的参考值方便对比tracert最后几跳的数值。第二确认自己当前在哪个网络环境。同一个域名在公司光纤、家里宽带、手机热点三种环境下跑出来的tracert结果差异非常大。如果是在排查某个具体问题尽量在问题发生的那个网络环境里跑别在别的网络环境下排队否则容易误判。运行的时候没什么讲究直接在命令行里敲。Windows按WinR输入cmd回车然后执行tracert -d www.test.cn3.2 输出的每一行到底告诉了我们什么下面是一次典型的输出示例数据实际结果取决于你的网络环境通过最多 30 个跃点跟踪 到 www.test.cn [93.184.216.34] 的路由: 1 1 ms 1 ms 1 ms 192.168.1.1 2 12 ms 10 ms 11 ms 100.64.0.1 3 15 ms 14 ms 14 ms 61.148.3.113 4 * * * 请求超时 5 21 ms 20 ms 23 ms 202.97.35.69 6 28 ms 29 ms 28 ms 219.158.99.77 7 38 ms 37 ms 38 ms 93.184.216.34我们逐行拆解第一行是提示信息说明最多追踪30跳目标域名解析后的IP是93.184.216.34。这一步就已经完成了DNS解析所以加了-d只会影响后续每一跳的显示不影响目标地址的解析。每一行对应一跳路由器。每行后面跟的三个时间是tracert对同一跃点连续探测三次的往返延迟单位是毫秒。三个时间都短说明这一跳很健康三个时间忽大忽小说明这一跳设备负载高或者链路质量不稳定。192.168.1.1是家用路由器的典型IP即第1跳网关。延迟1毫秒说明局域网内部非常健康。100.64.0.1属于运营商级NAT地址说明你家宽带用了运营商的大内网IP这是在很多家庭宽带场景下的正常现象不代表有问题。到第4跳出现* * *说明这一跳没有响应ICMP超时消息。到底是不是故障要看后续是否恢复正常。如果后续跳数正常显示且延迟平稳那多半是这台路由器出于安全策略不响应探测属常见现象不必紧张。最后到达目标地址93.184.216.34延迟38毫秒对照前面ping的结果链路整体是健康的。3.3 出现星号*到底是不是坏事很多新手看到* * *就慌了以为网络断了。我的经验是星号必须结合上下文来看。如果只有某一跳是星号前后几跳都正常那大概率是这一跳的路由器配置了“不响应ICMP超时消息”的规则。很多骨干网设备出于性能和安全的考虑会丢弃这类探测包但不影响正常数据转发。这种情况我一般直接忽略。如果从某一跳开始后面全部是星号且最后的目标地址也一直超时那就要警惕了。可能是这一跳之后链路中断也可能是目标服务器屏蔽了探测请求。这时候我建议换个目标再测一次比如tracert -d 223.5.5.5阿里DNS如果到223.5.5.5能正常跑通说明是你访问目标的链路问题如果连223.5.5.5都卡在同一个位置说明问题出在中间某段骨干网络。4. 实战案例一次网页打不开的完整排查过程4.1 症状描述与初步判断场景是这样的我朋友反馈公司某个业务系统网页能打开但经常转圈圈图片加载特别慢而其他人访问同一个地址却很快。因为是同一栋楼同一个网络出口问题大概率不在公司出口而在他本机到出口之间或者路由路径上某一段不稳定。我先让他做两件事一是看网页最终能不能打开、要多久二是执行ping www.test.cn -t跑两分钟观察延迟和丢包。结果显示目标地址能通但延迟波动很大从30毫秒到400毫秒都有还伴随少量丢包。这说明链路确实有问题但不知道发生在哪一段。4.2 用 tracert -d 定位到具体故障段接下来我让他执行tracert -d www.test.cn输出关键部分如下1 1 ms 1 ms 1 ms 192.168.1.1 2 10 ms 9 ms 11 ms 100.64.0.1 3 15 ms 16 ms 14 ms 61.148.3.113 4 18 ms 17 ms 18 ms 202.97.35.69 5 * * * 请求超时 6 请求超时 7 320 ms 450 ms 380 ms 219.158.99.77 8 380 ms 410 ms 390 ms 93.184.216.34看第7跳延迟突然飙升到300毫秒以上而且第5、6跳完全无响应。这就非常典型了问题出在第4跳之后、第7跳之前的这一段网络。第5、6跳不响应可能只是设备策略但第7跳延迟剧增说明链路质量已经严重劣化。结合他当时用的是跨运营商网络基本可以判断是跨网互联的拥堵问题。这类问题往往不是终端用户能解决的但有了tracert的结果他在报障时能直接把具体跳数和时间点贴给运营商沟通效率完全不一样。4.3 判断结果并给出对策对于不同情况我给的建议也不一样如果问题出在本地网关第1跳检查家里路由器的Wi-Fi信道、连接设备数或者直接重启路由器通常能解决。如果问题出在运营商接入段第2~3跳先重启光猫不行就报宽带故障把这个跳数的延迟数据发给运营商。如果问题出在骨干网或跨网段第4跳以后个人用户通常只能等待运营商优化或者尝试换一个网络环境测试区分是普遍问题还是个别线路问题。如果问题出在目标服务器机房最后几跳检查服务器本身的负载、带宽、安全策略或者联系服务器提供商。5. 常见问题与排查技巧实录5.1 高频问题速查表我把平时被问得最多的几个问题和对应思路整理成表格方便你直接查阅现象常见原因排查方向某一跳延迟异常高该设备负载高或链路拥塞连续跑多次确认是否持续对比其他目标地址是否同样卡连续多跳超时但目标通路由器屏蔽探测包属正常情况重点看延迟数值和能否到达最终目标第1跳延迟就很高局域网内拥塞或无线干扰检查Wi-Fi信号、连接设备数、网线是否松动到中途某跳后全部超时链路中断或远端丢弃换目标地址再测确认是链路问题还是目标问题不同时间跑结果差异很大网络高峰期拥塞在闲时重测对比确认是否存在规律性劣化目标域名解析慢但tracert快DNS解析问题用nslookup www.test.cn单独查解析耗时5.2 几个能让你少走弯路的实操技巧第一个技巧不要只看一次结果。网络是动态的一次tracert跑出来延迟高可能是瞬间波动不一定是持续故障。我习惯连续跑三次或者隔几分钟再跑一次对比同一跳的延迟变化。如果每次都高或者呈现越来越高的趋势才说明真有稳定问题。第二个技巧用多目标交叉验证。怀疑某个中间节点有问题时分别追踪几个不同的知名地址比如223.5.5.5、114.114.114.114、8.8.8.8看路径中是否都经过同一个异常节点以及异常出现的位置是否一致。多个结果互相印证判断会靠谱得多。第三个技巧注意IPv6的情况。现在很多域名同时有A记录和AAAA记录Windows的tracert默认可能走IPv6。如果你发现第一跳地址是类似fe80::开头的地址说明你走的是IPv6链路此时可以用tracert -6 -d www.test.cn明确走IPv6或者用tracert -4 -d www.test.cn强迫走IPv4便于对比两条路径的差异。第四个技巧把延迟拆成三段来看。我自己在分析tracert输出时习惯把路径拆成三段局域网段第12跳、运营商接入段第23跳、骨干网与目标段第3跳之后。每一段内部的延迟正常范围不同局域网段应该是15毫秒接入段一般在1030毫秒骨干网在几十毫秒级别。数值一旦明显超出对应范围问题就出在这一段这样分析起来思路非常清晰。5.3 别把这些坑踩了不要用tracert的结果直接判断服务器好坏。最后几跳延迟高不一定是目标服务器的责任也可能是接近目标网络的中间链路劣化。要判断服务器的性能应该结合服务器本地的资源监控来看。不要以为tracert每跳显示的IP就是唯一的转发路径。互联网路由是动态的数据包可能走不同的路径到达同一个目标两次tracert看到不同的中间IP是正常的不一定代表路由坏了。不要在企业内网或生产环境频繁跑大流量tracert。虽然tracert本身流量不大但一次会发多个探测包反复跑多个目标时会对网络产生不必要的小压力。在生产环境注意控制频率。6. 一个小扩展把 tracert 和其他工具组合起来用很多人只把tracert当成一个单点工具用完就完了这是浪费。我自己的习惯是遇到问题先ping探活再用tracert -d定位段位最后用pathping看每一跳的丢包率三个命令组合起来基本能覆盖90%的网络链路排查场景。pathping是Windows自带的一个命令可以理解为“tracert ping的结合体”。它会先走一遍路由追踪然后对每一跳做一段时间的统计输出每一跳的丢包率和延迟平均值。这个信息比单独一次tracert更加结构化适合用来分析“某一跳是不是持续丢包”。pathping -d www.test.cn-d参数在这里同样有用表示不做反向解析。这个命令跑起来比较耗时因为它要对每一跳发100个探测包并统计建议耐心等待或者先跑别的排查。举个例子我遇到过一种情况tracert结果中第3跳偶尔超时但整体延迟正常单次tracert看起来好像没问题。用pathping一跑发现第3跳丢包率高达30%但后面的跳数丢包率是0这就直接暴露了问题所在中间某一段链路存在间歇性丢包影响了整体网页访问体验。如果你是Linux/macOS用户更推荐用mtr。它是traceroute的增强版持续刷新每一跳的丢包率和延迟交互界面一目了然。配合-n参数也能跳过反向解析效果和tracert -d异曲同工。我这里再提醒一句命令工具只是辅助最终要结合具体业务场景来下结论。永远别因为某一跳出现了一个星号就急着断定网络故障也别因为整条链路都通畅就觉得一定是服务器问题。多测几次、多对比几个目标、多结合业务现象判断才会越来越准。我个人用tracert -d这么多年最大的体会是它在所有网络排查工具里最“直观”——一眼就能看出流量拐弯去了哪里、卡在哪一段。网络上那些看起来高深莫测的故障很多时候用一条命令就能圈定方向。你也不妨现在就找个时间在命令行里敲一次tracert -d www.test.cn对照着上面的输出解读给自己家网络做一次“链路体检”。跑完你会觉得原来网络排查也没有那么玄乎。
