什麼是 Traceroute 與 MTR？

Traceroute 與 MTR 是用來追蹤網路封包路徑的診斷工具。它們會顯示從你的裝置到目標主機之間經過的每一台路由器，並測量每一跳的延遲時間。對於需要排查連線變慢、封包遺失或路由異常的網管人員與開發者來說，這兩項工具是不可或缺的基礎。在台灣，無論是連線本地機房還是海外伺服器，理解封包實際走的路徑，都是縮短故障排除時間的第一步。

Traceroute 幾乎內建於所有作業系統中，在 Windows 上稱為 tracert。它發送測試封包到目的地，記錄途中每個中繼節點的 IP 位址或網域名稱，以及來回時間。最終產出的是一份靜態的路由快照，讓你看到封包實際走了哪條路。

MTR（My Traceroute）則結合了 traceroute 的路徑探索能力與類似 ping 的持續監控功能。根據 Cloudflare 的說明，MTR 先找出完整路徑，然後不斷對每一跳發送探測封包，即時更新延遲、丟包率與抖動數據。你可以把它視為一份持續刷新的路由儀表板，而不是單一畫面。

兩者的核心概念相同。Hop 是指任何轉發流量的路由器或網路節點。探測封包則是用來測試的封包。TTL（Time to Live）是 IP 表頭中的存活計數器，每經過一台路由器就會減一。當 TTL 歸零，路由器會丟棄封包並通常回傳 ICMP「Time Exceeded」訊息。

這個回覆就是揭露該路由器存在的關鍵。

雖然兩者都能完成路由追蹤，但它們的呈現方式與適用場景截然不同。選錯工具可能會讓你只看到問題的片段，而遺漏了真正的瓶頸。

運作原理：如何逐跳揭露路由路徑

Traceroute 的機制很直接。它把初始 TTL 設為 1。第一個路由器收到後減為 0，便回傳錯誤訊息。Traceroute 記下這個位址與時間。接著它發送 TTL 為 2 的封包，揭露第二跳。這個過程持續遞增，直到封包抵達目的地或達到預設的上限（通常是 30 跳）。

整個過程中，目的地主機在收到 TTL 足夠的封包後，通常會回傳 ICMP Port Unreachable 或 Echo Reply，讓工具知道已經抵達終點。這個機制是網際網路路由診斷的基礎。

MTR 發現路徑的方式相同，但在摸清整條路徑後，它會進入平行探測模式，同時對所有 hop 發送封包並即時統計。大多數實作預設使用 ICMP，不過兩者都能改用 UDP 或 TCP。這點很重要，因為許多防火牆會擋掉 ICMP，卻允許常見連接埠的 TCP 流量通過。

並不是每次探測都會收到回應。當某個 hop 在逾時時間內沒有回覆，畫面上就會出現星號（*）。這不一定代表節點故障，也可能是它過濾了 ICMP，或者當下負載過高導致回覆被丟棄。

誤判往往會讓你找錯方向。

Traceroute 與 MTR 的關鍵差異

因為 traceroute 執行一次就結束，它只捕捉到單一瞬間的狀態。MTR 則保持運作，收集數十甚至數百個樣本。這種持續性能抓到單次 traceroute 完全遺漏的間歇性問題，例如偶發性壅塞或短暫的路由震盪。

Traceroute 顯示的是個別探測時間，MTR 則彙整大量樣本，計算丟包率（Loss%）、平均延遲、最佳與最差值，以及標準差（StDev）。正如 APNIC 的解讀指南 所指出的，這些統計欄位比單次數據更能定位間歇性丟包或延遲尖峰。這樣的深度讓人更容易發現某條鏈路不穩，或是某個對等互連路由器過載。

速度方面也有差別。MTR 在掌握路徑後會並行探測所有 hop，而 traceroute 通常得等每一輪 TTL 遞增。因此 MTR 通常能更快產出完整結果。另外還有一個路由上的細節：MTR 使用一致的 ICMP 探測，在採用 ECMP（Equal-Cost Multi-Path）的網路上傾向留在同一條路徑；而 traceroute 若使用不同 UDP 連接埠，則可能暴露出多條平行路徑。

協議選擇也值得一提。Traceroute 在 Linux 上常預設使用 UDP，而 MTR 常預設使用 ICMP。某些路由器對 ICMP 的處理優先權較低，可能讓 MTR 測到的延遲看起來比實際流量更高。遇到這種情況，切換協議再測一次會是更好的做法。

在台灣的社群討論中，許多系統管理員會建議直接用 MTR 取代傳統 traceroute，特別是在 VPS 或伺服器環境下，因為持續監控能更快抓出問題區間。

實際操作與輸出解讀

在 Linux 終端機中，執行一次基本的 traceroute 只需要指定目標：

traceroute -n example.com

-n 參數會跳過 DNS 反解，讓測試更快、輸出更簡潔。典型的輸出如下：

traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
 1  192.168.1.1  1.2 ms  1.1 ms  1.3 ms
 2  10.10.0.1    5.4 ms  5.2 ms  5.5 ms
 3  * * *
 4  93.184.216.34  15.1 ms  14.9 ms  15.2 ms

第三跳的星號表示該節點未回應 ICMP，但封包仍成功抵達了第四跳與最終目的地。

這種現象在跨 ISP 或國際路由上很常見，不應直接解讀為斷線。

星號（*）並不代表該節點一定故障。許多營運商會優先處理轉發流量，而降低 ICMP 回覆的優先權，甚至直接過濾。

如果你需要持續觀察，可以用 MTR 的報表模式，在執行固定週期後產生一份可解析的摘要：

mtr --report -n --cycles 100 example.com

以下是 MTR 報表模式的典型輸出範例：

HOST: myserver                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1               0.0%   100    1.2   1.1   1.0   2.3   0.2
  2.|-- 10.10.0.1                 0.0%   100    5.4   5.3   5.1   6.8   0.3
  3.|-- ???                       0.0%   100    0.0   0.0   0.0   0.0   0.0
  4.|-- 93.184.216.34             0.0%   100   15.1  15.0  14.8  18.2   0.5

第三列的 ??? 代表該節點未回應，但 Loss% 為 0.0% 表示後續節點仍正常收到封包。這種細節在單次 traceroute 中很難確認。

對於需要向 ISP 或機房提交證據的場合，這份報表比單次 traceroute 更有說服力。Windows 使用者則可以選擇 WinMTR，它提供圖形介面與相同的核心功能。

除了終端機，你也可以使用線上工具進行多點測試。例如 Dig Trace MTR 工具 與 Traceroute 工具 能從不同網路節點發起測試，方便比較台灣與海外使用者的實際路由差異。

使用情境與注意事項

遇到連線不穩或延遲飆高時，先用 MTR 觀察哪一個 hop 的 Loss% 明顯上升，或是延遲從哪一跳開始大幅增加。鎖定問題節點後，就能針對該路由器或所屬 ISP 聯絡處理。在台灣，不同 ISP 之間的互連品質或國際出口壅塞，往往是延遲暴增的主因。

開發者與站長在部署服務前，也應該從多個據點執行 MTR，確認台灣與全球使用者的實際路由品質。不要只看單次 traceroute 就下結論，MTR 的持續數據更能區分暫時性波動與固定問題。間歇性丟包如果只在特定時段出現，單次快照幾乎不可能發現。

要特別注意的是，防火牆或安全設備經常會阻擋 ICMP。如果測試結果充滿星號，可以嘗試切換協議，例如改用 UDP（-u）或 TCP（-T）來取得更貼近真實流量的結果。另外，非對稱路由（去程與回程路徑不同）在網際網路上非常普遍，探測工具顯示的是去程路徑，但延遲問題可能出在回程，這點在分析時必須納入考量。

與其他診斷工具的關係

Traceroute 與 MTR 屬於網路層診斷工具，與 DNS 查詢、速度測試互補。它們回答的是「封包走了哪條路」與「哪一段慢了」，而不是「頻寬有多少」或「網域名稱解析是否正常」。學會這兩項工具後，下一步可以深入研究 BGP 路由政策、非對稱路由，以及 ECMP 對探測結果的影響，進一步提升排除複雜網路問題的能力。

無論你是排查台灣本地機房的連線品質，還是診斷連線到歐美伺服器的異常，理解 traceroute 與 MTR 的原理與限制，都是網路管理者不可或缺的基礎功。