How to Run an MTR Report When Your VPS Feels Slow (Step-by-Step)
Why an MTR Report Is the First Thing to Run
“My VPS feels slow” is a symptom, not a diagnosis — and the single most useful thing you can do about it is capture an MTR report. MTR (short for “My Traceroute”) combines ping and traceroute into one continuous test, showing you exactly where along the network path packets are being delayed or dropped.
As we covered in why solving VPS network issues requires cooperation, some parts of the path are only visible from your side. An MTR from your location is the piece of evidence that lets our team line your view up against ours and find the problem fast — it’s the exact input the process in how ReadyServer investigates a network performance issue starts from.
This guide shows you how to install MTR, run it correctly, read the results, and share them — on Linux, macOS, and Windows.
What MTR Actually Measures
Unlike a single ping (which only tests the endpoint) or a one-shot traceroute (which lists the hops once), MTR pings every hop along the route repeatedly and keeps a running tally. For each hop it reports:
- Loss% — the percentage of packets that hop failed to return
- Snt — how many packets were sent
- Last / Avg / Best / Wrst — the most recent, average, best, and worst round-trip times (ms)
- StDev — how much the latency is varying (a proxy for jitter)
Because it samples continuously, MTR reveals intermittent loss and jitter that a single ping would miss.
Step 1: Install MTR
Linux
# Debian / Ubuntu
sudo apt update && sudo apt install mtr
# RHEL / CentOS / AlmaLinux / Rocky
sudo dnf install mtrmacOS
brew install mtr
# mtr needs elevated privileges to send raw packets:
sudo mtr example.comWindows
Windows doesn’t ship MTR, but WinMTR is a free graphical equivalent. Download it, type the destination host or IP into the “Host” field, and click Start. Let it run until the “Sent” count passes ~100, then use Copy Text to clipboard to export the report.
Step 2: Run It Correctly
The most useful one-line command is:
mtr -rwzbc 100 your-server-ipWhat the flags do:
-r— report mode (runs, then prints a clean summary)-w— wide output, so long hostnames aren’t truncated-z— show the ASN (network owner) for each hop-b— show both the hostname and IP of each hop-c 100— send 100 packets (enough to expose intermittent loss)
Two things make or break the result:
- Run it while the problem is happening. An MTR taken after things recover tells us little.
- Run it in both directions. Internet routing is often asymmetric — the path to your server can differ from the path back. Run one MTR from your computer to the server IP, then SSH into the server and run one back toward your own public IP address (search “what is my IP” to find it).
So, ideally you capture two reports:
# From your computer -> server
mtr -rwzbc 100 your-server-ip
# On the server (via SSH) -> your location
mtr -rwzbc 100 your-home-or-office-public-ipStep 3: How to Read the Report
Here is a sample report. The key isn’t any single number — it’s the pattern down the hops:
My traceroute [v0.95]
host: 192.0.2.10 -> 203.0.113.55
Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 100 0.4 0.5 0.3 1.2 0.1
2. 10.20.0.1 0.0% 100 3.1 3.4 2.9 9.8 0.6
3. core1.myisp.net [AS64500] 2.0% 100 12.4 12.9 11.8 40.2 3.1
4. ix.example.net [AS64501] 0.0% 100 13.0 13.2 12.6 15.1 0.4
5. 203.0.113.55 [AS64502] 0.0% 100 13.1 13.3 12.7 15.4 0.5Reading it:
- Loss at a middle hop that clears further down is normal. Hop 3 shows 2.0% loss, but hops 4 and 5 show 0.0%. That means the hop-3 router is simply deprioritising the ping replies it has to generate — it is not actually dropping your traffic. Real loss would persist all the way to the final hop.
- Follow latency down the column. If
Avgjumps at one hop and every hop after it stays high, that hop is where the delay is introduced. A high latency that only appears at a distant destination can just be physics (distance), not a fault. - Watch StDev / Wrst for jitter. A big gap between
BestandWrst, or a highStDev, points to an unstable link rather than plain slowness. - The last hop is your server. Loss or latency that first appears only at the final hop can mean the server itself (firewall rate-limiting ICMP, or an overloaded box) rather than the network.
Common Patterns and What They Mean
- Loss/latency starts mid-path and persists to the end — a genuine problem on a transit or peering network between you and the server. Often outside both parties’ direct control, but exactly what we escalate with carriers.
- Loss only at intermediate hops, 0% at the destination — harmless ICMP rate-limiting. Not your problem.
- High latency at the very first hop — look at your own side: local router, Wi-Fi, or ISP.
- MTR looks clean but the app is still slow — the network isn’t the bottleneck; check the server and application. Our guides on testing hosting performance and troubleshooting common hosting issues help here.
Step 4: What to Send Us
When you reach us through in-app support chat, the fastest tickets include:
- Both MTR reports (to the server, and back from the server)
- Your location and ISP — many issues are route- or region-specific
- The times the problem occurs, and whether it is constant or intermittent
- Whether you also tested from a second network (e.g. mobile data) to rule out local issues
With that in hand, we can compare your path against our internal metrics and pinpoint the layer at fault within minutes rather than days.
Conclusion: Turn “It’s Slow” Into a Located Problem
An MTR report is the difference between “the network feels slow” and “packets start dropping at hop 6 on this transit network, from this region, at this time.” That precision is what gets an issue fixed quickly — and it’s a skill worth having whether you host with us or anywhere else. If you want infrastructure with a team that works this way, take a look at ReadyServer VPS hosting.