Network diagnostics: traceroute and connection quality check (WinMTR, MTR, Speedtest)

This guide will help you quickly figure out where exactly milliseconds and packets are “getting lost” – on the user's provider side, in the backbone, in the data centre or right on the server itself.

DANGER

Before you start: disable VPN/proxy and any network “accelerators” on the computer and the server.
Run the tests under a stable load – without active downloads/streams.

---

Step 1. Speed test on the server (Speedtest)

Connect to the server via SSH and run:

wget -qO- bench.sh | bash

Once it finishes, save a screenshot of the result and attach it to the ticket.
You don't need to send the text output.

DANGER

Why this matters: the command runs an automatic test that measures the network connection speed and shows the server's basic specifications – the results let you assess the link quality and identify possible limitations.

---

Step 2. Traceroute from your PC to the server (WinMTR)

1. Disable the VPN.
2. Download WinMTR from the official website: https://winmtr.net/.
3. Launch WinMTR and, in the Host field, enter your server's IP.
4. Click Start and wait for 100–200 packets (1–3 minutes).
5. Click Stop.
6. Send a screenshot of the result in the ticket.

WARNING

Tip: if you need to “catch” rare latency peaks – increase the duration to 5–10 minutes.

Some routers/nodes may not respond to ICMP probes – a single “loss” on an intermediate hop does not always mean a problem. The final hops and the “inheritance” of losses further down the route matter more (see the “How to read the results” section).

---

Step 3. Reverse traceroute from the server to your PC (MTR)

On the server, run:

sudo apt update && sudo apt install -y mtr && mtr -rw <IP-address_of_your_PC>

In place of <IP-address_of_your_PC>, enter your computer's real IP (not a VPN one). It's easy to find out: go to https://2ip.ru/.

Take a screenshot of the results and attach it to your request:

mtr -rw <PC_IP> | tee mtr-to-client.txt

WARNING

The pair “forward WinMTR” + “reverse MTR” lets you see the problem from both sides of the route and localise the segment with losses/jitter faster.

---

How to read the results in brief

• Loss% (losses): it's important to look not at a single hop but at the “inheritance” of losses. If losses appear on hop №n and persist on all subsequent hops – the problem, as a rule, starts at/after №n. If losses are visible on one hop but there are none on the next hop – most often the intermediate node is limiting ICMP (rate limit) responses, and this does not mean real traffic loss.
• Latency (Best/Avg/Wrst/Last): assess the values on the final hops and the overall trend. A steady rise in latency and spikes closer to the end of the route usually point to congestion on the route nearer the target segment or on the “last mile”.
• Jitter (variation): a large gap between Best and Wrst on the last hops – a sign of an unstable connection.

Explanation of terms:

hop – an intermediate node on the path from your device to the server;

ICMP – service “diagnostic” network responses (used in ping/traceroute);

rate limit – a limit on the response rate (a node may not respond to every request);

trend – the general pattern of change in the metrics (rising/falling/jumping around);

spikes – short-lived sharp increases in latency;

last mile – the part of the network closest to the end user (often affected by the provider/local network).

WARNING

If you are not sure how to interpret the results, just attach the Speedtest, WinMTR and MTR results – we will analyse them and get back to you with conclusions and recommendations.

---

What to send to F3 Cloud support

Put together a single request (a ticket or an email) and attach:

1. Your server's IP address, as well as your location and provider (on the client side).
2. The date and approximate time when the problem was observed (including the time zone).
3. The Speedtest result from the server – a screenshot.
4. The WinMTR result (PC → server) – a screenshot.
5. The MTR result (server → PC) – a screenshot.
6. Additional observations (if any): “lag in games”, “stream/video call dropouts”, dependence on the time of day, etc.

---

Frequently asked questions (FAQ)

WinMTR shows 100% loss on one of the intermediate hops – is that bad?

Not necessarily. Many intermediate routers limit or ignore responses to diagnostic requests (ICMP), which is why WinMTR may show “losses” on just that one hop.

Rely on two signs:

1. If there are no losses on the following hops (and especially on the last, target one) – this is, as a rule, a quirk of how the router responds and is not a problem.
2. If losses and/or rising latency persist on subsequent hops and reach the end of the route – this is already a sign of a real problem on the route.

The mtr command is not found on the server

Install mtr with a single command for your OS.

Debian/Ubuntu:

sudo apt update && sudo apt install -y mtr

CentOS Stream/Rocky Linux/AlmaLinux:

sudo dnf install -y mtr

How long should I keep the traceroute running?

Usually 1–3 minutes is enough to see a stable picture (roughly 100–200 packets). If the problem occurs “intermittently” (that is, it does not always appear) – increase the test duration to 5–10 minutes and attach a screenshot of the result.

---

Good practices

• Run tests under the same conditions: the same network, the same device and, where possible, a wired connection. This matters because Wi-Fi, different devices and different access points can give different ping, losses and speed – the results become incomparable.
• Don't run Speedtest and the traceroute (WinMTR/MTR) at the same time – run them one after the other. Parallel tests put extra load on the link and can artificially worsen the metrics (the speed gets “cut”, latency grows), which makes the diagnosis inaccurate.
• Run the tests at a moment when the problem is actually happening (for example, “it lags in the evening”, “ping jumps around in the game”). Tests “when everything is fine” often don't capture the cause and don't help the investigation.
• Take screenshots so that the key data is visible: the server IP/address (if displayed), the results table and the final values. It's better not to capture anything extra (personal tabs, notifications, chats) – select only the area with the result.
• If you have several networks or devices (home/office/LTE, different providers, different routers) – send a set of tests for each network separately and state clearly where exactly the test was run (for example: “home Wi-Fi Rostelecom”, “office cable”, “LTE MTS”). This helps to understand whether the problem is tied to a specific network/provider or reproduces everywhere.
• If you use VPN/proxy on the client side – disable them for the duration of the diagnostics or clearly note in the ticket that the tests were run through VPN/proxy. This matters because a VPN changes the route and can add latency, which distorts the results.