Traceroute vs. Ping: Was jedes Tool zeigt, mit Beispielen

Ping und Traceroute senden beide Pakete und messen die Zeit bis zur Antwort, beantworten aber unterschiedliche Fragen. Ping sagt Ihnen, ob ein Host antwortet und wie hoch die Round-Trip-Zeit (RTT) ist. Traceroute sagt Ihnen, welche Router zwischen Ihnen und diesem Host liegen und wo unterwegs die Zeit vergeht. Im Folgenden laufen beide Tools vom selben Server gegen denselben Host, im Abstand von einer Minute; danach hilft eine Tabelle bei der Entscheidung, welches Sie zuerst starten.

Der Unterschied in einer Tabelle

	Ping	Traceroute
Beantwortete Frage	Antwortet der Host, und wie schnell?	Welche Router liegen auf dem Pfad, und wo baut sich die Verzögerung auf?
Was gesendet wird	ICMP Echo Request	Pakete mit steigender TTL: UDP unter Linux und macOS, ICMP unter Windows (tracert)
Wer antwortet	Nur das Ziel	Jeder Router unterwegs (ICMP Time Exceeded), dann das Ziel
Ausgabe	Eine Zeit pro Paket, dann Verlust und min/avg/max	Eine Zeile pro Hop, drei Zeiten pro Zeile
Laufdauer	Unter Linux und macOS bis zum Abbruch, unter Windows 4 Pakete	Einige Sekunden bis eine Minute
Blinder Fleck	Sagt nichts darüber, wo eine Verzögerung entsteht	Eine Momentaufnahme; mittlere Hops können langsam oder verlustbehaftet wirken, ohne es zu sein

Ping: eine Zahl, sauber gemessen

Von unserem Server in Falkenstein, Deutschland, zu einem Vultr-Testhost in New Jersey, am 7. Oktober 2026 um 12:27 UTC:

$ ping -c 10 nj-us-ping.vultr.com
PING nj-us-ping.vultr.com (108.61.149.182) 56(84) bytes of data.
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=1 ttl=50 time=86.1 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=2 ttl=50 time=86.1 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=3 ttl=50 time=86.4 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=4 ttl=50 time=86.2 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=5 ttl=50 time=86.3 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=6 ttl=50 time=86.1 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=7 ttl=50 time=86.3 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=8 ttl=50 time=86.2 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=9 ttl=50 time=86.1 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=10 ttl=50 time=86.2 ms

--- nj-us-ping.vultr.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9410ms
rtt min/avg/max/mdev = 86.113/86.212/86.360/0.081 ms

• time= ist die RTT jedes Pakets: etwa 86 ms, hin und zurück.
• 0% packet loss und mdev 0,081 ms (die Streuung der Zeiten): Der Pfad ist stabil. Ein gesunder Pfad innerhalb eines Kontinents zeigt oft einen mdev-Wert unter 1 ms; Werte von einigen zehn Millisekunden deuten auf Überlastung oder WLAN hin.
• ttl=50 ist das, was bei der Ankunft von der Time-to-Live der Antwort übrig war. Hat der Host bei 64 begonnen, dem üblichen Standardwert unter Linux, dann hat die Antwort auf dem Rückweg 14 Router passiert, drei mehr als die 11 Hops, die Traceroute auf dem Hinweg zählt (siehe unten). Der Rückweg ist oft eine andere Route, und kein Tool, das Sie auf Ihrer Seite starten, kann sie zeigen.

Was Ping nicht sagen kann, ist, warum es 86 ms sind. Das ist die Aufgabe von Traceroute.

Traceroute: woher die 86 ms kommen

Derselbe Host, vom selben Server, eine Minute später, mit den standardmäßigen UDP-Testpaketen:

$ traceroute nj-us-ping.vultr.com
traceroute to nj-us-ping.vultr.com (108.61.149.182), 30 hops max, 60 byte packets
 1  * * *
 2  ex9k1.dc11.fsn1.hetzner.com (213.133.117.208)  0.517 ms  0.318 ms  0.291 ms
 3  core23.fsn1.hetzner.com (213.133.126.23)  3.999 ms  3.920 ms  3.834 ms
 4  juniper4.dc2.nbg1.hetzner.com (213.239.252.233)  2.806 ms juniper5.dc2.nbg1.hetzner.com (213.239.252.245)  2.854 ms juniper5.dc2.nbg1.hetzner.com (213.239.254.218)  2.959 ms
 5  ae12-498.nbg40.core-backbone.com (5.56.20.253)  2.763 ms  2.687 ms  2.666 ms
 6  ae7-2093.nyk10.core-backbone.com (81.95.9.195)  86.557 ms  86.413 ms  86.437 ms
 7  * * *
 8  * * *
 9  * * *
10  66.55.138.149.vultrusercontent.com (66.55.138.149)  85.763 ms  85.862 ms  85.692 ms
11  * * *
12  * * *
[dieselben * * * in jeder Zeile bis 30]
30  * * *

• Die 86 ms kommen auf einen Schlag, an Hop 6. Hop 5 ist nbg40 in Nürnberg, mit 2,7 ms; Hop 6 ist nyk10 in New York, mit 86,4 ms. Alles davor ist der Weg durch Deutschland, alles danach bleibt auf demselben Niveau: Die Zeit geht auf das Konto des Atlantiks. Das hätte Ihnen Ping nicht sagen können.
• Die Zeiten addieren sich nicht von Hop zu Hop. Hop 3 antwortet in 3,9 ms, der weiter entfernte Hop 4 in 2,8 ms. Jede Zeile ist eine eigene Laufzeitmessung, beantwortet von einem anderen Router, der sich für die Antwort seine eigene Zeit nimmt.
• Stumme Zeilen sind keine Unterbrechungen. Hop 1 und die Hops 7 bis 9 antworten nie, Hop 10 aber schon: Diese Router antworten einfach nicht auf Testpakete.
• Die letzte Zeile kommt nie. Nach Hop 10 folgen bis Hop 30 nur Sternchen, obwohl Ping gezeigt hat, dass der Host einwandfrei antwortet. Dieser Host antwortet nicht auf UDP-Testpakete. Als ICMP gesendet, wie bei Ping, erreicht ihn derselbe Trace:

$ traceroute -I -n -q 1 nj-us-ping.vultr.com
traceroute to nj-us-ping.vultr.com (108.61.149.182), 30 hops max, 60 byte packets
 1  *
 2  213.133.117.208  0.372 ms
 3  213.133.126.22  0.357 ms
 4  213.239.254.238  2.813 ms
 5  81.95.15.5  2.710 ms
 6  81.95.9.195  86.418 ms
 7  *
 8  *
 9  *
10  66.55.138.149  85.749 ms
11  108.61.149.182  85.975 ms

Das ist die häufigste Fehldeutung einer Traceroute-Ausgabe: Ein Trace, der in Sternchen endet, bedeutet nicht, dass der Host ausgefallen ist. Prüfen Sie mit Ping und tracen Sie dann erneut mit einem anderen Protokoll (-I für ICMP oder -T -p 443 für TCP unter Linux, als root).

Welches Tool zuerst?

Symptom	Zuerst	Danach
„Die Website ist nicht erreichbar“	Den Host anpingen, dazu einen Host, der sicher erreichbar ist (1.1.1.1)	Scheitert der Ping, mit Traceroute nachsehen, wo es endet. Viele Hosts blockieren Ping: Testen Sie den Dienst selbst (HTTP- oder Port-Check), bevor Sie Schlüsse ziehen
„Es ist langsam“	30 bis 60 Sekunden pingen: Mittelwert und Streuung	Traceroute oder mtr, um den Hop zu finden, an dem die Zeit springt und hoch bleibt
„Die Verbindung bricht manchmal ab“	Ein langer Ping (ping -c 300) für die Verlustrate	mtr -c 100, um zu sehen, ab welchem Hop der Verlust beginnt
„Liegt es an meinem Netz oder an ihrem?“	Traceroute von Ihrem Rechner	Derselbe Trace von einem anderen Standort, dann vergleichen
Große Übertragungen oder VPN hängen, kleine funktionieren	Ping mit einem Paket voller Größe, das nicht fragmentiert werden darf	Die Größe verringern, bis das Paket durchkommt: Das ist die Pfad-MTU

Der Test mit voller Paketgröße sendet 1.472 Byte Nutzdaten, die mit 28 Byte Headern ein Paket von 1.500 Byte ergeben: ping -M do -s 1472 host unter Linux, ping -D -s 1472 host unter macOS, ping -f -l 1472 host unter Windows.

Optionen, die das Ergebnis verändern

• ping -c 20: nach 20 Paketen aufhören (Windows: -n 20). -i 0.2 sendet alle 0,2 Sekunden ein Paket statt jede Sekunde.
• ping -W: Die Wartezeit auf jede Antwort wird unter Linux in Sekunden und unter macOS in Millisekunden angegeben, eine klassische Falle, wenn ein Skript zwischen beiden Systemen wandert.
• -4 oder -6 unter Linux und Windows: IPv4 oder IPv6 erzwingen (macOS hat dafür die eigenen Befehle ping6 und traceroute6). Ein Host kann über das eine Protokoll schnell und über das andere langsam sein.
• traceroute -n: die Reverse-DNS-Abfragen überspringen, viel schneller, aber Ihnen entgehen die Routernamen, oft der beste Hinweis darauf, wo sich ein Hop befindet.

Wo beide an Grenzen stoßen

• Nur eine Richtung. Beide zeigen den Pfad von dort aus, wo Sie sie starten. Der Rückweg, der sich laut dem TTL-Hinweis oben vom Hinweg unterscheidet, bleibt unsichtbar.
• Router beantworten Testpakete zuletzt. Ein Hop, der langsam oder verlustbehaftet aussieht, zählt nur, wenn jeder Hop danach bis zum Ziel genauso aussieht. Echte Beispiele dazu finden Sie in Netzwerkengpässe mit Traceroute erkennen.
• Ein einziger Zeitpunkt. Ein einzelner Durchlauf kann ein sporadisches Problem verpassen. mtr vereint beide Tools und wiederholt die Messung an jedem Hop.

Mit Ping und Traceroute von TraceMapper sehen Sie denselben Vergleich ohne Terminal: Beide laufen von unseren Servern und von mehr als 30 Standorten aus, jeder Hop auf einer Karte. Die Befehle für jedes System finden Sie unter Traceroute-Befehle für Windows, Mac und Linux.