Diese Anleitung hilft Ihnen, schnell herauszufinden, wo genau Millisekunden und Pakete „verloren gehen“ – beim Provider des Nutzers, im Backbone, im Rechenzentrum oder schon auf dem Server selbst.
DANGER
Vor dem Start schalten Sie VPN/Proxy und alle Netzwerk-„Beschleuniger“ auf dem Computer und auf dem Server aus.
Führen Sie die Tests bei gleichbleibender Last durch – ohne laufende Downloads oder Streams.
Schritt 1. Geschwindigkeitstest auf dem Server (Speedtest)
Verbinden Sie sich per SSH mit dem Server und führen Sie Folgendes aus:
wget -qO- bench.sh | bashSpeichern Sie danach einen Screenshot des Ergebnisses und hängen Sie ihn an das Ticket an.
Die Textausgabe müssen Sie nicht senden.
DANGER
Das ist wichtig, denn der Befehl startet einen automatischen Test, der die Geschwindigkeit der Netzwerkverbindung misst und die grundlegenden Eigenschaften des Servers anzeigt. Anhand der Ergebnisse lassen sich die Qualität des Kanals beurteilen und mögliche Einschränkungen erkennen.
Schritt 2. Traceroute von Ihrem PC zum Server (WinMTR)
- Schalten Sie das VPN aus.
- Laden Sie WinMTR von der offiziellen Website
https://winmtr.net/herunter. - Starten Sie WinMTR und geben Sie im Feld Host die IP-Adresse Ihres Servers ein.
- Klicken Sie auf Start und warten Sie 100–200 Pakete ab (1–3 Minuten).
- Klicken Sie auf Stop.
- Senden Sie einen Screenshot des Ergebnisses im Ticket.
WARNING
Um seltene Latenzspitzen „einzufangen“, verlängern Sie die Messung am besten auf 5–10 Minuten.
Manche Router/Knoten antworten nicht auf ICMP-Anfragen – ein einzelner „Verlust“ an einem Zwischen-Hop bedeutet nicht immer ein Problem. Wichtiger sind die letzten Hops und die „Vererbung“ der Verluste weiter entlang der Route (siehe Abschnitt „So lesen Sie die Ergebnisse“).
Wenn Sie gerade keinen Windows-Rechner zur Hand haben, können Sie eine entsprechende Traceroute auch mit dem Tool mtr durchführen:
macOS (Homebrew):
brew install mtr
sudo mtr -rw <Server-IP>Linux (Desktop):
sudo apt update && sudo apt install -y mtr
sudo mtr -rw <Server-IP>Warten Sie 100–200 Pakete ab und speichern Sie die Ausgabe in einer Datei:
sudo mtr -rw <Server-IP> | tee mtr-to-server.txtHängen Sie einen Screenshot an das Ticket an.
WARNING
Manche Router/Knoten antworten nicht auf ICMP-Anfragen – ein einzelner „Verlust“ an einem Zwischen-Hop bedeutet nicht immer ein Problem. Wichtiger sind die letzten Hops und die „Vererbung“ der Verluste weiter entlang der Route (siehe Abschnitt „So lesen Sie die Ergebnisse“).
Schritt 3. Traceroute in Rückrichtung vom Server zu Ihrem PC (MTR)
Führen Sie auf dem Server Folgendes aus:
sudo apt update && sudo apt install -y mtr && mtr -rw <IP-Adresse_Ihres_PCs>Setzen Sie statt <IP-Adresse_Ihres_PCs> die echte IP-Adresse Ihres Computers ein (nicht die des VPN). Am einfachsten finden Sie sie auf https://2ip.ru/ heraus.
Machen Sie einen Screenshot der Ergebnisse und hängen Sie ihn an Ihre Anfrage an:
mtr -rw <PC-IP> | tee mtr-to-client.txtWARNING
Das Paar „WinMTR in Hinrichtung“ + „MTR in Rückrichtung“ zeigt das Problem von beiden Seiten der Route, so lässt sich der Abschnitt mit Verlusten/Jitter schneller eingrenzen.
So lesen Sie die Ergebnisse – in Kürze
- Loss% (Verluste) – wichtig ist nicht ein einzelner Hop, sondern die „Vererbung“ der Verluste. Treten Verluste an Hop Nr. n auf und bleiben an allen folgenden Hops bestehen, beginnt das Problem in der Regel bei oder nach Nr. n. Sind Verluste an einem Hop zu sehen, am nächsten Hop aber nicht mehr, begrenzt meist der Zwischenknoten die Antworten auf ICMP (rate limit), und das bedeutet keinen echten Verlust von Datenverkehr.
- Latency (Best/Avg/Wrst/Last) – bewerten Sie die Werte an den letzten Hops und den allgemeinen Trend. Ein stetiger Anstieg der Latenz und Spitzen gegen Ende der Route deuten meist auf eine Überlastung nahe dem Zielsegment oder auf der „letzten Meile“ hin.
- Jitter (Schwankung) – ein großer Abstand zwischen Best und Wrst an den letzten Hops ist ein Zeichen für eine instabile Verbindung.
Begriffe kurz erklärt
Hop – ein Zwischenknoten auf dem Weg von Ihrem Gerät zum Server;
ICMP – „diagnostische“ Dienstantworten des Netzwerks (werden von ping/traceroute genutzt);
rate limit – Begrenzung der Antworthäufigkeit (ein Knoten antwortet eventuell nicht auf alle Anfragen);
Trend – der allgemeine Verlauf der Werte (steigen/fallen/springen);
Spitzen – kurzzeitige, starke Anstiege der Latenz;
letzte Meile – der Netzabschnitt, der dem Endnutzer am nächsten liegt (oft beeinflusst durch Provider/lokales Netz).
WARNING
Wenn Sie sich bei der Auswertung nicht sicher sind, hängen Sie einfach die Ergebnisse von Speedtest, WinMTR und MTR an. Wir analysieren sie und melden uns mit Schlussfolgerungen und Empfehlungen bei Ihnen.
Was Sie an den Support von F3 Cloud senden sollten
Stellen Sie eine einzige Anfrage zusammen (Ticket oder E-Mail) und fügen Sie Folgendes bei:
- Die IP-Adresse Ihres Servers sowie Ihren Standort und Provider (auf Ihrer Seite).
- Datum und ungefähre Uhrzeit, zu der das Problem auftrat (mit Angabe der Zeitzone).
- Das Speedtest-Ergebnis vom Server – als Screenshot.
- Das WinMTR-Ergebnis (PC → Server) – als Screenshot.
- Das MTR-Ergebnis (Server → PC) – als Screenshot.
- Weitere Beobachtungen (falls vorhanden), etwa „Einbrüche in Spielen“, „Abbrüche bei Streams/Videoanrufen“, Abhängigkeit von der Tageszeit usw.
Häufige Fragen (FAQ)
WinMTR zeigt 100 % Verlust an einem der Zwischen-Hops – ist das schlecht?
Nicht unbedingt. Viele Zwischenrouter begrenzen oder ignorieren Antworten auf Diagnoseanfragen (ICMP), deshalb kann WinMTR genau an einem Hop „Verluste“ anzeigen.
Achten Sie auf zwei Merkmale:
- Gibt es an den folgenden Hops (und besonders am letzten, dem Ziel) keine Verluste, ist das in der Regel eine Eigenheit des Routers beim Antworten und kein Problem.
- Bleiben Verluste und/oder steigende Latenz an den folgenden Hops bestehen und reichen bis zum Ende der Route, ist das bereits ein Zeichen für ein echtes Problem auf der Route.
Der Befehl mtr wird auf dem Server nicht gefunden
Installieren Sie mtr mit einem einzigen Befehl für Ihr Betriebssystem.
Debian/Ubuntu:
sudo apt update && sudo apt install -y mtrCentOS Stream/Rocky Linux/AlmaLinux:
sudo dnf install -y mtrWie lange sollte die Traceroute laufen?
Meist reichen 1–3 Minuten für ein stabiles Bild (etwa 100–200 Pakete). Tritt das Problem nur sporadisch auf (also nicht immer), verlängern Sie den Test auf 5–10 Minuten und hängen Sie einen Screenshot des Ergebnisses an.
Bewährte Vorgehensweisen
- Testen Sie unter gleichen Bedingungen – dasselbe Netz, dasselbe Gerät und nach Möglichkeit eine Kabelverbindung. Das ist wichtig, weil WLAN, verschiedene Geräte und verschiedene Zugangspunkte unterschiedliche Pings, Verluste und Geschwindigkeiten liefern können und die Ergebnisse dann nicht vergleichbar sind.
- Starten Sie Speedtest und Traceroute (WinMTR/MTR) nicht gleichzeitig, sondern nacheinander. Parallele Tests belasten den Kanal zusätzlich und können die Werte künstlich verschlechtern (die Geschwindigkeit wird „gedrosselt“, die Latenz steigt), sodass die Diagnose falsch ausfällt.
- Testen Sie dann, wenn das Problem tatsächlich auftritt (zum Beispiel „abends gibt es Einbrüche“, „im Spiel springt der Ping“). Tests, „wenn alles normal ist“, erfassen die Ursache oft nicht und helfen bei der Untersuchung nicht weiter.
- Machen Sie Screenshots so, dass die wichtigsten Daten sichtbar sind – IP/Adresse des Servers (falls angezeigt), die Ergebnistabelle und die Endwerte. Überflüssiges (private Tabs, Benachrichtigungen, Chats) nehmen Sie besser nicht mit auf, wählen Sie nur den Bereich mit dem Ergebnis aus.
- Wenn Sie mehrere Netze oder Geräte haben (Zuhause/Büro/LTE, verschiedene Provider, verschiedene Router), senden Sie die Tests für jedes Netz getrennt und geben Sie genau an, wo der Test gemacht wurde (zum Beispiel „WLAN zu Hause, Telekom“, „Büro, Kabel“, „LTE Vodafone“). So lässt sich erkennen, ob das Problem an einem bestimmten Netz/Provider liegt oder überall auftritt.
- Wenn Sie auf Ihrer Seite VPN/Proxy nutzen, schalten Sie diese für die Dauer der Diagnose aus oder vermerken Sie im Ticket ausdrücklich, dass die Tests über VPN/Proxy liefen. Das ist wichtig, weil ein VPN die Route ändert und zusätzliche Latenz verursachen kann, was die Ergebnisse verfälscht.