How To Use Traceroute and MTR For Faster Network Troubleshooting

When your site feels slow or a service just hangs, "the network" becomes the usual suspect. But staring at a spinning cursor does not tell you where things are broken.
This guide walks through how to use traceroute and mtr for practical network troubleshooting, so you can see where latency and packet loss actually appear.
If you run servers, do DevOps, or manage hosting, you will learn a simple way to diagnose network issues faster and talk to your provider with real data.

Before You Start: What Traceroute Actually Shows

Think of the internet as a series of checkpoints between you and the remote server.

Each checkpoint is a "hop": a router that forwards your traffic to the next place. When users say "your website is slow," the delay might be in your app, your database, the user's ISP, or some random hop in between.

traceroute does one main thing:

• It sends packets that are allowed to travel only 1 hop, then 2 hops, then 3 hops, and so on.

• Every time a packet expires, the router that dropped it sends a "time exceeded" message back.

• Traceroute prints each of these routers as a line in the output, giving you a path map to the destination.

So the question you are really asking with traceroute is:

"From my machine to this IP or hostname, which routers are on the path, and how long do they take to respond?"

Once you get comfortable reading that story hop by hop, network troubleshooting gets a lot less mysterious.

Running Your First Traceroute

On most Linux distributions, traceroute is already installed.

Basic usage:

bash
traceroute google.com

You will see something like:

text
traceroute to google.com (173.194.38.137), 30 hops max, 60 byte packets
1 192.241.160.253 0.56 ms 0.53 ms 0.52 ms
2 192.241.164.241 0.48 ms 0.43 ms 0.46 ms
3 xe-3-0-6.ar2.nyc3.us.nlayer.net (69.31.95.133) 1.80 ms 1.80 ms 1.76 ms
4 144.223.28.73 0.58 ms 0.56 ms 0.55 ms
...

The first line tells you:

• The host name you tested (google.com)

• The IP address DNS resolved

• The maximum number of hops it will try (default 30)

• The packet size being sent

Every line after that is one hop along the path.

If the command does not exist, install it:

• Debian/Ubuntu: sudo apt install traceroute

• CentOS/Rocky/Alma: sudo yum install traceroute or sudo dnf install traceroute

• Arch: sudo pacman -S traceroute

Once that works, you are ready to start reading the output.

Reading Traceroute Output (Hop by Hop)

Take a single line:

text
3 nyk-b6-link.telia.net (62.115.35.101) 0.31 ms 0.30 ms 0.29 ms

This breaks down as:

• 3: hop number (how far this router is from you in the path)

• nyk-b6-link.telia.net: host name from reverse DNS (if available)

• (62.115.35.101): the router's IP address

• 0.31 ms 0.30 ms 0.29 ms: round‑trip times for 3 test packets

By default, traceroute sends 3 probes to each hop and prints the round‑trip times at the end of the line.

You can tweak two of the most useful settings:

1. Maximum number of hops: -m

If the destination is far away in network terms, you might need more than the default 30 hops:

bash
traceroute -m 50 google.com

This tells traceroute to allow up to 50 hops before it gives up.

2. Number of packets per hop: -q

If you want more samples per hop to see stability, set the number of queries:

bash
traceroute -q 5 google.com

Now each hop will show 5 times instead of 3, which makes spikes and jitter easier to spot.

3. Skip reverse DNS lookups: -n

DNS lookups can slow things down or even fail. If you only care about IPs:

bash
traceroute -n google.com

You will see output like:

text
traceroute to google.com (74.125.235.7), 30 hops max, 60 byte packets
1 192.241.160.253 0.62 ms 0.59 ms 0.58 ms
2 192.241.164.241 2.82 ms 2.74 ms 2.82 ms
3 69.31.95.133 1.47 ms 1.47 ms 1.52 ms

This is often the mode people use in production network troubleshooting because it is fast and predictable.

Spotting Route Problems With Traceroute

Sometimes your traceroute looks clean for a few hops, and then suddenly you see stars:

text
15 209.85.248.220 78.94 ms 79.02 ms 78.95 ms
16 72.14.239.247 101.00 ms 92.47 ms 92.44 ms
17 * * 209.85.250.124 175.08 ms
18 * * *
19 * * *

A few things to understand here:

• * means no response was received within the timeout.

• This does not always mean "this hop is broken."

• Some routers are configured not to answer these probes.

• Sometimes only the next hop is the actual problem.

Traceroute gives you clues, not a courtroom verdict.

Common interpretations:

• If latency jumps sharply at hop N and stays high from N onward, the issue is likely at or after hop N.

• If only a single hop shows high numbers but the next hop returns to normal, that router may just be slow to respond to traceroute, not to real traffic.

• If you see timeouts only near the destination but users still connect fine, the remote side may be rate‑limiting these probes.

So you use traceroute to narrow down:

• "Is the problem near my end, in the middle, or close to the target?"

• "Is this likely my provider's network, an upstream carrier, or the destination?"

For calm, repeatable network troubleshooting, that context is gold.

Meet MTR: Traceroute On Autopilot

Traceroute is like a single photo. mtr (My Traceroute) is more like a video.

It combines ping and traceroute:

• It discovers the path, like traceroute.

• It keeps sending packets to every hop, like an ongoing ping.

• It updates stats in real time: packet loss, average latency, best and worst times, jitter.

Install mtr if you do not have it:

• Debian/Ubuntu: sudo apt install mtr

• CentOS/Rocky/Alma: sudo yum install mtr or sudo dnf install mtr

• Arch: sudo pacman -S mtr

Run your first test:

bash
mtr google.com

You will see a live screen similar to:

text
My traceroute [v0.95]
Host Loss% Snt Last Avg Best Wrst StDev

1. 192.241.160.253 0.0% 371 0.4 0.6 0.1 14.3 1.0

2. 192.241.164.241 0.0% 371 7.4 2.5 0.1 37.5 4.8

3. xe-3-0-6.ar2.nyc3.us 2.7% 371 3.6 2.6 1.1 5.5 1.1

4. sl-gw50-nyc-.sprintli 0.0% 371 0.7 5.0 0.1 82.3 13.1

Now you are not just looking at a single moment. You are watching how the route behaves over time.

MTR is especially useful when:

• Users complain "sometimes it is slow" (intermittent issues)

• You suspect packet loss between two networks

• You want hard numbers to give to your hosting or transit provider

Let it run for a while, then press q to quit.

Using MTR Reports For Shareable Evidence

Running mtr in interactive mode is nice for your eyes, but you often need something you can paste into a ticket or chat.

That is where report mode helps:

bash
mtr --report google.com

By default, mtr --report sends 10 packets to each hop and then prints a summary like:

text
HOST: my-server Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.241.160.254 0.0% 10 1.5 0.9 0.4 1.5 0.4
2.|-- 192.241.164.237 0.0% 10 0.6 0.9 0.4 2.7 0.7
3.|-- nyk-b6-link.telia.net 0.0% 10 0.5 0.5 0.2 0.7 0.2
4.|-- nyk-bb2-link.telia.net 0.0% 10 67.5 18.5 0.8 87.3 31.8

Key columns to watch for network troubleshooting:

• Loss%: packet loss at each hop

• Avg: average latency in ms

• Best / Wrst: best and worst observed values

• StDev: how jumpy the latency is

If you see packet loss starting at hop N and continuing for all later hops, that is a strong sign of trouble around hop N. This is exactly the type of screenshot or text that helps providers fix routing issues more quickly.

When To Loop In Your Hosting Provider

Here is a realistic flow when diagnosing network issues:

1. Notice a problem (slow site, random disconnects, failed API calls).

2. Run traceroute once or twice to see the rough path.

3. Run mtr --report (or interactive mtr for a while) to gather a fuller picture.

4. Compare from different locations if possible (home, office, another server).

If the problem is clearly inside or near your hosting provider's network, send them:

• Your traceroute output

• Your MTR report

• Time window and rough number of affected users

A good provider will understand this immediately and either confirm an incident or escalate to their upstream carriers.

If you want a hosting platform where this kind of network troubleshooting is normal, not exotic, it helps to pick a provider that designs for low latency and transparent routing. That is where a dedicated hosting platform built around fast paths can make a difference.

👉 Explore how GTHost dedicated servers give you low‑latency routes that play nicely with traceroute and MTR, so you can see and fix network issues faster

With a setup like that, your network troubleshooting tools actually show stable, predictable paths instead of chaos.

FAQs

1. When should I use traceroute vs MTR?

Use traceroute when you just want a quick snapshot of the route. Use mtr when the problem is intermittent or you need more precise data about packet loss and latency over time. For serious network troubleshooting and hosting work, most people end up using MTR more.

2. Does one bad hop always mean the network is broken there?

No. Some routers deprioritize or ignore traceroute/MTR probes but still forward real traffic normally. Look for patterns: if latency and loss stay bad for all later hops, that is more meaningful than one noisy hop followed by normal numbers.

3. Can traceroute and MTR fix my network problems?

They do not fix anything by themselves, but they tell you where to look. Once you know if the issue is on your local network, your ISP, your hosting provider, or somewhere in between, you can take targeted action, including changing routes or moving workloads to a better network.

4. Do hosting choices really affect traceroute and MTR results?

Yes. Different hosting providers have different peering, routing policies, and data center locations. A provider like GTHost that focuses on low‑latency connectivity and global coverage will usually give you cleaner traceroute/MTR paths and more stable performance for latency‑sensitive applications.

Conclusion

Traceroute gives you the story of how your packets travel hop by hop, and MTR turns that story into live stats you can actually act on. Used together, they make network troubleshooting less about guessing and more about seeing where latency and packet loss really happen.

When you combine these tools with a network‑aware hosting platform, you get faster paths, more stable performance, and clearer diagnostics. That is why 👉 GTHost is suitable for latency‑sensitive and network‑critical hosting scenarios: its dedicated servers and optimized routes give traceroute and MTR a clean, reliable network to work with, so your troubleshooting stays simple and your services stay fast.