MTR是一個功能強大的工具，使管理者能夠診斷和隔離網絡錯誤，并向上遊提供商提供網絡狀态報告。MTR表示的演進
traceroute
通過提供更大的資料樣本，好像增強指令
traceroute
與
ping
輸出。本文深入介紹了MTR，它産生的資料，以及如何根據它提供的資料得出結論。
有關網絡診斷技術的基本概述，請參閱我們的網絡診斷簡介。如果您的系統存在其他問題，請閱讀我們的正常系統診斷概述。
網絡診斷背景
網絡診斷工具包括
ping
，
traceroute
和
mtr，
它們使用Internet控制消息協定（ICMP）資料包來測試Internet上兩點之間的連接配接和傳輸。當使用者在Internet上ping主機時，會向主機發送一系列ICMP資料包，主機通過發送資料包作為響應。然後，使用者的用戶端能夠計算網際網路上兩點之間的往返時間。
相反，諸如traceroute和MTR之類的工具發送ICMP資料包的TTL遞增，可以檢視資料包在源和目的地之間産生的一系列跳。TTL即生存時間，控制着資料包在“死亡”并傳回主機之前将進行多少跳。通過發送一系列資料包并使它們在一跳、兩跳、三跳之後傳回，MTR能夠分析英特網上不同主機之間流量的通路。
MTR不是隻提供Internet的路由間的簡單概述，而是收集有關中間主機的狀态，連接配接和響應性的其他資訊。由于這些附加資訊，MTR可以提供Internet上兩台主機之間連接配接的完整描述。以下部分概述了如何安裝MTR軟體以及如何解釋此工具提供的結果。
安裝MTR
Linux
Debian / Ubuntu
apt update && apt upgrade
apt install mtr-tiny 複制
CentOS/ RHEL / Fedora
yum update
yum install mtr 複制
Windows
對于Windows，有一個名為“WinMTR”的MTR端口。您可以從WinMTR上遊下載下傳此應用程式。
蘋果系統
使用Homebrew或MacPorts在macOS上安裝MTR 。要使用Homebrew安裝MTR，請運作：
brew install mtr 複制
要使用MacPorts安裝MTR，請運作：
port install mtr 複制
生成MTR報告
因為MTR提供了從一個主機到另一個主機的路由流量的圖像，是以它本質上是一個定向工具。網際網路上兩點之間的路由可能因位置和位于上遊的路由器而有很大差異。是以，對于遇到連接配接問題的所有主機，最好雙向收集MTR報告。
Linode客戶支援往往會要求中期審查報告都要以你的Linode為起點或終點如果你遇到網絡問題。這是因為，當來自相反方向的資料包丢失時，MTR報告有時從一個方向檢測不到錯誤。
在引用MTR報告時，此文檔指的是源主機運作
mtr
查詢隊列作為目标主機。
在基于Unix的系統上使用MTR
使用以下文法生成MTR報告：
mtr -rw [destination_host] 複制
例如，要測試到目标主機
example.com
的流量的路由和連接配接品質：
mtr -rw example.com 複制
可以從本地計算機運作到您的Linode的MTR報告。替換
192.0.2.0
為您的Linode的IP位址：
mtr -rw 192.0.2.0 複制
SSH進入您的Linode并從您的Linode收集MTR到您的家庭網絡的報告。替換
198.51.100.0
為家庭網絡的IP位址。
mtr -rw 198.51.100.0 複制
如果您不知道您的家庭IP位址，請使用WhatIsMyIP.com。
如果未檢測到資料包丢失，則技術支援人員可能會要求您以更短的時間間隔運作：
mtr -rwc 50 -i 0.2 -rw 198.51.100.0 複制
在某些系統上，使用此标志可能需要管理權限：
sudo mtr -rwc 50 -i 0.2 -rw 198.51.100.0 複制
注意選項标志生成報告（簡稱r
）。--report
選項标志使用主機名，以便我們的技術人員和你可以看到每一跳（簡稱的全名w
）。--report-wide
選項标志設定多少資料包被發送并記錄在報告中。不使用時，預設值通常為10，但是對于更快的間隔，您可能需要将其設定為50或100.執行此操作時，報告可能需要更長時間才能完成。c
選項标志以更快的速度運作監測是否隻在網絡擁塞發生丢包。該标志訓示MTR每n秒發送一個資料包。預設值為1秒，是以将其設定為十分之幾秒（0.1,0.2等）通常很有幫助。i
在Windows系統上使用MTR
在Windows上使用GUI運作MTR。打開WinMTR，根據提示在框中鍵入目标主機，然後選擇開始選項以開始生成報告資料。如上所示，您需要使用Linux版本的MTR從您的Linode生成MTR報告。
閱讀MTR報告
由于MTR報告包含大量資訊，是以最初可能難以解釋。以下示例是本地連接配接
google.com
的報告：
$ mtr --report google.com
HOST: example Loss% Snt Last Avg Best Wrst StDev
1. inner-cake 0.0% 10 2.8 2.1 1.9 2.8 0.3
2. outer-cake 0.0% 10 3.2 2.6 2.4 3.2 0.3
3. 68.85.118.13 0.0% 10 9.8 12.2 8.7 18.2 3.0
4. po-20-ar01.absecon.nj.panjde 0.0% 10 10.2 10.4 8.9 14.2 1.6
5. be-30-crs01.audubon.nj.panjd 0.0% 10 10.8 12.2 10.1 16.6 1.7
6. pos-0-12-0-0-ar01.plainfield 0.0% 10 13.4 14.6 12.6 21.6 2.6
7. pos-0-6-0-0-cr01.newyork.ny. 0.0% 10 15.2 15.3 13.9 18.2 1.3
8. pos-0-4-0-0-pe01.111eighthav 0.0% 10 16.5 16.2 14.5 19.3 1.3
9. as15169-3.111eighthave.ny.ib 0.0% 10 16.0 17.1 14.2 27.7 3.9
10. 72.14.238.232 0.0% 10 19.1 22.0 13.9 43.3 11.1
11. 209.85.241.148 0.0% 10 15.1 16.2 14.8 20.2 1.6
12. lga15s02-in-f104.1e100.net 0.0% 10 15.6 16.9 15.2 20.6 1.7 複制
報告是用
mtr --report google.com
。生成的。這使用
report
選項，該選項将10個資料包發送到主機
google.com
并生成報告。如果沒有
--report
選項，
mtr
将在互動式環境中持續運作。互動模式反映了每個主機的目前往返時間。在大多數情況下，
--report
模式以有用的格式提供足夠的資料。
報告中的每個編号行代表一個躍點。躍點是資料包通過并到達目的地的Internet節點。主機的名稱（例如，示例中的“inner-cake”和“outer-cake”）由反向DNS查找确定。如果要省略rDNS查找，可以使用
--no-dns
選項，該選項生成類似于以下内容的輸出：
% mtr --no-dns --report google.com
HOST: deleuze Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 10 2.2 2.2 2.0 2.7 0.2
2. 68.85.118.13 0.0% 10 8.6 11.0 8.4 17.8 3.0
3. 68.86.210.126 0.0% 10 9.1 12.1 8.5 24.3 5.2
4. 68.86.208.22 0.0% 10 12.2 15.1 11.7 23.4 4.4
5. 68.85.192.86 0.0% 10 17.2 14.8 13.2 17.2 1.3
6. 68.86.90.25 0.0% 10 14.2 16.4 14.2 20.3 1.9
7. 68.86.86.194 0.0% 10 17.6 16.8 15.5 18.1 0.9
8. 75.149.230.194 0.0% 10 15.0 20.1 15.0 33.8 5.6
9. 72.14.238.232 0.0% 10 15.6 18.7 14.1 32.8 5.9
10. 209.85.241.148 0.0% 10 16.3 16.9 14.7 21.2 2.2
11. 66.249.91.104 0.0% 10 22.2 18.6 14.2 36.0 6.5 複制
除了簡單地檢視資料包到達其主機所使用的伺服器之間的路徑之外，MTR還在後面的七列中提供有關該連接配接的持久性的有價值的統計資訊。
Loss%
列顯示每跳的丢包百分比。
Snt
列計算發送的資料包數。
--report
除非指定
--report-cycles=[number-of-packets]
，否則該選項将發送10個資料包，其中
[number-of-packets]
表示要發送到遠端主機的資料包總數。
接下來的四列
Last
，
Avg
，
Best
和
Wrst
以毫秒為機關測量所有延遲（
ms
）。
Last
是最後發送的資料包的延遲，
Avg
是所有資料包的平均延遲，而
Best
并
Wrst
顯示最佳（最短）和最差（最長）往返時間的到該主機的包的時間。在大多數情況下，average（
Avg
）列應該是您關注的焦點。
最後一列
StDev
提供了每個主機的延遲标準偏差。标準差越大，延遲測量之間的差異越大。标準偏差允許您評估所提供的平均值（平均值）是否代表資料集的真實中心，或者是否因某種現象或測量誤差而偏斜。如果标準偏差很高，則延遲測量值不一緻。在對發送的10個資料包的延遲進行平均後，平均值看起來正常但實際上可能不能很好地表示資料。如果标準偏差很高，請檢視最佳和最差延遲測量，以確定平均值是實際延遲的良好表示，而不是太大波動的結果。
在大多數情況下，您可能會想到三個主要部分的MTR輸出。根據配置，前2或3跳通常代表源主機的ISP，而最後2或3跳代表目标主機的ISP。中間的跳數是資料包周遊到達目的地的路由器。
例如，如果MTR從您的家用PC運作到您的Linode，則前2或3個躍點屬于您的ISP。最後3個躍點屬于您的Linode所在的資料中心。中間的任何跳都是處于中間媒介的跳。在本地運作MTR時，如果您在源附近的前幾個躍點中看到異常，請聯系您當地的ISP或調查您的本地網絡配置。相反，如果您在目的地附近看到異常，則可能需要聯系目标伺服器的操作員或該計算機的網絡支援。不幸的是，在中間躍點存在問題的情況下，兩個服務提供商解決問題的能力都有限。
分析MTR報告
驗證資料包丢失
在分析MTR輸出時，您要尋找兩件事：丢包和延遲。如果您在任何特定跳中看到丢失百分比，則可能表示該特定路由器存在問題。但是，某些ISP通常會對MTR使用的ICMP流量進行速率限制。這可能給出丢包的錯覺然而實際上并沒有丢包。要确定您所看到的丢包是真實的還是由于速率限制，請檢視後續跳。如果後續跳顯示0.0％的丢包，那麼您可能是看到ICMP速率限制而非實際丢包：
root@localhost:~# mtr --report www.google.com
HOST: example Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 50.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 0.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2 複制
在這種情況下，跳1和2之間報告的丢包可能是由于第二跳的速率限制。剩餘8個躍點的流量都到第二跳，但沒有資料包丢失。如果丢失持續超過一跳，則可能存在丢包或路由問題。請記住，速率限制和丢包可以同時發生。在這種情況下，将序列中最低的丢包百分比作為實際丢包：
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 60.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 60.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 50.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 40.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 40.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 40.0% 10 39.6 40.5 39.5 46.7 2.2 複制
在這種情況下，跳2和3之間以及跳3和4之間有60％的丢包。您可以假設第三跳和第四跳可能會丢失一些流量，因為沒有後續主機報告零丢失。然而，一些丢包是由于速率限制，因為幾個最終的跳僅經曆了40％的丢包。報告不同數量的丢包時，請始終信任後續躍點中的報告。
一些丢包也可以通過傳回路線中的問題來解釋。資料包将毫無錯誤地到達目的地，但很難進行傳回。是以，當您遇到問題時，通常最好在兩個方向收集MTR報告。
不要調查或報告連接配接中所有的丢包事件。Internet協定對某些網絡性能下降具有彈性，并且在Internet上傳輸資料的路由可能會因負載、簡短維護事件和其他路由問題而發生波動。如果您的MTR報告顯示10％左右的少量丢包，則沒有理由去關注，因為應用層将補償這些丢包。
網絡延遲
除了幫助您評估資料包丢失外，MTR還将幫助評估主機與目标主機之間連接配接的延遲。由于實體限制，延遲總是随着路由中的跳數而增加。但是，增加應該是線性的。不幸的是，延遲通常是相對的，并且非常依賴于主機連接配接的品質和它們的實體距離。在評估可能存在問題的連接配接的MTR報告時，除了已知給定區域中其他主機之間的連接配接速度之外，還要關注早期的所有的功能報告。
連接配接品質還可能影響您到特定路由器遇到的延遲量。可以知道，撥接上網比連接配接到同一目的地的電纜數據機連接配接具有更高的延遲。以下MTR報告顯示的高延遲：
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 388.0 360.4 342.1 396.7 0.2
5. 72.14.233.56 0.0% 10 390.6 360.4 342.1 396.7 0.2
6. 209.85.254.247 0.0% 10 391.6 360.4 342.1 396.7 0.4
7. 64.233.174.46 0.0% 10 391.8 360.4 342.1 396.7 2.1
8. gw-in-f147.1e100.net 0.0% 10 392.0 360.4 342.1 396.7 1.2 複制
延遲量在跳3和4之間顯著增高。這可能是網絡延遲問題，因為在第四跳之後往返時間仍然很高。從該報告中可以知道，配置不良的路由器或擁塞的鍊路是可能原因，但無法确定原因。
不幸的是，高延遲并不總是意味着目前路線的問題。像上面那樣的報告意味着盡管第4跳出現了某種問題，但流量仍然到達目标主機并傳回到源主機。延遲也可能是由傳回路線問題引起的。您的MTR報告中将不會顯示傳回路由，并且資料包可以采用與特定目的地完全不同的路由。
在上面的示例中，雖然主機3和4之間的延遲有很大的跳躍，但延遲在任何後續跳躍中都不會異常增加。由此可以合理地假設第4個路由器存在一些問題。
ICMP速率限制還可以建立延遲的假象，類似于它可以建立丢包假象的方式：
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 0.0% 10 254.2 250.3 230.1 263.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2 複制
乍一看，跳躍4和5之間的延遲引起了人們的注意。然而，在第五跳之後，延遲急劇下降。這裡測量的實際延遲大約是40ms。在這種情況下，MTR的報告的延遲并沒有什麼影響。在評估MTR報告時，請考慮最後一跳的延遲。
通用MTR報告
一些網絡問題是新穎的并且需要更新到上遊網絡的營運商。但是，有一些常見的MTR報告可以描述常見的網絡問題。如果您遇到某種網絡問題并想要診斷問題，請考慮以下示例。
目标主機網絡配置不正确
在下一個示例中，由于路由器配置不正确，似乎100％丢失了目标主機。乍一看，似乎資料包沒有到達主機，但事實并非如此。
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 0.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 100.0 10 0.0 0.0 0.0 0.0 0.0 複制
流量确實到達目标主機。但是，MTR報告顯示丢失，因為目标主機未發送回複。這可能是由于未正确配置的網絡或防火牆（iptables）規則導緻主機丢棄ICMP資料包的結果。
您可以判斷丢失是由于配置錯誤的主機造成的，就是檢視顯示100％丢失的跳數。從以前的報告中，您可以看到這是最後一跳，并且MTR不會嘗試額外的躍點。雖然沒有基線測量很難找到這個問題，但這類錯誤很常見。
住宅或商業路由器
住宅網關有時會導緻誤導性報告：
% mtr --no-dns --report google.com
HOST: deleuze Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 10 2.2 2.2 2.0 2.7 0.2
2. ??? 100.0 10 8.6 11.0 8.4 17.8 3.0
3. 68.86.210.126 0.0% 10 9.1 12.1 8.5 24.3 5.2
4. 68.86.208.22 0.0% 10 12.2 15.1 11.7 23.4 4.4
5. 68.85.192.86 0.0% 10 17.2 14.8 13.2 17.2 1.3
6. 68.86.90.25 0.0% 10 14.2 16.4 14.2 20.3 1.9
7. 68.86.86.194 0.0% 10 17.6 16.8 15.5 18.1 0.9
8. 75.149.230.194 0.0% 10 15.0 20.1 15.0 33.8 5.6
9. 72.14.238.232 0.0% 10 15.6 18.7 14.1 32.8 5.9
10. 209.85.241.148 0.0% 10 16.3 16.9 14.7 21.2 2.2
11. 66.249.91.104 0.0% 10 22.2 18.6 14.2 36.0 6.5 複制
第二跳報告的100％損失并不表示存在問題。您可以看到後續躍點沒有丢失。
未正确配置ISP路由器
有時，您的資料包所使用的路由上的路由器配置錯誤，您的資料包可能永遠無法到達目的地：
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
6. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
7. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
8. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
9. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
10. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 複制
當沒有其他路線資訊時，會出現問号。有時，配置不當的路由器會在循環中發送資料包。您可以在以下示例中看到：
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0
6. 12.34.56.78 0.0% 10 0.0 0.0 0.0 0.0 0.0
7. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0
8. 12.34.56.78 0.0% 10 0.0 0.0 0.0 0.0 0.0
9. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0
10. 12.34.56.78 0.0% 10 0.0 0.0 0.0 0.0 0.0
11. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0
12. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
13. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
14. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 複制
這些報告顯示第4跳路由器未正确配置。發生這些情況時，解決問題的唯一方法是聯系源主機上的網絡管理者的操作員團隊。
ICMP速率限制
ICMP速率限制可能導緻明顯的資料包丢失。如果丢包到一個跳不會持續到後續跳，則丢失是由ICMP限制引起的。請參閱以下示例：
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 60.0% 10 27.2 25.3 23.1 26.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2 複制
本報告不會引起關注。速率限制是一種常見做法，它可以減少擁塞，優先處理更重要的流量。
逾時
逾時可能由于各種原因而發生。有些路由器将丢棄ICMP，缺少的回複将在輸出中顯示為逾時（
???
）。或者，傳回路線可能存在問題：
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. ??? 0.0% 10 7.2 8.3 7.1 16.4 2.9
6. ??? 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2 複制
逾時不一定表示資料包丢失。資料包仍然可以到達目的地，而不會出現明顯的丢包或延遲 逾時可能歸因于路由器為了QoS（服務品質）目的而丢棄資料包，或者導緻逾時的傳回路由可能存在一些問題。這是另一個誤報。
先進的MTR技術
較新版本的MTR能夠在指定的TCP端口上以TCP模式運作，而不是ICMP（ping）協定。在某些情況下，網絡性能下降可能隻限于特定端口，它們可能是由于配置不正當的防火牆規則或者特定路由器禁用特定端口所導緻的。在某個端口上運作MTR可能會顯示丢包，而預設的ICMP報告可能沒有。
在TCP模式下運作MTR在大多數機器上需要具有sudo權限：
sudo mtr -P 80 -i 0.5 -rwc 50 example.com
sudo mtr -P 22 -i 0.5 -rwc 50 example.com 複制
解決您的MTR報告中确定的路由和網絡問題
MTR報告顯示的大多數路由問題都是暫時的。大多數問題将在24小時内自行解決。在大多數情況下，當您能夠發現路由問題時，Internet服務提供商的監控已經報告了問題，管理者正在努力解決問題。如果您在較長時間内遇到服務品質下降，您可以選擇向提供商提醒您遇到的問題。聯系服務提供商時，請發送MTR報告以及您可能擁有的任何其他相關資料。沒有可用的資料，提供商無法驗證或修複問題。
雖然路由錯誤和問題占網絡速度問題的一定的百分比，但它們絕不是降低性能的唯一原因。網絡擁塞，特别是在高峰時段的長距離傳輸，可能會變得嚴重。跨大西洋和跨太平洋的網絡波動可能變化很大，并且受到一般網絡擁塞的影響。在這些情況下，建議您将主機和資源定位在盡可能靠近目标閱聽人的地理位置。
如果您遇到連接配接問題且無法解釋您的MTR報告，請打開支援服務單。在Linode Manager的“支援”頁籤中送出報告的輸出，我們的技術人員可以幫助您分析問題。
更多資訊
有關此主題的其他資訊，您可能需要參考以下資源。雖然提供這些是希望它們有用，但請注意，我們無法保證外部托管材料的準确性或時效性。
- 了解Traceroute指令 - Cisco Systems
- 關于traceroute的維基百科文章
- Traceroute by Exit109.com