企业官网建设流程全解析

朋友前几天跟我吐槽，说家里网络一到晚上就卡得不行，视频会议断断续续，我第一反应就是让他打开命令行，敲一条命令：tracert -d www.test.cn。不少人对ping很熟，但一说到tracert就犯怵，觉得输出密密麻麻看不懂；也有人知道这命令能查路由，却不知道为什么后面要跟个-d，不加行不行。

今天我就把tracert -d这件事彻底讲透。它会成为你排查网络问题、判断“卡在哪一跳”最顺手的工具之一，而且非常适合以下这几类人：经常被网络故障折腾的运维和开发、家里网络环境复杂想自己定位问题的普通用户，以及正在学网络基础、想把抽象概念落到实操上的学生。全程以www.test.cn为例，你拿到手就能照着跑一遍。

1. 先搞懂 tracert 到底在做什么

1.1 它和 ping 最大的不同：沿途每一站都给你报一遍

ping用来确认“目标通不通”，但它只告诉你结果，不告诉你路上发生了什么。数据包从你的电脑出发，到目标服务器，中间要经过很多台路由器，就像一个包裹从北京寄到广州，中途要经过好几个转运中心。tracert干的事情，就是让数据包每路过一个转运中心，都给你打一次卡，并把打卡记录逐一列出来。

这个“打卡”机制，依赖的是IP协议里的TTL（Time To Live）字段。TTL是一个数字，每经过一台路由器就减1，减到0时，路由器会丢弃这个包，并给发送方回一条ICMP超时消息。tracert正是利用这一点：先发一个TTL=1的包，第一台路由器收到后TTL变0，回包，于是你就知道了第一跳是谁；再发TTL=2的包，第一台路由器正常转发，第二台路由器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只是其中一个参数。我把日常会用到的几个整理成一张表，方便直接对照：

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按Win+R，输入cmd回车，然后执行：

tracert -d www.test.cn

3.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 高频问题速查表

我把平时被问得最多的几个问题和对应思路整理成表格，方便你直接查阅：

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输出时，习惯把路径拆成三段：局域网段（第1～2跳）、运营商接入段（第2～3跳）、骨干网与目标段（第3跳之后）。每一段内部的延迟正常范围不同，局域网段应该是1～5毫秒，接入段一般在10～30毫秒，骨干网在几十毫秒级别。数值一旦明显超出对应范围，问题就出在这一段，这样分析起来思路非常清晰。

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，对照着上面的输出解读，给自己家网络做一次“链路体检”。跑完你会觉得，原来网络排查也没有那么玄乎。