mtr (Matt's Traceroute) combines ping and traceroute into a single continuously-updating display. It sends probes to every hop on the path in real time, giving you live latency, jitter, and packet loss statistics for each router — not just a one-shot snapshot.
ICMP · UDP · TCP · Live Statistics · Linux · macOS · Windows
01 — Why mtr Beats Traceroute
| traceroute | mtr | |
|---|---|---|
| Probe style | One-shot, 3 probes per hop | Continuous — hundreds of probes over time |
| Statistics | RTT only | Loss %, Sent, Last, Avg, Best, Worst, StDev |
| Jitter | Not shown | StDev column shows jitter |
| Intermittent issues | Easy to miss | Accumulates over time — shows patterns |
| Output | Static text | Live ncurses display or report mode |
When a network issue is intermittent, traceroute might miss it entirely. mtr runs continuously and catches problems that appear only occasionally.
02 — Basic Usage
Interactive live display
mtr google.com
Run for N cycles then print report
mtr -r -c 100 google.com
Typical report output
Start: 2026-03-13T10:00:00+0000
HOST: myhost Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 100 1.2 1.1 0.9 2.1 0.2
2.|-- 10.0.0.1 0.0% 100 8.3 8.1 7.9 9.1 0.3
3.|-- 72.14.215.165 0.0% 100 11.9 12.0 11.5 13.2 0.4
4.|-- ??? 100.0% 100 0.0 0.0 0.0 0.0 0.0
5.|-- 142.250.185.46 0.0% 100 14.2 14.1 13.8 15.0 0.3
| Column | Meaning |
|---|---|
| Loss% | Percentage of probes with no reply at this hop |
| Snt | Total probes sent so far |
| Last | RTT of the most recent probe (ms) |
| Avg | Average RTT across all probes (ms) |
| Best | Lowest RTT seen (ms) |
| Wrst | Highest RTT seen (ms) |
| StDev | Standard deviation — measures jitter |
| ??? | Hop did not reply — ICMP blocked, but path continues |
03 — Common Flags
| Flag | Description | Example |
|---|---|---|
| -r | Report mode — run then exit | mtr -r google.com |
| -c <n> | Number of cycles to run | mtr -r -c 200 google.com |
| -n | No DNS — show IPs only (faster) | mtr -n google.com |
| -u | Use UDP probes | mtr -u google.com |
| -T | Use TCP probes | mtr -T -P 443 google.com |
| -P <port> | Target port (TCP/UDP mode) | mtr -T -P 80 google.com |
| -i <sec> | Probe interval in seconds | mtr -i 0.5 google.com |
| -m <hops> | Max number of hops | mtr -m 20 google.com |
| -4 / -6 | Force IPv4 or IPv6 | mtr -6 google.com |
| --json | Output as JSON | mtr --json -r google.com |
04 — Practical Examples
100-cycle report, no DNS
mtr -r -c 100 -n 8.8.8.8
Test TCP path to a web server on port 443
sudo mtr -T -P 443 -r -c 50 google.com
Share a report — save to file
mtr -r -c 100 google.com > mtr_report.txt
JSON output for scripting / monitoring
mtr --json -r -c 50 google.com | python3 -m json.tool
IPv6 path analysis
mtr -6 -r -c 50 ipv6.google.com
05 — Interpreting Results
| Pattern | Meaning |
|---|---|
| Loss% at one hop only, 0% after | That router rate-limits ICMP — not a real problem |
| Loss% starts at a hop and persists | Real packet loss at or after that hop — investigate that link |
| RTT jumps at one hop, stays high | Latency introduced at that link — congestion or long cable run |
| High StDev (jitter) | Inconsistent link — poor Wi-Fi, overloaded router, or bad cable |
| All ??? rows, destination replies | All intermediate routers block ICMP — normal, path is fine |
| Loss% at final destination | The target host is dropping packets — firewall or overload |
ℹ Always run mtr for at least 100 cycles before drawing conclusions — intermittent issues need time to show up in the statistics.
⚠ TCP and UDP modes may require sudo on Linux. If mtr shows all ??? hops, try switching probe type:
sudo mtr -T -P 80 google.com