If you run Linux servers, you’ve probably had that moment: something is “slow,” users are complaining, but ping and traceroute don’t tell you enough. That’s where the MTR network diagnostic tool shines. It mixes ping and traceroute into one live view so you can spot packet loss, latency spikes, and flaky hops in seconds.

In this guide, we’ll walk through 10 real-world mtr command examples you can use right away on your Linux servers. You’ll see how to get faster troubleshooting, clearer routes, and more stable services without needing complicated monitoring stacks.

1. What Is MTR, Really?

Think of MTR as traceroute on steroids, but still simple.

You run mtr from your Linux machine to a target host. While it runs, it keeps sending packets and keeps updating the screen. You see each hop on the path, plus:

• How many packets were lost at each hop

• How long packets take to travel there (latency)

• Whether the problem is close to you or somewhere deep in the network

So instead of a static traceroute snapshot, you get a live network health dashboard right in your terminal.

This is why MTR has become a must-have network diagnostic tool for sysadmins, DevOps, and hosting engineers.

2. How MTR Works (In Plain Language)

When you start mtr:

1. It discovers the route from your machine to the destination (like traceroute).

2. It sends a steady stream of ICMP ECHO requests (or TCP/UDP if you want) to each hop.

3. It keeps updating stats in real time: loss, latency, averages, worst, etc.

You just watch the numbers move. If one hop starts dropping packets or latency jumps, you notice it almost immediately.

This makes MTR great for:

• Checking why a site feels slow

• Verifying if the issue is inside your network or somewhere on the internet

• Taking snapshots you can send to your ISP or hosting provider

3. Installing MTR on Linux

On many Linux distributions, mtr is already installed. If not, install it with your package manager:

bash
sudo apt install mtr # Debian/Ubuntu
sudo yum install mtr # CentOS/RHEL (older)
sudo dnf install mtr # Fedora/RHEL (newer)

Once that’s done, you’re ready to start poking your network.

4. Example 1: Basic MTR to a Domain or IP

Start with the simplest test. You pick a target (domain or IP) and run:

bash
mtr google.com

or

mtr 216.58.223.78

You’ll see something like:

text
Start: Thu Jun 28 12:10:13 2018
HOST: my-server Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.0.1 0.0% 5 0.3 0.3 0.3 0.4 0.0
2.|-- 5.5.5.211 0.0% 5 0.7 0.9 0.7 1.3 0.0
3.|-- ...

Numbers keep updating until you quit with q or Ctrl+C. You can leave it running while someone tests your app, then see exactly when and where the network misbehaved.

5. Example 2: Show Only Numeric IP Addresses

Sometimes DNS gets in the way, or you just don’t care about hostnames. You can tell MTR to show only numeric IPs:

bash
mtr -n google.com

Now each hop is an IP address. This is handy when:

• DNS is slow or broken

• You’re copying IPs into a firewall or router config

• You want cleaner, shorter output

6. Example 3: Show Both Hostnames and IPs

Other times, you want the full picture: hostname and IP together. Use -b:

bash
mtr -b google.com

Now each line includes both pieces of information. This makes it easier to see which provider or region each hop belongs to while still having the raw IP handy.

7. Example 4: Limit the Number of Pings and Exit

If you don’t want an endless stream, you can tell MTR to send a fixed number of packets, then stop. Use -c for “count”:

bash
mtr -c 5 google.com

MTR sends 5 probes to each hop, then exits. The Snt column (Sent) shows the total packets used per hop. This is great when you want:

• A quick snapshot to paste into a ticket

• A short report for logs or documentation

• Automated checks in scripts

8. Example 5: Report Mode for Clean, Script-Friendly Output

Live output is nice for eyeballing, but sometimes you want a report you can save, parse, or send. That’s where report mode (-r) comes in:

bash
mtr -r -c 5 google.com > mtr-report.txt

This runs MTR, sends 5 packets per hop, and prints a one-time summary instead of live updates. You can also enable a wider format (easier to read) with -w:

bash
mtr -rw -c 5 google.com > mtr-report.txt

Now you have a tidy text report you can email or attach to an issue.

9. Example 6: Reorder Output Fields the Way You Like

Everyone focuses on different numbers. Maybe you care more about worst latency than average, or you want loss front and center.

Use the -o option to pick field order:

bash
mtr -o "LSDR NBAW JMXI" 216.58.223.78

Each letter stands for a field (loss, sent, avg, best, worst, etc.). You can check man mtr for the full list. This tiny tweak makes MTR more readable for your personal workflow or team standards.

10. Example 7: Change the Interval Between Probes

By default, MTR sends a probe every second. If you want slower or faster probing, use -i:

bash
mtr -i 2 google.com # 2 seconds between packets

When might you change the interval?

• Longer interval (like 2–5 seconds) for long observations over several minutes

• Shorter interval for quick stress-style checks (just don’t hit networks too hard)

11. Example 8: Use TCP or UDP Instead of ICMP

Some networks throttle or block ICMP (ping) traffic, which can make your tests misleading. MTR can send TCP SYN packets or UDP datagrams instead:

bash
mtr --tcp test.com

or

mtr --udp test.com

This lets you:

• Test paths more like real application traffic

• Work around ICMP filtering or rate limiting

• Get a more realistic view from certain networks or providers

If you’re testing from different data centers or between hosting providers, this TCP/UDP mode is especially useful.

And if you want to see how your diagnostics behave from powerful, globally distributed servers, it’s worth trying them from a hosting platform designed for real network work.
👉 Spin up an instant GTHost dedicated server and run live MTR tests from multiple locations
That way you’re not guessing from your laptop’s Wi‑Fi—you’re testing from serious infrastructure.

12. Example 9: Limit the Maximum Number of Hops

By default, MTR checks up to 30 hops. If you expect a longer path, or you want to cap it lower, use -m:

bash
mtr -m 35 216.58.223.78

This can help when:

• You’re testing very long routes (cross-continent, VPN, tunnels)

• You don’t care about deep hops and want quicker output

• You want to avoid noise beyond a certain point

13. Example 10: Set Packet Size Manually

Sometimes packet size matters. Maybe a path looks fine with tiny packets but fails when you send larger ones. You can adjust packet size with -s:

bash
mtr -r -s 1400 -c 5 google.com > mtr-report.txt

Common use cases:

• Testing MTU issues

• Simulating “real” traffic sizes

• Comparing behavior between small and large packets

14. Learning More

If you’re curious about more flags, open the manual:

bash
man mtr

You’ll find options for DNS behavior, output formats, address families, and more. But honestly, with the basic flags we’ve just used, you can already solve most day-to-day network mysteries on your Linux servers.

15. Quick FAQ

Q: What is MTR used for in Linux hosting and DevOps?
A: MTR is used as a network diagnostic tool to trace routes and measure latency and packet loss between your Linux server and another host. It’s especially useful in hosting, cloud, and data center environments where you need to quickly prove whether the issue is on your side, the client’s side, or somewhere in between.

Q: Is MTR better than traceroute for troubleshooting?
A: It’s not “better” in every way, but it’s usually more useful. Traceroute shows one snapshot; MTR keeps probing and updating in real time. That makes it easier to see intermittent issues, spikes, and unstable hops.

Q: Can I automate MTR checks?
A: Yes. Use report mode (-r) with a count (-c) and redirect output to a file. A cron job that runs mtr -rw -c 10 to key endpoints can give you lightweight historical data without installing a heavy monitoring stack.

Q: Does MTR work only with ICMP?
A: No. You can switch to TCP (--tcp) or UDP (--udp) to better mimic real application traffic, especially helpful in hosting and network infrastructure scenarios.

Conclusion

MTR takes the old combo of ping and traceroute and turns it into a live, practical Linux network diagnostic tool you can actually rely on when things get weird. With just a few simple flags, you can spot packet loss, isolate latency issues, and collect clean reports for your team or provider.

When you run these checks from reliable, low-latency infrastructure, they become even more accurate and useful. That’s why 👉 GTHost dedicated servers are a strong fit for real-world Linux network diagnostics and performance troubleshooting: you get instant, globally distributed servers that make your MTR tests faster, clearer, and closer to how your production traffic really behaves.