企业官网建设流程全解析

排查网络问题的时候，最头疼的往往不是“连不上”，而是“明明能连上，就是慢得离谱”。这时候大部分人第一反应是ping一下，发现丢包0%，然后卡住了。我在这类问题里碰过不少灰之后，养成了一个习惯：先ping，再traceroute。这篇文章就把traceroute在Linux下的安装和使用从头到尾讲清楚，包括原理、参数、输出怎么读、常见坑怎么避，以及什么时候该换mtr。不管你是刚接触Linux的新手，还是被网络问题折磨过的运维，照着操作都能少走弯路。

1. 追包这件事：traceroute到底做了什么

1.1 从TTL说起，搞清楚它为什么能“看见”每一跳

traceroute的核心思想，用一句话概括：通过故意让数据包“过期”，逼沿途的路由器自己报上名来。

每个IP数据包头上都有一个TTL字段，全称Time To Live，中文一般叫“生存时间”。这个字段很多人误以为是“时间”，其实它表示的是“经过的路由器跳数上限”。每经过一台路由器，TTL就减1，减到0的时候，路由器不会再转发这个包，而是丢弃它，同时回一个ICMP Time Exceeded（超时）消息给源地址，告诉发送方“这个包死在第几跳了”。

你可以把TTL想象成点外卖时写的“最多转几手”的接力棒规则。外卖员每转一手，接力次数减一，减到0还没送到，快递站就把单子退回去，还在回执上写了“已经转到第几手了”。traceroute就是利用了这套回执机制。

默认情况下，traceroute会从TTL=1开始发探测包，第1台路由器收到后TTL变0，丢包并返回超时消息，traceroute就记录下这台设备的IP。接着发TTL=2的包，第1台转发后TTL变成1，再到第2台变成0，于是第2台又回了一个消息。依此类推，每一跳的设备都被这样“逼问”出来，路径就画出来了。整个过程，像一个拿着探针的人，一层一层敲门问路。

1.2 为什么默认是30跳，这个数字从哪来

traceroute默认最大跳数是30，也就是最多追踪30层路由器。这个数字不是拍脑袋定的，早期互联网骨干网的架构层级少，端到端路径一般不会超过15跳，30作为上限已经留足了余量。到今天，哪怕跨国跨大洲的路径，大多数情况下也不会超过30跳。

但你在线路质量差、绕路严重的环境里，确实会看到TTL超过30的情况。这时候用-m 60把上限抬高就行，不要迷信默认值。我见过一段从某地到欧洲机房的路径走到了36跳，默认30根本看不完。

1.3 traceroute、ping、tracert三者的关系

• ping：只告诉你“目标通不通、延迟多少、丢不丢包”，不告诉你路径。
• traceroute（Linux）和tracert（Windows）：逐跳追踪路径，告诉你每一跳是谁、延迟多少，定位瓶颈在哪一段。
• Windows下叫tracert，Linux下叫traceroute，两者的参数不完全一样，别混着记。

实际排查的时候，我通常先ping确认通不通，再traceroute看路径。如果ping不通，traceroute能告诉你断在哪一跳，这个信息量比单纯“超时无响应”大得多。

2. 先搞清楚traceroute的三条命：UDP、ICMP和TCP

2.1 默认的UDP模式是怎么工作的

Linux发行版自带的traceroute，默认使用的探测方式是UDP。它向目标主机的端口发送一连串UDP数据包，端口号从33434开始，每发一个包端口号就加1。

为什么选UDP而不直接选ICMP？历史原因占一大半。早期的traceroute实现选UDP，是因为在当时的网络环境里，UDP包被丢弃后返回的ICMP错误消息最丰富，而且不容易跟正常的ICMP请求混在一起。另外，UDP的源端口是随机高位端口，目标端口是一个未使用的端口，这样目标主机收到后通常会回一个“端口不可达”的ICMP消息，traceroute看到这个消息就知道“到终点了”。

但UDP模式有个要命的问题：很多防火墙和运营商策略会直接丢弃陌生的UDP包，导致最终一跳“假超时”。所以现代网络环境下，UDP探测经常在半路就全是星号了。

2.2 ICMP模式为什么穿透性更好

traceroute -I参数切换到ICMP模式。原理和ping一样，发的是ICMP Echo Request包，每一跳的路由器返回的是TTL超时消息，目标主机返回的是Echo Reply。

为什么推荐优先试-I？因为绝大多数路由器和防火墙会放行ICMP，至少会放行TTL超时消息。很多内网设备对UDP探测包理都不理，但对ICMP响应得很痛快。我实测下来，在跨运营商、跨国链路，-I的成功率和可读性明显高于默认UDP模式。如果你第一次跑traceroute全是星号，第2秒就换成-I试试，往往立竿见影。

2.3 TCP模式适合穿透企业防火墙

traceroute -T参数是TCP SYN探测模式。它会向目标的指定端口（默认80）发TCP SYN包，通过三次握手的SYN-ACK响应来确认连通性。企业防火墙通常放行80、443这类常用端口，所以这个模式在“目标机器只允许特定端口访问”的场景下特别好用。

我经常用traceroute -T -p 443 目标IP来模拟HTTPS流量的路径。这样看到的结果，跟真实浏览器访问走的路径几乎一致，排障价值很高。代价是它依赖目标端口开放，如果目标没开对应端口，最终一跳可能只能看到“拒绝连接”，不影响前面路径的追踪。

2.4 三种模式的适用场景对比

新手建议先从-I开始跑，能避免大部分“全是星号”的挫败感。

3. 不同Linux发行版下的安装姿势

3.1 Debian/Ubuntu系列

Debian系的包管理命令是apt，安装非常简单：

sudo apt update sudo apt install traceroute

如果你的系统比较精简，apt安装完直接执行traceroute --version，能输出版本信息就说明装好了。Debian系还提供了inetutils-traceroute这个变体包，功能弱一些，不推荐。直接装正统的traceroute包就行。

3.2 RHEL/CentOS/Rocky系列

CentOS 7及以下用yum，CentOS 8及以上（包括Rocky Linux、AlmaLinux）用dnf：

# CentOS 7及以下 sudo yum install traceroute # CentOS 8+/Rocky/Alma sudo dnf install traceroute

这个系列的系统有时候默认不自带traceroute，因为最小化安装只装了iputils。装完一样用which traceroute确认一下路径。

3.3 Arch/Manjaro系列

Arch系一条命令：

sudo pacman -S traceroute

也没什么好说的，滚动发行版源里一般都有。

3.4 没有包管理器权限怎么办

在公司服务器或者容器里，可能没有sudo权限。这时可以看看有没有现成的二进制，比如BusyBox自带了一个简化版的traceroute：

busybox traceroute 目标IP

或者直接下载静态编译版本的traceroute放到用户目录，Linux的traceroute静态二进制很常见，直接扔到~/bin/下改个权限就能用。另外，ping是几乎所有系统都自带的，tcptraceroute用不了的时候，也能靠逐跳ping -t凑合排查，但那就是另一个故事了。

3.5 安装完先做个自检

装完之后，先跑一个简单的内网地址测试一下：

traceroute -I 192.168.1.1

正常能看到网关跳出来。如果这个都不通，多半是本地防火墙挡了出站ICMP，或者系统没有开启需要的协议支持。别急着怪工具。

4. 上手实测：常用参数与输出解读

4.1 参数清单，按实用程度排序

跑一次标准用法是：

traceroute -I -n -q 1 -m 20 目标IP或域名

这条命令的含义逐个拆开：

• -I：使用ICMP模式（推荐先试这个）
• -n：直接显示IP地址，不做反向DNS解析。不加这个参数时，traceroute会尝试把每一跳的IP解析成域名，会大大拖慢速度，而且很多CDN节点根本没有PTR记录，纯浪费时间。日常排查我几乎永远带着-n
• -q 1：每跳只发1个探测包。默认是3个，但3个除了让输出更花哨，提供的信息多不了多少，还会显著拖慢整体时间
• -m 20：最大探测20跳。省得它在30跳的空路径上慢慢磨

其他常用参数：

4.2 输出结果的每一列到底是什么意思

拿一条实际路径举例：

1 192.168.1.1 1.542 ms 1.634 ms 1.508 ms 2 10.10.1.1 3.214 ms 3.108 ms 3.256 ms 3 100.78.1.1 12.835 ms 12.715 ms 12.944 ms 4 202.96.1.1 18.322 ms 18.265 ms 18.410 ms 5 * * * 6 203.98.2.1 30.120 ms 30.088 ms 30.243 ms

从左到右的规律：

• 第一列是跳数，从1开始
• 第二列是这一跳设备的IP（加了-n时；不加时可能是域名）
• 第三到第五列，是这一跳每个探测包的往返时间RTT，单位毫秒。默认发3个包，所以有3个值

重点说延迟：每一跳的3个RTT值，代表的是“从我这里到这个设备”的往返延迟，不是这一段的延迟增量。第3跳12ms不代表第2跳到第3跳花了12ms，而是我从本机到第3跳的总延迟12ms。很多人看路径的时候把这搞混，结果判断错了瓶颈段。

4.3 一通实际排障的路径推演

我遇到过一个典型的“网页能打开但图片加载慢”问题。从本机到某个影像服务器的traceroute输出如下：

1 192.168.1.1 1.2ms 1.1ms 1.3ms 2 172.16.4.1 8.4ms 8.8ms 8.2ms 3 10.10.1.1 9.1ms 9.3ms 9.0ms 4 100.64.0.1 28.2ms 29.1ms 28.5ms 5 202.97.1.1 42.0ms 41.6ms 41.8ms 6 209.148.1.2 88.3ms 90.1ms 89.2ms 7 203.102.1.1 120.5ms 126.3ms 122.8ms 8 221.15.1.1 135.2ms 134.8ms 135.6ms

从这个输出能看出，延迟在第5跳到第6跳之间突然从40ms跳到88ms，增加约48ms；第6跳到第7跳又跳到120ms，再增32ms。这说明跨境或跨运营商的骨干段开始集中出现延迟积累，问题不在我这边，而在中间某段国际传输链路。这时候换线路、换出口，比在本地反复抓包有效得多。

4.4 第一次跑通，建议做这三步

1. 先跑内网网关，确认自身网络正常：traceroute -I -n 192.168.1.1
2. 再跑一个互联网公开地址，确认出口正常
3. 最后跑真正的目标地址，对比和上一步的差异点

这个“由近及远”的排查顺序，能帮你快速区分问题出在本地网络、运营商出口，还是远端服务器。

5. 实战排错：看懂星号、超时和异常路径

5.1 星号到底代表什么

traceroute输出里出现* * *是最常见的情况，很多人一看到就慌了，以为断网了。星号只代表这一跳没有收到回应，不代表路断了。

可能的原因有四类：

1. 设备不响应：不少路由器、交换机有专门策略，不回复TTL超时消息，尤其是一些高端运营级设备。它们不响应，不代表不转发
2. 防火墙丢弃：设备防火墙把UDP探测包或ICMP超时消息丢了
3. 负载均衡设备：部分大流量节点对探测包有独立策略，直接静默丢弃
4. 路径不对称：回来的路径和去的路径不一样，响应绕了别的路回来，没到你这个出口

判断星号是不是“链路断开”的关键，是看它后面连续的跳是否恢复了。如果第6跳是星号，第7跳、第8跳正常，那第6跳大概只是不响应而已。如果从第6跳开始到最终目标全是星号，那才要怀疑这一段链路真的断了。

5.2 最后一跳“超时”不等于目标故障

UDP模式下，目标主机如果开了防火墙，不会回“端口不可达”消息；ICMP模式下，也有很多服务器禁ping，不回Echo Reply。这两种情况都会导致目标主机那一跳显示星号，但实际业务是正常的。

所以真正判断“目标到底到没到”，不能只靠最后一跳的颜色。方法有两个：

• 换个模式试。UDP不通换ICMP，ICMP不通换TCP
• 观察目标主机前面的沿途跳数是否完整走完。如果路径已经走到了目标IP所在的倒数第2跳，且延迟正常，那其实路径大概率已经抵达目标网络的边界

5.3 RTT的波动看起来很吓人，怎么判断正常与否

每个探测包的RTT不完全一样，哪怕在同一跳，三个数值也可能差出几十毫秒。判断延迟是否正常，看的是整体趋势，而不是单个数值。

经验值可以这么参考（这里的数值只是通用参考，具体网络环境差异很大）：

• 同一运营商内，跨城市RTT一般在5-30ms
• 跨运营商，RTT可能到30-80ms
• 跨国物理链路，RTT在80-200ms都很正常
• RTT抖动（从一个包到下一个包）超过50ms，通常说明这一跳或相邻链路过载

5.4 路径来回不一样，别觉得是工具坏了

traceroute只能看到“去程”的路径，回程路径它看不见。网络世界里的路由并不对称，A到B走了电信线路，B到A可能切了联通线路。你在traceroute输出里看到的不一定是你业务数据真实的往返路径，如果你是做应用优化的人，这点要有心理准备。

5.5 权限问题：为什么我跑traceroute提示Operation not permitted

traceroute需要发送原始套接字包，普通用户默认没有这个权限。Debian系发行版给traceroute配置了文件能力，普通用户也能跑；但在某些严格系统上，非root用户会直接报错。

# 报错长这样 socket: Operation not permitted

解决办法就是加sudo：

sudo traceroute -I -n 目标IP

如果你在安全加固过的生产服务器上，可能连sudo都没得用，那就用不需要原始套接字的替代品，比如后面讲的mtr。

6. traceroute不够用的时候：mtr与它的互补逻辑

6.1 mtr是什么，为什么日常排障我更推荐它

traceroute是一次性快照，跑完就完，看到的是一个时间点的路径状态。而网络问题是动态的，丢包和延迟的抖动往往时好时坏。

mtr（My Traceroute）把traceroute和ping结合到了一起：它持续地向每一跳发送探测包，并且实时刷新丢包率、延迟平均值、最差值和最好值。相当于traceroute静态照片变成了动态监控视频。排查一个“间歇性丢包”的问题时，mtr跑一分钟就能看出哪一跳在反复丢包，而traceroute跑三次都不一定能抓到。

安装也很简单：

# Debian/Ubuntu sudo apt install mtr-tiny # RHEL/CentOS/Rocky sudo dnf install mtr

用起来最常用的参数组合：

mtr -rw -c 20 目标IP

拆开解读：

• -r：report模式，跑完指定次数后输出报告并退出，适合脚本采集
• -w：宽屏显示模式，输出更整齐，不会折行
• -c 20：每个跳发送20个探测包，建议至少10个以上，丢包率才有统计意义

6.2 mtr输出怎么读，跟traceroute有什么不同

My traceroute [v0.93] Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.1.1 0.0% 20 1.2 1.3 1.0 2.1 0.3 2. 10.10.1.1 0.0% 20 3.2 3.4 2.9 4.1 0.4 3. 100.64.0.1 0.0% 20 12.5 12.8 12.0 14.2 0.5 4. 202.97.1.1 50.0% 20 35.2 38.1 30.5 50.2 6.3 5. 203.98.2.1 0.0% 20 42.1 43.0 41.1 45.1 1.1 6. 221.15.1.1 0.0% 20 45.0 44.5 43.2 46.5 0.8

这个输出比traceroute有价值得多：

• Loss%列：丢包率。重点关注第4跳50%的丢包。如果第4跳丢包50%，而第5跳之后丢包为0，那说明第4跳只是“忙得没空回你的探测包”，实际数据流量走的是另一条转发通道，没有真丢包。如果第4跳丢包，第5跳也丢包，并且一直延续到最终跳，那就真正有问题了
• StDev列：标准差。这个数值越高，代表延迟波动越大。StDev超过5ms就要留意

mtr的丢包判断有个经典规律——中间跳丢包但最终跳不丢包，大概率是假象；最终跳丢包才是真丢包。记住这句话，能省掉很多无谓的排查。

6.3 mtr看延迟忽高忽低，怎么定位瓶颈

看mtr报告时，对比相邻两跳的Avg（平均延迟）差值。如果第4跳Avg是38ms，第5跳Avg是43ms，只差了5ms，那这段链路没有明显瓶颈。如果第6跳Avg是45ms，第7跳Avg突然变成95ms，中间50ms的差距就是瓶颈段。再回头用traceroute不带-n看这段的域名，基本能认出是对端运营商还是国际出口。

6.4 一些日常实用的排障组合拳

排查一个“网页慢”问题，我通常按下述顺序打组合拳：

# 第一步：先确认本机网络和DNS ping -c 4 目标IP # 第二步：看整体路径，用mtr持续观察两分钟 mtr -rw -c 120 目标IP # 第三步：定位到瓶颈段后，用traceroute的特定模式补充验证 traceroute -T -p 443 -n 目标IP # 第四步：如果怀疑MTU问题，再用大包ping测试 ping -M do -s 1472 -c 4 目标IP

这套流程下来，九成网络路径问题都能定位到具体的段和方向。最后再强调一次，mtr里发现的中间跳丢包不要慌，先看最终跳有没有丢包再说。

7. 我的几个经验之谈，说给刚上手的人

本文从原理讲到安装，从参数讲到排障，最后补了mtr这个替代工具，该覆盖的基本都覆盖了。在实际使用中，我体会最深的有三点：

第一，遇到古怪的路径问题，优先换探测模式而不是换工具。同一个目标，UDP全星号、ICMP正常、TCP部分跳不通，各有各的道理。多花一分钟切换模式，往往比反复猜效果要好。

第二，traceroute输出的域名信息不要浪费。反解出来的域名里，经常能看到运营商节点的地名缩写和链路类型编码，能帮你快速判断是哪家运营商、哪个地区的出口。偶尔遇到反解超时，再用-n关掉就好。

第三，所有延迟和丢包数据，都要结合时间点分析。晚高峰和凌晨的路径完全可能是两套，别拿凌晨3点的traceroute结果去判断晚上8点的卡顿。有条件的话，把traceroute和mtr多跑几个不同时间段再下结论。

最后，一个小技巧送给你：在服务器上加个别名，把常用参数固化下来。

alias trc='traceroute -I -n -q 1 -m 20' alias mtrc='mtr -rw -c 20'

下次排查直接打trc 目标IP和mtrc 目标IP，省得每次敲一长串参数。工具不在多，顺手最重要，希望你的网络永远不需要用到这些排障手段。