My Traceroute (MTR) Explained: Read Network Paths And Fix Packet Loss Without Guesswork

When a site is slow or a game keeps lagging, “the Internet is broken” is not a helpful answer. You want to see what’s really happening between your computer and the server. That’s where traceroute and My Traceroute (MTR) come in for everyday network monitoring and troubleshooting.

In this guide, we’ll walk through what a network path is, how traceroute works, and how MTR turns raw numbers into clear clues about latency and packet loss. The goal: make your life easier if you work with hosting, cloud infrastructure, or just run your own server.

Traceroute In Plain English

Think of the Internet as a chain of delivery drivers. Your packet leaves your machine, passes through a bunch of routers, and finally reaches a server somewhere in the world.

Traceroute is a simple tool that asks:
“Which drivers touched my package, and how long did each one take?”

When you run traceroute (Linux/macOS) or tracert (Windows), it tells you:

• The list of routers (called hops) that your traffic passes through

• The round-trip time (RTT) to each hop — how long it takes to send a packet there and get a reply

If you see a big jump in delay at some hop, or the path suddenly changes, that’s a hint where your performance problem might be.

What Is A Network Path?

A network path is just the route your data takes across different networks to reach its destination.

Your laptop and a remote server usually don’t live on the same network. So your traffic hops through a few (or many) other networks on the way. Each hop is a router at the edge of some network — your ISP, a backbone provider, a data center, and finally the hosting provider where your app or website lives.

When you troubleshoot hosting or cloud issues, understanding that path matters:

• It shows if the problem is inside your own network or somewhere on the Internet

• It helps you talk to your ISP or hosting provider with real evidence, not vibes

How Traceroute Actually Works

Traceroute does a clever trick using TTL (Time To Live) and ICMP.

Here’s the simplified version:

1. It sends packets to the destination IP with TTL = 1.

2. The first router along the way sees TTL go to 0 and says:
   “Sorry, time exceeded” and sends back an ICMP Time Exceeded message.

3. Traceroute logs that router as hop 1.

4. Then it sends new packets with TTL = 2, so the second router replies.

5. It keeps increasing TTL until:

   • The packets reach the destination, or

   • Packets stop coming back and it gives up

Along the way, it measures how long each reply takes. That’s the RTT per hop.

Depending on the OS and options:

• Outgoing packets can be ICMP or UDP (on Windows, UDP is often default)

• The return “time exceeded” packets are ICMP Type 11

If some router is configured to ignore certain packet types (for example, drop ICMP), you might see * * * for that hop — which doesn’t always mean the router is broken. It may just be quiet on purpose.

What Is My Traceroute (MTR)?

Now imagine traceroute and ping had a kid. That kid’s name is My Traceroute (MTR).

MTR combines:

• Traceroute’s list of hops on the network path

• Ping’s constant stream of packets and live statistics

So instead of a static snapshot, MTR keeps updating in real time:

• Latency to each hop (last, average, best, worst)

• Percentage of packet loss per hop

You don’t just see where your packets go. You see how healthy that path is over time, which is gold when you’re debugging random slowdowns in a hosting or gaming environment.

MTR works like this:

• First, it discovers the path, similar to traceroute

• Then it keeps sending packets along that path

• It continuously refreshes the numbers so you can see trends, not just one moment in time

Like traceroute, MTR:

• Can send outgoing packets as ICMP or UDP

• Relies on ICMP Time Exceeded (Type 11) replies along the way

When you manage servers, this gives you a live “heartbeat” of the path between your users and your infrastructure.

Why Tooling And Hosting Both Matter

When something breaks, you usually have two questions:

1. “Is the network path OK?”

2. “Is my server or hosting provider the bottleneck?”

MTR answers the first one really well. But it runs on real servers in the real world. If those servers are overloaded, underpowered, or scattered in the wrong locations, your troubleshooting hits a wall.

That’s where the choice of hosting provider comes in. With low-latency hardware, good peering, and locations close to your users, tools like MTR suddenly become much more useful because they reveal genuine Internet issues instead of showing you problems caused by weak infrastructure.

👉 Troubleshoot latency faster with GTHost instant dedicated servers designed for real-time network monitoring

When the underlying hosting is solid, you can trust that the weird spikes you see in MTR really are somewhere out on the path — not just an overworked shared VPS falling apart during peak time.

How To Read MTR Output

MTR output can look scary at first, but you’re mostly watching two things:

• Latency numbers per hop

• Loss% (packet loss percentage) per hop

Let’s walk through three typical patterns.

Example 1: A Clean Path

Imagine you run MTR to 1.1.1.1 (a public DNS server). You see something like:

text
Host Loss% Snt Last Avg Best Wrst StDev

1. myrouter 0.0% 100 2.0 1.5 1.0 3.0 0.5

2. ...

3. ...

4. one.one.one.one 0.0% 100 25.0 26.0 24.0 30.0 1.0

Key signs of a healthy path:

• Loss% is 0.0% (or close to it) on every hop

• Latency rises smoothly as you get closer to the destination

• No sudden, huge jumps that stay high all the way to the end

This is what “nothing is on fire” looks like.

Example 2: Looks Like Packet Loss… But Isn’t

Now picture MTR going to an IPv6 address. You see a bunch of scary numbers in the middle:

text
Host Loss% Snt Last Avg Best Wrst StDev

1. 2400:cb00:207:1000::1 0.0% 10 1.1 6.0 0.6 15.7 5.9

2. 2404:d400:4000:27::1 0.0% 10 0.4 0.6 0.2 2.9 0.8

3. 2404:d400:0:8:: 0.0% 10 125.7 125.7 125.7 126.2 0.2

4. 2001:978:2:42::e:1 50.0% 10 129.2 129.6 129.2 130.5 0.6

5. be2846.ccr42.fra03.cogentco 80.0% 10 151.9 139.5 127.1 151.9 17.6
   ...

6. 2400:cb00:36:1008::a29e:40e2 0.0% 9 302.9 302.9 302.8 303.2 0.1

At first glance, it looks like half the Internet is melting. But the last hop (the actual destination) shows 0.0% packet loss and stable latency.

What’s going on?

Many network operators use something called Control Plane Policing:

• Routers rate-limit how many ICMP packets they respond to

• They’ll happily forward your real traffic, but don’t always answer every probe from MTR

• So intermediate hops can show “loss” in MTR even when they’re forwarding traffic just fine

Rule of thumb:

• If loss appears at some hop, but disappears at later hops and the final destination, it’s usually just ICMP being rate-limited, not real packet loss along the path.

Example 3: Actual Packet Loss

Now a more serious case:

text
Host Loss% Snt Last Avg Best Wrst StDev

1. 162.158.216.129 0.0% 10 0.7 6.9 0.7 62.6 19.6

2. 118.69.221.209 0.0% 10 0.2 0.3 0.2 1.3 0.3

3. 118.69.252.172 0.0% 10 0.7 1.0 0.6 2.9 0.7

4. 118.69.132.169 0.0% 10 11.4 11.3 11.2 11.5 0.1

5. 118.69.247.64 0.0% 10 34.2 34.4 33.9 37.2 1.0

6. 13335.sgw.equinix 50.0% 10 27.5 27.9 27.1 29.1 0.8

7. 162.158.161.251 30.0% 10 26.8 26.8 26.8 26.8 0.0

Here, loss starts at hop 6 and continues through hop 7 (the destination). That’s a different pattern:

• Loss appears at some hop

• And that loss stays present at the final destination

This usually points to real packet loss on or beyond that hop, not just control-plane rate limiting. That’s when you:

• Open a ticket with your ISP or hosting provider

• Attach the MTR output

• Ask them to check the segment where loss starts

MTR gives you a simple story: “Everything is fine here, but starting right there, packets begin to vanish.”

Useful MTR Options You’ll Actually Care About

MTR has many flags, but most people only need a handful.

Some popular ones:

• TCP mode
  Use TCP instead of ICMP. Handy when routers or firewalls block ICMP, or when you want to test a specific port (like :443 for HTTPS).
  
  

• UDP mode
  Similar idea: use UDP instead of ICMP. Good for testing application-specific paths or working around ICMP filtering.
  
  

• Show IPs
  Show IP addresses next to hostnames. Makes it much easier to share details with upstream providers or cross-check routing.
  
  

• AS lookup
  Display AS numbers (Autonomous Systems). This tells you which network each hop belongs to, which helps you see where traffic moves from one provider to another.
  
  

To discover more, you can always run:

bash
mtr --help

Even if you’re not a network engineer, a few minutes with these options makes you far more effective at diagnosing hosting and connectivity issues.

Quick FAQs About MTR And Traceroute

Q1: How is MTR different from ping or traceroute?
Ping tests a single host with simple latency and loss numbers. Traceroute shows the path once. MTR combines both and runs continuously, so you see how each hop behaves over time.

Q2: Does MTR itself cause problems on the network?
Not in normal use. It sends small packets at a steady rate. Just avoid blasting it with huge send counts on production links for long periods.

Q3: When should I run MTR?
Run it when users complain about slowness, random timeouts, or high latency. It’s especially useful in server hosting and cloud environments where you need to prove whether the issue is local, in transit, or at the remote side.

Q4: Can I run MTR from a remote server instead of my own PC?
Yes, and you should. Running MTR from your server (for example, a dedicated box in a data center) toward your users or upstream services shows how the network looks from the server’s point of view, which is often what matters most.

Conclusion

MTR gives you a live map of the Internet between you and your destination, showing where latency rises and where packet loss actually starts, instead of leaving you guessing. Once you understand how to read the hops, you can separate fake “loss” from real network trouble and talk to providers with solid data.

If you run latency-sensitive workloads or real-time apps, your life gets much easier when solid tooling meets solid hosting — that’s why it’s worth looking at 👉 why GTHost is suitable for real-time, latency-sensitive hosting scenarios.