When your connection slows or fails, ping, traceroute, and MTR help you pinpoint exactly where the problem lies. Learn how these three essential network diagnostic tools work and when to use each one.
Publish date: 1/10/2026
Every network problem starts the same way: something isn't working. Maybe your server response times have doubled, your SSH connection keeps dropping, or your application can't reach its database. The frustrating part is that "the network is down" doesn't tell you much. Is it your local connection? Your ISP? A routing issue halfway across the internet?
That's where network diagnostic tools come in. Three command-line utilities have been solving these problems for decades: ping, traceroute, and MTR. Each one approaches network troubleshooting differently, and knowing when to use which tool can cut your debugging time from hours to minutes.
Ping is the simplest network diagnostic tool, and often the first one you'll reach for. It sends a small packet of data to a target host and measures how long it takes to get a response. Think of it like knocking on someone's door and timing how long it takes them to answer.
The tool uses ICMP (Internet Control Message Protocol) echo requests. When you ping a server, your computer sends an echo request packet, and if everything is working, the remote server sends an echo reply back. Ping then calculates the round-trip time and displays it in milliseconds.
Here's what a basic ping looks like:
ping google.com
You'll see output showing each response:
PING google.com (142.250.185.46): 56 data bytes
64 bytes from 142.250.185.46: icmp_seq=0 ttl=118 time=12.3 ms
64 bytes from 142.250.185.46: icmp_seq=1 ttl=118 time=11.8 ms
64 bytes from 142.250.185.46: icmp_seq=2 ttl=118 time=12.1 ms
The important numbers here are the time values. Consistently low response times (under 50ms for most purposes) indicate a healthy connection. High response times suggest latency issues, while dropped packets (no response) point to connectivity problems.
Ping excels at answering simple questions: Is the host reachable? How stable is the connection? You'll use it to verify that a server is online, check if your internet connection is working, or measure baseline latency to a specific destination.
It's particularly helpful for monitoring connection stability over time. Running ping -c 100 example.com sends 100 packets and gives you statistics about packet loss and average latency. If you see 5% packet loss and wildly varying response times, you know there's an issue worth investigating further.
That said, ping has limitations. Some networks block ICMP traffic entirely, so a failed ping doesn't always mean the host is down. It also won't tell you where along the path a problem exists if you're trying to reach a remote server.
While ping tells you if you can reach a destination, traceroute shows you the path your packets take to get there. It maps out each hop between your computer and the target, revealing which routers and networks your traffic passes through.
Traceroute works by sending packets with incrementally increasing TTL (Time To Live) values. The first packet has a TTL of 1, so it expires at the first router, which sends back an error message revealing its identity. The second packet has a TTL of 2 and reaches the second router before expiring, and so on. This continues until a packet reaches the final destination.
On Linux, you'll typically use the traceroute command (on Windows, it's tracert):
traceroute google.com
The output shows each hop along the path:
traceroute to google.com (142.250.185.46), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 1.234 ms 1.112 ms 1.098 ms
2 10.0.0.1 (10.0.0.1) 8.543 ms 8.432 ms 8.398 ms
3 isp-router.net (203.0.113.1) 12.345 ms 12.234 ms 12.198 ms
4 * * *
5 google-router.net (142.250.185.46) 15.234 ms 15.123 ms 15.098 ms
Each line represents a hop, showing the router's address and the round-trip time for three probe packets. The asterisks on line 4 indicate that router didn't respond, which is common since many networks deprioritize or block traceroute traffic.
Traceroute is your go-to tool when you need to identify where along the network path a problem occurs. If you're experiencing high latency to a specific server, traceroute can show you whether the delay happens at your ISP, at an intermediate network, or near the destination.
It's particularly useful for diagnosing routing issues. If packets are taking an unexpectedly long path, bouncing between continents when they should stay regional, traceroute makes it obvious. You might discover your traffic is being routed through an overloaded peering point or that your ISP is sending packets on a less-than-optimal path.
The main drawback is that traceroute only gives you a snapshot of the route at one moment in time. Network paths can change constantly as routers adapt to traffic conditions, and a single traceroute won't show you patterns over time. It also can't distinguish between actual network problems and routers that simply don't respond to probe packets.
MTR (My Traceroute) combines the best aspects of ping and traceroute into a single, continuously updating tool. While traceroute shows you the path once and ping tests a single destination repeatedly, MTR does both simultaneously, testing each hop along the route and providing real-time statistics.
Think of MTR as traceroute that runs continuously, measuring latency and packet loss at every hop over time. This lets you distinguish between a router that occasionally drops packets and one that's consistently failing. You can watch the numbers update in real-time, building a much more complete picture of network behavior than either ping or traceroute alone.
Installing MTR is straightforward on most Linux distributions:
# Debian/Ubuntu
sudo apt install mtr-tiny
# RHEL/AlmaLinux/Rocky Linux
sudo dnf install mtr
Running MTR is simple:
mtr google.com
You'll see an interactive display that updates continuously:
My traceroute [v0.95]
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 10 1.2 1.3 1.1 1.5 0.1
2. 10.0.0.1 0.0% 10 8.4 8.5 8.3 8.9 0.2
3. isp-router.net 2.0% 10 12.3 12.5 12.1 15.2 0.9
4. google-router.net 0.0% 10 15.1 15.2 15.0 15.6 0.2
The columns show packet loss percentage, number of packets sent, and latency statistics (last, average, best, worst, and standard deviation). This gives you much richer data than traceroute's three-packet snapshot.
MTR shines when you're dealing with intermittent issues or need to prove that a problem exists over time. If your SSH connection keeps timing out but only occasionally, running MTR for several minutes will show you exactly which hop is dropping packets or experiencing latency spikes.
It's also the best tool for demonstrating network issues to your ISP or hosting provider. A screenshot showing 15% packet loss at hop 3 over a 10-minute period is much more convincing than saying "the network feels slow sometimes." The statistics make it easy to differentiate between actual problems and normal network variance.
For interactive troubleshooting, MTR's real-time updates let you see the effect of changes immediately. If you're trying to diagnose whether switching DNS servers or routing through a VPN helps, you can watch the MTR output change as you make adjustments.
Each tool serves a distinct purpose in network troubleshooting, though there's some overlap in what they can tell you.
Ping is the fastest way to check basic connectivity and measure round-trip time to a single destination. It's simple, universally available, and works on virtually any system. However, it only tests the full path from source to destination; it won't tell you where problems occur along the way. Use ping when you need a quick health check or want to monitor stability to a single endpoint.
Traceroute maps the complete path your packets take, showing every router between you and the destination. This makes it indispensable for identifying where slowdowns or failures occur. The downside is that it only captures a moment in time, typically sending just three packets per hop. Use traceroute when you need to understand the routing path or identify which network segment is causing problems.
MTR gives you the benefits of both tools while adding continuous monitoring and detailed statistics. It shows the complete path like traceroute, but measures each hop over time like ping. This combination makes it the most informative tool for diagnosing complex or intermittent issues. The tradeoff is that MTR needs to run longer to gather meaningful data, and it's not pre-installed on all systems.
In practice, many network troubleshooting sessions start with ping to confirm the problem exists, move to traceroute to identify where it's happening, and then use MTR to gather detailed evidence about the issue. As you gain experience, you might skip straight to MTR since it provides the most complete picture.
Understanding what these tools tell you makes the difference between finding solutions quickly and wasting time chasing false leads.
When looking at ping results, focus on three things: response time, packet loss, and consistency. Response times under 50ms are generally fine for most applications, though latency-sensitive uses like gaming or VoIP benefit from under 30ms. Any packet loss is worth investigating, even 1-2%, since TCP connections will slow down as they retransmit lost packets. Wildly varying response times (jumping between 20ms and 200ms) suggest an overloaded network or interference.
Traceroute results require a bit more interpretation. The first hop is always your local gateway (usually your router), and response times there should be under 5ms. Each subsequent hop adds some latency; 1-5ms per hop is typical for well-connected networks. Large jumps in latency (going from 20ms to 150ms in a single hop) often indicate that hop crosses a significant geographic distance or moves between networks with poor peering. Don't panic over asterisks or timeouts at individual hops; many routers simply don't respond to traceroute probes, but they're still forwarding your packets fine.
MTR statistics deserve the most attention since they provide the richest data. Look at the Loss% column first; any hop showing consistent packet loss above 2-3% is a problem. However, only worry about loss if it persists through subsequent hops. If hop 4 shows 10% loss but hop 5 shows 0%, the issue is actually with how hop 4 responds to probes, not with packet forwarding. Check the StDev (standard deviation) column for latency consistency; high values indicate unstable routing or congestion.
One common mistake is focusing on individual bad measurements. If MTR shows one outlier of 500ms among dozens of 15ms readings, that's normal internet variance. Look for patterns: persistent packet loss, consistently high latency, or regular spikes that repeat at intervals.
Let's walk through some real situations where these tools solve specific problems.
Suppose your web application is responding slowly. First, ping the server to establish a baseline. If you're seeing 200ms response times when you'd normally see 20ms, you've confirmed latency is the issue. Run traceroute to see where the delay appears. If the first few hops look normal but latency jumps dramatically at your hosting provider's network, the problem is likely on their end. If the slowdown happens earlier, at your ISP's routers, you're dealing with a local network issue.
For intermittent connection drops, MTR is your best friend. Run it for at least 5-10 minutes while the problem occurs. If you see packet loss at your gateway (hop 1), check your local network; a failing router or WiFi interference is often the culprit. Loss that appears at your ISP's routers (typically hops 2-4) requires contacting them with your MTR data. Loss that only shows up at the final destination might indicate the remote server is overloaded, not a network issue.
Sometimes you'll troubleshoot connectivity to a specific service rather than a host. If SSH works but HTTP doesn't, the issue isn't at the network layer, so these tools won't help directly. But you can use them to rule out network problems: if MTR shows clean connectivity, focus your troubleshooting on application-level issues like firewall rules or service configuration.
When dealing with multiple servers or services, compare MTR results between them. If one server in a data center has perfect connectivity but another in the same location shows issues, the problem is specific to that server. If all servers in a region show the same problems, you're looking at a broader routing issue affecting that location.
Each tool offers options that unlock more detailed diagnostic capabilities beyond the basic usage.
Ping can test different packet sizes with the -s option, which helps identify MTU (Maximum Transmission Unit) issues. If ping -s 1400 example.com works but ping -s 1500 example.com fails, packets are being fragmented or dropped somewhere along the path. The -i option controls timing between packets; -i 0.2 sends 5 packets per second instead of the default 1 per second, useful for stress testing a connection. On Linux, you can also use -M do to disable packet fragmentation, which helps diagnose PMTU discovery problems.
Traceroute offers several protocol options. By default, Linux traceroute uses UDP probes, but you can switch to ICMP with -I or TCP with -T. This matters because some networks treat different protocols differently; a traceroute that fails with UDP might succeed with TCP. The -n option skips DNS resolution, speeding up results when you don't need hostnames. You can also control the number of probes per hop with -q; traceroute -q 1 example.com sends one probe instead of three, finishing faster when you just need to see the path.
MTR combines many advanced options into one tool. Running mtr --report --report-cycles 100 example.com generates a text report after 100 cycles, perfect for saving or sending to your hosting provider. The --tcp flag uses TCP SYN packets instead of ICMP, which can bypass firewalls that block ICMP. Using --port 443 tests the specific port your application uses, like mtr --tcp --port 443 example.com for HTTPS connectivity. The --aslookup option adds AS (Autonomous System) numbers to each hop, showing which organizations control each network segment.
For the deepest analysis, combine these tools with packet capture. Run MTR while capturing packets with tcpdump, then analyze the results together. This approach reveals issues like asymmetric routing, where packets take one path outbound but return via a different route.
Many routers don't respond to traceroute probes even though they successfully forward your packets. Network administrators often configure routers to ignore these diagnostic packets to reduce load and prevent reconnaissance. As long as subsequent hops respond normally, asterisks don't indicate a problem. Only worry if you see consecutive asterisks leading to complete failure, suggesting packets aren't being forwarded at all.
These tools diagnose network-level connectivity and routing, not application performance. They'll tell you if network latency or packet loss is causing slowness, but they can't identify problems with web server configuration, database queries, or application code. If MTR shows perfect connectivity but your website loads slowly, the issue lies in the application layer, not the network.
MTR measures latency to each individual hop along the path, while ping only measures end-to-end latency. More importantly, routers often prioritize regular traffic over diagnostic packets, so MTR might show higher latencies than your actual application traffic experiences. Also, MTR sends packets continuously while ping has delays between probes, which can reveal different patterns in network behavior.
First, verify the packet loss persists across multiple MTR runs at different times of day. Capture screenshots showing consistent loss over at least 10-15 minutes. Make sure the loss appears at your ISP's routers (typically the first few hops outside your local network) and continues through subsequent hops. Present this data to your ISP with specific hop numbers and timestamps. If they still deny issues, consider running MTR to multiple destinations; if all show problems at the same ISP hop, you have a strong case.
Windows includes ping and tracert (traceroute) by default, though with slightly different command syntax. Tracert uses -d instead of -n to skip DNS lookups, and -h instead of -m to set maximum hops. Windows doesn't include MTR by default, but you can download WinMTR, a Windows port with a graphical interface. The underlying network diagnostics work identically across operating systems.
Network troubleshooting doesn't have to feel like guesswork. Ping, traceroute, and MTR give you the visibility to identify problems quickly and confidently. Ping confirms connectivity and measures latency, traceroute maps the path your packets travel, and MTR combines both approaches with continuous monitoring and detailed statistics.
Start with ping for quick checks, use traceroute to map problems to specific network segments, and rely on MTR when you need concrete evidence of network issues over time. With practice, you'll develop an intuition for which tool fits each situation, cutting your troubleshooting time dramatically.
Thanks for reading! If you're looking for reliable infrastructure, xTom provides enterprise-grade dedicated servers and colocation services, while V.PS offers scalable, production-ready NVMe-powered VPS hosting perfect for any workload. We also offer IP transit, shared hosting, and additional IT services tailored to your needs.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.