用 traceroute 追踪数据包的网络路径：从本机到目标主机的每一跳-平芜编程栈

文档
教程
知识库

【免费下载链接】til

:memo: Today I Learned

项目地址：https://gitcode.com/gh_mirrors/ti/til

本篇技术指南讲解如何使用traceroute命令，逐跳还原数据包从你的机器到目标主机服务器的真实网络路径。结合 path-of-the-packets.md 中的完整示例输出，你将学会读懂每一跳的 IP、主机名与往返时延，掌握用跳数定位延迟瓶颈、判断断点所在网段的实战方法，并了解与dig等 DNS 工具配合使用的诊断套路。

为什么要追踪数据包路径

当你访问一个网站、SSH 一台服务器或调用一个 API 时，数据包并不是"直接飞到"目标机器的。它会依次经过你的局域网网关、运营商的接入设备、骨干路由、对等互联节点等多个中间路由设备——这些设备在行业中被称为"一跳"（hop）。

大多数时候这些中间环节是透明的，你只关心最终结果。但当出现网页加载缓慢、连接超时、丢包严重等问题时，"能通"与"通畅"是两回事：数据可能到达了目标，却在某个中间节点上消耗了大量时间。此时你需要一种手段，把整条路径上的每一跳都摊开来看——这就是traceroute的价值所在。

基本用法：一行命令看清整条路径

traceroute的用法非常简单，把目标主机名（域名或 IP）作为参数传入即可：

$ traceroute joshbranchaud.com

下面是 path-of-the-packets.md 中给出的真实输出，该示例来自作者从机场 Wi-Fi 连接笔记本到其个人站点的场景：

traceroute to joshbranchaud.com (198.74.60.157), 64 hops max, 52 byte packets 1 hotspot.boingohotspot.net (192.168.144.1) 1.209 ms 1.427 ms 1.080 ms 2 192.168.13.1 (192.168.13.1) 5.272 ms 3.545 ms 6.231 ms 3 10.106.144.1 (10.106.144.1) 13.671 ms 15.311 ms 12.895 ms 4 68.13.10.184 (68.13.10.184) 14.789 ms 12.980 ms 13.628 ms 5 68.13.8.221 (68.13.8.221) 19.922 ms 12.611 ms 17.853 ms 6 nyrkbprj01-ae3.0.rd.ny.cox.net (68.1.5.157) 48.917 ms 56.641 ms 51.771 ms 7 eqix.e-2-3.tbr2.ewr.nac.net (198.32.118.157) 62.977 ms 52.970 ms 48.667 ms 8 0.e1-2.tbr2.mmu.nac.net (209.123.10.114) 66.253 ms 57.311 ms 52.242 ms 9 207.99.53.46 (207.99.53.46) 57.478 ms 53.443 ms 54.510 ms 10 joshbranchaud.com (198.74.60.157) 59.853 ms 56.375 ms 55.393 ms

首行是摘要信息：目标域名解析为198.74.60.157，最多追踪 64 跳，探测包 52 字节。从输出中"64 hops max、52 byte packets"的表述看，这与 macOS/BSD 版traceroute的默认行为一致（Linux 常见实现默认上限为 30 跳），说明示例运行环境为类 BSD 的 traceroute 实现。

读懂每一跳：行内三要素

从第 2 行开始，每一行代表路径上的一个路由节点，包含三个信息块：

跳序号：最左侧的数字，1 表示第一跳，通常就是你的网关；
主机名与 IP：括号前是反向解析出的主机名，括号内是 IP 地址。反向解析不可用或路由器未配置 PTR 记录时，会直接显示 IP；
三个时间值：traceroute默认对每一跳发送 3 次探测，每次都会记录往返时延（RTT，单位毫秒）。因此每行出现三个时间，分别对应三次探测的结果。

把原始输出逐行拆开，可以得到这样一张路径全景表：

跳数	节点	IP 段	角色判断	典型时延
1	hotspot.boingohotspot.net	192.168.144.1	机场 Wi-Fi 网关（局域网）	约 1 ms
2	无主机名	192.168.13.1	内网二级路由	约 5 ms
3	无主机名	10.106.144.1	运营商私有接入段	约 15 ms
4–5	无主机名	68.13.10.184 / 68.13.8.221	ISP（Cox）骨干边缘	约 13–20 ms
6	nyrkbprj01-ae3.0.rd.ny.cox.net	68.1.5.157	ISP 区域汇聚路由（纽约）	约 50 ms
7–9	eqix/nac.net 系列	198.32.x.x / 209.123.x.x	对等互联与中转网络	约 48–66 ms
10	joshbranchaud.com	198.74.60.157	目标主机	约 55–60 ms

这张表揭示了几条值得注意的规律：

前三跳是"最后一公里"：192.168.x.x 与 10.x.x.x 都是私有地址段（RFC 1918），它们分别代表机场热点网关、内网路由和运营商的接入设备。如果你在自己家里或公司执行traceroute，看到 192.168.1.1、10.0.0.x 之类的地址同样意味着流量正处在本地网络内。
第 4 行起进入公网：68.13.10.184这类地址属于 ISP（示例中是 Cox）的公网地址段，此后每一跳都在运营商网络中。
主机名包含拓扑信息：第 6 行nyrkbprj01-ae3.0.rd.ny.cox.net中的ny表明该节点位于纽约，ae3.0通常是链路聚合接口（aggregated Ethernet）的编号——路由器的主机名常常直接暴露其地理位置和链路类型，是判断流量走向的免费情报。
时延的台阶式跃升：前三跳在 15 ms 以内，第 4–5 跳在 20 ms 以内，第 6 跳突然跳到 50 ms 左右。这种"台阶"通常对应着流量从一个网络域进入另一个网络域（如从本地接入网进入跨地域骨干），随后各跳保持稳定。如果某两跳之间出现突兀的大幅时延增长，那一段就是值得重点排查的链路。

常见的输出符号：`*`号意味着什么

实际使用中你会经常看到这样的输出行：

4 * * *

一行三个*表示这一跳的三次探测全部超时。这并不一定代表网络中断，常见原因包括：

该路由器出于安全策略不响应 traceroute 所用的探测报文；
路由器负载过高，丢弃了探测包；
某些中间设备只转发数据但不回复 ICMP 报文。

因此遇到*时，只要后续跳数仍然正常返回，通常可以认为路径是通的，只是个别节点"沉默"而已。只有连续大量跳数超时且最终无法到达目标时，才需要怀疑真正的断点。若要进一步确认，可以对比多轮 traceroute 的结果（例如使用mtr这类持续探测工具，或直接对目标执行连接测试）。

常用参数：man 手册里的常用选项

原文档在结尾建议通过man traceroute查看完整细节。结合常见实现，以下几个高频选项值得掌握：

参数	作用
`-m <hops>`	设置最大跳数上限，默认值在 macOS/BSD 为 64、Linux 常见为 30
`-q <n>`	设置每一跳的探测次数，默认通常为 3（对应每行三个时间值）
`-w <sec>`	设置等待每次探测回复的超时秒数，默认通常为 5 秒
`-n`	不做反向域名解析，直接显示 IP，可明显加快输出速度
`-I`	改用 ICMP Echo（类似 ping）作为探测报文，部分网络下更易被响应
`-p <port>`	指定目标端口（针对 UDP 探测模式）

例如，快速只显示 IP、单跳只探测一次、最多 20 跳的用法：

$ traceroute -n -q 1 -m 20 joshbranchaud.com

注意：不同发行版/平台的 traceroute 参数略有差异，具体以你机器上man traceroute的手册页为准。某些探测模式（如-I）在个别实现上需要 root 权限。

配合 dig 使用：先确认目标，再追踪路径

traceroute 首行输出中的 IP 来自 DNS 解析，而解析结果本身也可能成为排查对象——例如域名解析到了错误或陈旧的 IP，那么路径追踪自然也会"走错路"。在动手追踪之前，先用dig确认目标域名当前的解析结果，是一个稳妥的检查顺序。

仓库的 determine-the-ip-address-of-a-domain.md 展示了dig的基础用法：直接dig <domain>后，在输出的 ANSWER SECTION 中即可看到该域名对应的 A 记录 IP。

如果你觉得完整输出太啰嗦，resolve-the-public-ip-of-a-url.md 提供了更干净的写法——追加+short参数，直接只打印 IP：

$ dig joshbranchaud.com +short 159.203.106.229

将解析出的 IP 与 traceroute 首行的目标 IP 对照，若不一致，问题可能出在 DNS 层而非网络路径层；若一致，再根据 traceroute 的跳数数据定位网络层的问题。这套"dig 验证解析 + traceroute 追踪路径"的组合，是日常网络诊断中常用且高效的流程。

实战场景：什么时候该掏出 traceroute

综合上面的知识，traceroute最常见的用武之地有三个：

定位高延迟的来源：访问目标很慢时，逐跳查看 RTT。若所有跳都正常而只有最终目标慢，问题通常在目标服务器；若某两个特定节点之间 RTT 骤增，瓶颈就在那段链路。
判断连接失败的断点：路径在中途某跳全部*且之后也无法到达，说明断点位于该区域；若本地网络正常而第一跳就超时，问题往往在本地网关。
确认流量是否绕路：通过主机名中的城市缩写（如示例中的ny）可以判断流量是否绕经了非预期地区，从而评估跨地域访问的合理性。

需要说明的是，本仓库是 TIL（Today I Learned）知识笔记集合（见 README.md），traceroute本身是类 Unix 系统自带的网络诊断工具，不属于仓库源码，因此以上参数与行为描述基于该工具的通用实现。若你需要更深入的内容，man traceroute是权威的一手资料；本仓库 devops 分类下的 determine-the-ip-address-of-a-domain.md 与 resolve-the-public-ip-of-a-url.md 也可作为网络诊断工具箱的相邻补充。