> Die vollständige Liste der Artikel steht in [llms.txt](https://docs.f3cloud.com/llms.txt). Jede Seite gibt es auch als Markdown, dazu einfach .md an die Adresse anhängen. Diese Seite als Markdown: [https://docs.f3cloud.com/de/vps/network-troubleshooting-traceroute.md](https://docs.f3cloud.com/de/vps/network-troubleshooting-traceroute.md).

# Netzwerkdiagnose – Traceroute und Verbindungsqualität prüfen (WinMTR, MTR, Speedtest)

So prüfen Sie die Qualität der Verbindung zu Ihrem Server. Speedtest auf dem VPS, Traceroute mit WinMTR vom PC, MTR in Rückrichtung, Auswertung der Ergebnisse und was Sie an den Support senden.

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.

> **Wichtig.**
>
> **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:

```bash
wget -qO- bench.sh | bash
```

Speichern Sie danach einen Screenshot des Ergebnisses und hängen Sie ihn an das Ticket an. \
**Die Textausgabe müssen Sie nicht senden.**

> **Wichtig.**
>
> 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)

#### Windows (WinMTR)

1. **Schalten Sie das VPN aus.**
2. Laden Sie **WinMTR** von der offiziellen Website `https://winmtr.net/` herunter.
3. Starten Sie WinMTR und geben Sie im Feld **Host** die **IP-Adresse Ihres Servers** ein.
4. Klicken Sie auf **Start** und warten Sie 100–200 Pakete ab (1–3 Minuten).
5. Klicken Sie auf **Stop**.
6. **Senden Sie einen Screenshot des Ergebnisses im Ticket.**

> **Achtung.**
>
> 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“).

#### macOS / Linux (Alternative)

Wenn Sie gerade keinen Windows-Rechner zur Hand haben, können Sie eine entsprechende Traceroute auch mit dem Tool **mtr** durchführen:

**macOS (Homebrew):**

```bash
brew install mtr
sudo mtr -rw <Server-IP>
```

**Linux (Desktop):**

```bash
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:

```bash
sudo mtr -rw <Server-IP> | tee mtr-to-server.txt
```

Hängen Sie einen Screenshot an das Ticket an.

> **Achtung.**
>
> 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:

```bash
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:

```bash
mtr -rw <PC-IP> | tee mtr-to-client.txt
```

> **Achtung.**
>
> 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).

> **Achtung.**
>
> 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:

1. Die IP-Adresse Ihres Servers sowie Ihren Standort und Provider (auf Ihrer Seite).
2. Datum und ungefähre Uhrzeit, zu der das Problem auftrat (mit Angabe der Zeitzone).
3. Das Speedtest-Ergebnis vom Server – als Screenshot.
4. Das WinMTR-Ergebnis (PC → Server) – als Screenshot.
5. Das MTR-Ergebnis (Server → PC) – als Screenshot.
6. Weitere Beobachtungen (falls vorhanden), etwa „Einbrüche in Spielen“, „Abbrüche bei Streams/Videoanrufen“, Abhängigkeit von der Tageszeit usw.

***

### Häufige Fragen (FAQ)

<details>

<summary>WinMTR zeigt 100 % Verlust an einem der Zwischen-Hops – ist das schlecht?</summary>

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:

1. 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.
2. 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.

</details>

<details>

<summary>Der Befehl mtr wird auf dem Server nicht gefunden</summary>

Installieren Sie mtr mit einem einzigen Befehl für Ihr Betriebssystem.

Debian/Ubuntu:

```bash
sudo apt update && sudo apt install -y mtr
```

CentOS Stream/Rocky Linux/AlmaLinux:

```bash
sudo dnf install -y mtr
```

</details>

<details>

<summary>Wie lange sollte die Traceroute laufen?</summary>

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.

</details>

***

### 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.