Traceroute Linux: traceroute vs ping for Linux Network Diagnostics

Use ping first, then use traceroute when ping says “something is wrong” but refuses to say where. Ping checks if a host answers. Traceroute shows the path your packets take to reach it. Together, they are the flashlight and the map for Linux network diagnostics.

TLDR: Use ping google.com to test if a server is reachable and how slow the reply is. Use traceroute google.com to see each network hop between your Linux machine and that server. Example: if ping shows 35% packet loss, traceroute may show that loss starts at hop 6, which points to an ISP or routing issue. For a support team handling 100 tickets a week, this can cut guessing time by 10 to 20 minutes per case.

Ping Is the “Are You Alive?” Tool

ping is simple. Almost silly simple. You send a tiny packet to a server. The server sends one back. If it replies, you know it is reachable.

Run this:

ping linux.org

You will see replies like this:

64 bytes from linux.org: icmp_seq=1 ttl=54 time=22.8 ms

The key part is time=22.8 ms. That is latency. Lower is better. If you see timeouts, something is wrong.

• Low time: Good. The connection is quick.
• High time: Slow. Expect lag.
• Packet loss: Bad. Packets are vanishing.
• No reply: The host may be down, blocked, or refusing ping.

Stop ping with Ctrl + C. Linux will show a neat summary. It includes packet loss and average response time.

Honestly, it feels like ping is that friend who says “Yep, something is off” and then walks away.

Traceroute Is the “Where Did It Break?” Tool

traceroute goes one step deeper. It shows each router between your machine and the target. These routers are called hops.

Run this:

traceroute linux.org

You may see something like this:

1  router.local        1.1 ms
2  isp.gateway         8.4 ms
3  core.network        14.7 ms
4  *
5  linux.org           23.2 ms

Each line is a hop. Each time value shows how long that hop took to respond. A star means no answer came back. That does not always mean failure. Some routers ignore probe packets. Annoying? Yes. Fatal? Not always.

The catch is that traceroute can look broken when the website still works fine. Some routers are just quiet little gremlins.

Traceroute vs Ping: The Simple Difference

Think of it like sending a pizza delivery.

• Ping asks: “Did the pizza arrive?”
• Traceroute asks: “Which streets did the driver take?”

If the pizza arrives cold, ping tells you it was slow. Traceroute helps find where the driver got stuck.

When to Use Ping

Use ping when you need a fast check. It is great for first contact. Like tapping the microphone.

Good cases for ping:

• You want to know if a server is online.
• You need to check latency.
• You suspect packet loss.
• You are testing DNS with a domain name.
• You are checking a local router.

Useful examples:

ping 8.8.8.8
ping example.com
ping -c 5 example.com

The -c 5 option sends only 5 packets. This saves you from staring at an endless stream of replies. Tiny mercy. Big comfort.

When to Use Traceroute

Use traceroute when ping gives you a clue, but not the answer. It is best when you need the route.

Good cases for traceroute:

• A website is slow, but not down.
• Ping works, but latency jumps.
• A server works from one network, but not another.
• You need proof for an ISP ticket.
• You suspect routing trouble.

Useful examples:

traceroute example.com
traceroute 8.8.8.8
traceroute -n example.com

The -n option skips DNS lookups. That makes results faster and cleaner. It shows IP addresses instead of names.

Installing Traceroute on Linux

Ping is usually installed already. Traceroute may not be. Because of course the tool you need at 2 a.m. may be missing.

On Debian or Ubuntu:

sudo apt update
sudo apt install traceroute

On Fedora:

sudo dnf install traceroute

On Arch Linux:

sudo pacman -S traceroute

After that, run:

traceroute example.com

Why Traceroute Output Gets Weird

Traceroute is useful. It is also a bit messy.

You may see * * *. That means the hop did not reply. It may be blocking the probe. It may be overloaded. Or it may simply be configured to stay silent.

You may also see one slow hop in the middle. Do not panic right away. If later hops are fast again, that router may be slow to answer traceroute only. It may still forward traffic just fine.

Look for patterns:

• All hops get slow after one point: That point may be the issue.
• Only one hop is slow: It may not matter.
• Stars continue until the end: The target or path may be blocked.
• First hop is slow: Check your router or Wi-Fi.

ICMP, UDP, and Why Linux Traceroute Acts Different

Ping uses ICMP. That is a network control protocol. Many admins allow it. Some block it.

Linux traceroute often uses UDP probes by default. Some systems use ICMP or TCP options. Firewalls may treat each type in a different way.

That means ping can fail while a website still loads. It also means traceroute can look ugly while the service works. Networks love making simple things weird.

You can try ICMP traceroute like this:

traceroute -I example.com

You can try TCP traceroute like this:

sudo traceroute -T example.com

TCP mode can help when firewalls block UDP or ICMP. It often gives better clues for web servers.

A Small Real World Scenario

Imagine a user says, “The app is slow.” Classic. Helpful as a foggy window.

You start with ping:

ping -c 20 app.company.com

The result shows 18% packet loss and an average latency of 190 ms. That is not great.

Then you run:

traceroute -n app.company.com

The first 4 hops are fine. Hop 5 jumps from 25 ms to 180 ms. Every hop after that stays high. Now you have a real clue. The problem likely starts near hop 5.

This is much better than saying, “The internet is broken.” Your ISP will still ask boring questions. But at least you have numbers.

Try MTR When You Want Both

mtr mixes ping and traceroute. It keeps testing each hop over time. It is great for spotting packet loss.

Install it like this:

sudo apt install mtr

Run it like this:

mtr example.com

For a report:

mtr -rw example.com

If ping is a quick knock and traceroute is a route map, MTR is the grumpy inspector with a clipboard.

Best Workflow for Linux Network Diagnostics

1. Ping the IP: Try ping 8.8.8.8.
2. Ping the domain: Try ping example.com.
3. If IP works but domain fails: Check DNS.
4. If ping is slow or lossy: Run traceroute.
5. If traceroute is unclear: Try mtr.
6. If needed: Test ICMP, UDP, and TCP modes.

Final rule: Use ping for the quick yes or no. Use traceroute for the “where did this mess begin?” moment. They are not rivals. They are a tiny Linux detective team, and one of them always brings receipts.