Try the Traceroute

Traceroute Tool — Map the Network Path to Any Host & Find Latency

By sadiqbd · June 6, 2026

Traceroute Tool — Map the Network Path to Any Host & Find Latency

Traceroute shows you the path your data actually takes

Ping tells you if a host is reachable and how long a round trip takes. Traceroute goes further: it maps every hop between you and the destination — every router the packet passes through on its journey — and shows the latency at each step.

When connectivity is slow or broken, traceroute identifies exactly where the problem occurs: whether it's on your local network, at your ISP, somewhere in a transit provider's backbone, or close to the destination server.

How Traceroute Works

Traceroute exploits the TTL (Time to Live) field in IP packets.

  1. Traceroute sends a packet with TTL=1 to the destination
  2. The first router (hop 1) decrements TTL to 0 and sends back an ICMP "Time Exceeded" message
  3. Traceroute records this router's IP and the round-trip time
  4. It sends a packet with TTL=2
  5. The second router decrements TTL to 0 and sends back "Time Exceeded"
  6. This continues until the destination is reached (it returns ICMP Echo Reply instead)

Each iteration reveals one hop and its latency. The result is a complete map of the route from source to destination.

Reading Traceroute Output

traceroute to example.com (93.184.216.34)
 1  192.168.1.1        1.2 ms    1.1 ms    1.0 ms   [Home router]
 2  10.20.30.1         8.4 ms    8.2 ms    8.6 ms   [ISP gateway]
 3  203.190.10.1      12.3 ms   11.9 ms   12.1 ms   [ISP backbone]
 4  122.161.0.1       15.2 ms   14.8 ms   15.0 ms   [Transit provider]
 5  * * *                                            [No response]
 6  23.209.11.99     110.2 ms  110.8 ms  109.9 ms   [CDN edge]
 7  93.184.216.34    112.4 ms  111.9 ms  112.1 ms   [Destination]

Columns: hop number, IP address, three round-trip time measurements

* * *: No response — the router at hop 5 is either blocking ICMP, filtering TTL-expired responses, or temporarily unreachable. This doesn't mean the connection is broken — packets may still be forwarded; only the "Time Exceeded" response is suppressed.

Key things to look for:

  • Where latency jumps sharply: A sudden increase between two hops indicates a slower link (undersea cable, long-distance hop) or congestion at that point
  • Where * * * appears repeatedly: If you see multiple consecutive * * * followed by a successful hop, those intermediate routers are filtering ICMP — normal. If * * * appears all the way to the end, something is blocking the path
  • Where the trace stops: If traceroute doesn't reach the destination, the hop where it stops (or the last responding hop) points to the problem

How to Use the Traceroute Tool on sadiqbd.com

  1. Enter the hostname or IP address — the destination to trace the route to
  2. Run the trace — the tool executes traceroute from its server to the target
  3. Read the hop-by-hop results — IP addresses, hostnames (where available), and latency at each hop

Note: Like the ping tool, this traces from sadiqbd.com's server, not from your device. For tracing from your own location, use the terminal:

  • Windows: tracert example.com
  • Mac/Linux: traceroute example.com

Real-World Examples

Diagnosing a slow website from your server

Your VPS in Singapore reports slow response times when connecting to a US-based API endpoint.

Traceroute from your server to the API shows:

Hop 1–3: Singapore → Singapore ISP (5ms)
Hop 4–6: Singapore → Hong Kong transit (25ms)
Hop 7: * * *
Hop 8–10: Hong Kong → Los Angeles (165ms — large jump)
Hop 11–13: Los Angeles → Dallas (185ms)
Hop 14: Dallas API endpoint (188ms)

The 140ms jump at hop 8 is a trans-Pacific submarine cable — expected, not a problem. Total latency of 188ms is reasonable for Singapore-to-Dallas. If your application requires low latency, deploy closer to the API.

Identifying a congested transit hop

A CDN you use for assets has been slow during business hours. Traceroute reveals:

Hop 5: Transit provider router — 12ms (off-peak), 280ms (peak hours)

The same hop that takes 12ms at night takes 280ms during business hours — severe congestion at a specific transit provider router. The CDN provider should know about this; it's in their upstream's network, not yours.

Debugging intermittent connectivity to a database

Your application server occasionally can't reach a remote database. Traceroute during an outage:

Hop 1–4: Local to ISP (normal)
Hop 5: * * *
Hop 6: * * *
Hop 7: * * *
[Trace ends — destination unreachable]

The trace dies at hop 5. Either a router in the path has gone down, or a firewall rule has been added that blocks traffic to the destination. Compare to a successful trace to identify what changed.

Verifying CDN routing

You want to confirm your CDN is routing users to the nearest edge node. Traceroute to your CDN-served domain:

Final hops: ... → singapore-edge.cdn.com (45ms)

Traffic is going to the Singapore edge — correct for your Asian users. If it were routing to the US edge (200ms+), there'd be a CDN configuration issue.

Common Traceroute Patterns

* * * followed by a successful hop

Normal — the intermediate router filters ICMP "Time Exceeded" responses but still forwards packets. The trace continues past it.

Latency increases then stays high

A link with high inherent latency (international cable) — expected. Latency doesn't decrease after a high-latency hop because the signal transit time is non-negotiable.

Latency fluctuates wildly on one hop

Congestion at that router. Packets are queueing before being forwarded, causing variable delay.

Trace stops mid-way

The destination or an intermediate router is actively blocking traffic, or the routing path is broken. The last responding hop is the last point of successful delivery.

Round-trip times decrease on a later hop

Possible due to asymmetric routing — the forward and return paths are different. The return path for hop N+1 might be shorter than for hop N, causing the measured RTT to decrease.

Traceroute vs. MTR

MTR (My Traceroute) combines ping and traceroute, continuously sending packets and showing packet loss and latency statistics at each hop in real time. It's more informative for intermittent issues because it catches packet loss that sporadic traceroute snapshots might miss.

MTR is available as a command-line tool (mtr example.com) and as WinMTR for Windows. For persistent connectivity problems, MTR over 30–60 seconds gives much richer data than a single traceroute.

Tips for Using Traceroute

Run during both normal and problematic times. A trace during normal operation establishes a baseline. A trace during a slow period reveals which hop's latency has changed.

Don't be alarmed by * * * in the middle of an otherwise successful trace. Many routers suppress ICMP responses. If the trace reaches the destination, the path is functional.

Compare traces from multiple vantage points. If you're troubleshooting a user-reported issue, a trace from your server to the destination is useful, but a trace from the user's location (or a server in their region) is more directly relevant.

Look at the jump between hops, not just absolute values. A hop at 150ms after one at 20ms indicates a 130ms latency addition — significant. A hop at 150ms after one at 145ms adds only 5ms — negligible.

Frequently Asked Questions

What does it mean when traceroute shows * * * for every hop? All routers on the path are filtering ICMP Time Exceeded responses. This sometimes happens on networks where ICMP is broadly blocked. The destination may still be reachable — try a ping to check connectivity.

Why are some IP addresses labelled * with no hostname? Reverse DNS isn't configured for that IP, so there's no hostname to display. The IP itself is still shown for manual lookup.

Can traceroute cross firewalls? Traceroute stops where a firewall blocks the probe packets (ICMP or UDP, depending on implementation). The last successful hop before a firewall typically shows the network boundary.

What's the difference between traceroute on Linux/Mac and tracert on Windows? Traceroute (Linux/Mac) uses UDP probes by default. Tracert (Windows) uses ICMP Echo Requests. This causes differences in which firewalls block it and how routers respond. The online tool uses a server-side implementation that behaves like Linux traceroute.

Is the traceroute tool free? Yes — completely free, no sign-up required.

Traceroute transforms "the internet is slow" from a vague complaint into a specific, actionable diagnosis. Whether you're troubleshooting latency, verifying routing, or investigating an outage, the hop-by-hop map shows you exactly where things go right — and where they don't.

Try the Traceroute tool free at sadiqbd.com — map the complete network path to any host and find where latency originates.

Try the related tool:
Open tool