看懂 traceroute 和 MTR 的輸出：不只是「封包走哪裡」

traceroute 是每個系統管理員和開發者都跑過的指令，但真正看懂輸出的人遠比跑過它的人少。「封包走 15 個 hop、延遲 30ms」——然後呢？哪個延遲是正常的？星號代表什麼？非對稱路由是問題還是正常現象？

這篇文章的目的是讓你在下次需要診斷網路問題時，不只是把輸出截圖丟給 ISP 說「我不知道這是什麼意思」。

TTL 是如何讓 traceroute 運作的

理解 traceroute 輸出的基礎是搞懂 TTL（Time to Live）。

每個 IP 封包在標頭裡帶著一個 TTL 值，路徑上每個路由器轉發封包時，會把 TTL 減 1。當 TTL 歸零，路由器丟棄這個封包，並向來源 IP 回一個 ICMP Time Exceeded 訊息，告訴它「你的封包在我這裡被丟了」。

traceroute 利用這個機制：

1. 送出 TTL=1 的封包 → 第一個路由器歸零、丟棄、回傳 ICMP → 得到第一跳的 IP 和延遲
2. 送出 TTL=2 的封包 → 第一個路由器把 TTL 減到 1、轉發；第二個路由器歸零、回傳 → 得到第二跳
3. 依此類推，直到封包抵達目的地

Linux 的 traceroute 預設用 UDP，macOS 和 Windows（tracert）用 ICMP echo request，效果相同，但穿透某些防火牆的能力稍有不同。

看懂一份真實的 traceroute 輸出

1
2
3
4
5
6
7
8
9

$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)        0.812 ms   0.654 ms   0.723 ms
 2  10.0.0.1 (10.0.0.1)              5.234 ms   5.189 ms   5.421 ms
 3  220.128.xx.xx                   10.842 ms  11.023 ms  10.754 ms
 4  * * *
 5  72.14.215.165                   22.134 ms  22.089 ms  22.312 ms
 6  108.170.247.97                  23.451 ms  23.398 ms  23.512 ms
 7  8.8.8.8                         24.123 ms  24.089 ms  24.234 ms

每一行代表一個「hop」——路徑上的一個路由器。三個時間值是同一個 hop 被測三次的延遲。

hop 1：你的本地閘道（家用路由器），延遲 < 1ms 是正常的。

hop 2：ISP 的接入層設備，幾毫秒。

hop 3：ISP 骨幹，延遲跳到 10ms，這個增量（約 5ms）是從你到 ISP 骨幹的實際傳輸時間。

hop 4：三個星號——不代表這個 hop 有問題，下面詳細說明。

hop 5 之後：延遲從 10ms 跳到 22ms，增量約 12ms，這段可能是跨海纜或長距離路由。

星號（* * *）的真正意義

這是最常被誤解的部分。* * * 不代表封包在那裡「卡住」或「丟失」——它代表那個 hop 的路由器沒有回覆 ICMP Time Exceeded 訊息。

有幾個可能的原因：

路由器刻意不回 ICMP：許多路由器（尤其是骨幹網的路由器）為了安全或減少 CPU 負擔，設定成不產生 ICMP 回應。這非常常見，尤其在中間幾跳。看到 * * * 但後面的 hop 有正常延遲，代表路徑是通的，只是中間那台路由器靜音而已。

ICMP 被防火牆攔截：路由器自己有回應，但路徑上的防火牆把 ICMP Time Exceeded 擋掉了。

Rate limiting：某些路由器對 ICMP 有速率限制，偶爾的 * 可能只是那次請求碰到限制。

判斷準則：如果 * * * 後面的 hop 有正常回應，那個 * * * 就不是問題。 問題是 * * * 一直持續到最後而且目的地無法連線，那才需要深入診斷。

延遲分析：增量才是關鍵

大多數人看 traceroute 只看每跳的絕對延遲，但更重要的是相鄰兩跳之間的延遲增量。

1
2
3

3  220.128.xx.xx   10ms
4  * * *
5  72.14.215.165   22ms

hop 5 的延遲比 hop 3 多了約 12ms。這 12ms 就是 hop 3 到 hop 5 這段路徑的實際傳輸時間（hop 4 沒有回應，但封包確實通過了）。

正常的延遲增量：

• 同城市節點之間：< 5ms
• 跨城市（例如臺北到香港）：15-40ms
• 跨太平洋（臺灣到美西）：80-120ms
• 臺灣到歐洲：180-250ms

如果某跳的增量突然暴增（例如平均 5ms 一跳，突然某跳增加了 80ms），那裡可能有壅塞、設備問題或異常路由。

反常現象：有時候某一跳的延遲比後一跳還高。這通常是路由器給 ICMP 回應的優先級低（正在忙著轉發流量，偶爾才處理 ICMP），不代表實際的傳輸路徑有問題。

MTR：比 traceroute 更有用的工具

traceroute 是一次性的快照，mtr（My Traceroute）是持續追蹤，會一直送封包並統計每個 hop 的狀況：

1

sudo mtr -n --report-wide 8.8.8.8

1
2
3
4
5
6
7

HOST: myserver              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1          0.0%    10    0.8   0.9   0.7   1.1   0.1
  2.|-- 10.0.0.1             0.0%    10    5.2   5.3   5.1   5.8   0.2
  3.|-- 220.128.xx.xx        0.0%    10   10.8  10.9  10.5  11.4   0.3
  4.|-- ???                100.0%    10    0.0   0.0   0.0   0.0   0.0
  5.|-- 72.14.215.165        0.0%    10   22.1  22.3  21.9  23.1   0.4
  6.|-- 8.8.8.8              0.0%    10   24.1  24.2  23.9  24.8   0.3

各欄位的意義：

• Loss%：封包遺失率。中間節點的 100% 通常是「不回 ICMP」，不是真正的丟包。只有最後一跳（目的地）的 Loss% 才代表真正的連線問題。
• Snt：送出的封包數
• Last / Avg / Best / Wrst：最後一次 / 平均 / 最低 / 最高延遲（ms）
• StDev：延遲的標準差——這個數字高，代表延遲不穩定（抖動大），對即時應用（視訊通話、遊戲）影響大

跑 MTR 至少要讓它送 100 個封包（加 -c 100），短時間的樣本不夠準確：

1

sudo mtr -n -c 100 --report 8.8.8.8

非對稱路由：去程和回程走不同路

traceroute 只顯示去程的路徑，但延遲包含了去程和回程兩段。

臺灣到某臺美國伺服器，去程可能走中華電信的海纜，回程可能走另一家 ISP 的路由——這叫非對稱路由，完全正常。但它會造成一個診斷困境：traceroute 顯示去程路徑正常，但延遲看起來高，因為回程走了更長的路。

要診斷非對稱路由，需要從目的地方向也跑一次 traceroute，或用 paris-traceroute（避免 ECMP 多路徑對測量的干擾）：

1
2
3
4
5

# 安裝 paris-traceroute
sudo apt install paris-traceroute

# 測試（用 TCP 比 ICMP 更能穿透防火牆）
sudo paris-traceroute -p tcp 8.8.8.8

常見問題模式

問題一：某跳之後延遲突然暴增但不恢復

1
2
3

6  transit-router-a   25ms
7  transit-router-b   180ms
8  destination        185ms

hop 6 到 7 增加了 155ms——幾乎可以確定 hop 7 在另一個大洲，封包在這裡跨海了。如果這條路由不合理（例如明明是臺灣到香港卻繞去美國），代表路由設定有問題或 BGP 選路異常。

問題二：最後幾跳 100% loss

1
2
3

 8  203.0.113.1     0.0%
 9  ???            100.0%
10  ???            100.0%

目標伺服器完全不回應。可能是：伺服器掛了、防火牆封掉了 traceroute 的探測協定（換用 TCP traceroute 試試）、或該網段封鎖了所有 ICMP。

問題三：間歇性 loss 在中間節點

1
2

5  72.14.x.x    15.0%   22ms
6  8.8.8.8       0.0%   24ms

hop 5 有 15% loss 但 hop 6（目的地）完全沒有 loss——這代表 hop 5 的路由器對 ICMP 有速率限制，實際流量沒有受影響。

遇到問題時的標準診斷流程

1. ping 目的地 — 確認基本連通性和延遲
2. mtr -n -c 50 目的地 — 看完整路徑和 loss 統計
3. 注意最後一跳的 Loss%，不是中間跳的
4. 計算相鄰跳之間的延遲增量，找出異常點
5. 如果懷疑是路由問題，也從目的地方向做一次 traceroute（或要求對方做）
6. 換用 TCP traceroute（traceroute -T -p 80 目的地）確認不是 ICMP 被過濾的假象

NCSE Network 的 IP Transit 服務直連是方電訊機房，提供 10M 到 100G 的頻寬選擇，BGP 路由設定可依需求調整。如果你在排查路由問題或評估網路基礎設施，歡迎到 ncse.tw 了解更多。