How to Perform an MTR Network Test

MTR combines ping and traceroute into a single tool that continuously tests each hop between two points on the network. When you report a network issue to support, an MTR test gives us the data needed to identify whether the problem is on your ISP, in transit, or at our end.

Running MTR on your server (server → your IP)

SSH into your server and run:

mtr --report --report-cycles 60 YOUR_IP_OR_DOMAIN

• --report: runs a fixed number of cycles and outputs a summary
• --report-cycles 60: sends 60 packets to each hop (about 60 seconds)

Replace YOUR_IP_OR_DOMAIN with your home/office IP or a domain that resolves to it.

Example output:

HOST: server.yourdomain.com     Loss%  Snt  Last  Avg  Best  Wrst StDev
 1. 10.0.0.1                    0.0%   60   0.5   0.4   0.3   0.8   0.1
 2. 192.168.1.1                 0.0%   60   1.2   1.1   0.9   2.1   0.2
 3. transit1.isp.com            0.0%   60   5.1   5.0   4.8   6.2   0.3
 4. YOUR_IP                     0.0%   60  12.3  12.1  11.8  14.2   0.5

Running MTR on your computer (your PC → server)

Windows

Install WinMTR, enter your server IP or hostname, and click Start. After 100+ packets, click Export HTML and share the result.

macOS

# Install via Homebrew
brew install mtr

# Run (requires sudo on macOS)
sudo mtr --report --report-cycles 60 YOUR_SERVER_IP

Linux

# Install
sudo apt install mtr    # Ubuntu/Debian
sudo yum install mtr    # CentOS/AlmaLinux

# Run
mtr --report --report-cycles 60 YOUR_SERVER_IP

Reading the output

Column	What it means
Host	Hostname or IP of each network hop
Loss%	Packet loss percentage at that hop
Snt	Packets sent
Last	Latency of the last packet (ms)
Avg	Average latency (ms)
Best	Best (lowest) latency seen
Wrst	Worst (highest) latency seen
StDev	Standard deviation: higher = more inconsistent

Interpreting results

No loss anywhere: network is healthy. Issue is likely not network-related.

Loss at one intermediate hop, no loss after: intermediate routers often deprioritize ICMP (ping) traffic. Not a real problem if the hops after it show no loss.

Loss starting at a hop and continuing to the end: real packet loss at or after that hop. The hop where loss first appears is where the issue starts.

High latency spike at one hop: routing issue or congested link. If latency returns to normal after, it may be an ICMP deprioritization artifact. If latency stays high, it’s a real problem.

100% loss at the last hop (your server): the server may have ICMP blocked by the firewall. Run the test from the server outward as well to confirm.

Sharing MTR results with support

When opening a support ticket about network issues, include:

1. MTR from your computer to the server
2. MTR from the server to your computer
3. The time and date the issue occurred
4. Your ISP name and approximate location

Both directions are important: network issues are often asymmetric (one direction works fine, the other has problems).