1. 从一次"ping通了但服务连不上"的排查说起
ping通了，端口却连不上——这个场景但凡做过网络排查的人都不陌生。我第一次遇到这个问题时，盯着终端里ping返回的稳定延迟发呆，心里想的是"网络明明是通的，为什么服务就是访问不了"。后来才明白，ping只验证了 ICMP 这一条路，而数据包从你的机器到目标机器之间，可能经过十几跳路由器，每一跳都可能做出不同的转发决策。ping通了只代表"有一条路能走通"，不代表"你关心的那条路能走通"。
traceroute就是用来解决这个问题的。它能把数据包从本机到目标主机之间经过的每一跳路由器都列出来，让你看到完整的路径。哪一跳开始延迟飙升、哪一跳开始丢包、数据包在哪个节点拐了弯，全都一目了然。这篇文章面向的是需要在 Linux 环境下做网络排查的运维人员、后端开发者和刚接触网络诊断的新手，我会把traceroute的安装、参数、输出解读和实战排查思路完整讲一遍，同时补充一些官方文档里不会写的实操经验。
需要提前说明的是，traceroute和ping一样，只是诊断工具，它的输出反映的是"探测包"的路径，不一定完全等同于你实际业务流量的路径。这个差异在后面的章节里会详细展开，先记住这个前提，能帮你少走很多弯路。
2. traceroute 到底在探测什么：TTL 机制与三种探测包的选择
2.1 TTL 递减：让路由器"主动暴露自己"
要理解traceroute的输出，必须先理解 IP 协议头里的TTL（Time To Live，生存时间）字段。TTL 是一个 8 位字段，最大值 255。每经过一台路由器，TTL 就减 1。当 TTL 减到 0 时，路由器会丢弃这个包，并向源地址发回一个ICMP Time Exceeded（超时）消息。
正常情况下，TTL 的作用是防止数据包在网络里无限循环。但traceroute把这个机制反过来用了：它先发一个 TTL=1 的包，第一跳路由器收到后 TTL 减为 0，丢弃并回一个 ICMP 超时消息，traceroute就拿到了第一跳的地址；接着发 TTL=2 的包，第二跳路由器回消息，拿到第二跳地址；以此类推，直到包到达目标主机。
目标主机收到包后，因为 TTL 还没减到 0，不会回超时消息，而是回一个ICMP Port Unreachable（端口不可达）或者ICMP Echo Reply，traceroute据此判断"到终点了"。整个过程就像你往一个长长的走廊里依次扔出编号 1、2、3 的球，每个接到球的人告诉你他是第几个，直到球被终点的人接住。
2.2 UDP、ICMP、TCP 三种探测方式怎么选
traceroute默认用的是UDP 探测包，目标端口从一个高位端口（通常是 33434）开始递增。目标主机收到 UDP 包后，因为那个端口大概率没有服务在监听，会回一个 ICMP Port Unreachable，traceroute就知道到了。
但 UDP 方式有个现实问题：很多防火墙和中间设备对高位 UDP 端口的态度很粗暴，直接静默丢弃，连 ICMP 超时消息都不回。这时候你会看到输出里出现一堆* * *，路径断在半路。遇到这种情况，可以换用-I参数走ICMP Echo方式，或者用-T参数走TCP SYN方式。
TCP 方式在实战中特别有用，因为你可以指定一个"看起来正常"的端口，比如-T -p 443，让探测包伪装成一次 HTTPS 连接尝试。很多防火墙对 443 端口的 TCP 包是放行的，这样就能穿透过去看到更完整的路径。三种方式的对比我整理成了下面这张表：
| 探测方式 | 参数 | 探测包类型 | 适用场景 | 常见问题 |
|---|---|---|---|---|
| UDP | 默认 | UDP 高位端口 | 通用场景，目标无防火墙 | 防火墙静默丢包，输出大量* |
| ICMP | -I | ICMP Echo Request | 目标允许 ICMP 但限制 UDP | 部分设备限速 ICMP，延迟偏高 |
| TCP | -T | TCP SYN | 穿透防火墙，模拟真实业务 | 需要指定端口，部分系统需 root |
提示：
-T和-I方式在部分发行版上需要 root 权限，因为要构造原始套接字。如果不想用 sudo，可以给二进制文件设置cap_net_raw能力，具体命令在下一章给出。
2.3 为什么输出里的延迟是三个值
你运行traceroute后看到的每一行通常长这样：
3 10.0.0.1 1.234 ms 1.456 ms 1.789 ms三个时间值是traceroute对同一跳发了三次探测包的结果。为什么要发三次？因为网络延迟本身是波动的，单次测量没有代表性。三个值能让你看出这一跳的延迟是否稳定：如果三个值都在 1ms 左右，说明这一跳很稳；如果分别是 1ms、50ms、200ms，说明这一跳存在拥塞或抖动。
默认情况下traceroute每跳发 3 个包，可以用-q参数调整，比如-q 1只发一个包加快速度，或者-q 5发五个包获得更稳定的统计。我在排查间歇性丢包问题时习惯用-q 5，因为三个包有时候刚好都躲过了丢包窗口，看不出问题。
3. 各发行版安装实操：从包管理器到权限配置
3.1 主流发行版的安装命令
traceroute在大多数 Linux 发行版里都不是默认预装的，需要手动装。不同发行版的包名和包管理器不一样，我把常见的整理如下：
| 发行版 | 包管理器 | 安装命令 | 包名 |
|---|---|---|---|
| Debian / Ubuntu | apt | sudo apt update && sudo apt install traceroute | traceroute |
| CentOS / RHEL 7 | yum | sudo yum install traceroute | traceroute |
| RHEL 8+ / Fedora | dnf | sudo dnf install traceroute | traceroute |
| Arch Linux | pacman | sudo pacman -S traceroute | traceroute |
| openSUSE | zypper | sudo zypper install traceroute | traceroute |
| Alpine | apk | sudo apk add traceroute | traceroute |
安装完成后用traceroute --version验证一下。如果提示命令找不到，先确认PATH里是否包含/usr/sbin或/usr/bin，有些发行版把traceroute装在/usr/sbin下，而普通用户的PATH默认不含这个目录。
3.2 免 sudo 使用 TCP/ICMP 模式的权限配置
前面提到-T和-I需要 root 权限。如果你经常用这两个模式，每次都敲 sudo 很烦，而且有些自动化脚本里不方便提权。这时候可以给traceroute二进制文件单独授予原始套接字能力：
# 先确认 traceroute 的实际路径 which traceroute # 假设输出是 /usr/bin/traceroute # 授予 cap_net_raw 能力 sudo setcap cap_net_raw+ep /usr/bin/traceroute # 验证能力是否生效 getcap /usr/bin/traceroute # 应输出：/usr/bin/traceroute cap_net_raw+ep设置完之后普通用户就能直接用-T和-I了。这里有个坑要注意：系统更新traceroute包后，二进制文件会被替换，之前设置的 capability 会丢失。所以如果你依赖这个配置，最好把它写进自动化配置脚本里，每次更新后重新执行一遍。
注意：
setcap授予的是文件级别的能力，任何能执行这个文件的用户都会获得原始套接字权限。在多用户共享的生产服务器上，要评估这个安全影响，必要时改用 sudo 白名单的方式。
3.3 容器环境里的特殊处理
在 Docker 容器里跑traceroute会遇到两个额外问题。第一，很多精简基础镜像（比如alpine、distroless）根本没装traceroute，需要先装。第二，容器默认的NET_RAWcapability 可能被禁用，导致-T和-I报Operation not permitted。
解决办法是在启动容器时加上--cap-add=NET_RAW：
docker run --rm -it --cap-add=NET_RAW alpine sh # 进入容器后 apk add traceroute traceroute -T -p 443 example.com如果是 Kubernetes 环境，需要在 Pod 的 securityContext 里加上NET_RAW能力。这个细节在排查 Service 网络问题时特别关键，因为容器网络经过 NAT 和虚拟网桥，路径和宿主机上看到的完全不一样。
4. 输出解读：每一列数字背后的含义与常见误判
4.1 逐字段拆解一行输出
先看一个典型的traceroute输出：
traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets 1 gateway (192.168.1.1) 0.521 ms 0.498 ms 0.476 ms 2 10.10.0.1 (10.10.0.1) 3.214 ms 3.102 ms 3.289 ms 3 * * * 4 203.0.113.5 (203.0.113.5) 12.456 ms 12.301 ms 12.678 ms 5 93.184.216.34 (93.184.216.34) 25.123 ms 24.987 ms 25.234 ms第一行是头部信息：目标域名、解析出的 IP、最大跳数（默认 30）、探测包大小（默认 60 字节）。从第二行开始是每一跳。
每一跳的格式是：跳数 主机名 (IP地址) 延迟1 延迟2 延迟3。主机名是通过反向 DNS 解析得到的，如果解析不出来就只显示 IP。反向解析有时候很慢，可以用-n参数跳过解析，直接显示 IP，能明显加快输出速度。
第 3 跳的* * *表示这一跳没有收到任何响应。这不一定代表这一跳有问题，可能是那台路由器配置了不回应 ICMP 超时消息，也可能是防火墙拦截了。关键要看后面的跳数是否还能继续——如果第 4、5 跳正常，说明路径是通的，只是第 3 跳"不愿意说话"而已。
4.2 延迟突然跳变怎么判断
延迟从第 2 跳的 3ms 跳到第 4 跳的 12ms，这个跳变是否正常？判断标准是看跳变的幅度和后续是否持续。如果只是单跳跳变然后恢复，通常是那一跳的设备本身处理 ICMP 的优先级低，不代表链路慢。如果延迟从某一跳开始持续累加，每一跳都比上一跳高很多，那说明这段链路确实存在拥塞或长距离传输。
这里有个反直觉的点：路由器的 ICMP 响应延迟不代表转发延迟。很多核心路由器把"回应 ICMP 超时消息"当成低优先级任务，CPU 忙的时候可能延迟几百毫秒才回。但它转发你的实际数据包可能只用了几微秒。所以看到某一跳延迟很高，不要急着下结论说"这一跳有问题"，要看后续跳数的延迟是否也高。
4.3 路径不对称：去和回可能走不同的路
traceroute只探测了去程路径。数据包从目标返回你本机的路径（回程）可能完全不同。这是 IP 网络的基本特性——路由是逐跳独立决策的，去和回没有必然的对称关系。
这个特性在排查"能连上但很慢"的问题时特别重要。你可能看到去程路径很干净，延迟很低，但实际业务体验很差，因为回程路径绕了远路或者经过了拥塞节点。要探测回程路径，需要在目标主机上也跑一次traceroute指向你的机器，两边对比才能看清全貌。
提示：如果目标主机你能控制，最稳妥的排查方式是两端同时抓包（
tcpdump）加双向traceroute，把去程、回程、实际流量三条线对齐看。单看一端的traceroute很容易误判。
5. 高频参数实战：把 traceroute 调成趁手的排查工具
5.1 加速与精简：-n、-q、-w 的组合
默认的traceroute在排查时经常显得慢，主要慢在反向 DNS 解析和每跳三个包的等待上。我常用的加速组合是：
traceroute -n -q 1 -w 1 example.com逐个解释：-n跳过反向 DNS 解析，直接显示 IP；-q 1每跳只发一个包；-w 1每个包只等 1 秒就超时（默认是 5 秒）。这三个参数组合起来，30 跳的探测通常几秒就能跑完，适合快速摸清路径轮廓。
但要注意，-q 1牺牲了统计意义，单包结果可能受瞬时抖动影响。我的习惯是：第一遍用加速参数快速看路径，发现可疑跳数后再用默认参数或-q 5对可疑段做精细复测。这样既快又不丢精度。
5.2 指定源地址与网卡：多网卡服务器的必备技能
多网卡服务器上跑traceroute，如果不指定源地址，系统会按路由表选一个默认出口，可能不是你想要的网卡。用-s指定源 IP，用-i指定出口网卡：
# 指定从 192.168.1.100 这个源地址发出探测 traceroute -s 192.168.1.100 example.com # 指定走 eth1 网卡 traceroute -i eth1 example.com这个在排查"某条专线不通"的问题时特别有用。比如服务器有两条上行链路，一条走专线一条走公网，你需要验证专线路径是否正常，就必须用-s把源地址绑到专线对应的 IP 上，否则探测包可能从公网口出去了，测出来的路径根本不是专线的。
5.3 调整最大跳数与包大小
默认最大跳数是 30，跨洲际的路径有时候会超过 30 跳，导致探测提前结束。用-m调大：
traceroute -m 64 example.com包大小用-p之外，还有个容易混淆的参数。UDP 模式下-p指定的是目标起始端口，不是包大小。要改探测包大小得看具体实现，GNU traceroute 里没有直接改包大小的通用参数，但可以通过指定更大的端口号范围间接影响。这个细节很多人搞混，以为-p是 packet size，其实是 port。
另外 MTU 相关问题也值得关注。如果路径中某一段 MTU 较小而探测包较大，可能触发分片，影响结果。排查 MTU 问题时，可以配合ping -M do -s <size>来定位具体哪一跳的 MTU 变小了，traceroute本身不直接显示 MTU 信息。
6. 真实排查链路：从"服务连不上"到定位问题跳
6.1 完整排查过程的复现
假设你遇到一个场景：某台服务器上的应用访问外部某个 API 超时，但ping目标域名是通的。下面是我实际的排查步骤，你可以照着复现。
第一步，确认基础连通性：
ping -c 4 api.example.com如果ping通，说明 ICMP 路径没问题，问题可能出在 TCP 层或特定端口。
第二步，用 TCP 模式探测目标端口：
sudo traceroute -T -p 443 -n api.example.com这里用-T -p 443是因为业务走的是 HTTPS，用 TCP 443 探测最贴近真实流量。如果这一步能走通到目标，说明 TCP 路径是通的，问题可能在应用层。
第三步，如果 TCP 探测卡在某一跳，记录下卡住的位置：
1 192.168.1.1 0.5 ms 2 10.10.0.1 3.2 ms 3 * * * 4 * * * 5 * * * ... 30 * * *从第 3 跳开始全是*，说明探测包在第 3 跳之后就被丢弃了。这时候换 ICMP 模式再试：
sudo traceroute -I -n api.example.com如果 ICMP 模式能走通，说明是 TCP 探测包被中间设备拦截了，可能是防火墙策略问题。如果 ICMP 也卡在同一位置，那问题更可能出在路由或链路层面。
第四步，对卡住的那一跳做精细复测，加大探测包数量和超时时间：
sudo traceroute -T -p 443 -q 5 -w 3 -n api.example.com如果多次复测结果一致，基本可以确认问题位置。接下来就是联系对应链路的网络管理员，或者检查本端到那一跳之间的防火墙策略。
6.2 排查中容易踩的三个坑
第一个坑：把* * *直接当成故障。前面说过，很多路由器就是不回 ICMP 超时消息。判断标准是看后续跳数是否恢复。如果中间几跳是*但后面又出现了正常跳数，那只是中间设备不响应，路径本身是通的。
第二个坑：忽略探测方式的影响。同一个目标，UDP 模式看到 15 跳，TCP 模式可能只看到 8 跳，因为中间设备对不同协议的处理策略不同。排查时要以"最贴近业务流量的探测方式"为准。业务走 TCP 就用 TCP 探测，业务走 UDP 就用 UDP 探测。
第三个坑：在容器里排查却看宿主机的路径。容器网络经过 NAT，容器内traceroute看到的第一跳通常是 Docker 网桥网关，而不是物理网络的第一跳。要排查真实路径，得在宿主机上跑，或者用--net=host模式启动容器。
6.3 结合 mtr 做持续观测
traceroute是"一次性快照"，而网络问题是动态的。如果怀疑是间歇性丢包，单次traceroute很可能抓不到。这时候可以用mtr（My Traceroute），它把traceroute和ping结合起来，持续对每一跳发包并统计丢包率：
# 安装 mtr sudo apt install mtr # 以报告模式跑 100 个包 mtr -r -c 100 api.example.commtr的输出会显示每一跳的丢包率和延迟统计，比单次traceroute更能反映间歇性问题。我的经验是：traceroute用来快速定位路径，mtr用来确认问题是否持续存在。两者配合使用，排查效率会高很多。
7. 几个容易被忽略的边界情况
7.1 目标禁 ping 时 traceroute 还能用吗
能。traceroute不依赖目标响应 ICMP Echo。UDP 模式下，目标回的是 ICMP Port Unreachable；TCP 模式下，目标回的是 TCP RST 或 SYN-ACK。只要目标主机在运行，这些响应通常都会有。所以"目标禁 ping"不影响traceroute探测到目标，只是最后几跳的判定方式不同。
7.2 IPv6 环境下的 traceroute6
如果你的环境是 IPv6，要用traceroute6命令（有些发行版里是traceroute -6）：
traceroute6 example.com # 或者 traceroute -6 example.comIPv6 的traceroute原理和 IPv4 一样，也是靠 Hop Limit（相当于 IPv4 的 TTL）递减。但 IPv6 没有 UDP 校验和的问题，探测方式略有不同。如果你的网络是双栈的，排查时要注意区分走的是 v4 还是 v6 路径，两者可能完全不同。
7.3 输出里的 AS 号和地理位置信息
原生traceroute不显示 AS 号和地理位置。如果需要这些信息，可以配合whois查询每一跳的 IP：
whois 203.0.113.5 | grep -i "org-name\|country"或者用一些在线的可视化工具，把traceroute输出粘贴进去生成路径图。不过在排查生产问题时，我一般不用这些花哨的工具，直接看 IP 和延迟就够了。AS 号信息在判断"路径是否绕路"时有用——如果去程经过了三个不同的 AS 才到目标，而目标明明就在同一个城市，那大概率是路由策略有问题。
7.4 权限不足时的降级方案
如果既没有 root 权限，也不能设置 capability，-T和-I都用不了，只能用默认的 UDP 模式。这时候如果 UDP 被拦截，排查会受限。降级方案是用ping配合-R参数（记录路由）：
ping -R -c 1 example.comping -R会记录去程和回程经过的路由器，但最多只能记录 9 跳，而且很多路由器不支持这个选项。它只能作为traceroute不可用时的补充手段，精度和完整性都差不少。
8. 我在实际使用中总结的几条经验
traceroute这个工具看起来简单，但真正用好需要理解它背后的机制和局限。我踩过的坑里，最常见的就是把* * *当成故障、把单次结果当成定论、忽略探测方式对结果的影响。这三点如果都能避开，排查效率会提升一大截。
另外一个实用习惯是：把常用的traceroute命令做成 alias。比如我在.bashrc里加了alias tr='traceroute -n -q 1 -w 1'，日常快速排查直接敲tr就行。需要精细复测时再用完整参数。这种小习惯积累下来，能省下不少敲命令的时间。
最后分享一个判断路径是否"正常"的土办法：把traceroute的结果和ping的延迟对比。如果ping目标显示 20ms，而traceroute最后一跳也是 20ms 左右，说明路径延迟主要来自物理距离，正常；如果ping是 20ms 但traceroute中间某一跳突然出现 200ms 然后后面又降回 20ms，那这一跳的高延迟大概率是设备本身处理 ICMP 慢，不是链路问题。这个对比方法虽然粗糙，但在没有专业链路监控工具的情况下，能快速帮你排除掉大部分误判。
