Writing

Traceroute is showing * * *: is it actually broken?

Published 14 September 2026

Almost certainly not. An asterisk means a router declined to introduce itself, which it is entitled to do and which says nothing about whether it forwards your traffic. Ask which of the four patterns you are looking at, because only one of them is a problem.

The one check that settles it

Look below the asterisks. Did any later hop answer?

If yes, you are done: the packets reached that later router, so they passed straight through the silent one. Nothing is wrong. Nothing was dropped. The router in between simply chose not to send you a reply.

If no later hop answered and the trace never reached the destination, you have the one ambiguous case, and there is a way to resolve it further down.

On Windows it says "Request timed out" instead

Windows tracert prints Request timed out. where Linux and macOS print * * *. It is the same event described in different words: no reply came back from that hop within the timeout. Everything below applies identically.

Do not confuse it with ping reporting "Request timed out", which is a different question: there you are asking the destination itself, and silence means the destination did not answer. In a traceroute it is an intermediate router declining to identify itself, which is routine.

The four patterns

1. Asterisks in the middle, later hops answer: fine

 9  be-1001-ar-sp01.example.net    10  12  12
10  *                              *   *   *
11  50.173.202.102                 11  31  13
12  216.198.79.1                   12  12  12  ← destination

Hop 10 is silent and hop 11 replied. Your packets went through hop 10 to get to hop 11. This is the most common pattern in any traceroute across the public internet, and it is not a fault of any kind.

The router at hop 10 may be configured not to send ICMP time-exceeded messages, a common hardening choice. It may also generate them at a low priority and drop them under load. Either way it is forwarding perfectly well.

2. Some probes at one hop, not all: rate limiting

 7  bundle-2103-tcr04.example.net   *   *  21

One reply out of three. Routers commonly rate-limit how many ICMP errors they will generate per second, because generating them costs CPU that would otherwise forward packets. Answering one probe in three is that limit doing its job. It is not 67% packet loss.

3. Asterisks from the first hop onward: look closer to home

If every hop is silent from hop 1, the problem is not out on the internet. Either your own network blocks ICMP outbound, something on your machine is filtering it, or the tool does not have the privileges it needs. Traceroute from a different network and see whether the behaviour follows you.

4. Asterisks to the end, destination never reached: the ambiguous one

11  50.173.202.102                 11  31  13
12  *                              *   *   *
13  *                              *   *   *
...
30  *                              *   *   *

This is the only pattern worth investigating, and even here the most likely explanation is benign: a great many servers sit behind a load balancer or firewall that answers nothing, so the trace dies at the last router that will talk to you. The destination is often perfectly healthy.

Do not resolve this with more traceroute. Check whether the service is actually up:

• Open a TCP connection to the port you care about. If port 443 accepts a connection, the host is reachable and traceroute was simply being ignored.
• If nothing answers on any port either, then you have a real problem. You also know roughly where the path stopped.

Two things traceroute asterisks are routinely mistaken for

They are not packet loss

A router refusing to generate a reply tells you nothing about whether it forwards data. Traceroute measures the router's willingness to talk about itself; your traffic is a completely separate path through the same box.

If you want to know about loss, ping the destination and look at the loss figure there. Loss at an intermediate hop, as reported by traceroute, is very often just rate limiting.

Hop latency is not path latency

A hop showing 200 ms while the hops after it show 20 ms does not mean that router is slow, and it certainly does not mean it is congested. It means that router took its time generating a courtesy reply: again, low priority work compared with forwarding.

The number that matters is the round-trip time to the final hop. Read the last line; the rest of the traceroute output is a set of diagnostics about individual routers, not a cumulative measure of your connection.

So when should you worry?

• The destination never answers and no port on it accepts a connection.
• Round-trip time to the destination climbs and stays high, rather than one hop in the middle looking slow.
• Ping to the destination shows sustained loss: not traceroute to a hop in the middle.
• The path changes repeatedly between runs and never completes.

Everything else (silent hops, one missing probe, a spike at hop six) is the internet behaving normally while declining to explain itself.

Why this cannot be a web page

You may have noticed there is no "run a traceroute" button here. That is deliberate. A traceroute run from a web server measures the path from that server to the destination, which is not your path and tells you nothing about your problem. Browsers cannot send ICMP, so any web-based traceroute is really someone else's traceroute.

A DNS lookup is different: the answer is the same wherever you ask from, which is why that one works fine in a browser.

If the path completes but large transfers still stall, that is a different fault with the same innocent-looking traceroute: SSH connects then hangs covers path MTU black holes.

For another error that sends people to the wrong place, see unable to get local issuer certificate: one message, two opposite causes.

If the trace never reaches the destination and ping reports something rather than silence, the message itself narrows it: destination host unreachable means a router answered and said no.