What Is Traceroute? How to Use and Read Tracert Output

What is traceroute?

Traceroute is a network diagnostic command that shows which routers (hops) your packets cross on the way to a destination and how long each step takes. Windows names it tracert, while macOS and Linux name it traceroute. You use it to find where a website slows down or drops out.

In short, the command draws a map of the route. When you open a website, your packets do not travel over one cable. They pass from your home router to your internet provider, then through backbone networks, and finally into the data center that hosts the server. So traceroute lists that chain hop by hop.

We answer the question "what is traceroute" in plain terms here. Besides that, we cover the commands on all three operating systems, how to read the output, and the situations that raise false alarms. Ping and round trip time get a separate article, so we do not repeat them. Our explanations rely on primary sources such as Microsoft Learn, the Linux man pages and RFC 792.

How does traceroute work, and what is the TTL trick?

Every IP packet carries a TTL (time to live) field in its header. IPv6 calls the same field the hop limit. Also, each router lowers the value by at least one before it forwards the packet. When the value reaches zero, the router drops the packet and sends an ICMP Time Exceeded message back to the sender. RFC 792 defines that message as type 11.

Traceroute exploits this behavior on purpose. First, it sends a packet with a TTL of 1. As a result, the first router drops it and answers with its own address. Then traceroute retries with a TTL of 2, so the second router reveals itself. Then the loop continues until the destination answers or the tool hits its maximum hop count.

• Router reply: an ICMP Time Exceeded message gives you that hop's address and the round trip time.
• Destination reply: Windows receives an ICMP echo reply (type 0), while the default Linux UDP probe ends with an ICMP port unreachable message.
• Timeout: if no reply arrives, the line shows an asterisk (*).
• Probe count: Linux traceroute sends three probes per hop by default, so each line shows three times.

So what is traceroute in one line? It is a discovery tool. Guessing the route is not its job. Instead, it reveals the routers that your packets actually crossed, one after another.

How do you use the tracert command on Windows?

Open Command Prompt or PowerShell from the Start menu and type the destination name. In the examples below, replace example.com with your own domain. By default the command also follows up to 30 hops.

tracert example.com
tracert /d example.com
tracert /d /h 20 /w 2000 example.com

According to Microsoft Learn, the /d parameter stops the lookup of router names, which speeds up the result. The /h parameter sets the maximum number of hops, and the default is 30. Likewise, /w sets how long to wait for each reply in milliseconds, and the default is 4000. Finally, /4 and /6 force IPv4 or IPv6.

Also, the Microsoft tracert reference says the command sends ICMP echo requests. As a result, a destination that filters ICMP can leave the last lines blank. We explain below why that is not always a problem.

How do you use the traceroute command on macOS and Linux?

First, open a terminal and type the command directly. On some Linux distributions the tool does not come preinstalled. On Debian and Ubuntu, the command sudo apt install traceroute installs the package. However, macOS ships with the command.

traceroute example.com
traceroute -n example.com
traceroute -n -m 20 -q 2 -w 2 example.com

According to the Linux man page, -n skips name lookups, -m sets the maximum hop count, -q sets the number of probes per hop, and -w sets the wait time. The defaults are 30 hops, 3 probes and 5 seconds. The traditional method sends UDP packets that start at port 33434. As a result, an ICMP port unreachable reply tells you the packet reached the destination.

The same page lists -I for ICMP echo, -T for TCP SYN, and -4 or -6 for the IP version. However, the macOS version comes from BSD, so its option set can differ. Read man traceroute on your own system before you rely on a flag. For the full option list, see the Linux traceroute man page.

What is traceroute and how does it differ from ping?

Ping tells you whether the destination answers and how long the round trip takes, as a single number. However, traceroute shows the same journey step by step. In other words, ping answers "is there a problem?" while traceroute asks "where on the path is the problem?" Neither replaces the other, so you use them together.

In practice, you first ping the target to see whether it answers. If it answers but the site feels slow, you then run traceroute to inspect the path.

What do the lines in a traceroute output mean?

The output below is fictional. We picked the addresses from blocks that the standards set aside for documentation, so they do not describe a real network.

traceroute to example.com (203.0.113.10), 30 hops max, 60 byte packets
 1  192.0.2.1 (192.0.2.1)  1.2 ms  1.0 ms  1.1 ms
 2  198.51.100.1 (198.51.100.1)  8.4 ms  8.1 ms  8.6 ms
 3  * * *
 4  198.51.100.37 (198.51.100.37)  12.9 ms  13.2 ms  12.8 ms
 5  203.0.113.1 (203.0.113.1)  14.0 ms  13.7 ms  14.2 ms
 6  203.0.113.10 (203.0.113.10)  14.5 ms  14.1 ms  14.3 ms

Next, we read the output line by line.

• The first column is the hop number. Line 1 is usually the router in your home or office.
• The three time columns show the round trip time of the three probes for that hop, in milliseconds.
• The last column shows the router name or IP address. Names come from reverse DNS, so some lines show only the address.
• The three stars on line 3 mean that hop did not answer.

The Microsoft reference says the displayed path lists the near side interface of each router, the one closest to the sender. Therefore, do not draw firm geographic conclusions from a name or address. Finally, line 6 is the destination itself, and the trace ends there.

How do you read a traceroute output step by step?

Asking what is traceroute is only the first step, because the real skill is reading the output. If you scan the lines in the same order every time, you make fewer wrong calls. The list below is the simple checklist we follow when we first look at an output.

1. Check line 1. It is usually your own router, and its time should be tiny. If it looks bad, inspect your local network first.
2. Follow the times from top to bottom. On a healthy path the values climb slowly like a staircase, so a sudden and lasting jump stands out.
3. Separate the star lines. If later hops answer, you can ignore the stars.
4. Focus on the last line. The time at the destination is the closest value to what your visitors feel. Middle lines only give clues.
5. Repeat the measurement. Run the same command at another time and from another network, then compare the results.

If you skip these five steps, you raise needless alarms. For example, complaining to your provider because of one slow line often leads to a pointless email thread. Treat the output as a hypothesis, not as a verdict.

If traceroute shows a star (*), is the connection down?

Usually not. In other words, a star only means that no reply arrived within the timeout. The Microsoft reference states that some routers do not return Time Exceeded messages for expired packets, so they stay invisible to the command. That said, the packet still crosses those routers.

To read a star correctly, look at the rest of the output. In practice, the distinctions below help in daily work.

• A star in the middle while later hops answer: the router filters or limits ICMP replies, and traffic flows.
• A star on the last hop while the site opens in a browser: the destination server or firewall ignores traceroute probes.
• Stars on every line after one hop and the site does not open: there may be an outage or a filter on the path. Repeat the test from another network, for example mobile data.
• A star on the very first line: the problem most likely sits in your local network. Check the router and the cable.

If the site never loads, you can also check it from outside with our is it down tool. That way, you separate a problem on your connection from a problem that affects everyone.

What is traceroute telling you when one hop shows high latency?

However, a high time on one hop is not proof of a problem by itself. The deciding test is simple: if the high value continues on later hops and at the destination, the problem is real. If only one line is high and the next lines return to normal, that router most likely gives low priority to ICMP replies.

The MTR documentation says this openly. It notes that some modern routers give ICMP echo packets lower priority than other traffic, so the reliability that mtr reports can look much worse than the real reliability. Therefore, the same logic applies to traceroute lines.

We made up these numbers for illustration, so treat them as an example calculation. Moreover, distance matters. On a path that crosses an ocean, a clear rise in time is normal. Never trust a single measurement, and run the command several times at different hours.

Which situations raise false alarms in traceroute?

When we read a traceroute output, we first ask "is this really a problem?" The cases below produce the most false alarms.

1. One hop with a high time: the router prioritizes its own traffic and answers ICMP late. If later hops are low, do not worry.
2. Stars in the middle: a router with ICMP replies off does not block traffic.
3. A star on the last hop: the destination may filter ICMP or UDP probes, while web traffic on TCP port 443 flows fine.
4. Jitter across three samples: three samples are too few for statistics, so collect hundreds with mtr.
5. Guessing geography from hop names: reverse DNS names can mislead. Do not assume the packet crossed a city because the name says so.
6. Different IPs on the same hop number: load balancing makes this normal, not a fault.

These cases share one cause. Traceroute does not look at the routers themselves. It looks at the ICMP replies that the routers choose to send. In other words, you see the trace that traffic leaves behind, not the traffic itself.

What does a real network problem look like in traceroute?

However, real problems tend to be consistent. You see the same degradation in the same place, repeatedly, and it carries through to the destination. The table below lists example readings, not a firm diagnosis. Always confirm with a second measurement before you decide.

Every row ends with the same advice: repeat the measurement and compare it with a second source. Blaming a provider on one command output is often unfair.

How do load balancing and asymmetric routing mislead traceroute?

Two points on the internet do not need a single path. Routers can spread traffic across several equal cost paths. In that case, the probes that traceroute sends one after another can take different routes, and you see different addresses on the same hop number. The output can look inconsistent for that reason.

Second, direction is a trap too. Specifically, traceroute only shows the forward path. However, the reply packets can take a different route back. The time you see is the sum of going and returning. Therefore, a high time on one hop can come from the return path instead of the forward path.

• If you can run the same test from the destination side, compare both directions.
• Providers sometimes offer public "looking glass" pages that show the route from inside their own network.
• On Windows, the /R parameter tests the reverse route with an IPv6 routing extension header. The Microsoft reference defines it for IPv6.

In short, read the output like a snapshot taken from one angle, not like a full photograph. Collecting more than one sample is the safer habit.

What is MTR and how does it differ from traceroute?

In the words of its official man page, mtr combines the functionality of the traceroute and ping programs in a single tool. It sends packets with low TTL values and reports the response percentage and response times along the route. If you know what traceroute is, mtr is easy to learn. Traceroute gives you a single snapshot, while mtr measures the same path continuously, so it suits fluctuating problems better.

mtr -r -w -n -c 100 example.com

• -r turns on report mode. mtr runs for the given number of cycles, prints statistics and exits.
• -c sets the number of cycles (packets). The example above takes 100 measurements.
• -w prints the full host names without cutting them, and -n skips name lookups and shows only IPs.
• The report columns are Loss%, Snt, Last, Avg, Best, Wrst and StDev.

On Windows, Microsoft points to the pathping command for a similar job. It reports latency and packet loss for each router and link. You can read the mtr man page for details. However, installation and permissions differ by system.

When do you need TCP or UDP probes in traceroute?

Classic traceroute uses ICMP or UDP, so some firewalls block it. The traffic that carries visitors to your site is TCP, for example port 443 for the web. If you want a more realistic view of the path to an ICMP filtered target, you can use a TCP SYN probe on Linux.

sudo traceroute -T -p 443 example.com

According to the man page, -T selects TCP SYN probes and -p sets the destination port. This option sends raw packets, so it may need administrator rights. Also, the method does not give the same result on every network, because some networks limit SYN probes too.

The Windows tracert command uses ICMP echo and offers no TCP option. Therefore, if you want the same effect on Windows, you need a different tool. For most site owners this detail does not matter. In short, a plain traceroute or tracert is usually enough for a first try.

What does traceroute show about a slow website, and what does it miss?

If you ask what is traceroute worth on a slow site, the honest answer is that it only measures the network path. A slow page usually has its cause in the page itself, not in the network. For example, large images, heavy JavaScript files, slow database queries and a server that sends the first byte late come first. None of these show up in a traceroute output.

So the right order is this: measure in the browser first, then look at the network path if you need to. A Lighthouse performance test shows the bottlenecks on the page side. Our articles on how site speed affects SEO and on how page speed affects ecommerce sales support the same order.

• Network path suspicion: trouble from other countries, failures on some carriers, drops at certain hours.
• Page side suspicion: slowness on every network, heavy images, many third party scripts.
• Server side suspicion: a long time to first byte, slowdowns at busy hours.

If your ad budget flows to a slow site, fix the technical base first. In our SEO consulting and web design work, we make this split at the start.

How do you combine traceroute with DNS, SSL and IP tools?

You rarely solve an access problem with one command. The order below helps you separate network path, domain and certificate problems from each other.

1. Confirm that the domain resolves to the right IP address with the DNS lookup tool.
2. Check who owns that IP address with the IP lookup tool and the WHOIS lookup.
3. Then run traceroute and see whether the path reaches the destination.
4. If the connection works but the browser shows a warning, inspect the certificate with the SSL checker.
5. If you use IPv6, run the IPv6 test and try the IPv6 path separately with tracert /6 or traceroute -6.

IPv4 and IPv6 paths can differ. As a result, a site can open on one and fail on the other. You can find the basics of certificates in our article on what an SSL certificate is.

How do you test the IPv6 path with traceroute?

The path to an IPv6 destination can cross different routers than the IPv4 path. A site can therefore load fine over IPv4 and stay slow over IPv6. To test both paths separately, you name the protocol explicitly.

tracert /6 example.com
traceroute -6 example.com

The Microsoft reference says /4 and /6 force IPv4 or IPv6. In the Linux man page, -4 and -6 do the same job. IPv6 addresses show up as hexadecimal groups that colons separate, and a documentation address looks like 2001:db8::1. In other words, the reading logic matches IPv4 exactly.

However, if the destination has no IPv6 address or your network offers no IPv6, the command fails. In other words, that is not a malfunction. If you want to check your IPv6 support first, the IPv6 test gives you a quick answer.

Which security and privacy points matter when you run traceroute?

Traceroute sends small packets and is harmless on its own. Still, a few rules apply. First, use it only on your own systems or on targets you have permission to test. Scanning many targets in a row can look like network reconnaissance on the other side.

• When you post an output on a public forum, hide your public IP address and any internal network addresses.
• When you send an output to provider support, you may need to share your source IP. Do that only through the support channel.
• Hop names can contain customer or company details. Review the output before you share it.
• Before you write heavy or automated scanning scripts, read the target's terms of use.

For a broader view of security, see our article on the OWASP Top 10. Traceroute is not a vulnerability scanner, and it does not show risks at the application layer.

What is traceroute not good for: when should you leave it to your hosting provider?

We are a digital marketing and web team, not a hosting company. So we draw an honest line: if part of the path sits inside your provider's or a carrier's network, you cannot fix that part. Routing policies, peering agreements and network device settings are outside your access.

• If the delay or outage starts at hops inside your provider's network, open a support ticket.
• When the problem shows up only from one carrier, only the parties involved can fix the link between carriers.
• Should your shop take payments and the outage continue, inform the provider first, then deepen your own tests.
• On shared hosting, do not try to change server settings. You do not have the rights anyway.

Instead, what you can do is collect good evidence. As a result, a ticket with the right output gets a faster answer. To weigh network quality and support when you pick a provider, read how to choose web hosting. Also, a ready backup strategy keeps you calm during an outage.

Which traceroute output should you send to hosting support?

In practice, support teams can do very little with a message that says "the site does not open". A concrete output narrows the problem fast. We suggest adding the list below to your ticket.

1. When you saw the problem: date, time and time zone.
2. The target domain and the IP address it resolved to during the test.
3. Your test network: home internet, office or mobile data.
4. The tracert or traceroute output, and if possible a 100 cycle report that you took with mtr.
5. The result of the same test from another network, and which networks show the problem.
6. Whether the problem is constant or appears only at certain hours.

To save the output to a file, you can redirect it. On Windows, the > sign writes the tracert output to a text file. On Linux and macOS, the tee command writes to the screen and to a file at once.

tracert example.com > tracert.txt
traceroute -n example.com | tee traceroute.txt

Paste the output as text instead of a screenshot. That way the support team can copy the lines into their own tools. Also, share your own IP address only inside the support channel.

What are the most common traceroute mistakes?

In practice, mistakes usually come from interpretation, not from the command. The list below sums up the errors we see most often.

• Drawing a conclusion from one output. Take several measurements instead.
• Stretching a star or a high time on a middle hop over the whole path.
• Skipping the network path because ping works, or the opposite: calling the site dead because traceroute shows stars.
• Reading geography or the provider from a reverse DNS name.
• Mistaking a page speed problem for a network problem and working only with traceroute.
• Sharing the output publicly without a privacy check.

So the practical answer to "what is traceroute" is this: a simple but strong tool that shows the path. If you read it correctly, it helps you tell whether the problem sits with you, with the provider or on the route. For speed, accessibility and technical decisions on your website, you can contact us through our web design service.