traceroute 路径追踪

上一节的 ping 告诉你"通不通、快不快"，但它有个致命盲区：你的包在互联网上到底走了哪条路？如果卡住了，是卡在哪一跳？这些问题 ping 一律答不上来——它只看起点和终点，中间是黑箱。这一节的主角 traceroute（Windows 上叫 tracert），专门负责掀开这个黑箱：它的魔术道具恰恰是上一节讲的 TTL 倒计数——故意把包的寿命设成 1、2、3……逼沿途每一个路由器"自报家门"，把一条看不见的路，变成一张看得见的逐跳地图。但读懂这张地图需要三个反直觉的常识：星号不等于故障、去路不等于回路、中间慢不等于真的慢——本节一个个拆给你看。

先把这一节的术语翻译成人话

照例术语先行，本节词汇不多，但每个都影响你读输出的姿势：

核心魔术：把 TTL 当钓鱼竿用

先复习上一节的关键设定：每个 IP 包头部有个 TTL 倒计数，每过一台路由器减 1，减到 0 时路由器把这个包销毁，并顺手用 ICMP 发一条"超时"消息回给寄件人。ping 是老老实实地用 TTL——设大一点，让它活着到终点。traceroute 的脑洞在于：故意把包弄死在半路。

推演一遍全程。第一个包，TTL 设成 1：它出发后到达第一台路由器（你家路由器或运营商的接入设备），路由器照章办事——减 1，归零，销毁，回一条"超时"消息。这条超时消息上带着路由器自己的 IP——它等于被迫自报了家门。第二个包，TTL 设成 2：顺利穿过第一跳（减成 1），到第二台路由器归零，第二台自报家门。第三个包 TTL=3，钓出第三跳……如此往复，直到某个包活着抵达目的地——目的地回的不是"超时"，而是"端口不可达"或回声应答，traceroute 看到这种回信就知道：到站了，收竿。

说白了，traceroute 就是用"故意超时"当鱼饵，一次钓一跳，钓到终点为止。每钓一跳，它连发三个包，分别掐表，于是每行输出有三个时间。一个去洛杉矶的包要过 15 台路由器，traceroute 就钓 15 轮——听起来笨，但整个探测过程通常几秒钟跑完，因为发包是流水线式的，不必等一轮钓完再发下一轮。

把这个过程画成图，一眼看穿。探测一个隔了三跳的目标：

第 1 轮：TTL=1 的包 → 路由器A 减到 0 → 销毁 → 回报"超时"(带A的IP)
        你 ←──────── A 自报家门：第 1 跳是 A

第 2 轮：TTL=2 的包 → A(减成1) → 路由器B 减到 0 → 销毁 → 回报"超时"(带B的IP)
        你 ←──────── B 自报家门：第 2 跳是 B

第 3 轮：TTL=3 的包 → A → B → 路由器C 减到 0 → 销毁 → 回报"超时"(带C的IP)
        你 ←──────── C 自报家门：第 3 跳是 C

第 4 轮：TTL=4 的包 → A → B → C → 目的地（活着到站！）
        你 ←──────── 目的地回"端口不可达"：收竿，路径共 4 跳

注意一个精妙处：每一轮包都要从头重走一遍前几跳——钓第 4 跳时，包先穿过 A、B、C 才在终点被应答。所以 traceroute 的总耗时是各轮之和，路径越长测得越久；30 跳的长路径，遇到慢的回包要等好几秒。这不是缺陷，是"只能从头走起"的必然——毕竟没有哪台路由器允许你"直接从第 10 跳开始测"。

为什么每跳测三次：采样而非占卜

你可能注意到每跳有三个时间——为什么要测三次而不是一次？因为网络延迟天生抖动：同一台路由器，这一秒 8ms、下一秒 50ms 都正常。只测一次，撞上尖刺还是低谷全凭手气，结论就是抽签。测三次取样本，你至少能看出三件事：基础水平（三个数都低=真快）、稳定性（三个数接近=稳）、是否偶发尖刺（两低一高=有抖动但不致命）。

这就是工程里最朴素的"采样"思想：想知道粥的温度，搅一搅再尝，比只尝一口靠谱。专业工具 mtr 更进一步——每跳测几百上千次，统计出每跳的平均值、最好、最差和丢包率，把"三次抽样"升级成"长期体检"。但原理完全同源：单次测量是占卜，多次采样才是测量。这个思想后面每一节都会反复出现，值得现在就刻进脑子里。

一段小历史：为什么 Windows 叫 tracert

插一段三十秒的考古，解答一个悬案：同一个工具，为什么 Windows 叫 tracert（8 个字母），macOS/Linux 叫 traceroute（11 个字母）？答案是历史包袱。traceroute 由传奇网络工程师范·雅各布森（Van Jacobson）在 1988 年写出，名字老老实实取 trace route 两个词。而 Windows 的命令行继承自 DOS 时代，DOS 规定文件名最多 8 个字符加 3 个字符扩展名（所谓 8.3 格式）——11 个字母塞不下，微软砍成了 tracert。三十多年过去，DOS 早已入土，这个砍短的名字却成了几亿 Windows 用户的肌肉记忆。技术的命名里全是历史的化石——你每敲一次 tracert，都是在给 1980 年代的文件名限制上坟。

亲手跑一次：命令与输出

动手。Windows 上命令名是 tracert（八个字母，是 trace route 的缩写）；macOS 和 Linux 上是 traceroute（Windows 里没有这个名字，得装）：

典型输出长这样（已简化）：

  1     3 ms     2 ms     3 ms  192.168.1.1
  2     6 ms     5 ms     6 ms  100.64.0.1
  3     8 ms     9 ms     8 ms  219.158.xxx.xxx
  4    10 ms    11 ms    10 ms  110.242.xxx.xxx
  5    12 ms    12 ms    11 ms  110.242.68.4

跟踪完成。

逐列拆解。第一列是跳数：第 1 跳就是你家路由器（192.168.1.1——内网地址，一眼认出）；第 2 跳通常是运营商的接入网关（100.64 开头是运营商内网段）；第 3 跳往后进入骨干网；最后一跳是目的地本身。中间三列是三个探测包各自的往返时间——注意，这是"你到这一跳"的累计时间，不是"上一跳到这一跳"的增量。最后一列是该跳路由器的 IP，很多系统还会附上反向解析出的主机名，例如 bt-229-253.dialup.bta.net.cn 这种，光看名字就能猜出城市和运营商。

读输出的三条军规：星号、跳变、最后一跳

新手拿到 traceroute 输出，最常犯三个解读错误。这三条军规请先背下来，后面逐条展开：

• 军规一：星号不等于故障某几行打星号（* * *）只是"这一跳没回话"，流量可能照样正常通行——见下文"星号的真相"。
• 军规二：中间某跳延迟高，不等于那里有问题路由器对探测包"优先级低、爱答不理"，回复慢不代表转发慢——判断延迟要看"最后一跳"的最终数字。
• 军规三：最后一跳才作数整条路径诊断的黄金标准：如果最后一跳时间正常，中间的波动基本可以无视；如果最后一跳不通，才回过头找"最后正常的一跳"和"第一个异常的跳"之间的那一段。

星号的真相：不回话的三种原因

输出里某一行变成 5 * * *，很多人第一反应"这里断了"。先别慌——星号只说明"这台路由器没有回复你的探测包"，和"你的流量过不去"完全是两码事。三种常见原因：

原因一：路由器不屑于回 ICMP。骨干网的核心路由器每天转发天文数字的包，它们的主业是转发，回 ICMP 差错报告属于"客服工作"——不少运营商干脆配置核心路由器"只转发、不回话"，把算力全部留给主业。这种星号最常见，也最无害：就像干线运输车不给客服回电话，但货照送。特征是：这跳是星号，下一跳却正常出现了——说明流量明明穿过去了。

原因二：防火墙拦截。第 8 章讲过，ICMP 会被安全策略限流或丢弃；不少企业网络、云服务商（回顾 § 7.2 的安全组）对来自陌生人的探测包直接静默。特征类似：星号后面继续有回应。

原因三：真的断了。这才是故障星号的模样——特征非常鲜明：从某一跳开始，后面全是星号，一直星到尾。前面有正常回应、某一行开始集体沉默、再无下文：这才是"路径断在最后一台肯说话的路由器之后"的铁证。记住这个对比：孤星无碍，连星断路。一个两个星号看都别看；一整片星号才值得行动。

去路不等于回路：非对称路由

接下来是本节第一个反直觉真相：traceroute 显示的路径，只是"去的方向"的路径。回程走的可能是完全另一条路。

为什么？回忆第 5 章讲路由的部分（§ 5.2）：路由器各自独立决定"下一跳交给谁"，判据是各自的路由表——而路由表是每台设备根据实时状况（哪条线堵了、哪条线便宜了）独立计算的。没有哪条规定说"你怎么去的就得怎么回"。就像上班你走二环因为快，下班走三环因为二环晚高峰堵死——两张地图，两个决策者。网络上这叫非对称路由（asymmetric routing），而且是常态而非例外。

这带来一个实用推论：你 ping 测出的 RTT，是"去路+回路"两段的总和；traceroute 某一跳的时间，是"到你家去的那条回程路"的时间——等等，有点绕，重新说：traceroute 第 N 跳显示的 10ms，是你家到第 N 跳路由器、再从第 N 跳回到你家的合计。如果去程走 A 路、回程走 B 路，这 10ms 就混了两条路的时间。这解释了为什么偶尔会看到"第 5 跳 10ms、第 6 跳 8ms"这种时间不增反降的怪象——不是包会时光倒流，而是第 6 跳的回程恰好走了条更快的路。看到延迟下降不用惊讶，那是非对称路由的日常表演。

再打个比方：你约朋友吃饭，你从家打车去餐厅 20 分钟，朋友从公司打车回你家取落下的东西只要 15 分钟——你们"同一段路"的耗时根本不可比，因为起点、终点、路线全都不同。traceroute 每一跳都是一次"独立的往返打车"，谁也不比谁慢是应当的，谁比谁快也不稀奇。

中间慢不等于真的慢：ICMP 的"二等舱"待遇

第二个反直觉真相：你常会看到某中间跳延迟突然飙到 200ms，而最后一跳只有 30ms——按理说越走越远应该越来越慢，中间怎么会反而更慢？

答案在于路由器的"人格分裂"。一台路由器身上有两套工作：转发（主业：把别人的包快速送走）和响应（副业：处理发给自己本人的包，比如回复你的 traceroute 探测）。副业走的通道优先级低——好比银行行长，给你办业务（转发）秒速，但你要找他本人签字（回复探测）得排队等他有空。你测到的是行长签字的速度，不是银行办业务的速度。

所以读中间跳延迟的正确姿势是：只看趋势，不看单点；中间的尖刺一律存疑，最终的延迟以终点为准。真正值得警惕的中间信号只有一种：从某一跳开始所有后续跳（包括终点）的延迟都系统性抬高——那说明瓶颈在这条链路的上游某处，这一跳才是"嫌疑最大的第一现场"。判断口径：延迟翻倍以上且延续到终点，才立案；孤立的尖刺，释放。

实战方法论：两跳之间夹出病灶

把前面的规则合成一套可操作的排错流程。场景：你访问某网站很慢，ping 也确认了延迟高。现在要回答"慢在哪一段"：

• 第一步：traceroute 目标域名，拿到完整路径；
• 第二步：先看最后一跳的时间——这是全程延迟的总成绩，确认问题量级；
• 第三步：找"分水岭"——从上往下找第一次延迟明显跳涨的相邻两跳（比如第 4 跳 10ms、第 5 跳 180ms，后面全在 180ms 以上）；
• 第四步：病灶锁定在"第 4 跳路由器 → 第 5 跳路由器"之间那一段链路上；
• 第五步：查这两跳的归属（IP 归属地/主机名）——如果分水岭前后分属两家运营商，多半是"网间互联瓶颈"；如果都在你家运营商网内，报障时就报这两跳的 IP。

这套"夹逼法"的价值在于：它把一句模糊的"网好卡"翻译成了"某某运营商某某段链路拥塞"——报障时客服没法用"重启试试"打发你，因为你手里有逐跳的证据链。这就好比去医院不说"我不舒服"，而是直接说"左膝弯曲时疼、X 光片在此"——诊断效率天差地别。

读 IP 的门道：从轨迹里认出城市与角色

traceroute 输出的每一跳 IP 都是一枚线索，会读的人能从一串数字里认出一幅地图。三个技巧：

技巧一：认内网段。192.168.x.x、10.x.x.x、100.64.x.x 开头的，都是"内网地址"（第 3 章讲过的私有地址，详见 § 3.5）——第一跳的 192.168.1.1 是你家路由器；第二跳若是 100.64 开头，那是运营商给你的"大内网"接入层。前几跳在内网，后面进入公网，这个分界本身就是信息。

技巧二：认骨干网代码。国内运营商的骨干路由器主机名里藏着城市和角色缩写，比如 219.158 开头常见于联通 169 骨干，主机名里常带 bj（北京）、sh（上海）、gz（广州）等城市码。看到 ...bj... → ...sh... 的轨迹，你就知道流量从北京骨干出口直奔上海。国际访问更明显：中间突然冒出一串海外城市的跳（losangeles、sanjose 之类），说明流量走的太平洋海缆。

技巧三：认 CDN 截胡。traceroute 一个大网站，路径往往十几跳就停在某个很近的城市——第 7 章讲过的 CDN 在起作用（详见 § 7.1）：你根本没到它的源站，半路就被最近的边缘节点"截和"了。路径特别短、延迟特别低，本身就是"命中 CDN"的证据。反过来，如果某天路径突然变长、绕道别的城市、延迟翻几倍——大概率是 CDN 调度把你派去了一个更远的节点，或者本地节点故障把你甩去了异地容灾。

看不见的跳：MPLS 隧道与路径盲区

讲一个进阶盲区，解释一种"路径短得可疑"的现象。你 traceroute 一个省外的目标，明明物理上隔着七八台骨干路由器，输出却只有 4 跳——中间那几跳凭空消失了？

罪魁叫 MPLS 隧道（多协议标签交换），骨干网的标配技术。通俗地说：运营商在骨干入口给包贴上一张"隧道标签"，包进入隧道后，中间所有路由器只看标签转发、不再检查也不递减 IP 包头上的 TTL——直到隧道出口才"撕标签"恢复普通转发。TTL 没减，traceroute 的钓竿就钓不到中间任何一台：整条隧道在输出里被压缩成了"一跳"。这就像你坐高铁从北京到上海，中间经过几十个县市，但你的车票上只写着"北京→上海"——中间站全部隐形，因为你全程没下车、没人查你的票。

对诊断的影响：MPLS 让路径"看起来"比实际短，好在延迟数字依然是真实累计的（时间不会因为隧道而消失），所以判断延迟和分水岭的方法不变；受影响的只是"跳数"和"中间是谁"这两项信息。看到一跳跨省的怪物行，别怀疑物理定律，先想到隧道。本质上就是：traceroute 能看见"IP 层的站牌"，看不见"隧道里的穿行"——地图有疆界，工具有盲区，知己知彼才能用好。

两个实战案例：绕路与网间瓶颈

案例一：绕路的留学生。小刘在英国留学，访问国内某视频站，画面转圈。traceroute 一看：从伦敦出发，第 5 跳到了美国纽约，第 8 跳到美国西岸洛杉矶，第 11 跳横跨太平洋到了日本东京，第 14 跳才落地上海。也就是说，一趟"英国→中国"的访问，先向西横穿大西洋，再横穿北美大陆，再横跨太平洋——绕了地球小半圈。这不是故障，是国际互联的商业现实：欧洲到中国的直连容量小、价格高，很多流量被调度到"欧洲—美国—亚洲"这条传统大动脉上。解法也诚实：要么选有直连线路的服务（有些云厂商有中欧直连），要么接受物理现实。traceroute 在这里的价值是把"为什么这么慢"从玄学变成了地图。

案例二：网间瓶颈的游戏玩家。老周玩某游戏延迟常年 120ms，同小区用另一家运营商的朋友只有 20ms。traceroute 对比两人路径：老周的流量前 6 跳一切正常，第 7 跳进入某互联点后延迟从 15ms 跳到 110ms 且延续到终点——分水岭的两跳，前一台属于老周的运营商，后一台属于游戏服务器所在的运营商。病灶是两家运营商之间的互联带宽不足（晚高峰尤其明显）。这种问题用户侧无解，但诊断价值巨大：换一家"和游戏服务器同网"的运营商，延迟立刻 110ms→20ms。traceroute 不但告诉他"病在哪"，还直接指出了"药在哪"。

绕路检测：为什么延迟有时高得离谱

有了逐跳地图，"绕路"就无所遁形。判断标准很直白：看地理逻辑。你在北京，访问一个北京公司的服务器，正常轨迹应该短促干净；如果轨迹里出现"广州→上海→北京"这种大三角，你的流量绕了半个中国——延迟当然低不了。

绕路的常见成因有三种。一是路由策略：运营商之间按商业协议走流量，"价格最优"和"路径最短"未必一致——好比航班中转，有时直飞贵、绕飞便宜，物流公司就选绕飞。二是互联点稀疏：两家运营商之间可能只有少数几个互联出口（比如都在广州"握手"），于是东北的流量也得先南下广州过马路再折返东北——这不是谁笨，是"马路"就修在那。三是故障绕行：某段骨干光缆断了（渔船抛锚挖断海缆是经典事故），路由协议自动重新计算，全体流量改道——延迟普遍上涨，就是大范围绕行的信号。

国际访问的绕路尤其值得一看。你 traceroute 一个海外网站，看到轨迹先到美国西岸再折回亚洲的目标地——恭喜，你目睹了国际互联的"洛杉矶情结"：大量亚太流量都在美国西岸的互联点中转。看懂轨迹里的城市名，你比 99% 的用户都清楚自己的数据正在地球上画什么线。

工具箱扩展：traceroute 的亲戚们

标准 traceroute 默认发 UDP 包（Unix 传统）或 ICMP 包（Windows 的 tracert），某些防火墙专门拦 UDP 高端口导致路径中段假性星号——所以实战中有个技巧：换协议再测一次。Linux 上 traceroute -I 强制用 ICMP，traceroute -T 用 TCP 80 端口（伪装成正常网页流量，最容易穿过防火墙）。三种协议各测一遍互相印证，星号是"真沉默"还是"被过滤"就清楚了。

另外两个值得认识的亲戚：mtr（my traceroute）是 traceroute 和 ping 的合体——它持续不断地对每一跳同时测延迟和丢包，输出一张动态更新的表格，观察几分钟，哪一跳丢包、哪一跳抖动一目了然，是工程师长时观测的首选；可视化工具则把每跳 IP 在世界地图上打点亮线（比如各种在线 traceroute 站点），轨迹变成一幅"数据环球旅行图"——直观震撼，适合建立体感，但严谨诊断还是看原始数字。

Windows 用户还有个隐藏福利：pathping，系统自带，干的就是 mtr 的活——先跑一遍 traceroute，然后对每一跳连续探测 25 秒，最后输出每跳的丢包率和延迟统计。相当于 tracert 的"加长版体检"，不用装任何东西。它的输出分上下两张表：上面是路径，下面是统计——看下面那张，丢包率列里有数字的行，就是你该盯住的嫌疑犯。简单说，日常快速看路用 tracert，要证据链用 pathping，这俩组合基本够用；macOS/Linux 用户装个 mtr 等价替代。

顺带一提在线 traceroute 服务：国内外都有网站提供"从它们那里发探测"的服务——你可以指定"从上海、从法兰克福、从洛杉矶分别 traceroute 同一个目标"，对比三条轨迹。这等于借了几双不同位置的眼睛同时看一条路——判断"到底是我家到目标慢，还是目标本身慢"时特别好用：如果全球各地测它都慢，是目标的问题；只有你这条线慢，是你路径的问题。

安全视角：地图也是情报

最后补一个安全视角——呼应第 8 章的世界观：traceroute 的地图对主人是诊断书，对攻击者就是侦察图。逐跳探测能摸清目标网络的拓扑结构：有几层、用什么设备、入口在哪、哪段是薄弱的互联点。因此不少企业网络会限制 ICMP 出站——不让内部员工随意向外探测（防信息泄露），也配置边界设备不回应外部探测（防侦察）。云服务商的默认安全组（§ 7.2）不开 ICMP，也是同理。

于是出现一个有点黑色幽默的循环：防御者为了不被侦察而沉默，诊断者为了排错而探测，双方用的都是同一种包。作为普通读者你只需要记住：在自家网络里用 traceroute 是完全正当的日常诊断；对别人的网络做大规模逐跳扫描，则既不礼貌也不合规——工具无罪，用法分善恶，这也是第 8 章讲过的老结论。

动手清单：一次规范的路径诊断

• tracert 目标域名（Windows）/ traceroute 目标域名（macOS/Linux），拿到完整路径；
• 先看最后一跳：时间正常 → 中间波动无视，问题多半不在网络层；
• 时间异常 → 从上往下找"分水岭"：第一次延迟跳涨的相邻两跳；
• 记下分水岭两跳的 IP 和主机名——这就是病灶区间；
• 看到星号先数连续性：孤星无视，连星才断路；
• Linux 用户可换协议复测（-I / -T）排除防火墙过滤假象；
• 想长时观测用 mtr，想看全球视角用在线 traceroute 站点对照。

常见误区

• 误区一："有星号就是断网"孤立的星号只代表那台路由器没回复探测，流量多半正常穿行。只有从某跳起连续星号到结尾，才是路径中断的证据。
• 误区二："第 8 跳 300ms，这跳有问题"中间跳的延迟是路由器"回复你"的副业速度，不代表它转发主业慢。判断看终点和延续性：尖刺孤立则忽略，抬升延续到终点才立案。
• 误区三："延迟应该逐跳递增，怎么还降了"非对称路由是常态：每跳测的是"去+回"混合时间，回程换路就会让数字上下跳动。下降不奇怪，上升不延续也不奇怪。
• 误区四："traceroute 的路径就是这个网站的固定路径"路由是动态计算的，两次跑结果都可能不同（还受 CDN 调度影响）。它是"这一刻的快照"，不是永久地图。
• 误区五："跳数越多越慢"跳数和延迟没有必然关系：同城绕 15 跳骨干可能只要 8ms，跨洋直连 5 跳也要 150ms。决定延迟的是距离和拥塞，不是站数。