路由追踪是什么？Traceroute工作原理与使用方法详解

本文详解路由追踪（Traceroute/tracert）的工作原理与排障方法。针对网站访问慢、跨运营商延迟高或跨境绕路等问题，通过 TTL 机制逐跳解析数据传输路径，精准定位网络瓶颈，并提供针对单跳超时与异常延迟的正确分析思路。

Chahu 团队2026-08-255 分钟阅读

网站明明可以正常打开，但某些地区访问特别慢；同一个服务器，电信用户延迟只有几十毫秒，移动用户却突然升到一两百毫秒；服务器部署在新加坡，实际访问路径却绕到了日本甚至美国。遇到这类问题时，只看 Ping 往往很难判断原因。这时候就需要用到路由追踪（Traceroute）。

Traceroute 是网络排障中非常常见的一种工具，它能够把本地设备到目标服务器之间经过的网络路径一跳一跳显示出来。对于网站运维、服务器管理、CDN 调度、跨境网络优化来说，掌握路由追踪的基本使用方法，往往比单纯看一个 Ping 延迟更有价值。

本文就从 Traceroute 的工作原理开始，讲清楚路由追踪怎么看、不同系统怎么使用，以及遇到超时、绕路、高延迟时应该如何判断。

一、路由追踪是什么？

我们在浏览器输入www.example.com，表面上看是电脑和服务器“点对点”连接，但实际上，数据包在互联网里需要经过层层转发：

你的电脑 ➔ 家庭路由器 ➔ 运营商接入网 ➔ 省级骨干网 ➔ 运营商互联节点/国际出口 ➔ 目标数据中心 ➔ 网站服务器

数据包中途经过的每一台路由器，都算作一个“跳数”（Hop）。路由追踪的作用，就是把这一路上经过的中间节点尽可能地找出来。

通过一次 Traceroute 测试，你可以清晰地看到：

  • 数据到达目标一共经过了多少跳；

  • 每一跳对应的 IP 地址；

  • 每一个节点的往返响应时间（RTT）；

  • 延迟是从哪一个节点开始突然暴涨的；

  • 线路有没有跨省、跨运营商或者跨国绕路；

  • CDN 是否把你调度到了奇怪的节点。

简而言之，Ping 解决的是“通不通、快不快”的问题，而 Traceroute 解决的是“数据到底是怎么走的、哪里在堵车”的问题。

需要在不同操作系统中使用时，命令名称略有区别：

  • Windows 系统命令为：tracert

  • Linux / macOS 系统命令为：traceroute

ScreenShot_2026-08-25_110659_684.png

二、Traceroute 是怎么工作的？

Traceroute 看起来像是有一张地图能直接查到全网路径，但它的实现原理非常巧妙，利用的是 IP 数据包里的一个基础字段——TTL（Time To Live，生存时间）。

为了防止数据包因为路由环路在网络里无限循环，每一个数据包被发出来时都有一个 TTL 值（比如 64）。数据包每经过一台路由器，TTL 就会被自动减 1。一旦 TTL 减到 0，路由器就会直接丢弃这个包，并向源头发送一个 ICMP 超时通知（Time Exceeded）。

Traceroute 就是利用了“TTL 到 0 就会触发报警”的机制，搞了一套“投石问路”的操作：

  1. 探测第一跳： 发送一个 TTL = 1 的数据包。数据包到达第一台路由器，TTL 减为 0，这台路由器只能无奈返回一个 ICMP 超时消息。电脑收到后，记录下第一台路由器的 IP 和耗时。

  2. 探测第二跳： 发送一个 TTL = 2 的数据包。顺利穿过第一台路由器（TTL 变成 1），到达第二台路由器时 TTL 归零，第二台路由器返回超时消息。第二跳 IP 和耗时顺利拿到。

  3. 依次类推： 接下来发送 TTL = 3、4、5……直到数据包真正到达目标服务器。

这就是 Traceroute 的本质：它并不是一下子拿到了完整路径，而是一次次故意让数据包“超时”，一步步把沿途的节点逼出来的。

三、为什么每一跳通常会显示三个延迟？

实际运行 Traceroute 时，经常会看到类似结果：

5    18 ms    20 ms    19 ms    202.97.xx.xx

很多刚接触路由追踪的人会以为：“这里是不是有三个不同的节点？”其实不是。这三个时间通常是对同一跳进行多次探测得到的 RTT，也就是往返延迟。

例如：

18 ms
20 ms
19 ms

说明三次探测结果比较接近，这一跳整体比较稳定。如果结果变成：

20 ms
86 ms
21 ms

则说明至少其中一次探测出现了较大波动。

不过需要注意，单独一次 RTT 突然升高，并不能直接证明该路由节点存在故障。后面还要结合整条路径一起判断。

四、不同操作系统怎么使用 tracert？

1. Windows 系统

按下Win + R输入cmd打开命令行，直接输入：tracert  www.example.com 或者测试指定 IP：tracert 8.8.8.8

在排障时，强烈建议加上-d参数：tracert -d www.example.com -d表示禁用 IP 到主机名的反向域名解析。不解析主机名能大幅缩短测试时间，终端输出会丝滑很多。

2. macOS 与 Linux 系统

macOS 终端直接输入：traceroute www.example.com

Linux 也是同样的命令。如果提示找不到命令，可以通过包管理器安装：

  • Ubuntu/Debian：sudo apt install traceroute

  • CentOS/RHEL：sudo yum install traceroute

五、Traceroute 结果应该怎么看？

真正使用路由追踪时，最重要的并不是“会不会执行命令”，而是能不能看懂结果。假设得到下面这一组数据：

1    <1 ms    <1 ms    <1 ms    192.168.1.1
2     5 ms     4 ms     5 ms    100.64.0.1
3     8 ms     9 ms     8 ms    202.96.xx.xx
4    15 ms    14 ms    16 ms    202.97.xx.xx
5    38 ms    41 ms    39 ms    203.xx.xx.xx
6    42 ms    43 ms    41 ms    103.xx.xx.xx
7    44 ms    45 ms    44 ms    8.8.8.8

主要看以下几个地方。

1. Hop 是什么意思？

前面的：1、2、3、4、5代表 Hop，也就是“跳数”。可以粗略理解为：数据经过的第几个三层网络节点。

例如：

1    192.168.1.1

通常可能是本地路由器。后面的节点则可能逐渐进入：

  • 运营商接入网络；

  • 城域网；

  • 骨干网；

  • 跨运营商互联；

  • 国际线路；

  • 目标数据中心。

不过需要注意：跳数多，不等于线路一定差。一条稳定的 15 跳线路，完全可能比一条只有 8 跳但中间严重拥堵的线路更快。所以不要看到：20 hops就直接判断线路质量不好。

2. RTT 应该怎么看？

例如：

18 ms
40 ms
120 ms

这里显示的是探测包到达该节点并返回的大致往返时间。

真正应该重点观察的，是：

延迟从哪一跳开始持续明显升高。

例如：

4     16 ms
5     18 ms
6     20 ms
7    185 ms
8    188 ms
9    191 ms

从第 7 跳开始，后续延迟都维持在 180 ms 以上。

这种情况通常说明：

第 6 跳到第 7 跳之间发生了明显的网络变化。

可能包括：

  • 进入跨境线路；

  • 进入长距离骨干链路；

  • 出现跨运营商互联；

  • 国际出口发生拥堵；

  • BGP 路由出现绕路。

这比单纯看到：

Ping = 190 ms

有价值多了。

因为 Ping 只能告诉你“结果很慢”，Traceroute 则开始告诉你“慢可能发生在哪里”。

六、 常见误区与异常排查

在看路由追踪结果时，新手极其容易陷入几个误区，导致误判问题。

误区 1：看到* * *就以为网络断了 

有时候会看到中间某一跳全是星号：7 30 ms 29 ms 31 ms 202.xx.xx.xx8 * * *9 35 ms 36 ms 34 ms 203.xx.xx.xx很多人第一反应是“第 8 跳路由器挂了”。其实完全不是。只要第 9 跳、第 10 跳还能正常拿到回应，就说明数据包早就顺畅地穿过了第 8 跳。第 8 跳显示星号，只是因为那台路由器设置了防火墙策略，拒绝回应 ICMP 超时包，或者对这类诊断包做了限速处理而已。

误区 2：中间某一跳延迟特别高，但后面又恢复了 

比如：4 18 ms 17 ms 19 ms 202.97.xx.xx5 210 ms 190 ms 205 ms 202.97.xx.xx6 22 ms 21 ms 23 ms 202.97.xx.xx第 5 跳飙到 200ms 以上，但第 6 跳又回到了 20ms。这同样不是网络故障。路由器的核心职责是“转发数据”，它的 CPU 在繁忙时会优先保证用户业务数据的通行，而把回复 Traceroute 这类诊断包的优先级拉到最低。这只是路由器处理 ICMP 响应变慢了，真实的业务流量过这台路由器时根本不慢。

七、 为什么光在本地测是不够的？

从你自己电脑上运行tracert，只能代表“你家宽带 ➔ 目标服务器”这一条路径。

如果你是在做网站运维或网络排障，这远远不够。因为：

  • 广州电信用户走的是广州出口；

  • 北京联通用户可能走的是北京出口；

  • 移动用户可能在跨运营商互联节点卡住了。

如果你遇到了“部分地区访问慢”或者“特定运营商卡顿”的问题，可以通过Chahu 这种能同时从全国甚至全球几十个测试点发包，将不同地区、不同运营商到你服务器的路径横向对比。

很多时候一对比就会真相大白：上海电信走的是直连，30ms 到达；北京联通却不知道为什么绕了一圈日本，延迟直接到了 150ms。找到了绕路的节点，才能针对性地去找运营商调路由，或者更换节点配置。

八、 排查网络问题的正确顺序

当网站或服务出现访问变慢的问题时，单靠某一个工具都是片面的，最科学的方式是在chahu按顺序使用这四步：

  1. DNS 查询： 先确认域名解析出来的 IP 对不对，有没有被错调度到远方的 CDN 节点。

  2. Ping 测试： 看看基础连通性，丢包率高不高，整体延迟大概在什么范围。

  3. Traceroute（路由追踪）： 如果延迟高或丢包，用它定位数据到底是在哪一段链路（本地网、运营商骨干网、国际出口）开始出问题的，有没有发生奇葩的绕路。

  4. HTTP 测速 / 接口分析： 如果网络路径和延迟完全正常，网站依然打不开，那问题根本不在网络上，赶紧去查服务器 CPU、数据库查询、TLS 握手或者代码性能（TTFB）。

​

ScreenShot_2026-08-25_110644_517.png

路由追踪真正有价值的地方，并不是把一串 IP 地址显示出来，而是让原本看不见的网络访问路径变得可观察。当网站出现跨地区延迟、某个运营商访问异常、海外线路绕路或者 CDN 节点调度不合理时，Ping 往往只能告诉你“慢了”，而 Traceroute 则能够继续向下追查：到底经过了哪里，又是从哪里开始变慢的。

不过 Traceroute 也不是网络故障判断的唯一依据。中间节点不响应、单跳延迟升高、路径变化，都不一定意味着真实业务流量存在故障。在实际网站排障中，更可靠的方法仍然是把 DNS 查询、Ping、Traceroute 和 HTTP 测速 结合起来。

DNS 用来确认解析和节点调度，Ping 判断基础网络质量，Traceroute 查看完整访问路径，HTTP 测速再进一步定位 TCP、TLS、TTFB 和页面加载阶段的问题。这样从“域名解析”一路查到“网络路径”和“网站响应”，通常才能真正找到网站访问慢的原因，而不是只停留在一个看起来异常的毫秒数字上。

常见问题

Q1：为什么用 Ping 能 Ping 通，但网站在浏览器里就是打不开？ 

A： Ping 使用的是 ICMP 协议，仅代表网络传输层是通畅的；而浏览器访问网站走的是 HTTP/HTTPS 协议，涉及应用层和具体的服务器业务逻辑。如果服务器的 80/443 端口被防火墙拦截、Nginx/Apache 服务宕机、SSL 证书配置错误，或者数据库超时，就会出现“Ping 得通，但网页打不开”的现象。

Q2：路由追踪里的 MTR 和 Traceroute 有什么区别？ 

A： Traceroute 只是在特定时间点对路径进行一次性的静态“扫描”；而 MTR（My Traceroute）可以看作是 Ping 和 Traceroute 的结合体。MTR 会对整条路径上的每一个节点发起持续性的发包测试，从而动态、实时地统计每一个节点的丢包率和延迟抖动。在排查偶发性卡顿或持续丢包时，MTR 的参考价值比 Traceroute 更高。

Q3：遇到 BGP 路由绕路或者跨境延迟暴涨，作为网站管理员该怎么解决？ 

A： 普通用户或单台服务器很难直接干预运营商的骨干网 BGP 路由策略。如果发生路由绕路，最有效的解决手段包括：启用包含全球优质节点（如 CN2 GIA、9929、CMIN2 等优化线路）的 CDN 服务；或者通过 SD-WAN、异地转发节点进行流量接入；也可尝试向数据中心运营商提交工单，申请协助优化上游 BGP 路由广播。

Q4：执行 Traceroute 时，UDP、TCP 和 ICMP 模式有什么不同？ 

A： 不同操作系统默认使用的协议不同（例如 Windows tracert 默认用 ICMP，而 Linux/macOS traceroute 默认用 UDP）。由于现在很多网络设备和防火墙会直接屏蔽 UDP 流量或丢弃 ICMP 超时包，导致测试出现大量星号。如果默认探测不出来，可以在 Linux 下使用traceroute -T或tcptraceroute强制改用 TCP（如 80/443 端口）进行探测，这样穿透防火墙成功率最高。