traceroute Command in Linux

The traceroute command is a network diagnostic tool that displays the path packets take from your system to a destination host. It shows each hop (router) along the route and the time it takes for packets to reach each one.

Network administrators use traceroute to identify where packets are being delayed or dropped, making it essential for troubleshooting connectivity issues, latency problems, and routing failures.

This guide covers how to use the traceroute command with practical examples and explanations of the most common options.

Syntax #

The general syntax for the traceroute command is:

traceroute [OPTIONS] DESTINATION

• OPTIONS - Flags that modify the behavior of the command.
• DESTINATION - The target hostname or IP address to trace.

Installing traceroute #

The traceroute command is not installed by default on all Linux distributions. To check if it is available on your system, type:

traceroute --version

If traceroute is not present, the command will print “traceroute: command not found”. You can install it using your distribution’s package manager.

Install traceroute on Ubuntu, Debian, and Derivatives #

sudo apt update && sudo apt install traceroute

Install traceroute on Fedora, RHEL, and Derivatives #

sudo dnf install traceroute

Install traceroute on Arch Linux #

sudo pacman -S traceroute

How traceroute Works #

When you run traceroute, it sends packets with incrementally increasing TTL (Time to Live) values, starting at 1. Each router along the path decrements the TTL by 1. When the TTL reaches 0, the router discards the packet and sends back an ICMP “Time Exceeded” message.

By increasing the TTL with each round of packets, traceroute discovers each hop along the route until the packets reach the final destination.

By default, traceroute sends three UDP packets per hop (on Linux) and displays the round-trip time for each packet.

Those UDP probes do not go to a normal service port. The first probe targets port 33434 and every following probe increments the port by one, which is why firewall rules written for traceroute allow a UDP range starting at 33434 rather than a single port. Two alternative methods use one fixed port instead: -T sends TCP SYN packets to port 80, and -U sends UDP packets to port 53.

The fixed-port UDP method has an important limitation. Unlike TCP traceroute, -U sends probe data to the application listening on the destination port. Many services will not respond to that data, so the final hop may not appear. Use this method only when you need to test a path through a specific allowed UDP port.

Basic Usage #

To trace the route to a destination, run traceroute followed by the hostname or IP address:

traceroute google.com

The output should look something like this:

traceroute to google.com (142.250.185.78), 30 hops max, 60 byte packets
 1  router.local (192.168.1.1)  1.234 ms  1.102 ms  1.056 ms
 2  10.0.0.1 (10.0.0.1)  12.345 ms  12.234 ms  12.123 ms
 3  isp-gateway.example.net (203.0.113.1)  15.678 ms  15.567 ms  15.456 ms
 4  core-router.example.net (198.51.100.1)  20.123 ms  20.012 ms  19.901 ms
 5  google-peer.example.net (192.0.2.1)  22.345 ms  22.234 ms  22.123 ms
 6  142.250.185.78 (142.250.185.78)  25.678 ms  25.567 ms  25.456 ms

Understanding the Output #

Each line in the traceroute output represents one TTL value along the route. A responding hop usually shows these fields:

• Hop number - The TTL value used for that row (1, 2, 3, etc.).
• Hostname - The DNS name of the router, if available.
• IP address - The IP address of the router in parentheses.
• Round-trip times - One measurement for each responding probe, three by default.

The first line shows the destination, maximum number of hops (default 30), and packet size (default 60 bytes).

Interpreting the Results #

Asterisks (* * *) indicate that no response was received for that hop. This can happen when:

• The router is configured to not respond to traceroute probes.
• A firewall is blocking the packets.
• The packets were lost due to network congestion.

Increasing latency at one intermediate hop does not prove that the router or its incoming link is slow. Routers can deprioritize or rate-limit traceroute responses while forwarding normal traffic without delay.

Persistent high latency that begins at one hop and continues through later hops and the destination is more useful. Repeat the trace before treating it as a path problem. Even then, traceroute narrows the area to investigate but cannot identify the exact link because every measurement includes the return path.

Several addresses on one hop line often appear when the probes take different paths through equal-cost multipath routing. A route change during the trace can produce the same result, and traditional traceroute may expose different paths because its UDP destination port changes with every probe. Multiple addresses do not by themselves indicate a fault, but the displayed hops may not form one end-to-end route.

Hop Annotations #

A hop line sometimes prints a short code after a round-trip time:

 7  203.0.113.9 (203.0.113.9)  24.512 ms !X

The code comes from the ICMP “Destination Unreachable” message the router sent back, and it tells you why the probe could not continue:

Of these, !X is the most useful. A router or firewall on the path is rejecting your probes explicitly, which is different from the silent * * * case. !H means the reporting router could not reach the destination host. Near the end of a trace, this can happen when the last-hop router cannot deliver the packet, for example because the target is offline.

Common Options #

The traceroute command accepts several options to customize its behavior:

• -n - Do not resolve IP addresses to hostnames. This speeds up the output by skipping DNS lookups.
• -m max_ttl - Set the maximum number of hops (default is 30).
• -q nqueries - Set the number of probe packets per hop (default is 3).
• -w waittime - Set the time in seconds to wait for a response (default is 5).
• -I - Use ICMP ECHO packets instead of UDP.
• -T - Use TCP SYN packets instead of UDP, port 80 by default. Requires root privileges.
• -U - Use UDP packets sent to one fixed port, 53 by default, instead of incrementing the port on every probe.
• -p port - Set the destination port for UDP or TCP probes.
• -s source_addr - Use the specified source IP address.
• -i interface - Send packets through the specified network interface.

Skip DNS Resolution #

To speed up the trace and display only IP addresses, use the -n option:

traceroute -n google.com

The output shows numeric IP addresses without hostnames:

traceroute to google.com (142.250.185.78), 30 hops max, 60 byte packets
 1  192.168.1.1  1.234 ms  1.102 ms  1.056 ms
 2  10.0.0.1  12.345 ms  12.234 ms  12.123 ms
 3  203.0.113.1  15.678 ms  15.567 ms  15.456 ms

This is useful when DNS resolution is slow or when you only need IP addresses.

Change Maximum Hops #

By default, traceroute stops after 30 hops. To change this limit, use the -m option:

traceroute -m 15 google.com

This limits the trace to 15 hops maximum.

Change Number of Probes #

To send a different number of probe packets per hop, use the -q option:

traceroute -q 1 google.com

This sends only one probe per hop, resulting in faster but less detailed output.

Use ICMP Instead of UDP #

By default, Linux traceroute uses UDP packets. Some networks block UDP, so you can use ICMP ECHO packets instead:

sudo traceroute -I google.com

Use TCP Instead of UDP #

For networks that block both UDP and ICMP, you can use TCP SYN packets:

sudo traceroute -T google.com

You can also specify a port, such as port 443 for HTTPS:

sudo traceroute -T -p 443 google.com

This is useful for tracing routes through firewalls that only allow specific TCP ports.

Trace IPv6 Routes #

To trace IPv6 routes, use the -6 option:

traceroute -6 ipv6.google.com

Specify Source Interface #

If your system has multiple network interfaces, you can specify which one to use:

traceroute -i eth0 google.com

Or specify the source IP address:

traceroute -s 192.168.1.100 google.com

If you are not sure which interface the kernel would pick on its own, check the routing table first with ip route .

traceroute vs tracepath #

Linux systems often include tracepath, which is similar to traceroute but does not require root privileges and automatically discovers the MTU (Maximum Transmission Unit) along the path.

Use tracepath for quick traces without root access:

tracepath google.com

Use traceroute when you need more control over the probe method or when tracepath does not provide enough information.

traceroute vs tracert #

Windows ships tracert rather than traceroute. Both tools answer the same question, but they share neither their defaults nor their option names, so a command copied from a Windows guide will not run on Linux.

The probe type is the largest difference. tracert sends ICMP Echo Request packets, while Linux traceroute sends UDP packets. A path that looks broken on Linux but fine on Windows is often a network that filters UDP and allows ICMP. Use -I to get the closest match to tracert behavior:

sudo traceroute -I example.com

The everyday options map like this:

Both commands stop after 30 hops by default. Watch the timeout units when you translate a command: tracert /w takes milliseconds and defaults to 4000, while traceroute -w takes seconds and defaults to 5.

Practical Examples #

Diagnose Slow Connections #

If a website is loading slowly, trace the route to identify where the delay occurs:

traceroute -n example.com

Look for a latency increase that continues through the remaining hops and the destination across repeated traces. Ignore an isolated slow response when later hops return to normal, since that router is still forwarding traffic without the same delay. When no persistent increase appears but the connection remains slow, the cause may be intermittent path loss, the transport, or the application. Use tcpdump to inspect the actual connection traffic.

Check if a Host is Reachable #

If ping shows packet loss, use traceroute to find where packets are being dropped:

traceroute google.com

Hops showing * * * followed by successful hops indicate a router that does not respond to probes but forwards traffic. If all remaining hops show * * *, later devices may be filtering or rate-limiting replies. The trace alone cannot locate the failure, so confirm whether the destination is reachable with the protocol you are troubleshooting.

Trace Through a Firewall #

If standard UDP probes are blocked, try ICMP or TCP:

sudo traceroute -I google.com
sudo traceroute -T -p 80 google.com

TCP traceroute treats both a reset from a closed port and a SYN/ACK response from an open port as evidence that it reached the destination. If the trace completes but the service remains unavailable, use nmap to check whether the port is open, closed, or filtered.

Compare Routes to Different Servers #

To understand routing differences, trace routes to multiple servers:

traceroute -n server1.example.com
traceroute -n server2.example.com

This helps identify whether traffic to different destinations takes different paths through your network.

Quick Reference #

Troubleshooting #

All hops show * * *
Your system received no replies to the default UDP probes. Try ICMP (-I) or TCP (-T) instead. If those methods also show asterisks, the probes or their replies may be filtered, or the destination may be unreachable. This result alone does not identify where the failure occurs.

Only the first hop responds
Your local router responds, but later devices do not. Downstream filtering, reply rate limiting, and routing problems can all produce this result. Test the destination with the protocol you are troubleshooting and, if possible, compare the result from another network before contacting your network administrator or ISP.

Trace never completes
The destination may be unreachable, later replies may be filtered, or the path may exceed the maximum hop count. Increase the limit with -m 60 only when the trace reaches the default 30-hop limit. A higher limit will not help when asterisks begin earlier in the route.

High latency at a specific hop
A single hop with high latency does not always indicate a problem. Routers often deprioritize ICMP responses. If the final destination has acceptable latency, the intermediate high latency may not affect actual traffic.

Latency increases then decreases
This can occur due to asymmetric routing, where the return path differs from the outbound path. The times displayed include the round trip, so a longer return path can inflate the displayed latency.

Permission denied
The -T option requires root privileges. The -I option may also require them when your group is outside the system’s ping_group_range. Run the command with sudo.

FAQ #

What is the difference between traceroute and ping?
ping tests whether a destination is reachable and measures round-trip latency. traceroute shows the path packets take and the latency at each hop along the route. Use ping for basic connectivity checks and traceroute for diagnosing where problems occur.

Why do some hops show asterisks?
Asterisks (* * *) mean no response was received. The router may be configured to ignore traceroute probes, a firewall may be blocking them, or the packets may have been lost. This does not necessarily mean the router is down.

What is the default protocol used by traceroute?
On Linux, traceroute uses UDP by default. On Windows, tracert uses ICMP. You can switch Linux traceroute to ICMP with -I or TCP with -T.

How do I trace the route on Windows?
Windows uses tracert, as in tracert example.com. It sends ICMP by default and uses slash-style options, so see the traceroute vs tracert table above when you need to translate a command in either direction.

What does TTL mean in traceroute?
TTL (Time to Live) is a field in the IP packet header that limits the packet’s lifespan. Each router decrements the TTL by 1. When it reaches 0, the router discards the packet and sends an ICMP “Time Exceeded” message. Traceroute uses this mechanism to discover each hop.

How can I trace the route to a specific port?
Use the -p option with TCP (-T) or UDP to specify the destination port:

sudo traceroute -T -p 443 example.com

Is there an alternative to traceroute for continuous diagnostics?
mtr combines ping and traceroute in a single, continuously updating view and is useful for ongoing packet loss and latency checks.

Conclusion #

If UDP probes are blocked on your network, fall back to sudo traceroute -I (ICMP) or sudo traceroute -T -p 443 (TCP to port 443). The TCP form is most likely to pass through stateful firewalls.

For more options, refer to the traceroute man page by running man traceroute in your terminal.

About the authors

Dejan Panovski

Dejan Panovski is the founder of Linuxize, an RHCSA-certified Linux system administrator and DevOps engineer based in Skopje, Macedonia. Author of 1000+ Linux tutorials with 20+ years of experience turning complex Linux tasks into clear, reliable guides.

View author page