Was ist MTR? So erstellen und lesen Sie einen mtr-Bericht

MTR (My Traceroute, ursprünglich Matt's traceroute) vereint traceroute und ping. Es ermittelt alle Router zwischen Ihnen und einem Ziel, schickt dann fortlaufend Testpakete an jeden von ihnen und führt darüber Statistik. Ein Traceroute ist eine einzelne Momentaufnahme des Pfads, ein mtr-Bericht besteht aus hundert davon, pro Hop zusammengefasst. Dieser Leitfaden zeigt die Installation und die wichtigen Optionen und geht einen echten Bericht von unseren Servern Spalte für Spalte durch.

mtr installieren

System	Installation	Aufruf
Debian, Ubuntu	sudo apt install mtr-tiny (nur Textmodus) oder mtr	mtr example.com
Fedora, RHEL, Rocky	sudo dnf install mtr	mtr example.com
macOS	brew install mtr	sudo mtr example.com
Windows	WinMTR, ein eigenständiges Programm mit ähnlichen Spalten, oder mtr unter WSL 2	WinMTR starten, Host eingeben

Unter macOS legt Homebrew mtr in seinem Ordner sbin ab, der nicht immer im PATH steht, und mtr braucht sudo, um seine Testpakete zu senden. Ohne Optionen öffnet mtr eine Live-Ansicht, die sich jede Sekunde aktualisiert (beenden mit q). Für alles, was Sie aufbewahren oder weitergeben wollen, gibt es den Berichtsmodus, der eine feste Zahl von Durchläufen ausführt und das Ergebnis einmal ausgibt:

mtr -rwz -c 100 example.com

Die Optionen, die Sie kennen sollten

Option	Wirkung
-r	Berichtsmodus: erst messen, dann eine Tabelle ausgeben, die sich überall einfügen lässt
-w	Breiter Bericht: vollständige Hostnamen statt gekürzter
-c 100	Anzahl der Testpakete pro Hop. 10 für einen schnellen Blick, 100 für den Bericht an einen Provider
-z	Zeigt die AS-Nummer jedes Hops, damit Sie sehen, wo ein Netz an das nächste übergibt
-n	Kein Reverse DNS: schneller, aber Ihnen entgehen die Routernamen, die oft ein Städtekürzel enthalten
-b	Zeigt Namen und IP-Adresse jedes Hops
-T -P 443	TCP-Testpakete an Port 443, für Netze, die ICMP verwerfen
-u	UDP-Testpakete statt ICMP
-4, -6	Erzwingt IPv4 oder IPv6
-i 0.5	Sekunden zwischen zwei Testpaketen (Standard: 1; unter 1 nur als root)
--json	Maschinenlesbare Ausgabe

Ein echter Bericht, Spalte für Spalte gelesen

Diesen Bericht haben wir am 7. Oktober 2026 um 12:26 UTC von unserem Server in Falkenstein, Deutschland (Hetzner), zu einem Vultr-Testhost in New Jersey erstellt, mit 100 Testpaketen pro Hop. Nur der Hostname unseres Rechners ist gekürzt:

$ mtr -rwz -c 100 nj-us-ping.vultr.com
HOST: falkenstein                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    172.20.0.1                           73.0%   100    0.2   0.1   0.0   0.2   0.0
  2. AS24940  ex9k1.dc11.fsn1.hetzner.com           0.0%   100    4.7   1.0   0.3  15.1   1.7
  3. AS24940  core22.fsn1.hetzner.com               0.0%   100    0.8   0.7   0.3   1.7   0.2
  4. AS24940  juniper5.dc2.nbg1.hetzner.com         0.0%   100    3.0   5.2   2.8  65.6   9.2
  5. AS201011 ae12-499.nbg40.core-backbone.com      0.0%   100    3.2   3.0   2.7   3.3   0.1
  6. AS201011 ae7-2093.nyk10.core-backbone.com      0.0%   100   86.6  86.7  86.5  87.0   0.1
  7. AS???    ???                                  100.0   100    0.0   0.0   0.0   0.0   0.0
  8. AS???    ???                                  100.0   100    0.0   0.0   0.0   0.0   0.0
  9. AS???    ???                                  100.0   100    0.0   0.0   0.0   0.0   0.0
 10. AS20473  66.55.138.149.vultrusercontent.com    2.0%   100   85.7  85.9  85.6  87.3   0.2
 11. AS20473  108.61.149.182.vultrusercontent.com   0.0%   100   86.2  86.4  85.9 107.1   2.1

• Loss%: der Anteil der Testpakete an diesen Hop, auf die keine Antwort kam. Hier sind es 73 % an Hop 1 und 2 % an Hop 10, am Ziel dagegen 0 %. Nichts davon ist echter Verlust (siehe unten).
• Snt: an jeden Hop gesendete Testpakete, hier 100.
• Last, Avg, Best, Wrst: Round-Trip-Zeiten (RTT) in Millisekunden, und zwar die des letzten Testpakets, der Mittelwert, die schnellste und die langsamste. Best kommt dem am nächsten, was der Pfad physikalisch zulässt: 85,9 ms bis New Jersey.
• StDev: wie stark die Zeiten schwanken, also der Jitter. 0,1 bis 0,2 ms an den meisten Hops: ein ruhiger Pfad.
• AS (mit -z): das Netz, dem die jeweilige Adresse gehört. Die Hops 2 bis 4 gehören zu Hetzner (AS24940), die Hops 5 und 6 zu Core-Backbone (AS201011), die Hops 10 und 11 zu Vultr (AS20473). An den Übergängen zwischen diesen Netzen zeigt sich Überlastung meistens, wenn es denn welche gibt.
• Namen: Routernamen enthalten oft eine Stadt. Hop 5 ist nbg40 (Nürnberg) mit 3 ms, Hop 6 ist nyk10 (New York) mit 86,7 ms: die Atlantiküberquerung in einer einzigen Zeile.

Drei Dinge im Bericht, die falsch aussehen, es aber nicht sind

1. Verlust an einem Hop, der sich nicht fortsetzt. Hop 1 (das Gateway des Containers, in dem der Test läuft) bleibt 73 % seiner Antworten schuldig, bei Hop 10 sind es 2 %, und jeder Hop danach beantwortet alles. Router beantworten Testpakete in Software, mit niedriger Priorität, und viele begrenzen, wie viele Antworten sie pro Sekunde senden. Verkehr, der durch sie hindurchläuft, ist davon nicht betroffen.
2. Ein langsamer Hop, gefolgt von schnellen. Hop 4 liegt im Schnitt bei 5,2 ms, im schlechtesten Fall bei 65,6 ms, während Hop 5 direkt dahinter nie über 3,3 ms hinausgeht. Der Router hat sich mit der Antwort auf einige Testpakete Zeit gelassen; die Pakete, die er weiterleitete, hat er nicht verzögert.
3. Stumme Hops. Die Hops 7 bis 9 antworten nie (???, 100 %). Das sind Router, die so konfiguriert sind, dass sie nicht antworten. Da die Hops 10 und 11 antworten, kommen die Pakete offensichtlich durch sie hindurch.

Daraus folgt die Regel: Verlust oder Latenz zählen nur, wenn sie an einem Hop beginnen und sich bis zum Ziel fortsetzen. Zeigte Hop 6 einen Verlust von 15 % und die Hops 7 bis 11 denselben, dann begänne das Problem an Hop 6 oder auf der Leitung direkt davor. Eine Spitze, die am nächsten Hop verschwindet, liegt am Router, nicht am Pfad.

Die gleiche Messung nach Singapur, in derselben Minute gestartet, zeigt diese Effekte noch deutlicher: Ein Arelion-Router in Hamburg beantwortete nur 47 % der Testpakete, ein anderer in Singapur 18 %, mit einem schlechtesten Wert von 381,6 ms, und das Ziel beantwortete 100 % davon, im Schnitt in 165,5 ms.

Wie viele Testpakete, von wo und wann

• 10 Testpakete reichen, um den Pfad zu sehen. 100 braucht es, um Verlust zu messen: Bei 10 Testpaketen erscheint ein Verlust von 1 % meistens als 0 %.
• Messen Sie, während das Problem auftritt. Ein mtr-Lauf eine Stunde später zeigt einen gesunden Pfad und beweist nichts.
• Messen Sie von mehr als einem Ort aus. Derselbe Host in New Jersey, in derselben Minute von unserem Server in Gravelines, Frankreich (OVHcloud), gemessen, antwortete in 71,7 ms statt 86,4 ms: OVH transportiert den Verkehr im eigenen Netz bis New York und übergibt ihn am Internet-Knoten NYIIX an Vultr, während er von Falkenstein aus über Core-Backbone läuft. Gleiches Ziel, zwei Routen, 15 ms Unterschied.
• Denken Sie an den Rückweg. Jeder Zeitwert im Bericht ist eine RTT, und der Rückweg kann über eine andere Route laufen, die mtr nicht sieht. Wenn möglich, starten Sie mtr auch von der Gegenseite aus.

Einen mtr-Bericht an Ihren Provider schicken

• Verwenden Sie mtr -rwzb -c 100: Bericht, vollständige Namen, AS-Nummern und IP-Adressen.
• Notieren Sie Datum, Uhrzeit mit Zeitzone, Ihre öffentliche IP und das Ziel.
• Wird ICMP irgendwo auf dem Pfad gefiltert, ergänzen Sie -T -P 443 und weisen Sie darauf hin.
• Benennen Sie den ersten Hop, an dem Verlust oder Latenz beginnen und bis zum Ende bleiben, nicht den Hop mit der größten Zahl.

mtr, traceroute und ping

Tool	Was es misst	Standard-Testpaket	Ideal für
ping	RTT und Verlust, nur bis zum Ziel	ICMP Echo	Erreichbarkeit, Antwortzeit, Stabilität
traceroute	Der Pfad, drei Testpakete pro Hop, ein einziger Durchlauf	UDP unter Linux und macOS, ICMP unter Windows (tracert)	Die Route sehen
mtr	Der Pfad, mit Verlust- und Latenzstatistik für jeden Hop	ICMP (auf Wunsch UDP oder TCP)	Sporadische Probleme, Belege für einen Provider

Unter Windows ohne WinMTR leistet das eingebaute pathping Ähnliches in zwei Durchgängen: erst ein Trace, dann etwa 25 Sekunden Testpakete pro Hop. Zu den Unterschieden zwischen den ersten beiden Tools siehe Traceroute vs. Ping, zum Traceroute-Befehl auf jedem System Traceroute-Befehle für Windows, Mac und Linux.

Wenn Sie mtr nicht selbst ausführen können

Firmennetze blockieren die Testpakete oft, auf Smartphones läuft kein mtr, und ein Test über Ihren eigenen Anschluss sagt nichts über den Pfad von anderswo. TraceMapper führt dieselbe Messung von unseren Servern und von mehr als 30 Standorten aus durch, setzt jeden Hop mit Latenz, Verlust und Netz auf eine Karte und hält das Ergebnis als Link fest, den Sie verschicken können. Wie Sie herausfinden, wo sich ein Pfad tatsächlich verschlechtert, zeigt Netzwerkengpässe mit Traceroute erkennen.