All Tools

Traceroute

Map the network path to any destination.

Traceroute maps the network path packets take to reach a destination, hop by hop. It sends probes with incrementing TTL (Time-To-Live) values; each router along the path decrements the TTL and returns an ICMP "time exceeded" when it hits zero, revealing each intermediate hop.

Use this tool to troubleshoot network connectivity — identify where packets are being dropped, discover high-latency hops, understand routing paths between networks, and diagnose DNS resolution issues at each hop. It's essential for debugging slow websites, VPN connections, and multi-network architectures.

The trace runs from our server location — results may differ from your local network due to geographic routing differences.

google.comcloudflare.comgithub.com
Want the full picture?
Run a free Website Health Check →

Common questions

A traceroute maps the network path between your location and a target host, showing each hop (router) along the way and the latency at each step.

Asterisks mean the router at that hop did not respond within the timeout. This is common and does not necessarily indicate a problem with the final destination.

Yes. Enter a domain or IP address. Some networks block traceroute packets, which may result in incomplete paths.

What traceroute reveals

Traceroute maps the network path from our probe host toward a destination by recording intermediate routers (hops) and their response times. When a site is slow or unreachable for some networks, the path often shows where delay or blackholing begins — useful evidence for hosts and ISPs.

When to use traceroute

  • Diagnosing regional slowness that ping alone cannot explain
  • Checking whether traffic leaves your ASN as expected after a BGP or CDN change
  • Finding the hop where timeouts start during an outage
  • Comparing paths before and after switching upstream providers

How to read hop output

Early hops are usually your probe’s local network and transit. Stars (*) often mean a hop rate-limits ICMP; they are not always a failure. A sudden RTT jump that persists on later hops usually marks the congested or distant segment. The final hop should match the destination; if it never appears, filtering or an unreachable host is likely.

Common mistakes

  • Treating every starred hop as “broken”
  • Comparing absolute RTT across different probe locations without context
  • Stopping at the first timeout instead of checking whether HTTPS still works

Example scenario

After a DNS cutover to an anycast CDN, some users still hit a distant POP. Traceroute from our region showed an unexpected detour through a congested peer. Updating CDN steering rules shortened the path and brought TTFB back in line with the speed test baseline.

Limitations

Paths are from our server’s vantage point. Load balancers and firewalls may hide or rewrite hops. Combine with Ping Test and DNS Lookup for a fuller picture.

Related resources

Ping Test · Speed Test · IP Geolocation · Website Health Check