如何判讀 MTR 測試結果與路由掉包？

MTR 報告能顯示封包從您的電腦傳輸至目的地的完整路徑。每一行代表一個節點 (Hop)。要準確判斷網路問題，請重點觀察以下兩個指標：Loss% (掉包率) 與 Avg (平均延遲)。

---

📊 關鍵指標解讀

1. Loss% (掉包率)

• 含義：封包在該節點遺失的比例。
• 判斷標準：
  • 0%：連線完美，無掉包。
  • 1-2%：輕微掉包，可能影響遊戲體驗，但網頁瀏覽無感。
  • >5%：嚴重掉包，會導致斷線、卡頓與傳輸失敗。
  • 100% (No Response)：該節點設定為不回應 ICMP 請求（防火牆阻擋），若後續節點正常，則此 100% 可忽略，並非故障。

2. Avg (平均延遲) / Worst (最差延遲)

• 含義：封包往返該節點所需的時間 (ms)。
• 判斷標準：突增的延遲通常代表該節點擁塞或路徑發生繞道。

---

🕵️‍♂️ 實戰分析範例

案例一：本地網路故障

若掉包 從第 1 或第 2 個節點就開始出現，且一路延續到最後：

1. 192.168.1.1       Loss% = 5.0%
2. 168.95.1.1        Loss% = 5.0%
...
10. vps-ip           Loss% = 5.0%

結論：問題出在您的路由器、數據機或您當地的 ISP (如中華電信)。 解法：請重啟數據機或聯繫您的網路供應商。

案例二：中間運營商故障 (最常見)

若前面節點正常，從中間某個節點突然開始掉包，並延續到最後：

1. local-network     Loss% = 0%
...
6. pccw-backbone     Loss% = 20%  <-- 問題起點
7. tw-gate           Loss% = 20%
8. vps-ip            Loss% = 20%

結論：國際頻寬擁塞或中間運營商 (如 PCCW, Hinet) 線路異常。 解法：此為大網環境問題，通常需等待運營商修復。請將報告截圖提交給我們，以利向線路商透過。

案例三：目標主機故障

若只有最後一個節點 (Dest) 出現掉包，前面完全正常： 結論：可能是 VPS 負載過高、防火牆阻擋或遭攻擊。

---

💡 常見誤區

看到中間有節點 Loss 100%？ 請往下看，若該節點之後的節點 Loss% 回復為 0%，則代表該節點僅是被設定為「不回應 Ping」，並非斷線。這是正常現象，請忽略它。

---

如何判读 MTR 测试结果与路由掉包？ MTR 报告能显示封包从您的电脑传输至目的地的完整路径。每一行代表一个节点 (Hop)。要准确判断网路问题，请重点观察以下两个指标： Loss% (掉包率) 与 Avg (平均延迟) 。 --- 📊 关键指标解读 1. Loss% (掉包率) - 含义 ：封包在该节点遗失的比例。 - 判断标准 ： - 0% ：连线完美，无掉包。 - 1-2% ：轻微掉包，