How to Use MTR to Diagnose Network Paths and Intermittent Packet Loss

Intermittent packet loss is the worst kind of network problem. A single traceroute might look clean while your users are still complaining. That's where MTR comes in. By the end of this guide, you'll know how to run it, read its output, and tell the difference between real congestion and routers that simply don't like answering pings.

What is MTR?, MTR stands for My Traceroute (originally Matt's Traceroute), written by Matt Kimball in 1997 and maintained by Roger Wolff since 1998). It's a command-line tool that discovers every router between you and a destination, then keeps probing each hop continuously. Instead of three samples and done, it gathers live statistics. You'll see loss percentage, average latency, best and worst times, and standard deviation per hop. That persistence is exactly why it catches problems traceroute misses.

MTR starts out just like a standard traceroute, sending packets with a Time-to-Live of 1, then 2, and so on, until it maps the full path. Once it knows the hops, it fires fresh probes at every hop in parallel, usually once per second. Return traffic is almost always ICMP Time Exceeded or Echo Reply messages. The result is a live-updating table that paints a real picture of route health.

You can switch between ICMP, UDP, or TCP probes depending on what the firewalls along the path allow. The official MTR repository has the full protocol details if you want to dig deeper.

On Linux or macOS, you probably already have it. If not, install it through your package manager. Windows users can grab WinMTR or run the native Linux version through WSL. To start diagnosing, just point it at a target:

mtr 1.1.1.1

That interactive curses interface refreshes in real time. It's great for watching a link in the moment, but terrible for copying into a ticket. For real troubleshooting, use --report mode:

mtr --report --report-cycles 100 example.com

This sends a hundred probes and prints a clean text table you can paste into an email or support chat. If ICMP is blocked along the path, try TCP SYN mode on a specific port:

mtr -T -P 443 example.com

Reading the output is where most people get tripped up. Let's look at a typical Dig Trace MTR Tool report:

Host                                                                 Loss% Drop Rcv  Avg  StDev  Javg 
 1. AS36352 _gateway (23.94.20.53)                                    0.0%    0  10  1.7    0.8   0.6
 2. ???                                                              100.0%   10   0  0.0    0.0   0.0
 3. AS3356 core1.example.net (198.51.100.1)                            0.0%    0  10  12.4   1.2   0.9
 4. AS3356 edge2.example.net (198.51.100.5)                            2.0%    1   9  45.2  15.3   8.1

Everyone stares at the Loss% column first. Here's the thing: if hop 2 shows 100% loss but every hop after it looks fine, that router is almost certainly just dropping ICMP probes. It's not dropping your actual traffic. Routers prioritize forwarding packets over answering pings, and many rate-limit or block ICMP entirely to their control plane. Cloudflare's MTR guide explains this behavior well.

Remember: Only sustained loss at the final destination hop proves end-to-end packet loss. Middle-hop loss without downstream impact is usually a red herring.

APNIC's guide to interpreting traceroute and MTR hammers this point home. The last line is what matters. If the destination shows 5% loss and high StDev, you've got a real problem. StDev measures jitter, and a high number means latency is all over the place. Javg smooths that out into a jitter average.

When Avg climbs steadily at one specific hop and stays elevated after it, that's your bottleneck. If only one middle hop spikes but the destination is flat, blame the router's control plane and keep looking.

Asymmetric routing trips up a lot of admins. The internet doesn't guarantee the return path matches the forward path. A clean MTR from server to client means nothing if the reverse path is congested. Always test both directions. Have the remote side run MTR back to you, or use an out-of-band host. DigitalOcean's tutorial covers bidirectional testing in more detail.

ISPs and cloud providers will ignore a single traceroute. Arm yourself with data. An MTR report with 50 to 100 cycles and timestamps gives them quantitative proof. Run it during peak and off-peak hours so you can show a pattern. Save a baseline when the network is healthy too. When trouble hits, you'll want something to compare against instead of guessing what "normal" looks like.

If you're dealing with DNS resolution issues or want routing context, add AS number lookups with -z:

mtr -z --report example.com

This adds the autonomous system number next to each hop, which helps identify exactly which network owns the problematic router. It's a small flag that saves time when you're pointing fingers across provider boundaries.

MTR isn't magic. It's just persistent. It won't fix a bad route, but it'll show you where things go sideways with enough data to back up your claim. Next time you get a vague "the internet is slow" ticket, skip the single traceroute. Fire up MTR in report mode, let it run for a minute, and look at that final hop. That's where the truth lives.

If you plan on using MTR for troubleshooting, studying or self-learn, check out our Web based MTR Tool.