How to Use the Traceroute Command: traceroute vs mtr for Diagnosing Network Routes

Use traceroute for a quick route map, and use mtr when the problem flickers or packet loss comes and goes. Traceroute shows each router hop between you and a target. It works by sending packets with rising TTL values, so each hop reports back as packets expire [source: Cloudflare].

TLDR: traceroute is the flashlight. mtr is the security camera. If a customer says your app is slow, run traceroute app.example.com first to see the path. Then run mtr -rwzc 100 app.example.com; if hop 8 shows 32% packet loss over 100 tests, you have a much better clue than one lonely traceroute run.

What traceroute actually does

Think of the internet as a weird road trip.

Your laptop is the van. The website is the beach. Routers are gas stations along the way. Traceroute asks, “Which gas stations did we pass?”

It sends tiny test packets toward a destination. Each packet is allowed to travel only a certain number of hops. The first packet stops at hop 1. The next stops at hop 2. Then hop 3. And so on.

Each router that stops a packet may reply. Traceroute writes down the router address and the time it took.

The result looks like this:

traceroute example.com

1  192.168.1.1      2 ms
2  10.20.0.1        8 ms
3  203.0.113.9     25 ms
4  198.51.100.4    90 ms
5  example.com     92 ms

Simple, right? Mostly.

It drives me a little crazy that a clean traceroute can still hide a bad network. One run is just a snapshot. If the problem happens every 20 seconds, you might miss it completely.

How to run traceroute

The command depends on your system.

Linux: traceroute example.com
macOS: traceroute example.com
Windows: tracert example.com

You can test a domain:

traceroute google.com

Or an IP address:

traceroute 8.8.8.8

On Linux, traceroute often uses UDP packets by default. Sometimes firewalls block those. Try ICMP instead:

traceroute -I example.com

Or try TCP, which can look more like normal web traffic:

traceroute -T example.com

How to read traceroute without crying

Each line is a hop. Each time value is round trip time. Lower is usually better.

1 to 10 ms: local or very close.
10 to 50 ms: normal for many regional routes.
50 to 150 ms: common for long distance traffic.
200 ms or more: possible distance, congestion, or satellite links.

Watch for sudden jumps.

5  203.0.113.10     20 ms
6  198.51.100.6    210 ms
7  198.51.100.9    212 ms

Here, hop 6 is where the delay starts. That does not always mean hop 6 is broken. It may just be the first place where the route crosses a long distance link.

Now look at this:

5  203.0.113.10     20 ms
6  * * *
7  198.51.100.9     24 ms
8  example.com      25 ms

The stars mean no reply. But traffic still reached hop 8. So hop 6 may be ignoring traceroute probes. That is common. Routers are busy. Some refuse to answer nosy little test packets.

What mtr does better

mtr means “My Traceroute” on many systems. It mixes traceroute and ping. That makes it very handy.

Traceroute runs once. MTR keeps testing. It shows loss, best time, worst time, average time, and more.

Install it if needed:

sudo apt install mtr
brew install mtr

Then run:

mtr example.com

For a clean report, use:

mtr -rwzc 100 example.com

-r: report mode.
-w: wide output.
-z: show autonomous system numbers when available.
-c 100: send 100 probes.

That last number matters. Five probes can lie. One hundred probes tell a better story.

Traceroute vs mtr: which should you use?

Tool	Best for	Weak spot
traceroute	Quick path checks	Only shows one moment
mtr	Packet loss and unstable routes	Needs time to collect data

Use traceroute when you need a quick answer.

Is traffic leaving my network?
Which provider path is being used?
Does the route stop before the target?

Use mtr when the issue is annoying and random.

Calls break up every few minutes.
A game lags, then recovers.
A website loads fast at 9:00, then crawls at 9:05.

Honestly, it feels like network problems enjoy hiding until you stop watching. MTR keeps watching. That is why admins love it.

A simple user case

Say your remote worker in Chicago says the company dashboard is slow. The server is in Virginia. Everyone else seems fine.

First, run traceroute:

traceroute dashboard.example.com

You see the route reaches the server. No total failure. Good.

Then run MTR for 100 probes:

mtr -rwzc 100 dashboard.example.com

The report shows this:

Hop  Loss%  Avg   Worst
1    0.0%   3     8
2    0.0%   12    22
3    0.0%   18    30
4    28.0%  95    310
5    27.0%  98    330
6    0.0%   101   340

This is tricky. Hop 4 shows loss. Hop 5 shows loss. Hop 6 shows no loss. That means the earlier routers may be limiting replies to test packets. If the final hop has no loss, the end-to-end path may be okay.

But if the final hop also shows 28% loss, that is real pain. Now you have a strong clue. Send the report to the ISP or network team.

Common traps

Stars do not always mean failure. They can mean “I will not answer.”
High latency on one middle hop may be harmless. Check later hops.
Packet loss matters most at the destination. Middle hops can be misleading.
Run tests from both sides if possible. Routes are often different each way.
Test by IP and hostname. DNS problems can look like route problems.

Good commands to keep nearby

# Quick route map
traceroute example.com

# Windows route map
tracert example.com

# Use ICMP probes
traceroute -I example.com

# Use TCP probes
traceroute -T example.com

# Live MTR view
mtr example.com

# Shareable MTR report
mtr -rwzc 100 example.com