Netzwerkengpässe mit Traceroute erkennen

Ein Netzwerkengpass ist die Stelle auf einem Pfad, an der Verzögerung oder Verlust beginnen und nicht mehr verschwinden. Traceroute und mtr können ihn finden, doch das meiste, was sie zeigen, ist Rauschen: Router, die Testpakete langsam beantworten, verwerfen oder ganz schweigen, während sie echten Verkehr einwandfrei weiterleiten. Anhand echter Traces von unseren Servern vom 7. Oktober 2026 zeigt dieser Leitfaden die Regel, die beides voneinander trennt, und was zu tun ist, wenn Sie einen echten Engpass gefunden haben.

Die Regel: Es muss bis zum Ziel anhalten

Jede Zeile in einem Trace ist eine eigene Messung der Round-Trip-Zeit (RTT), beantwortet von einem anderen Router. Router leiten Verkehr in Hardware weiter, beantworten Testpakete aber in Software, mit niedriger Priorität, und die meisten begrenzen, wie viele Antworten sie pro Sekunde senden. Ein Hop, der langsam oder verlustbehaftet aussieht, zählt also nur, wenn jeder Hop danach bis zum Ziel genauso aussieht. TraceMapper wendet dieselbe Regel an, wenn es einen Trace bewertet: Ein Anstieg zählt nur, wenn er bis zum Ziel anhält.

Echter Trace 1: 82 % „Verlust“, der keiner ist

Von unserem Server in Falkenstein, Deutschland, zu einem Vultr-Testhost in Singapur (mtr -rwz -c 60, 60 Testpakete pro Hop):

  5. AS1299   hbg-b2-link.ip.twelve99.net                      0.0%    60   11.9  11.7  11.3  12.1   0.2
  6. AS1299   hbg-bb3-link.ip.twelve99.net                    53.3%    60   25.0  25.0  24.7  25.3   0.2
  7. AS1299   ffm-bb1-link.ip.twelve99.net                     0.0%    60   30.2  30.1  29.8  30.5   0.2
  8. AS1299   prs-bb1-link.ip.twelve99.net                     0.0%    60   38.6  38.1  37.7  38.6   0.2
  9. AS1299   mei-b5-link.ip.twelve99.net                      0.0%    60   32.3  32.3  32.0  32.7   0.2
 10. AS1299   sng-b6-link.ip.twelve99.net                      0.0%    60  169.7 178.0 169.5 249.9  16.1
 11. AS1299   sng-b7-link.ip.twelve99.net                      0.0%    60  169.0 169.0 168.0 179.5   2.2
 12. AS1299   sng-b5-link.ip.twelve99.net                     81.7%    60  168.0 190.1 167.6 381.6  64.2
 13. AS1299   constantcompany-ic-379815.ip.twelve99-cust.net   0.0%    60  164.7 165.1 164.7 166.3   0.2
 14. AS???    ???                                             100.0    60    0.0   0.0   0.0   0.0   0.0
 15. AS???    ???                                             100.0    60    0.0   0.0   0.0   0.0   0.0
 16. AS20473  45.32.98.222.vultrusercontent.com                0.0%    60  172.5 172.3 172.0 172.5   0.1
 17. AS20473  45.32.100.168                                    0.0%    60  164.7 165.5 164.3 175.0   1.8

• Hop 6 verliert 53 % der Testpakete, Hop 7 keines. Gingen an Hop 6 wirklich Pakete verloren, würde jeder Hop danach den Verlust ebenfalls zeigen. Der Router in Hamburg rationiert einfach seine Antworten.
• Hop 12 verliert 82 %, mit einem schlechtesten Wert von 381,6 ms und einer Standardabweichung von 64,2 ms. Schon der nächste Hop beantwortet alle 60 Testpakete mit einer Streuung von 0,2 ms, und auch das Ziel beantwortet alle. Alarmierende Zahlen, kein Problem.
• Hop 10 zeigt Jitter (schlechtester Wert 249,9 ms, Abweichung 16,1 ms), Hop 11 fast keinen. Wieder sind es die Antworten des Routers, nicht der Pfad.
• Hop 9 antwortet schneller als Hop 8 (32,3 ms gegenüber 38,1 ms). Die Latenz an Zwischen-Hops muss nicht wachsen: Jeder Router nimmt sich für die Antwort seine eigene Zeit.

Jeder Alarm in diesem Trace ist Rauschen. Das Ziel, mit dem Sie sich tatsächlich verbinden, beantwortete 100 % der Testpakete, im Schnitt in 165,5 ms.

Echter Trace 2: ein großer Sprung, der Entfernung ist, kein Engpass

Im selben Trace steigt die Zeit von 32 ms an Hop 9 auf etwa 169 ms an den Hops 10 und 11 und bleibt bis zum Ziel auf diesem Niveau. Der Anstieg hält an, ist also echt. Ein Engpass ist er trotzdem nicht: Die Routernamen wechseln von europäischen Städten (hbg Hamburg, ffm Frankfurt, prs Paris) zu sng, Singapur. Die zusätzlichen 137 ms sind die Seekabel zwischen Europa und Asien; Singapur liegt etwa 10.000 km von Falkenstein entfernt, was in Glasfaser schon vor jedem Routing mindestens 100 ms RTT kostet.

Ein anhaltender Sprung ist nur dann ein Engpass, wenn er größer ist, als die Entfernung erklären kann, oder wenn er mit der Tageszeit schwankt. Vergleichen Sie ihn mit der Untergrenze: Bei etwa 1 ms RTT pro 100 km Glasfaser sind 137 ms für einen interkontinentalen Hop normal, 137 ms zwischen zwei Routern in derselben Stadt nicht.

Echter Trace 3: ein Hop in London, der in 298 ms antwortet

Nach Sydney, vom selben Server, in derselben Minute:

  6. AS24940  core7.lon.hetzner.com                         0.0%    60   22.2  22.1  21.7  22.4   0.1
  7. AS???    ???                                          100.0    60    0.0   0.0   0.0   0.0   0.0
  8. AS4637   i-1001.ulhc-core03.telstraglobal.net          6.7%    60  299.7 298.8 297.6 302.2   0.8
  9. AS4637   i-1045.paix-core02.telstraglobal.net          0.0%    60  297.6 298.7 297.6 299.6   0.6
 10. AS1221   bundle-ether6.stl-core30.sydney.telstra.net   0.0%    60  346.6 345.7 344.6 346.7   0.6
 ...
 16. AS20473  108.61.212.117.vultrusercontent.com           0.0%    60  341.4 341.2 340.9 341.5   0.1

Hop 6 ist Hetzner in London, mit 22 ms. An Hop 8 übernimmt Telstra Global (AS4637). Laut RIPE IPmap, das Router geolokalisiert, steht auch dieser Hop in London, und doch antwortet er in 298 ms. Ein Paket kann nicht 276 ms brauchen, um London zu durchqueren. Tatsächlich reist die Antwort des Routers auf einer anderen, viel längeren Route zurück. Jeder Zeitwert in einem Traceroute ist eine RTT, und der Rückweg bleibt für Sie unsichtbar. Der Sprung, auf den es hier ankommt, sind die 341 ms am Ziel, gegenüber einer Untergrenze von 162 ms für die 16.220 km bis Sydney: Die Route, nicht das Kabel, verdoppelt die Latenz.

Die Muster auf einen Blick

Was Sie sehen	Was es bedeutet	Was zu tun ist
Verlust oder Verzögerung an einem Hop, am nächsten verschwunden	Der Router rationiert oder verzögert seine Antworten	Nichts
Verlust oder Verzögerung, die an Hop N beginnen und bis zum Ziel anhalten	Ein echtes Problem an Hop N oder auf der Leitung direkt davor	Belege sammeln (siehe unten) und dem Netz melden, dem Hop N gehört
Ein großer Sprung, der anhält und zur Entfernung passt	Ausbreitung: ein Ozean oder ein Kontinent	Nichts, oder den Server näher an die Nutzer bringen
Ein großer Sprung, größer als die Entfernung erklären kann, oder eine Stadt weit abseits der direkten Linie	Ein Routing-Umweg	Einen anderen Provider oder Upstream ausprobieren, ein CDN nutzen oder den Umweg melden
Verzögerung, die nur zu Stoßzeiten auftritt, ab einem bestimmten Hop	Überlastung: eine Warteschlange an diesem Hop	Zu verschiedenen Zeiten tracen und mit Zeitstempeln melden
Sternchen bis zum Ende, aber Ping antwortet	Das Ziel ignoriert diesen Pakettyp	Erneut tracen mit -I (ICMP) oder -T -p 443 (TCP)
Sternchen von Hop N bis zum Ende, und kein Ping	Der Pfad endet dort, oder eine Firewall verwirft alles	Den Port des Dienstes testen und von einem anderen Standort aus tracen
Das Problem beginnt innerhalb der Hops 1 bis 3	Ihr eigenes Netz oder Ihre Anschlussleitung	Per Kabel testen, ohne dass sonst etwas läuft, dann Ihren Provider anrufen

Den Hop lokalisieren

• Routernamen enthalten meist ein Stadt- oder Flughafenkürzel: nbg Nürnberg, nyk New York, hbg Hamburg, ffm Frankfurt, prs Paris, lon London, sng Singapur, tky Tokio. Lassen Sie -n weg, um sie zu sehen.
• AS-Nummern (mtr -z) zeigen, zu wessen Netz ein Hop gehört. In den Traces oben: Hetzner AS24940, Arelion AS1299, Telstra Global AS4637, Telstra AS1221, Vultr AS20473. Überlastung zeigt sich oft an der Übergabe zwischen zweien von ihnen; siehe wie ASN und BGP-Routing funktionieren.
• Eine Karte macht Umwege offensichtlich. TraceMapper setzt jeden Hop mit seinem Netz und seiner Latenz auf eine Karte.

Belege, auf die ein Provider reagiert

• Ein Bericht mit mtr -rwzb -c 100, aufgenommen, während das Problem auftritt, und zum Vergleich einer aus einer Zeit, in der alles in Ordnung ist.
• Derselbe Test von einem anderen Standort. Derselbe Host in New Jersey antwortete unserem Server in Falkenstein in 86,4 ms und unserem Server in Gravelines in 71,7 ms, über unterschiedliche Netze: Der Vergleich der Messpunkte zeigt, ob das Problem an Ihrem Anschluss hängt oder am Ziel.
• Wenn möglich beide Richtungen: Bitten Sie die Gegenseite um einen Trace zurück zu Ihnen.
• Datum, Uhrzeit mit Zeitzone, Ihre öffentliche IP-Adresse und das Ziel.

Zu den einzelnen Spalten dieser Berichte siehe wie Sie einen mtr-Bericht lesen, zu den Befehlen für jedes System Traceroute-Befehle für Windows, Mac und Linux.