tracepath 命令详解与参数实测（Ubuntu 22.04）
以 Ubuntu 22.04（iputils-tracepath 20211215）实测逐参数讲解 tracepath 命令：-n、-m 最大跳数、-l 初始包长、-p 目标端口、-b 双显名字与 IP、-4/-6 地址族全部选项与真实回显，覆盖跳数/延迟/MTU/pmtu 输出列解读、中间跳被过滤的 no reply 真实现象、tracepath6 的去留与 traceroute/mtr 三方对比。
tracepath 命令详解与参数实测（Ubuntu 22.04）
目标：全面掌握 tracepath 的每一个参数——
-n关闭反向解析、-m最大跳数、-l初始探测包长、-p目标端口、-b同时打印名字与 IP、-4/-6地址族，并读懂跳数/延迟/MTU/pmtu 输出列、reached/Too many hops/Resume终态行、中间跳被过滤时的no reply真实现象，全部命令与回显已在 Ubuntu 22.04（iputils-tracepath 20211215）实测通过。
一、环境信息
本文所有命令均在以下真实服务器环境逐条执行并记录回显，读者可按相同条件复现：
- 操作系统：Ubuntu 22.04.5 LTS，架构 x86_64，root 用户执行；
- tracepath 版本：
tracepath from iputils 20211215（软件包版本3:20211215-1ubuntu0.1）； - 本机地址
172.17.0.2/16，默认网关（默认路由下一跳）172.17.0.1； - 上联出口
192.168.146.2（NAT 出口设备，同时是内网 DNS 服务器）； - 演示目标选型：公网
223.5.5.5（阿里公共 DNS，网络可达、可 ping）、内网网关172.17.0.1、回环127.0.0.1与::1；IPv6 公网目标240c::6666与ipv6.baidu.com（本机无 IPv6 出口，用于实测-6的失败形态）。
💡 说明：本文到公网目标的探测路径在第 2 跳之后全部显示
no reply——这是本服务器到公网链路的真实现象（中间设备不回送 ICMP 超时报文，见 5 章 Q1），如实保留、不回避；到回环目标的reached完整形态用于对照「正常到达示例」。
二、命令概览
2.1 语法与测试数据
tracepath 是 iputils 自带的路径追踪工具，向目标逐跳发送探测包并利用 ICMP「超时/不可达」报文收集沿途每一跳，同时沿途收集 PMTU（路径最大传输单元） 信息——这是它与 traceroute 最核心的差异。语法（取自实测 usage 原文）：
Usage
tracepath [options] <destination>
Options:
-4 use IPv4
-6 use IPv6
-b print both name and ip
-l <length> use packet <length>
-m <hops> use maximum <hops>
-n no dns name resolution
-p <port> use destination <port>
-V print version and exit
<destination> dns name or ip address
<destination>：必填，目标的域名或 IP 地址；- 选项均为单字母短选项，无等价长选项（2.2 实测）。
本文测试数据约定：公网目标 223.5.5.5，内网网关 172.17.0.1，上联出口 192.168.146.2，回环 127.0.0.1/::1，IPv6 目标 240c::6666。每个参数小节均可独立执行复现。
2.2 usage 全量输出（无参数 / -h / --help 三形态）
tracepath 不带参数时打印 usage 并退出（退出码 255）；-h 打印同一段 usage；--help 不被识别，报 invalid option -- '-' 后打印同一段 usage。三形态实测：
tracepath
tracepath -h
tracepath --help
实测回显（无参数形态；-h 输出与之一致；--help 仅在首行多一行 tracepath: invalid option -- '-'）：
$ tracepath
Usage
tracepath [options] <destination>
Options:
-4 use IPv4
-6 use IPv6
-b print both name and ip
-l <length> use packet <length>
-m <hops> use maximum <hops>
-n no dns name resolution
-p <port> use destination <port>
-V print version and exit
<destination> dns name or ip address
For more details see tracepath(8).
退出码=255
$ tracepath --help
tracepath: invalid option -- '-'
（以下 usage 与无参数形态逐行一致，略）
退出码=255
⚠️ 两个结论：① tracepath 没有 --help 长选项（报 invalid option 后仍打印用法）；② 三种形态的退出码都是 255（getopt 解析失败的固定返回值），不是常见的 1 或 2。
2.3 版本信息与 tracepath6 的去留
tracepath -V
dpkg -S /usr/bin/tracepath
dpkg -l iputils-tracepath | tail -1
ls -l /usr/bin/tracepath*
which tracepath6
实测回显：
$ tracepath -V
tracepath from iputils 20211215
退出码=0
$ dpkg -S /usr/bin/tracepath
iputils-tracepath: /usr/bin/tracepath
$ dpkg -l iputils-tracepath | tail -1
ii iputils-tracepath 3:20211215-1ubuntu0.1 amd64 Tools to trace the network path to a remote host
$ ls -l /usr/bin/tracepath*
-rwxr-xr-x 1 root root 18584 Jul 24 2025 /usr/bin/tracepath
$ which tracepath6
tracepath6 不存在
tracepath6: command not found
💡 要点：老版本 iputils 会提供独立的 tracepath6（IPv6 版 tracepath），Ubuntu 22.04 的 iputils 20211215 不再提供 tracepath6 二进制——IPv6 探测统一走 tracepath -6（见 3.8）。写成脚本时不要再 which tracepath6 判断，直接 tracepath -6。
三、参数逐项实测
3.1 无参数基础探测：tracepath 223.5.5.5 与输出列解读
不带选项向公网目标探测，是最常用形态。实测：
tracepath 223.5.5.5
实测回显（完整 30 跳）：
$ tracepath 223.5.5.5
1?: [LOCALHOST] pmtu 1500
1: 172.17.0.1 0.454ms
1: 172.17.0.1 0.026ms
2: 192.168.146.2 0.109ms
3: no reply
4: no reply
5: no reply
（第 5~29 跳均为 no reply，逐行一致，略）
29: no reply
30: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
退出码=0
输出列完整解读：
| 输出片段 | 含义 |
|---|---|
1?: [LOCALHOST] pmtu 1500 | 起始行：本机发出（? 表示路径未知），初始 pmtu 取自出口接口 MTU（本机 1500） |
1: 172.17.0.1 0.454ms | 第 1 跳：返回报文的源地址 + 往返延迟（毫秒）。同一跳打印两行 = tracepath 对该跳发了两个探测包（几微秒内重复出现属正常） |
2: 192.168.146.2 0.109ms | 第 2 跳：NAT 出口设备应答 |
3~30: no reply | 中间跳无应答（设备不回 ICMP 超时，或探测包被过滤） |
Too many hops: pmtu 1500 | 达到最大跳数（默认 30）仍未到达目标 |
Resume: pmtu 1500 | 结束汇总：整条路径的 PMTU 结论 |
💡 要点：tracepath 用「UDP 探测包 + ICMP 超时应答」收集路径；能看 no reply 出现的位置即可判断过滤发生在第几跳之后（本例第 2 跳之后的公网方向全部被过滤，但路径探测仍正常发起）。
3.2 -n：不做反向解析
-n（no dns name resolution）跳过对每一跳地址的 PTR 反查。实测：
tracepath -n 223.5.5.5
实测回显（前 5 跳）：
$ tracepath -n 223.5.5.5
1?: [LOCALHOST] pmtu 1500
1: 172.17.0.1 0.061ms
1: 172.17.0.1 0.005ms
2: 192.168.146.2 0.146ms
3: no reply
（第 4~30 跳均为 no reply，逐行一致，略）
Too many hops: pmtu 1500
Resume: pmtu 1500
退出码=0
💡 要点：本例输出与不带 -n 时一致——因为这些跳点本就没有 PTR 记录。-n 的真实价值：① 公网探测时跳点若有 PTR 可免去 DNS 反查等待（尤其 PTR 缺失时的超时）；② 输出稳定显示 IP，便于脚本 grep。要「同时看名字和 IP」用 -b（3.6）。
3.3 -m：最大跳数
-m 跳数 限制探测的最大跳数（默认 30），达到即打印 Too many hops 收尾。实测 3 跳、1 跳、0 跳三种：
tracepath -m 3 223.5.5.5
tracepath -m 1 192.168.146.2
tracepath -m 0 223.5.5.5
实测回显：
$ tracepath -m 3 223.5.5.5
1?: [LOCALHOST] pmtu 1500
1: 172.17.0.1 0.054ms
1: 172.17.0.1 0.027ms
2: 192.168.146.2 0.098ms
3: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
退出码=0
$ tracepath -m 1 192.168.146.2
1?: [LOCALHOST] pmtu 1500
1: 172.17.0.1 0.040ms
1: 172.17.0.1 0.017ms
Too many hops: pmtu 1500
Resume: pmtu 1500
退出码=0
$ tracepath -m 0 223.5.5.5
Too many hops: pmtu 65535
Resume: pmtu 65535
退出码=0
💡 要点：
-m 3把 30 跳压成 3 跳，第 3 跳无应答后立即以Too many hops收尾——脚本里做「快速探测首两跳」的标准写法；-m 0不发任何探测包，直接Too many hops: pmtu 65535（此时没有任何路径信息，pmtu 退回 65535 占位值），可用于验证 tracepath 自身可用性；- 注意
-m 1 192.168.146.2显示网关后即终止：-m计数的是跳数上限，目标在第 2 跳而上限是 1，同样以Too many hops结束——它不代表「到不了」，只代表「没走完」。
3.4 -l：初始探测包长
-l 字节 指定初始探测包长度（默认从接口 MTU 派生）。包长直接影响 PMTU 探测路径，回显里的 pmtu 值会跟随变化。实测 1200 字节与超限的 70000 字节：
tracepath -l 1200 223.5.5.5
tracepath -l 70000 223.5.5.5
实测回显：
$ tracepath -l 1200 223.5.5.5
1: 172.17.0.1 0.026ms
2: 192.168.146.2 0.159ms
3: no reply
4: no reply
Too many hops: pmtu 1200
Resume: pmtu 1200
退出码=0
$ tracepath -l 70000 223.5.5.5
1: send failed
Resume: pmtu 70000
退出码=0
💡 要点：
-l 1200后起始行不再出现[LOCALHOST] pmtu 1500，终态pmtu 1200与包长一致——PMTU 结论按你设定的初始长度起算；-l 70000超过 UDP 报文上限（65535），第一跳直接send failed，但退出码仍为 0——tracepath 的失败不明显体现在退出码（详见 5 章 Q6），判断要靠输出；-l的典型用途：验证「更小包能通、大包被丢」的 PMTU 黑洞问题（如 VPN/隧道场景把初始包长设为 1200/1400 逐步试探）。
3.5 -p：目标端口
-p 端口 设置探测 UDP 包的目的端口（默认从 44444 起步递增）。实测 53 端口：
tracepath -p 53 223.5.5.5
实测回显：
$ tracepath -p 53 223.5.5.5
1?: [LOCALHOST] pmtu 1500
1: 172.17.0.1 0.037ms
1: 172.17.0.1 0.026ms
2: 192.168.146.2 0.142ms
3: no reply
4: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
退出码=0
💡 要点：-p 不改变「ICMP 超时应答」收集机制，只改变探测包的伪装端口。用途：某些中间设备按端口过滤 UDP，换 -p（如 53/123/8080）有时能让探测包穿透到更远一跳；对目标本身，端口是否开放不影响结果（tracepath 不期待目标应用层应答）。
3.6 -b：同时打印名字与 IP
-b（print both name and ip）在每一跳同时显示主机名与 IP 地址。实测：
tracepath -b 223.5.5.5
实测回显：
$ tracepath -b 223.5.5.5
1?: [LOCALHOST] pmtu 1500
1: 172.17.0.1 (172.17.0.1) 0.038ms
1: 172.17.0.1 (172.17.0.1) 0.011ms
2: 192.168.146.2 (192.168.146.2) 0.093ms
3: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
退出码=0
💡 要点：输出格式变为 名字 (IP)——本例这些内网设备没有 PTR 记录，名字与 IP 相同；在公网链路上探测时（若有跳点 PTR）能看到形如 router-gw.example.net (203.0.113.9) 的双显行。与 -n 的关系：-b 需要做反查，-n 跳过反查，两者互斥使用。
3.7 -4：强制 IPv4 探测
-4 强制使用 IPv4 传输（对 IPv4 目标是默认行为）。实测：
tracepath -4 223.5.5.5
实测回显：
$ tracepath -4 223.5.5.5
1?: [LOCALHOST] pmtu 1500
1: 172.17.0.1 0.031ms
1: 172.17.0.1 0.025ms
2: 192.168.146.2 0.076ms
3: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
退出码=0
💡 要点：-4 对 IPv4 目标等价于默认行为；它的存在意义是与 -6 成对出现，在「域名目标」场景强制地址族（如双栈域名同时有 A/AAAA 记录时，tracepath -4 域名 锁定走 IPv4 路径）。
3.8 -6：IPv6 探测（三种形态全实测）
-6 强制 IPv6 传输。实测 IPv6 回环、IPv6 公网目标、对 IPv4 目标误用三种形态：
tracepath -6 ::1
tracepath -6 240c::6666
tracepath -6 ipv6.baidu.com
tracepath -6 223.5.5.5
tracepath 240c::6666
实测回显：
$ tracepath -6 ::1
1?: [LOCALHOST] 0.009ms pmtu 65536
1: localhost 0.723ms reached
1: localhost 0.016ms reached
Resume: pmtu 65536 hops 1 back 1
退出码=0
$ tracepath -6 240c::6666
1: send failed
Resume: pmtu 128000
退出码=0
$ tracepath -6 ipv6.baidu.com
1: send failed
Resume: pmtu 128000
退出码=0
$ tracepath -6 223.5.5.5
tracepath: 223.5.5.5: Address family for hostname not supported
退出码=1
$ tracepath 240c::6666
1: send failed
Resume: pmtu 128000
退出码=0
💡 要点（三种形态对应三类现象）：
::1回环reached：有完整应答的标准到达示例——reached标记、Resume: pmtu 65536 hops 1 back 1（pmtu=65536、1 跳、回程路由对称 back 1）。IPv6 回环接口 pmtu 65536（IPv4 回环是 65535，见 3.9）；- IPv6 公网目标
send failed：本机无 IPv6 出口（无默认 IPv6 路由），探测包根本发不出去，起始 pmtu 显示 128000（IPv6 理论上限占位）； -6对 IPv4 目标：地址族不匹配，直接报Address family for hostname not supported退出码 1——这是三种形态里唯一 rc≠0 的；- 对 IPv6 字面量目标不加
-6也自动走 IPv6（形态 4 与形态 2 输出一致）。
3.9 目标可达性三态：reached / no reply + Too many hops / send failed
用同一条命令对三类目标实测，对照 tracepath 的三种终态。实测：
tracepath 127.0.0.1
tracepath 192.168.146.2
实测回显：
$ tracepath 127.0.0.1
1: localhost 0.029ms reached
Resume: pmtu 65535 hops 1 back 1
退出码=0
$ tracepath 192.168.146.2
1?: [LOCALHOST] pmtu 1500
1: 172.17.0.1 0.038ms
1: 172.17.0.1 0.013ms
2: no reply
3: no reply
（第 3~30 跳均为 no reply，逐行一致，略）
30: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
退出码=0
⚠️ 如实记录的真实波动：192.168.146.2（同一台上联设备）在 3.1/3.3 的探测中曾于第 2 跳正常应答（0.098~0.159ms），而本次全程 30 跳 no reply——中间设备对 tracepath 高端口 UDP 探测的应答并不稳定（设备 CPU 繁忙、速率限制、探测端口递增后的过滤策略都会影响）。这正是 5 章 Q1「no reply ≠ 不通」的实证：判断目标可达性要以 ping/业务端口为准，tracepath 看的是「沿途谁回话」。
💡 要点：reached（回环形态）行没有 pmtu 起始行时 pmtu 仍出现在 Resume（IPv4 回环 65535）；Too many hops + no reply 说明路径未走完且沿途无应答；send failed 说明本地根本发不出去（无路由/无出口）。三态判读表：
| 终态 | 含义 | 典型原因 |
|---|---|---|
reached | 探测包到达目标 | 正常到达 |
no reply + Too many hops | 走满跳数未达，沿途（部分）无应答 | 中间设备过滤 ICMP 超时应答 |
send failed | 本地发包失败 | 无对应协议出口/路由 |
3.10 技术拓展：tracepath 与 traceroute、mtr 对比
Ubuntu 22.04 下三个路径探测工具的定位差异（traceroute 属独立包 traceroute，mtr 属 mtr-tiny/mtr 包，均为常见配套工具）：
| 维度 | tracepath（本文主角） | traceroute | mtr |
|---|---|---|---|
| 软件包 | iputils-tracepath（Ubuntu 默认预装） | traceroute（需另装） | mtr-tiny / mtr（需另装） |
| 探测方式 | UDP（-p 指定端口），自动跟随 ICMP 报文 | 默认 UDP，可 -I 用 ICMP、-T 用 TCP | 可选 ICMP/UDP/TCP |
| PMTU 发现 | ✔ 独有能力（沿途自动收集并打印 pmtu 变化） | ✘（仅 traceroute6 部分相关选项） | ✘ |
| 输出形态 | 一次性打印后退出 | 一次性打印后退出 | 全屏交互实时刷新（-r 报表模式） |
| 每跳统计 | 单轮往返延迟 | 单轮往返延迟 | 丢包率/最好/平均/最差（持续多轮） |
| root 权限 | 不需要（UDP 高端口） | UDP/ICMP 模式不需要，TCP/原始套接字模式部分需要 | 需要（构造 ICMP/TCP 探测） |
| 适用场景 | 快速看路径 + 诊断 MTU 黑洞 | 经典逐跳排障、指定探测类型 | 定位「哪一跳在丢包」（持续观测） |
💡 要点：选型一句话——随手看路径和 MTU 用 tracepath（预装且免 root）；要指定 ICMP/TCP 探测方式用 traceroute；要持续定位丢包跳点用 mtr。三者都依赖沿途设备回送 ICMP 超时报文，no reply/* * * 的成因相同（见 Q1）。
四、实战示例
4.1 场景一：验证本机网关与首跳连通
网络故障的第一步：确认默认网关本身可达且延迟正常（首跳通常 < 1ms）：
tracepath -n -m 2 172.17.0.1
tracepath -n 223.5.5.5 | head -4
实测回显：
$ tracepath -n -m 2 172.17.0.1
1?: [LOCALHOST] pmtu 1500
1: 172.17.0.1 0.042ms reached
1: 172.17.0.1 0.006ms reached
Resume: pmtu 1500 hops 1 back 1
退出码=0
$ tracepath -n 223.5.5.5 | head -4
1?: [LOCALHOST] pmtu 1500
1: 172.17.0.1 0.024ms
1: 172.17.0.1 0.005ms
2: 192.168.146.2 0.134ms
要点：Resume: pmtu 1500 hops 1 back 1 = 1 跳到达、回程对称，且两行都带 reached 标记，网关健康；head -4 裁剪公网探测的前 4 行即可看到「本机→网关→出口」两跳结构。⚠️ 网关目标用 -m 2 保证探测走完（hops 1 即 reached）；目标更远时用更大 -m。
4.2 场景二：PMTU 黑洞排查（用 -l 逐步降低包长）
「ping 通但业务卡死/大包丢」的经典排查：用 -l 从大包开始逐步降档，观察哪一档不再有应答（PMTU 黑洞定位思路）：
tracepath -n -m 3 -l 1472 223.5.5.5
tracepath -n -m 3 -l 1200 223.5.5.5
实测回显：
$ tracepath -n -m 3 -l 1472 223.5.5.5
1: 172.17.0.1 0.045ms
2: 192.168.146.2 0.137ms
3: no reply
Too many hops: pmtu 1472
Resume: pmtu 1472
退出码=0
$ tracepath -n -m 3 -l 1200 223.5.5.5
1: 172.17.0.1 0.045ms
2: 192.168.146.2 0.147ms
3: no reply
Too many hops: pmtu 1200
Resume: pmtu 1200
退出码=0
要点：本例两个包长在前两跳都有应答（该链路对 1472 字节探测仍转发），pmtu 结论跟随 -l 值。若某链路对大包在特定跳之后 send failed 或全部无应答而小包正常，即可锁定 PMTU 降档点——这是 VPN/隧道/GRE 场景最实用的 tracepath 技能。
4.3 场景三：换端口探测绕过 UDP 过滤
部分中间设备只过滤特定端口的 UDP 探测。用 -p 换目标端口（53/123 等常见放行端口）再探：
tracepath -n -m 3 223.5.5.5
tracepath -n -m 3 -p 53 223.5.5.5
实测回显：
$ tracepath -n -m 3 223.5.5.5
1?: [LOCALHOST] pmtu 1500
1: 172.17.0.1 0.050ms
1: 172.17.0.1 0.006ms
2: 192.168.146.2 0.148ms
3: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
退出码=0
$ tracepath -n -m 3 -p 53 223.5.5.5
1?: [LOCALHOST] pmtu 1500
1: 172.17.0.1 0.095ms
1: 172.17.0.1 0.006ms
2: 192.168.146.2 0.164ms
3: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
退出码=0
要点：本例换 53 端口后路径应答范围不变（第 2 跳之后的过滤与端口无关，属 ICMP 超时应答被过滤）。对比实验的价值在于排除「端口过滤」这一变量：多端口结果一致 → 过滤发生在 ICMP 应答层面；某端口能穿透更远 → 换该端口探测。
4.4 场景四：无 IPv6 出口的快速诊断
判断本机有没有 IPv6 出口，一条命令即可（结合 3.8 三形态）：
tracepath -6 ::1
tracepath -6 240c::6666
实测回显：
$ tracepath -6 ::1
1?: [LOCALHOST] 0.008ms pmtu 65536
1: localhost 0.766ms reached
1: localhost 0.024ms reached
Resume: pmtu 65536 hops 1 back 1
退出码=0
$ tracepath -6 240c::6666
1: send failed
Resume: pmtu 128000
退出码=0
要点：::1 能 reached 说明 IPv6 协议栈本身在；公网目标 send failed 说明没有 IPv6 默认路由/出口——两层结论一次分清。若两者都失败则应检查 IPv6 内核模块与地址配置。
五、注意事项与常见问题
Q1：到公网的探测全是 no reply，是不是网络不通？
大概率不是。tracepath 依赖沿途路由器回送 ICMP「TTL 超时」报文；出于安全（防探测）与性能考虑，公网链路普遍对这类应答限速或不回送（实测本环境第 2 跳之后全部 no reply，但业务访问 223.5.5.5 完全正常）。判断「通不通」用 ping 或业务端口探测；tracepath 的 no reply 只说明「这一跳不肯回话」，第 2 跳有应答、之后全无是常见形态。对照：目标为回环/本机网关时必有 reached（3.9/4.1）。
Q2：tracepath 的 no reply 和 traceroute 的 * * * 是一回事吗？
本质相同——都是该跳没有回送 ICMP 超时报文。差异在呈现：traceroute 打 * * *（一个探测一个星号，每跳 3 个），tracepath 直接打 no reply 一行。两工具在同一链路上不可达的跳点范围一致；tracepath 额外带 pmtu 信息，traceroute 可换 ICMP/TCP 探测方式（-I/-T）尝试穿透 UDP 过滤。
Q3：Too many hops / reached / Resume 三种结尾怎么读？
reached = 探测包到达目标，后面跟着本轮 PMTU 结论（如 Resume: pmtu 1500 hops 1 back 1，hops=到达所需跳数，back=回程路径是否对称）；Too many hops = 走完 -m 跳数上限仍未到达（不代表不通，3.3 的 -m 0 连探测都不发也是这个结尾）；send failed = 本地发包失败（无路由/无出口，3.8）。Resume: pmtu X 里的 X 是沿途确认的路径 MTU——若比接口 MTU 小，说明链路上有更小 MTU 的设备（隧道/VPN 常见）。
Q4：tracepath -6 报 Address family for hostname not supported？
-6 配了 IPv4 目标（3.8 实测 tracepath -6 223.5.5.5 即此错，退出码 1）。IPv6 探测要配 IPv6 地址或解析出 AAAA 的域名；对 IPv4 字面量目标不要加 -6。另外 Ubuntu 22.04 已无 tracepath6 命令（2.3 实测不存在），一律用 tracepath -6。
Q5：tracepath 需要 root 吗？为什么？ 不需要。它默认用 UDP 探测且源端口落在非特权范围（44444 起步递增），普通用户即可执行；traceroute 的 TCP 模式、mtr 默认模式需要构造原始套接字才要 root。这也是 tracepath 适合写进巡检脚本的原因之一。
Q6：tracepath 失败时退出码为什么还是 0？
实测（3.4/3.8/3.9）：send failed、no reply、Too many hops 的退出码都是 0，只有 usage 错误（rc=255）和地址族错误（rc=1）非零。tracepath 把「路径没走完」视为正常观察结果而非错误——探测本身就是结论。脚本里判断可达性要解析输出（grep reached），或改用 ping 的退出码做判断。
六、参考链接
- tracepath(8) 手册（Ubuntu 22.04 jammy）：https://manpages.ubuntu.com/manpages/jammy/en/man8/tracepath.8.html
- iputils 上游源码（tracepath 所在项目）：https://github.com/iputils/iputils
- traceroute(8) 手册（对比工具）：https://manpages.ubuntu.com/manpages/jammy/en/man8/traceroute.8.html
- mtr 手册（对比工具）：https://manpages.ubuntu.com/manpages/jammy/en/man8/mtr.8.html
- RFC 1191（路径 MTU 发现，pmtu 语义依据）：https://datatracker.ietf.org/doc/html/rfc1191
- RFC 792（ICMP 协议，超时/不可达应答机制）：https://datatracker.ietf.org/doc/html/rfc792