路由追蹤是什麼？Traceroute 工作原理與使用方法詳解

網站明明可以正常開啟，但某些地區訪問特別慢；同一個伺服器，電信用戶延遲只有幾十毫秒，行動用戶卻突然升到一兩百毫秒；伺服器部署在新加坡，實際訪問路徑卻繞到了日本甚至美國。遇到這類問題時，只看 Ping 往往很難判斷原因。這時候就需要用到路由追蹤（Traceroute）。

Traceroute 是網路排障中非常常見的一種工具，它能夠把本地設備到目標伺服器之間經過的網路路徑一跳一跳顯示出來。對於網站維運、伺服器管理、CDN 調度、跨境網路優化來說，掌握路由追蹤的基本使用方法，往往比單純看一個 Ping 延遲更有價值。

本文就從 Traceroute 的工作原理開始，講清楚路由追蹤怎麼看、不同系統怎麼使用，以及遇到逾時、繞路、高延遲時應該如何判斷。

一、路由追蹤是什麼？

我們在瀏覽器輸入www.example.com，表面上看是電腦和伺服器「點對點」連線，但實際上，資料封包在網際網路裡需要經過層層轉發：

你的電腦 ➔ 家庭路由器 ➔ 電信商接入網 ➔ 省級骨幹網 ➔ 電信商互聯節點/國際出口 ➔ 目標資料中心 ➔ 網站伺服器

資料封包中途經過的每一台路由器，都算作一個「跳數」（Hop）。路由追蹤的作用，就是把這一路途經的中間節點盡可能地找出來。

透過一次 Traceroute 測試，你可以清晰地看到：

• 資料到達目標一共經過了多少跳；

• 每一跳對應的 IP 位址；

• 每一個節點的往返回應時間（RTT）；

• 延遲是從哪一個節點開始突然暴漲的；

• 線路有沒有跨省、跨電信商或者跨國繞路；

• CDN 是否把你調度到了奇怪的節點。

簡而言之，Ping 解決的是「通不通、快不快」的問題，而 Traceroute 解決的是「資料到底怎麼走的、哪裡在塞車」的問題。

需要在不同作業系統中使用時，命令名稱略有區別：

• Windows 系統命令為：tracert

• Linux / macOS 系統命令為：traceroute

二、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 到主機名稱的反向 DNS 解析。不解析主機名稱能大幅縮短測試時間，終端機輸出會順暢很多。

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）。

​

路由追蹤真正有價值的地方，並不是把一串 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 連接埠）進行探測，這樣穿透防火牆成功率最高。