1. tracert 到底是什么一条命令背后的网络追踪逻辑1.1 从“网页打不开”说起tracert 解决什么问题先说个场景。你正在工位上处理一个线上问题用户反馈某个网页或者接口访问很慢甚至直接超时。你第一反应是 ping 一下结果丢包严重或者时延很高。可这时候你只知道“到目标机器网络不稳定”但到底是在哪一段出的问题是本地网关、运营商骨干网、还是目标服务器所在机房你完全不知道。这时候就需要 tracert 出场了。tracert 是 Windows 系统自带的网络诊断命令Linux 和 macOS 上对应的是 traceroute。它的核心能力是把你到目标地址之间经过的每一跳路由器都列出来并测量每一跳的响应时延。说得直白一点你从家里开车去公司ping 只能告诉你全程花了多久而 tracert 能把每个红绿灯、每个收费站、每个路口的时间全部单独标出来。而 -d 参数就是让 tracert 不要费劲去做反向域名解析直接显示 IP 地址。为什么要这么做因为默认情况下tracert 每经过一跳都会尝试把该路由器的 IP 反向解析成域名。这个解析过程本身很慢在 DNS 不可用或者解析超时的情况下一条命令可能要跑好几分钟而加上了 -d整个过程会快得多。这篇文章适合谁看日常接触网络排障的运维、开发、实施工程师以及那些经常需要跟“网络为什么卡”较劲的普通用户。读完你不仅能熟练使用 tracert -d还能看懂输出结果里每一行到底在说什么遇到奇葩网络问题的时候有自己的排查思路。1.2 TTL 机制为什么逐跳追踪能够实现讲 tracert 之前必须先搞懂一个基础概念TTLTime To Live生存时间。IP 包在网络上传输每经过一个路由器TTL 值就会减 1。TTL 的原始设计目的是防止数据包在环路中无限循环避免网络被无效数据包打爆。当 TTL 减到 0 时路由器会丢弃这个数据包并向发送方回送一个 ICMP 超时消息告诉发送方“这个包的寿命到了我把它扔了它死在我这儿了”。tracert 正是利用了这一点。它先发送一个 TTL1 的数据包第一个路由器收到后 TTL 减为 0于是丢弃该包并发回一个 ICMP 超时消息。发送方据此知道了第一跳路由器的 IP 和时延。接着发送 TTL2 的数据包第二个路由器同样处理发送方知道第二跳。如此往复一直到数据包成功到达目标主机。这个原理和“丢一个球听回声判断距离”很像。每次把球扔近一点从回声延迟推算每段路的耗时。只要目标主机不拒绝响应你就能把整条路径一节一节地摸清楚。需要说明的是tracert 默认向目标主机发送的是 ICMP Echo Request 包也就是 ping 包这一点与 Linux 上的 traceroute 默认使用 UDP 包不同我后面会详细展开。整个过程中每一跳通常发送 3 个探测包分别记录三次时延所以你会看到输出里每行有 3 个时间。1.3 -d 参数到底做了什么为什么说它是提速开关tracert 的完整参数里-d 的官方解释是“不将地址解析成主机名”。这句话看起来简单但实际影响很大。默认状态下tracert 在拿到每一跳路由器的 IP 后会发起反向 DNS 查询尝试获得该 IP 对应的域名。比如某跳 IP 是 219.158.6.57反向解析出来可能是 bj141-126-218.bjtelecom.net 这样的域名。这个信息有时候确实有用你能通过域名看出这一跳属于哪个运营商、哪个地区。但问题是反向 DNS 查询不稳定特别是在跨运营商、跨地区的情况下经常出现解析超时。解析超时一次就要等好几秒而一次 tracert 可能要经过 15 跳、20 跳每一跳都等整条命令跑下来非常痛苦。加上 -d 之后tracert 拿到 IP 就直接显示跳过所有反向解析步骤速度提升非常明显。尤其是目标地址比较远、链路跳数多的情况下原本可能跑一分钟现在几秒钟就出结果。这也是为什么我日常排障时tracert 后面几乎永远跟着一个 -d除非我明确需要从路由器域名判断运营商归属才会故意不带 -d 跑一次。注意-d 只是不做反向域名解析并不会影响路由追踪本身的探测逻辑。你看到的 IP、时延、丢包信息都照常输出。2. 核心参数拆解与选型思路-d 只是冰山一角2.1 tracert 全部参数一览除了 -d 你还应该知道什么tracert 的命令格式一般长这样tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] [-R] [-S srcaddr] [-4] [-6] target_name我挑几个常用参数来讲实测下来最有用的是 -h、-w偶尔用 -d 和 -4。参数全称/含义实际用途-dDo not resolve addresses to hostnames跳过反向域名解析显著提速日常排障首选-h maximum_hops最大跳数默认 30目标距离远或中间节点特别多时可以调大到 60 甚至更多-w timeout每个应答等待的超时时间单位毫秒默认 4000网络差时把超时缩短到 1000避免长时间傻等-j host-list松散源路由列表一般用不到需要指定路径测试时才用-R追踪往返路径Windows 下特定场景才用日常很少碰-S srcaddr指定源地址多网卡机器上指定从哪个 IP 发包很实用-4 / -6强制使用 IPv4 / IPv6目标地址同时有 A 和 AAAA 记录时用来指定协议栈这里重点说一下 -w 参数。默认 4000 毫秒是 4 秒如果某一跳的路由器不响应每发一个探测包都要等 4 秒才超时3 个包就是 12 秒。如果连续几跳都不响应光等待时间就非常可观。所以我在常用的排障命令里一般会写成tracert -d -w 1000 www.test.cn把超时缩短到 1 秒既能快速判断“这一跳是否可达”又不会因为等待太久拖慢整体排查节奏。当然如果网络本身很差1 秒可能不够结果会出现大量超时误判这时候可以适当调回 2000 或 3000具体看你所在网络的状况。2.2 为什么 Windows 的 tracert 和 Linux 的 traceroute 不一样这是个经常被忽略、但在实际工作里非常容易踩坑的点。Windows 的 tracert 默认发送 ICMP Echo Request 包而 Linux 的 traceroute 默认发送 UDP 包目标端口从 33434 开始依次递增。两者最终都能实现路由追踪但在防火墙策略各异的生产环境里结果可能完全不同。比如某些路由器或主机只允许 ICMP 通过你用 Linux 的 traceroute 可能到某跳就全超时换成 Windows 的 tracert 却能正常显示。反过来也一样有些节点限流 ICMP但 UDP 探测包能顺利穿过。所以在跨平台对比网络路径时不要因为“换个系统结果不一样”就判断网络有问题先确认两侧使用的探测协议是否一致。还有一个细节目标主机收到 ICMP Echo Request 后正常情况下会回 ICMP Echo Replytracert 据此判断到达终点。但如果目标主机在防火墙层面禁 ping你会看到前面的跳都正常最后一跳却全是超时这时候不代表链路不通只是目标机不回 ICMP 而已。判断方法是看输出里“最后一跳的 IP 是不是目标 IP”如果是说明包其实已经到了只是响应被拦了。2.3 什么场景必须加 -d什么场景需要故意去掉我把日常使用场景分成三类对应的参数选择完全不同。第一类是快速判断链路质量。比如用户反馈访问某系统慢我要在最短时间内知道是“本地网关问题”“运营商中间链路问题”还是“目标机房问题”。这时候必须用 tracert -d因为我要的是速度和跳数分布不是域名。加了 -d10 秒内就能看到整条路径的时延变化快速定位大致故障段。第二类是判断运营商和地域归属。有时候某跳时延特别高我需要知道这一跳是哪个运营商的设备。比如看到 219.158.x.x结合反向解析域名里的 bjtelecom 或 cncgroup能判断是不是跨运营商绕路了。这时候就不能加 -d得让 tracert 自动做反向解析哪怕慢一点也值得。如果不放心可以先用 -d 快速跑一遍拿到跳数再针对特定跳做 nslookup 查询。第三类是深度链路分析。比如配合 -h 增加最大跳数看访问某些海外或者偏远地区的站点是否存在绕路或者结合 -S 指定源地址测试多线服务器的不同线路质量。这种场景一般用完整参数组合而不是单纯加不加 -d 的问题。简单总结默认先跑 tracert -d需要看运营商归属时再跑一次不带 -d 的完整版。3. 实操从「tracert -d www.test.cn」出发的完整排障流程3.1 前期准备先确认目标地址再动手在执行命令之前我习惯先做两个确认。一是确认目标地址是否可达。www.test.cn 本身是 IANA 预留的测试域名正常情况下指向 127.0.0.1 或类似回环测试地址直接用做生产排障没有实际意义。实际工作中我会先把用户反馈的域名或者接口地址确认清楚再用 nslookup 或者 ping 验证一下域名能不能解析出 IPnslookup www.test.cn解析结果里会显示 A 记录或者 AAAA 记录。如果域名都解析不出来那问题可能出在本地 DNS 上这时候做 tracert 也没有意义。二是确认当前机器的网络状态。执行命令前先 ping 一下本地网关确定本机到第一跳是通的。如果本机到网关都不通后面所有路由追踪的结果都是虚的。注意在企业内部环境中很多网络设备开启了 ICMP 限制或者自我保护策略表现为部分跳数不响应不代表链路中断。看到星号先别慌多对比几组数据再下结论。3.2 执行命令与输出解读每一行到底在说什么确认完前置条件后执行核心命令tracert -d -w 1000 www.test.cn假设目标地址可达输出一般长这样以下用保留地址段做示例实际生产环境以你跑的为准通过最多 30 个跃点跟踪到 www.test.cn [203.0.113.10] 的路由: 1 1 ms 1 ms 1 ms 192.168.1.1 2 3 ms 2 ms 2 ms 100.64.0.1 3 5 ms 5 ms 6 ms 202.96.209.5 4 8 ms 8 ms 9 ms 202.97.32.14 5 12 ms 11 ms 12 ms 203.0.113.10 跟踪完成。我们来逐行拆解。第一行的“通过最多 30 个跃点跟踪到”是告诉你默认最大跳数是 30。如果要追踪更远的路径用 -h 参数增加上限。第一列数字是跳数序号代表数据包经过的第几个路由器。第二列到第四列是三次探测的时延单位毫秒。最后一列是这一跳的 IP 地址因为加了 -d所以显示的是 IP而不是域名。从上面的示例可以看出本机 192.168.1.1 是网关1 毫秒左右100.64.0.1 是运营商接入层设备3 毫秒左右202.96.209.5 和 202.97.32.14 是骨干网节点时延在 8-9 毫秒最后一跳直接到了目标 203.0.113.10。整条链路很健康数据包从出口到目标只花了 12 毫秒左右。这里有一个非常重要的观察点如果某一跳的时延突然从 5ms 跳到 50ms且后续跳数都在 50ms 上下波动那么问题大概率出在“时延突增的那一跳”上。如果某一跳不响应显示三个星号 * * *但是下一跳又正常了通常说明这一跳屏蔽了 ICMP链路本身大概率没有断。3.3 基于结果的三类典型判断时延、丢包、绕路拿到了 tracert 的输出下一步就是做判断。我总结了三个最常见的判断模型直接套用就行。**第一类时延持续偏高。**如果每一跳的时延都在 100ms 以上而且从第一跳开始就是这样那大概率是你本地出口带宽拥塞或者本地网络设备性能不足。如果前面几跳正常、从中间某跳开始时延翻倍那问题出在运营商互联互通或者跨地域传输上。判断标准是“时延突增点在哪一段问题就在哪一段”。**第二类丢包严重。**tracert 输出中如果某几跳的时延能出来但另外一些跳偶尔显示超时说明这些节点存在丢包。这时候用 ping -n 100 目标IP 做长时间测试看整体丢包率。如果丢包率超过 2%线路质量已经算很差了超过 10% 会明显影响业务。**第三类绕路。**绕路的典型特征是跳数特别多、时延特别大比如从北京访问上海站点中间经过了 20 多跳时延异常高。这种一般是路由策略和 BGP 选路导致的。遇到这种情况最直接的方法是换一条链路测试比如从另外一家的网络出口访问同一目标对比绕路路径。如果两边都绕路可能目标机房的接入本身就有问题。4. 常见问题与排查技巧实录4.1 全是星号是网络断了还是设备不响应这是最常遇到的问题tracert 跑了半天中间几跳全是 * * *甚至从第一跳开始就是星号。很多新手第一反应是“网络断了”但实际上星号出现的原因很多。**一是设备禁 ping。**很多路由器和防火墙默认禁 ICMP或者做了限速策略。这类设备在 tracert 里就会表现为超时但数据包仍然能正常转发。判断方法如果星号只有几跳后续跳数依然能正常显示并最终到达目标那说明链路本身是通的。**二是目标地址本身不可达。**这时候是从某一跳开始往后全部超时。需要确认目标服务器是否正常运行、防火墙是否放行、路由是否有回程。可以换一个已知正常的公网地址做对比测试比如跟踪 223.5.5.5如果这个地址能正常跟踪说明问题在目标侧如果同样超时问题在你本地网络出口。**三是 MTU 问题。**这个比较隐蔽。有些网络环境存在 MTU 不一致的情况导致大数据包被丢弃而 tracert 发出的探测包可能因为分片策略不同而超时。这种情况下可以尝试用 ping -f -l 1472 目标IP 测试不分片数据包能否通过如果通则说明 MTU 设置有问题。注意不要因为看到星号就手动重启网络设备。先把星号出现的规律记下来逐跳对比结合 ping 结果才能下结论。4.2 前几跳就超时是租户隔离还是路由策略企业网络里经常遇到一种情况本机到网关正常但第二跳就开始超时后面恢复正常。这通常不是故障而是网络设计上的隔离策略。比如云服务器场景下底层虚拟网络设备承担了路由转发功能但本身不回 ICMP所以 tracert 第二跳会显示超时实际上数据包已经正常转发了。再比如部分运营商接入网设备做了安全策略对非必要的 ICMP 消息直接丢弃也会导致类似的输出。遇到这种情况我的建议是不要因为中间某一跳不响应就判定网络故障。连续做三次 tracert 对比如果每次星号出现的位置都一样、且首尾时延正常基本可以断定是设备策略问题不影响业务。4.3 组合诊断tracert 不要单打独斗单靠 tracert 一条命令很难覆盖所有网络场景我日常排障会搭配几个命令组合使用。ping -n 100 目标IP长时间测丢包率和稳定性弥补 tracert 只发 3 个包的不足。pathping 目标IPWindows 自带的命令结合了 tracert 和 ping 的功能。它会先做路由追踪然后对每一跳发送多个探测包做统计。缺点是跑得慢但结果很细致。route print查看本机路由表确认默认网关配置是否正确、有没有错误的静态路由干扰。nslookup 域名确认 DNS 解析结果排除解析异常导致的“连不上”。举个例子用户反馈“某系统非常慢”我先 tracert -d -w 1000 目标IP发现第 7 跳开始时延从 10ms 飙到 80ms然后用 ping -n 50 第7跳IP发现丢包 8%基本能确定是运营商光路质量问题。这时候直接联系运营商报障拿数据说话效率高很多。4.4 实测技巧三连加速、保存结果、批量追踪这里分享三个实测很好用的小技巧。**加速技巧。**tracert 默认每个探测包等待 4 秒对排障来说太慢了。除了用 -w 1000 缩短等待时间还可以直接勾选“在此系统上禁用 DNS 解析”以外的优化手段比如先 ping 一下目标拿 IP然后直接用 IP 作为目标参数省去域名解析的时间。命令示例ping www.test.cn tracert -d -w 1000 203.0.113.10**保存结果。**网络排障时经常需要把结果发给同事或者存档。tracert 输出重定向到文件tracert -d www.test.cn C:\Users\Administrator\Desktop\tracert_result.txt**批量追踪。**如果有多台服务器需要同时排查可以写一个简单的批处理脚本循环执行echo off for %%i in (www.test.cn 223.5.5.5 114.114.114.114) do ( echo %%i tracert -d -w 1000 %%i ) pause把批处理保存为 .bat 文件双击就能批量跑输出一目了然。这个脚本看起来不起眼但在需要对比多条链路的时候非常省事。5. 从一次真实的「访问慢」案例看 -d 的实战价值5.1 案例背景与排查过程去年有次处理一个线上故障用户反馈访问某个内部业务系统很卡打开一个页面要十几秒。由于是跨地域访问总部在北京服务器在华南某数据中心我一开始怀疑是链路质量问题。先在用户侧执行了ping -n 50 目标IP结果显示平均时延 45ms丢包 1.5%看起来不算太差。但用户实际体验卡顿明显说明问题可能不在基础连通性上。继续执行tracert -d -w 1000 目标IP输出立刻发现问题第 8 跳到第 9 跳之间时延从 25ms 直接跳到 42ms随后一路在 42-48ms 之间波动。按照第三类判断模型我初步怀疑是运营商骨干节点之间的路由选路有问题。为了验证我又用不解析域名的快速方式和带域名解析的方式各跑了一次。虽然第二次因为反向解析多等了一些时间但从域名上确认了第 8 跳属于北方某运营商的骨干节点第 9 跳已经进入了南方另一家运营商的地盘。这个交叉点正好是时延突增的位置问题定位到了跨运营商互联路由器上。后续联系两边运营商核对路由表果然是其中一侧的 BGP 路由策略出现了异常导致流量绕行了一段路程。调整策略后再次执行 tracert -d第 9 跳的时延恢复了正常。5.2 复盘-d 在这个案例里帮了什么忙如果没有 -d整个排查过程会非常煎熬。那次跨地域追踪一共 12 跳如果用默认模式每一跳都要做反向 DNS 解析而运营商骨干节点的反向解析往往很慢甚至超时。算下来一次全量追踪可能要 5 到 8 分钟用户在现场等着根本耗不起。加上 -d 之后整条链路 20 秒内出结果。先用最短时间拿到链路全貌确认问题大致位置再决定是否需要启用更耗时的反向解析来获取运营商信息。这个“先快后慢、先粗后细”的排查思路比一上来就跑完整版命令要高效得多。还有一个细节在做跨运营商判断时我只对关键的中间跳第 8、9 跳用 nslookup 做手工反向解析而不是让全部跳数都等待反向解析。这样可以兼顾速度和细节。5.3 避坑心得分享这次案例里也踩了一些坑整理一下供大家参考。**坑一只盯时延不看丢包。**当初第一轮 ping 显示丢包 1.5%下意识以为网络质量还行实际上业务对时延变化非常敏感。后来用 pathping 对中间节点做统计发现第 9 跳丢包率在 8% 左右在高峰期甚至更高。排障时时延和丢包必须两个指标一起看单看一项很容易误判。**坑二忽略了本地出口带宽。**刚开始排查时我一度怀疑是本机所在办公网的出口带宽被占满。后来通过 tracert 第一跳和第二跳的时延对比确认本地网络没有问题才把重点转向运营商链路。所以做 tracert 时先看前两跳如果前两跳时延就不正常先解决本地网络问题再继续排查。**坑三跨运营商问题容易被误伤。**这次故障里其实在多个区域都有用户反馈受影响。如果没有 tracert 输出做证据运营商不会轻易承认路由策略有调整。有了逐跳的数据报障时直接把第 8 跳和第 9 跳的对端 IP 摆出来对方一看就明白问题在哪。我个人一直把 tracert -d 当作网络排障的第一板斧。它不像专业抓包工具那么复杂也不需要安装任何第三方软件Windows 自带、Linux 自带随手就能用。关键是在用之前先想清楚你要快速判断链路方向加 -d你要看运营商归属去掉 -d你需要做深度链路对比那就把 -h、-w 这些参数一起用起来。再分享一个小技巧日常可以把常用命令结合域名批量检测的脚本保存好遇到网络问题随时拿出来跑。熟练了之后你看到 tracert 的输出就能在几秒内形成判断这种“一眼定位问题”的能力靠的就是对命令本身和网络原理的深度理解。
tracert -d 命令详解：网络排障中快速定位链路问题的实用指南
1. tracert 到底是什么一条命令背后的网络追踪逻辑1.1 从“网页打不开”说起tracert 解决什么问题先说个场景。你正在工位上处理一个线上问题用户反馈某个网页或者接口访问很慢甚至直接超时。你第一反应是 ping 一下结果丢包严重或者时延很高。可这时候你只知道“到目标机器网络不稳定”但到底是在哪一段出的问题是本地网关、运营商骨干网、还是目标服务器所在机房你完全不知道。这时候就需要 tracert 出场了。tracert 是 Windows 系统自带的网络诊断命令Linux 和 macOS 上对应的是 traceroute。它的核心能力是把你到目标地址之间经过的每一跳路由器都列出来并测量每一跳的响应时延。说得直白一点你从家里开车去公司ping 只能告诉你全程花了多久而 tracert 能把每个红绿灯、每个收费站、每个路口的时间全部单独标出来。而 -d 参数就是让 tracert 不要费劲去做反向域名解析直接显示 IP 地址。为什么要这么做因为默认情况下tracert 每经过一跳都会尝试把该路由器的 IP 反向解析成域名。这个解析过程本身很慢在 DNS 不可用或者解析超时的情况下一条命令可能要跑好几分钟而加上了 -d整个过程会快得多。这篇文章适合谁看日常接触网络排障的运维、开发、实施工程师以及那些经常需要跟“网络为什么卡”较劲的普通用户。读完你不仅能熟练使用 tracert -d还能看懂输出结果里每一行到底在说什么遇到奇葩网络问题的时候有自己的排查思路。1.2 TTL 机制为什么逐跳追踪能够实现讲 tracert 之前必须先搞懂一个基础概念TTLTime To Live生存时间。IP 包在网络上传输每经过一个路由器TTL 值就会减 1。TTL 的原始设计目的是防止数据包在环路中无限循环避免网络被无效数据包打爆。当 TTL 减到 0 时路由器会丢弃这个数据包并向发送方回送一个 ICMP 超时消息告诉发送方“这个包的寿命到了我把它扔了它死在我这儿了”。tracert 正是利用了这一点。它先发送一个 TTL1 的数据包第一个路由器收到后 TTL 减为 0于是丢弃该包并发回一个 ICMP 超时消息。发送方据此知道了第一跳路由器的 IP 和时延。接着发送 TTL2 的数据包第二个路由器同样处理发送方知道第二跳。如此往复一直到数据包成功到达目标主机。这个原理和“丢一个球听回声判断距离”很像。每次把球扔近一点从回声延迟推算每段路的耗时。只要目标主机不拒绝响应你就能把整条路径一节一节地摸清楚。需要说明的是tracert 默认向目标主机发送的是 ICMP Echo Request 包也就是 ping 包这一点与 Linux 上的 traceroute 默认使用 UDP 包不同我后面会详细展开。整个过程中每一跳通常发送 3 个探测包分别记录三次时延所以你会看到输出里每行有 3 个时间。1.3 -d 参数到底做了什么为什么说它是提速开关tracert 的完整参数里-d 的官方解释是“不将地址解析成主机名”。这句话看起来简单但实际影响很大。默认状态下tracert 在拿到每一跳路由器的 IP 后会发起反向 DNS 查询尝试获得该 IP 对应的域名。比如某跳 IP 是 219.158.6.57反向解析出来可能是 bj141-126-218.bjtelecom.net 这样的域名。这个信息有时候确实有用你能通过域名看出这一跳属于哪个运营商、哪个地区。但问题是反向 DNS 查询不稳定特别是在跨运营商、跨地区的情况下经常出现解析超时。解析超时一次就要等好几秒而一次 tracert 可能要经过 15 跳、20 跳每一跳都等整条命令跑下来非常痛苦。加上 -d 之后tracert 拿到 IP 就直接显示跳过所有反向解析步骤速度提升非常明显。尤其是目标地址比较远、链路跳数多的情况下原本可能跑一分钟现在几秒钟就出结果。这也是为什么我日常排障时tracert 后面几乎永远跟着一个 -d除非我明确需要从路由器域名判断运营商归属才会故意不带 -d 跑一次。注意-d 只是不做反向域名解析并不会影响路由追踪本身的探测逻辑。你看到的 IP、时延、丢包信息都照常输出。2. 核心参数拆解与选型思路-d 只是冰山一角2.1 tracert 全部参数一览除了 -d 你还应该知道什么tracert 的命令格式一般长这样tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] [-R] [-S srcaddr] [-4] [-6] target_name我挑几个常用参数来讲实测下来最有用的是 -h、-w偶尔用 -d 和 -4。参数全称/含义实际用途-dDo not resolve addresses to hostnames跳过反向域名解析显著提速日常排障首选-h maximum_hops最大跳数默认 30目标距离远或中间节点特别多时可以调大到 60 甚至更多-w timeout每个应答等待的超时时间单位毫秒默认 4000网络差时把超时缩短到 1000避免长时间傻等-j host-list松散源路由列表一般用不到需要指定路径测试时才用-R追踪往返路径Windows 下特定场景才用日常很少碰-S srcaddr指定源地址多网卡机器上指定从哪个 IP 发包很实用-4 / -6强制使用 IPv4 / IPv6目标地址同时有 A 和 AAAA 记录时用来指定协议栈这里重点说一下 -w 参数。默认 4000 毫秒是 4 秒如果某一跳的路由器不响应每发一个探测包都要等 4 秒才超时3 个包就是 12 秒。如果连续几跳都不响应光等待时间就非常可观。所以我在常用的排障命令里一般会写成tracert -d -w 1000 www.test.cn把超时缩短到 1 秒既能快速判断“这一跳是否可达”又不会因为等待太久拖慢整体排查节奏。当然如果网络本身很差1 秒可能不够结果会出现大量超时误判这时候可以适当调回 2000 或 3000具体看你所在网络的状况。2.2 为什么 Windows 的 tracert 和 Linux 的 traceroute 不一样这是个经常被忽略、但在实际工作里非常容易踩坑的点。Windows 的 tracert 默认发送 ICMP Echo Request 包而 Linux 的 traceroute 默认发送 UDP 包目标端口从 33434 开始依次递增。两者最终都能实现路由追踪但在防火墙策略各异的生产环境里结果可能完全不同。比如某些路由器或主机只允许 ICMP 通过你用 Linux 的 traceroute 可能到某跳就全超时换成 Windows 的 tracert 却能正常显示。反过来也一样有些节点限流 ICMP但 UDP 探测包能顺利穿过。所以在跨平台对比网络路径时不要因为“换个系统结果不一样”就判断网络有问题先确认两侧使用的探测协议是否一致。还有一个细节目标主机收到 ICMP Echo Request 后正常情况下会回 ICMP Echo Replytracert 据此判断到达终点。但如果目标主机在防火墙层面禁 ping你会看到前面的跳都正常最后一跳却全是超时这时候不代表链路不通只是目标机不回 ICMP 而已。判断方法是看输出里“最后一跳的 IP 是不是目标 IP”如果是说明包其实已经到了只是响应被拦了。2.3 什么场景必须加 -d什么场景需要故意去掉我把日常使用场景分成三类对应的参数选择完全不同。第一类是快速判断链路质量。比如用户反馈访问某系统慢我要在最短时间内知道是“本地网关问题”“运营商中间链路问题”还是“目标机房问题”。这时候必须用 tracert -d因为我要的是速度和跳数分布不是域名。加了 -d10 秒内就能看到整条路径的时延变化快速定位大致故障段。第二类是判断运营商和地域归属。有时候某跳时延特别高我需要知道这一跳是哪个运营商的设备。比如看到 219.158.x.x结合反向解析域名里的 bjtelecom 或 cncgroup能判断是不是跨运营商绕路了。这时候就不能加 -d得让 tracert 自动做反向解析哪怕慢一点也值得。如果不放心可以先用 -d 快速跑一遍拿到跳数再针对特定跳做 nslookup 查询。第三类是深度链路分析。比如配合 -h 增加最大跳数看访问某些海外或者偏远地区的站点是否存在绕路或者结合 -S 指定源地址测试多线服务器的不同线路质量。这种场景一般用完整参数组合而不是单纯加不加 -d 的问题。简单总结默认先跑 tracert -d需要看运营商归属时再跑一次不带 -d 的完整版。3. 实操从「tracert -d www.test.cn」出发的完整排障流程3.1 前期准备先确认目标地址再动手在执行命令之前我习惯先做两个确认。一是确认目标地址是否可达。www.test.cn 本身是 IANA 预留的测试域名正常情况下指向 127.0.0.1 或类似回环测试地址直接用做生产排障没有实际意义。实际工作中我会先把用户反馈的域名或者接口地址确认清楚再用 nslookup 或者 ping 验证一下域名能不能解析出 IPnslookup www.test.cn解析结果里会显示 A 记录或者 AAAA 记录。如果域名都解析不出来那问题可能出在本地 DNS 上这时候做 tracert 也没有意义。二是确认当前机器的网络状态。执行命令前先 ping 一下本地网关确定本机到第一跳是通的。如果本机到网关都不通后面所有路由追踪的结果都是虚的。注意在企业内部环境中很多网络设备开启了 ICMP 限制或者自我保护策略表现为部分跳数不响应不代表链路中断。看到星号先别慌多对比几组数据再下结论。3.2 执行命令与输出解读每一行到底在说什么确认完前置条件后执行核心命令tracert -d -w 1000 www.test.cn假设目标地址可达输出一般长这样以下用保留地址段做示例实际生产环境以你跑的为准通过最多 30 个跃点跟踪到 www.test.cn [203.0.113.10] 的路由: 1 1 ms 1 ms 1 ms 192.168.1.1 2 3 ms 2 ms 2 ms 100.64.0.1 3 5 ms 5 ms 6 ms 202.96.209.5 4 8 ms 8 ms 9 ms 202.97.32.14 5 12 ms 11 ms 12 ms 203.0.113.10 跟踪完成。我们来逐行拆解。第一行的“通过最多 30 个跃点跟踪到”是告诉你默认最大跳数是 30。如果要追踪更远的路径用 -h 参数增加上限。第一列数字是跳数序号代表数据包经过的第几个路由器。第二列到第四列是三次探测的时延单位毫秒。最后一列是这一跳的 IP 地址因为加了 -d所以显示的是 IP而不是域名。从上面的示例可以看出本机 192.168.1.1 是网关1 毫秒左右100.64.0.1 是运营商接入层设备3 毫秒左右202.96.209.5 和 202.97.32.14 是骨干网节点时延在 8-9 毫秒最后一跳直接到了目标 203.0.113.10。整条链路很健康数据包从出口到目标只花了 12 毫秒左右。这里有一个非常重要的观察点如果某一跳的时延突然从 5ms 跳到 50ms且后续跳数都在 50ms 上下波动那么问题大概率出在“时延突增的那一跳”上。如果某一跳不响应显示三个星号 * * *但是下一跳又正常了通常说明这一跳屏蔽了 ICMP链路本身大概率没有断。3.3 基于结果的三类典型判断时延、丢包、绕路拿到了 tracert 的输出下一步就是做判断。我总结了三个最常见的判断模型直接套用就行。**第一类时延持续偏高。**如果每一跳的时延都在 100ms 以上而且从第一跳开始就是这样那大概率是你本地出口带宽拥塞或者本地网络设备性能不足。如果前面几跳正常、从中间某跳开始时延翻倍那问题出在运营商互联互通或者跨地域传输上。判断标准是“时延突增点在哪一段问题就在哪一段”。**第二类丢包严重。**tracert 输出中如果某几跳的时延能出来但另外一些跳偶尔显示超时说明这些节点存在丢包。这时候用 ping -n 100 目标IP 做长时间测试看整体丢包率。如果丢包率超过 2%线路质量已经算很差了超过 10% 会明显影响业务。**第三类绕路。**绕路的典型特征是跳数特别多、时延特别大比如从北京访问上海站点中间经过了 20 多跳时延异常高。这种一般是路由策略和 BGP 选路导致的。遇到这种情况最直接的方法是换一条链路测试比如从另外一家的网络出口访问同一目标对比绕路路径。如果两边都绕路可能目标机房的接入本身就有问题。4. 常见问题与排查技巧实录4.1 全是星号是网络断了还是设备不响应这是最常遇到的问题tracert 跑了半天中间几跳全是 * * *甚至从第一跳开始就是星号。很多新手第一反应是“网络断了”但实际上星号出现的原因很多。**一是设备禁 ping。**很多路由器和防火墙默认禁 ICMP或者做了限速策略。这类设备在 tracert 里就会表现为超时但数据包仍然能正常转发。判断方法如果星号只有几跳后续跳数依然能正常显示并最终到达目标那说明链路本身是通的。**二是目标地址本身不可达。**这时候是从某一跳开始往后全部超时。需要确认目标服务器是否正常运行、防火墙是否放行、路由是否有回程。可以换一个已知正常的公网地址做对比测试比如跟踪 223.5.5.5如果这个地址能正常跟踪说明问题在目标侧如果同样超时问题在你本地网络出口。**三是 MTU 问题。**这个比较隐蔽。有些网络环境存在 MTU 不一致的情况导致大数据包被丢弃而 tracert 发出的探测包可能因为分片策略不同而超时。这种情况下可以尝试用 ping -f -l 1472 目标IP 测试不分片数据包能否通过如果通则说明 MTU 设置有问题。注意不要因为看到星号就手动重启网络设备。先把星号出现的规律记下来逐跳对比结合 ping 结果才能下结论。4.2 前几跳就超时是租户隔离还是路由策略企业网络里经常遇到一种情况本机到网关正常但第二跳就开始超时后面恢复正常。这通常不是故障而是网络设计上的隔离策略。比如云服务器场景下底层虚拟网络设备承担了路由转发功能但本身不回 ICMP所以 tracert 第二跳会显示超时实际上数据包已经正常转发了。再比如部分运营商接入网设备做了安全策略对非必要的 ICMP 消息直接丢弃也会导致类似的输出。遇到这种情况我的建议是不要因为中间某一跳不响应就判定网络故障。连续做三次 tracert 对比如果每次星号出现的位置都一样、且首尾时延正常基本可以断定是设备策略问题不影响业务。4.3 组合诊断tracert 不要单打独斗单靠 tracert 一条命令很难覆盖所有网络场景我日常排障会搭配几个命令组合使用。ping -n 100 目标IP长时间测丢包率和稳定性弥补 tracert 只发 3 个包的不足。pathping 目标IPWindows 自带的命令结合了 tracert 和 ping 的功能。它会先做路由追踪然后对每一跳发送多个探测包做统计。缺点是跑得慢但结果很细致。route print查看本机路由表确认默认网关配置是否正确、有没有错误的静态路由干扰。nslookup 域名确认 DNS 解析结果排除解析异常导致的“连不上”。举个例子用户反馈“某系统非常慢”我先 tracert -d -w 1000 目标IP发现第 7 跳开始时延从 10ms 飙到 80ms然后用 ping -n 50 第7跳IP发现丢包 8%基本能确定是运营商光路质量问题。这时候直接联系运营商报障拿数据说话效率高很多。4.4 实测技巧三连加速、保存结果、批量追踪这里分享三个实测很好用的小技巧。**加速技巧。**tracert 默认每个探测包等待 4 秒对排障来说太慢了。除了用 -w 1000 缩短等待时间还可以直接勾选“在此系统上禁用 DNS 解析”以外的优化手段比如先 ping 一下目标拿 IP然后直接用 IP 作为目标参数省去域名解析的时间。命令示例ping www.test.cn tracert -d -w 1000 203.0.113.10**保存结果。**网络排障时经常需要把结果发给同事或者存档。tracert 输出重定向到文件tracert -d www.test.cn C:\Users\Administrator\Desktop\tracert_result.txt**批量追踪。**如果有多台服务器需要同时排查可以写一个简单的批处理脚本循环执行echo off for %%i in (www.test.cn 223.5.5.5 114.114.114.114) do ( echo %%i tracert -d -w 1000 %%i ) pause把批处理保存为 .bat 文件双击就能批量跑输出一目了然。这个脚本看起来不起眼但在需要对比多条链路的时候非常省事。5. 从一次真实的「访问慢」案例看 -d 的实战价值5.1 案例背景与排查过程去年有次处理一个线上故障用户反馈访问某个内部业务系统很卡打开一个页面要十几秒。由于是跨地域访问总部在北京服务器在华南某数据中心我一开始怀疑是链路质量问题。先在用户侧执行了ping -n 50 目标IP结果显示平均时延 45ms丢包 1.5%看起来不算太差。但用户实际体验卡顿明显说明问题可能不在基础连通性上。继续执行tracert -d -w 1000 目标IP输出立刻发现问题第 8 跳到第 9 跳之间时延从 25ms 直接跳到 42ms随后一路在 42-48ms 之间波动。按照第三类判断模型我初步怀疑是运营商骨干节点之间的路由选路有问题。为了验证我又用不解析域名的快速方式和带域名解析的方式各跑了一次。虽然第二次因为反向解析多等了一些时间但从域名上确认了第 8 跳属于北方某运营商的骨干节点第 9 跳已经进入了南方另一家运营商的地盘。这个交叉点正好是时延突增的位置问题定位到了跨运营商互联路由器上。后续联系两边运营商核对路由表果然是其中一侧的 BGP 路由策略出现了异常导致流量绕行了一段路程。调整策略后再次执行 tracert -d第 9 跳的时延恢复了正常。5.2 复盘-d 在这个案例里帮了什么忙如果没有 -d整个排查过程会非常煎熬。那次跨地域追踪一共 12 跳如果用默认模式每一跳都要做反向 DNS 解析而运营商骨干节点的反向解析往往很慢甚至超时。算下来一次全量追踪可能要 5 到 8 分钟用户在现场等着根本耗不起。加上 -d 之后整条链路 20 秒内出结果。先用最短时间拿到链路全貌确认问题大致位置再决定是否需要启用更耗时的反向解析来获取运营商信息。这个“先快后慢、先粗后细”的排查思路比一上来就跑完整版命令要高效得多。还有一个细节在做跨运营商判断时我只对关键的中间跳第 8、9 跳用 nslookup 做手工反向解析而不是让全部跳数都等待反向解析。这样可以兼顾速度和细节。5.3 避坑心得分享这次案例里也踩了一些坑整理一下供大家参考。**坑一只盯时延不看丢包。**当初第一轮 ping 显示丢包 1.5%下意识以为网络质量还行实际上业务对时延变化非常敏感。后来用 pathping 对中间节点做统计发现第 9 跳丢包率在 8% 左右在高峰期甚至更高。排障时时延和丢包必须两个指标一起看单看一项很容易误判。**坑二忽略了本地出口带宽。**刚开始排查时我一度怀疑是本机所在办公网的出口带宽被占满。后来通过 tracert 第一跳和第二跳的时延对比确认本地网络没有问题才把重点转向运营商链路。所以做 tracert 时先看前两跳如果前两跳时延就不正常先解决本地网络问题再继续排查。**坑三跨运营商问题容易被误伤。**这次故障里其实在多个区域都有用户反馈受影响。如果没有 tracert 输出做证据运营商不会轻易承认路由策略有调整。有了逐跳的数据报障时直接把第 8 跳和第 9 跳的对端 IP 摆出来对方一看就明白问题在哪。我个人一直把 tracert -d 当作网络排障的第一板斧。它不像专业抓包工具那么复杂也不需要安装任何第三方软件Windows 自带、Linux 自带随手就能用。关键是在用之前先想清楚你要快速判断链路方向加 -d你要看运营商归属去掉 -d你需要做深度链路对比那就把 -h、-w 这些参数一起用起来。再分享一个小技巧日常可以把常用命令结合域名批量检测的脚本保存好遇到网络问题随时拿出来跑。熟练了之后你看到 tracert 的输出就能在几秒内形成判断这种“一眼定位问题”的能力靠的就是对命令本身和网络原理的深度理解。