The mtr Command — Advanced Network Diagnostics

Overview

mtr (My Traceroute) combines the functionality of ping and traceroute into a single, powerful diagnostic tool. It continuously sends packets and displays real-time statistics for every hop along the network path, including packet loss percentage and latency — making it far more informative than either tool alone.

Basic Syntax

mtr [options] hostname_or_IP

Basic Usage

Interactive mode

mtr example.com

This opens a live, continuously updating display:

                          My traceroute  [v0.95]
Host:  myserver              Loss%  Snt   Last   Avg  Best  Wrst StDev
 1. gateway (192.168.1.1)     0.0%   50    0.5   0.6   0.3   1.2   0.2
 2. isp-router.net            0.0%   50    5.1   5.3   4.8   6.2   0.4
 3. core.isp.net              0.0%   50   12.3  12.1  11.5  13.4   0.5
 4. peer-exchange.net         2.0%   50   15.7  16.2  14.9  22.1   1.8
 5. cdn-router.net            0.0%   50   18.4  18.1  17.2  19.8   0.6
 6. example.com               0.0%   50   20.2  20.5  19.1  22.3   0.7

Press q to quit.

Understanding the Output

Column	Description
Host	Router or device at each hop
Loss%	Percentage of packets lost at this hop
Snt	Number of packets sent
Last	Latency of the most recent packet (ms)
Avg	Average latency (ms)
Best	Lowest latency recorded (ms)
Wrst	Highest latency recorded (ms)
StDev	Standard deviation — indicates consistency (lower = more stable)

How to Interpret the Results

Packet loss at a single hop but not at later hops:

 3. router-a.net    5.0%   ...
 4. router-b.net    0.0%   ...
 5. destination.com 0.0%   ...

This is usually not a real problem — the intermediate router is simply deprioritizing ICMP responses. Check the destination hop for the true picture.

Packet loss that continues to the destination:

 3. router-a.net    0.0%   ...
 4. router-b.net   15.0%   ...
 5. router-c.net   15.0%   ...
 6. destination.com 15.0%  ...

The issue starts at hop 4 — this is where packets are being dropped.

Latency spike that continues:

 3. router-a.net    avg: 12ms
 4. router-b.net    avg: 85ms   ← Jump here
 5. destination.com avg: 86ms

Hop 4 is the bottleneck.

Report Mode

Generate a text-based report (non-interactive) — perfect for sharing with support teams:

mtr --report example.com

Or specify the number of packets:

mtr --report -c 100 example.com

Sample report output:

HOST: myserver                Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- gateway               0.0%   100    0.5   0.6   0.3   1.2   0.2
  2.|-- isp-router.net        0.0%   100    5.2   5.4   4.7   6.5   0.4
  3.|-- example.com           0.0%   100   20.1  20.3  19.0  22.1   0.7

Useful Flags

Flag	Description
`--report`	Generate a report and exit
`-c N`	Number of pings per hop (default: 10)
`-n`	Don’t resolve hostnames (faster)
`-w`	Wide report mode (shows both hostnames and IPs)
`-4`	Force IPv4
`-6`	Force IPv6
`-i SECONDS`	Interval between pings (default: 1)
`-s SIZE`	Packet size in bytes
`--tcp`	Use TCP instead of ICMP
`--port PORT`	Specify port for TCP mode

mtr vs. traceroute

Feature	mtr	traceroute
Real-time updates	Yes — continuous monitoring	No — single snapshot
Packet loss per hop	Yes — with percentages	No
Average latency per hop	Yes	Limited (only 3 probes)
Best for	In-depth, ongoing diagnostics	Quick path check
Report mode	Yes (`--report`)	No

Practical Examples

Diagnose connectivity issues with your website

mtr --report -c 50 yourdomain.com

Test using TCP (bypasses ICMP-blocking firewalls)

mtr --tcp --port 443 yourdomain.com

Wide report with IPs and hostnames

mtr --report-wide -c 100 yourdomain.com

Skip DNS lookups for faster results

mtr -n --report example.com

Installation

mtr may not be pre-installed. To install:

# Debian/Ubuntu
sudo apt install mtr

# CentOS/RHEL
sudo yum install mtr

Tips

When reporting network issues to your hosting provider, include the full output of mtr --report -c 100 yourdomain.com — it provides everything support teams need.
Run mtr from both directions if possible (local → server and server → your machine) to catch asymmetric routing problems.
Focus on the destination hop for the true picture — intermediate hops with minor loss are usually cosmetic.
Use --tcp --port 443 when ICMP-based results seem incomplete due to firewall filtering.