MTR unter Linux: Netzwerkdiagnose einfach erklärt

MTR Netzwerkdiagnose hilft dir, wenn eine Verbindung langsam ist, Pakete verloren gehen oder ein Server nur gelegentlich erreichbar ist. Das Werkzeug verbindet die Routenverfolgung von Traceroute mit wiederholten Messungen wie bei Ping. Du siehst damit nicht nur, ob dein Ziel antwortet, sondern auch, welche Router unterwegs reagieren und wie sich deren Antwortzeiten entwickeln.

Ein einzelner Ping sagt dir: Das Ziel ist erreichbar. Schön! Wenn sich eine SSH-Verbindung trotzdem wie ein Faxgerät mit schlechter Laune anfühlt, brauchst du etwas mehr Informationen. Genau hier wird MTR interessant. Ich zeige dir die Installation, sinnvolle Befehle und vor allem, wie du die Ergebnisse liest, ohne den erstbesten Router zu Unrecht zum Schuldigen zu erklären.

🧭 Was ist MTR und wofür nutzt du es?

MTR steht heute üblicherweise für My Traceroute; ursprünglich bezog sich der Name auf Entwickler Matt Kimball. Es ist ein freies Diagnosewerkzeug für die Kommandozeile. Jede Zeile der Ausgabe steht für einen Hop, also einen antwortenden Router beziehungsweise das Ziel auf dem untersuchten Weg.

Dafür schickt MTR getrennte Messpakete mit schrittweise erhöhtem TTL-Wert los. TTL begrenzt, wie viele Router ein Paket passieren darf. Läuft der Wert unterwegs ab, kann der betreffende Router mit einer ICMP-Meldung antworten. MTR wiederholt diese Messungen und berechnet für jeden antwortenden Hop eine eigene Statistik. Es verfolgt also nicht ein einziges Paket und misst dessen Laufzeit an allen Stationen.

• Eine langsame Verbindung zu einem Webserver oder VPS eingrenzen.
• Paketverlust und schwankende Antwortzeiten über einen längeren Zeitraum beobachten.
• Messungen aus dem LAN, über WLAN und über ein VPN vergleichen.
• IPv4 und IPv6 getrennt untersuchen.
• Einen nachvollziehbaren Report für den Provider oder Hosting-Support erstellen.

Der Startpunkt zählt: Starte MTR auf dem Rechner, auf dem das Problem auftritt. Eine Messung auf deinem VPS untersucht den Weg vom VPS zum Ziel. Sie erklärt nicht automatisch, warum dein Notebook über WLAN Probleme hat. Auch VPNs und Container verändern den untersuchten Weg.

📦 MTR installieren

Du brauchst ein Terminal, ein erreichbares Ziel und für die Paketinstallation Administratorrechte. Für einen Linux-Server genügt die Terminal-Version. Einen dauerhaft laufenden Dienst oder einen Docker-Stack brauchst du dafür nicht.

Ubuntu und Debian

sudo apt update
sudo apt install mtr-tiny
mtr --version

mtr-tiny enthält die schlanke Terminal-Variante ohne grafische Oberfläche. Trotz des Namens ist das kein Spielzeug. Für die folgenden Beispiele reicht das Paket völlig aus.

Fedora

sudo dnf install mtr
mtr --version

macOS mit Homebrew

brew install mtr
sudo mtr 1.1.1.1

Homebrew weist für MTR auf benötigte Root-Rechte hin. Falls deine Shell mtr nach der Installation nicht findet, nutze den vollständigen Pfad:

sudo "$(brew --prefix)/sbin/mtr" 1.1.1.1

Windows: Messpunkt bewusst wählen

MTR gibt es auch für Windows: Mit WinMTR kannst du Netzwerkwege, Antwortzeiten und Paketverlust direkt über eine grafische Oberfläche untersuchen. Die Windows-Version steht hier zum Download bereit. Zur Einrichtung und Verwendung von WinMTR werde ich in Kürze einen eigenen Beitrag schreiben. Hier konzentriere ich mich auf MTR unter Linux.

Unter Windows kannst du mit einer bereits eingerichteten Ubuntu-Umgebung in WSL die Linux-Befehle verwenden. Installiere dort mtr-tiny wie oben. Beachte aber: WSL besitzt je nach Konfiguration eine eigene virtuelle Netzwerkschicht. Du misst damit aus WSL heraus. Für ein Problem, das nur eine Windows-Anwendung betrifft, sind ergänzende Messungen direkt unter Windows sinnvoll.

Windows bringt mit pathping außerdem ein Werkzeug mit, das Routenverfolgung und Verlustmessungen kombiniert. Es ist kein MTR und seine Optionen unterscheiden sich. Für einen ersten Vergleich kannst du in PowerShell pathping 1.1.1.1 verwenden.

🚀 Erste MTR Netzwerkdiagnose starten

mtr -4 -n 1.1.1.1

-4 erzwingt IPv4. -n zeigt IP-Adressen statt rückwärts aufgelöster Hostnamen. Das hält die Anzeige übersichtlich. Bei einem Zielnamen wird dessen Adresse trotzdem per DNS aufgelöst; -n schaltet nicht jede DNS-Abfrage ab.

Du erhältst eine laufend aktualisierte Ansicht. Lass die Messung etwas arbeiten und beobachte besonders die letzte Zeile. Zehn Pakete sind ein Funktionstest, aber noch keine belastbare Aussage über gelegentliche Aussetzer.

• q: MTR beenden.
• n: Anzeige zwischen IP-Adressen und Hostnamen umschalten.
• r: Zähler zurücksetzen, etwa nach einem Wechsel von WLAN auf Kabel.
• h oder ?: Hilfe der interaktiven Ansicht anzeigen.

Wenn MTR auf deinem Linux-System wegen fehlender Berechtigungen keine Pakete senden kann, wiederhole den Befehl mit sudo. Paketierte Versionen sind häufig bereits passend eingerichtet. Du musst dafür nicht pauschal Dateirechte oder Firewall-Regeln ändern.

📊 Die Ausgabe richtig lesen

Eine typische Statistik sieht so aus. Das folgende Beispiel ist bewusst vereinfacht und keine echte Messung:

Hop  Adresse         Loss%  Snt  Last   Avg  Best  Wrst  StDev
1    192.168.1.1       0.0%  100   1.1   1.2   0.8   3.5    0.4
2    198.51.100.1     40.0%  100  10.0  10.5   8.0  22.0    2.3
3    203.0.113.1       0.0%  100  12.4  12.8  10.2  24.0    2.0
4    1.1.1.1           0.0%  100  13.1  13.6  10.8  25.0    2.1

• Loss%: Anteil der Messungen ohne empfangene Antwort für diesen Hop.
• Snt: Anzahl der gesendeten Messpakete für die Zeile.
• Last: letzte gemessene Antwortzeit.
• Avg: durchschnittliche Antwortzeit.
• Best und Wrst: kleinste und größte gemessene Antwortzeit.
• StDev: Standardabweichung der Antwortzeiten. Größere Werte zeigen stärkere Streuung.

Die Zeitwerte stehen in Millisekunden und beschreiben die Round-Trip-Time: vom Messrechner zum jeweiligen Hop und zurück. Die Zeilen sind keine addierbaren Teilstrecken. Ziehst du den Wert eines Routers vom nächsten ab, erhältst du deshalb keine verlässliche Laufzeit der Verbindung zwischen beiden.

40 Prozent Verlust an einem Router: Muss ich mir Sorgen machen?

Im Beispiel antwortet Hop 2 auf einen Teil der Messungen nicht. Alle späteren Stationen und das Ziel antworten jedoch vollständig. Das spricht eher für eine Begrenzung oder niedrige Priorität der Diagnoseantworten dieses Routers als für 40 Prozent Verlust beim Weiterleiten deiner Nutzdaten. Ein Router kann fleißig Pakete transportieren und trotzdem wenig Lust auf Ping haben.

Verdächtiger wird es, wenn Verlust ab einer Stelle bei mehreren nachfolgenden Hops bis zum Ziel sichtbar bleibt. Dann lohnt sich eine längere Gegenprobe. Das Muster ist ein Hinweis, aber kein Beweis für einen bestimmten defekten Router: Hin- und Rückwege können verschieden sein, und auch das Ziel kann Diagnoseantworten begrenzen.

Was bedeuten ??? und hohe Antwortzeiten?

??? bedeutet, dass MTR an dieser Stelle keine passende Antwort erhält. Firewalls oder Router können solche Antworten unterdrücken. Wenn danach weitere Hops und das Ziel antworten, ist die Verbindung offensichtlich nicht an dieser Zeile zu Ende.

Auch eine hohe Antwortzeit an nur einem Zwischenrouter ist noch kein Nachweis einer langsamen Weiterleitung. Bleiben spätere Hops schnell, arbeitet vermutlich vor allem dessen Antwort auf die Messung langsam. Steigen die Werte dagegen dauerhaft bis zum Ziel, solltest du den Zeitpunkt, die Auslastung und Vergleichsmessungen genauer betrachten.

📝 Einen Report erstellen und speichern

Für den Support ist eine feste Ausgabe praktischer als eine Anzeige, die ständig weiterläuft. Ich würde mit 100 Messzyklen und einer Sekunde Abstand starten:

mtr -4 -r -w -b -c 100 -i 1 www.cleveradmin.de

-r aktiviert den Report-Modus, -w die breite Ausgabe und -b zeigt Hostnamen mit IP-Adressen. -c 100 begrenzt die Messung. Plane ungefähr zwei Minuten ein: Routenermittlung und das Warten auf ausstehende Antworten können zusätzlich Zeit benötigen.

Mit tee bleibt der fertige Report im Terminal sichtbar und landet gleichzeitig in einer Datei:

mtr -4 -r -w -b -c 100 -i 1 www.cleveradmin.de | tee "mtr-$(date +%Y%m%d-%H%M%S).txt"

Notiere dazu den Zeitpunkt mit Zeitzone, deinen Anschluss beziehungsweise Messstandort, das konkrete Ziel und das beobachtete Problem. „SSH hängt seit 18:20 Uhr, Messung über LAN ohne VPN“ hilft mehr als „Internet kaputt“. Prüfe vor einer öffentlichen Veröffentlichung außerdem, welche IP-Adressen und Hostnamen du damit preisgibst.

🔀 ICMP, TCP und UDP vergleichen

Standardmäßig arbeitet MTR mit ICMP. Das ist für einen Einstieg gut geeignet. Wenn ein Ziel nicht auf ICMP antwortet, aber seine Webseite erreichbar ist, kann eine TCP-Messung zusätzliche Informationen liefern.

TCP zum HTTPS-Port 443

sudo mtr -4 -r -w -n -T -P 443 -c 100 www.cleveradmin.de

-T nutzt TCP-SYN-Pakete, -P 443 setzt den Zielport. So prüfst du den Weg mit einem Protokoll und Port, die zu einer HTTPS-Verbindung passen. Zwischenrouter werden weiterhin über ihre ICMP-Fehlermeldungen sichtbar.

Ein TCP-MTR ist kein HTTPS-Funktionstest. Es prüft weder das Zertifikat noch die Anmeldung oder die Ladezeit einer Webseite. Für die Anwendungsebene kannst du anschließend beispielsweise curl -I https://www.cleveradmin.de ergänzen. Auch ein antwortender geschlossener TCP-Port kann eine Diagnoseantwort liefern; eine sichtbare Zielzeile bestätigt nicht allein einen funktionierenden Webdienst.

UDP-Messung

sudo mtr -4 -r -w -n -u -P 33434 -c 100 1.1.1.1

-u verwendet UDP. Der hier gesetzte Port ist ein Beispiel für Diagnosepakete, kein DNS-Test. UDP-Programme reagieren nicht zwangsläufig auf beliebige Daten. Fehlende Antworten vom Ziel können deshalb auch durch Filter oder die Art des Dienstes entstehen.

🌐 IPv4 und IPv6 getrennt prüfen

mtr -4 -r -w -n -c 100 www.cleveradmin.de
mtr -6 -r -w -n -c 100 www.cleveradmin.de

IPv4 und IPv6 können völlig unterschiedliche Wege nehmen. Funktioniert eine Webseite nur manchmal schlecht, lohnt sich dieser Vergleich. Voraussetzung für die zweite Messung sind eine funktionierende IPv6-Verbindung und eine IPv6-Adresse des Ziels. Ohne beides ist eine Fehlermeldung kein Beweis für eine Störung beim Anbieter.

Wenn ein Name mehrere Adressen besitzt, notiere die tatsächlich gemessene Zieladresse. Für einen sauberen Vorher-nachher-Vergleich kannst du dieselbe IP direkt verwenden. Bei CDNs und Anycast kann selbst dieselbe IP je nach Standort oder Zeitpunkt an einem anderen Server enden.

🛠️ Mehr Möglichkeiten für den Alltag

JSON für die weitere Auswertung

mtr -4 -r -n -j -c 100 1.1.1.1 > mtr-report.json

Die JSON-Ausgabe lässt sich in Skripten weiterverarbeiten. Je nach Paket-Build stehen auch XML und CSV zur Verfügung. Schau mit mtr --help nach, was deine installierte Version unterstützt. Beim CSV-Format verwendet MTR traditionell Semikolons als Trennzeichen.

Ein bestimmtes Netzwerkinterface verwenden

sudo mtr -4 -I eth0 -r -w -n -c 100 1.1.1.1

Ersetze eth0 durch den tatsächlichen Namen aus ip -br address. Das ist bei Rechnern mit mehreren Interfaces nützlich. Eine Bindung an ein Interface zaubert allerdings keine fehlende Route herbei. Für den Vergleich zwischen WLAN und LAN solltest du zusätzlich prüfen, welcher Weg zum Ziel tatsächlich eingerichtet ist.

Netzbetreiber und Paketgröße untersuchen

mtr -4 -z -r -w -c 100 1.1.1.1
mtr -4 -s 1200 -r -w -n -c 100 1.1.1.1

-z ergänzt, soweit auflösbar, die Nummer des autonomen Systems. Das kann helfen, die beteiligten Netzbetreiber einzuordnen. -s verändert bei ICMP die Paketgröße. Unterschiedliche Ergebnisse bei verschiedenen Größen können Anlass für weitere Untersuchungen sein; einen eindeutigen MTU-Test ersetzt das nicht. Im TCP-Modus wird diese Größenoption ignoriert.

🧪 Praktisch geprüft auf Ubuntu 24.04

Für diesen Beitrag habe ich die vorhandene Version MTR 0.95 auf Ubuntu 24.04 verwendet und kurze IPv4-Messungen mit ICMP, TCP und UDP sowie die JSON-Ausgabe geprüft. Die kurzen Läufe dienen der Funktionsprüfung der Befehle. Für die eigentliche Fehlersuche sind die längeren Reports oben sinnvoller.

Besonders anschaulich war der ICMP-Lauf mit zehn Messzyklen zu 1.1.1.1. Hier ein gekürzter Ausschnitt der echten Ausgabe vom 6. Oktober 2026; die ursprünglichen Hop-Nummern bleiben erhalten:

HOST: dev02-ubuntu  Loss%   Snt   Last   Avg  Best  Wrst StDev
  5.|-- 10.81.85.22   30.0%    10   49.0  34.0  27.2  49.0   7.7
  6.|-- 195.71.243.34  0.0%    10   29.0  35.0  29.0  52.9   7.7
 10.|-- 1.1.1.1        0.0%    10   32.1  33.3  28.2  37.5   2.7

Hop 5 zeigte 30 Prozent fehlende Antworten, der unmittelbar folgende Hop und das Ziel dagegen keinen Verlust. Aus diesem Lauf lässt sich deshalb kein 30-prozentiger Verlust deiner Nutzdaten an Hop 5 ableiten. Genau diese Unterscheidung erspart dir manche unnötige Fehlersuche.

🧯 So gehst du bei einer Störung vor

• Miss zuerst vom betroffenen Rechner aus. Halte fest, ob WLAN, LAN oder VPN verwendet wird.
• Prüfe den lokalen Router und anschließend das betroffene Ziel. Ein Vergleichsziel hilft, ein allgemeines Anschlussproblem von einem einzelnen Zielproblem zu trennen.
• Erstelle einen Report mit mindestens 100 Zyklen. Wiederhole die Messung während der Störung und später zum Vergleich.
• Vergleiche ICMP mit TCP auf dem relevanten Port sowie IPv4 mit IPv6, sofern verfügbar.
• Betrachte Verlust und Antwortzeiten bis zum Ziel. Einzelne auffällige Zwischenstationen reichen für eine Schuldzuweisung nicht aus.
• Wenn du beide Enden kontrollierst, miss auch in Gegenrichtung. Das ist eine eigene Messung und kein nachträglicher Blick auf den Rückweg des ersten Reports.

MTR misst keine verfügbare Bandbreite. Für Durchsatztests brauchst du ein anderes Werkzeug, etwa iperf3 mit einem passenden Gegenstück. Es überprüft auch keine DNS-Antworten, TLS-Zertifikate oder Anwendungsfehler. Es zeigt dir Hinweise zum Netzwerkweg und zu den Antworten auf deine Messpakete. Das ist viel wert, wenn du die Grenzen im Blick behältst.

✅ Mein Fazit

MTR gehört für mich in die Werkzeugkiste zur Netzwerkdiagnose: schnell gestartet, ohne großen Aufbau nutzbar und deutlich aussagekräftiger als ein einzelner Ping. Der eigentliche Nutzen entsteht aber beim Lesen der Ausgabe.

Wenn du nur einen Befehl mitnehmen möchtest, nimm mtr -4 -r -w -n -c 100 1.1.1.1 und ersetze das Ziel durch den tatsächlich betroffenen Host. Danach schaust du zuerst auf die letzte Zeile und erst dann auf die Zwischenstationen. Ein Router mit schlechter Laune ist noch kein kaputtes Internet!

🔗 Quellen und weiterführende Informationen

• Offizielles MTR-Repository: Projekt, Quellcode und Hinweise zur Interpretation.
• Ubuntu-Handbuch zu MTR 0.95 und Debian-Handbuch: Optionen und Ausgabe.
• Ubuntu-Paket mtr-tiny und Fedora-Paket mtr.
• Homebrew-Formel für MTR: Installation unter macOS.

👥 Techniverse Community

Lust auf Austausch rund um Matrix, Selfhosting und andere smarte IT-Lösungen?
In der Techniverse Community triffst du Gleichgesinnte, kannst Fragen stellen oder einfach nerdigen Talk genießen. 🚀

👉 Jetzt der Gruppe auf Matrix beitreten
~ Direkte Raumadresse: #community:techniverse.net

👉 Für lockere Gespräche abseits der Kernthemen komm in den Talkraum
~ Direkte Raumadresse: #talk:techniverse.net

Wir freuen uns, wenn du dabei bist!