Traceroute shows every router (hop) between the source and destination on the internet, revealing the complete network path. For each hop, it shows the router's IP address, hostname (from reverse DNS), the round-trip time (RTT) to that hop, and optionally the carrier that owns the IP. The key diagnostic value is that by comparing RTT values between consecutive hops, you can identify exactly where latency increases — pointing directly to which network segment or carrier is responsible for the delay. Traceroute also reveals routing anomalies like suboptimal geographic paths, routing loops, and traffic asymmetry.

Asterisks (* * *) in a traceroute result mean that specific router did not send back an ICMP Time Exceeded response — it timed out. This is extremely common and does NOT necessarily indicate a problem. Many backbone routers and carrier-grade equipment are configured to drop or rate-limit ICMP Time Exceeded messages to reduce processing load and avoid being a useful diagnostic target for network mapping. As long as hops after the asterisks continue to respond, the path is working through that router — it's just invisible to traceroute. You should only be concerned about asterisks if they appear at every hop from a certain point onward, indicating a potential blockage or the destination being unreachable.

Tracert is simply the Windows version of the traceroute command — the name comes from "trace route" abbreviated differently. Functionally they are nearly identical. The main technical difference: Windows tracert uses ICMP Echo Requests (same as ping), while the original Unix/Linux traceroute uses UDP packets sent to high-numbered ports. The results are typically very similar for most paths. Linux also has traceroute -I (ICMP mode) which behaves identically to Windows tracert. The Windows PowerShell equivalent is Test-NetConnection -TraceRoute. On Linux, mtr (My Traceroute) is generally preferred over traceroute for ongoing diagnostics as it runs continuously and shows packet loss statistics.

This is a common observation and the explanation is straightforward: servers prioritise serving actual HTTP requests over responding to ICMP traceroute probes. When a server is under load, it processes HTTP requests first and queues ICMP responses — this makes the traceroute RTT appear higher than actual HTTP response time. Load balancers and CDN edge nodes in particular often respond to ICMP from a different queue than HTTP traffic. Additionally, some servers respond to ICMP from a different interface or CPU core than HTTP traffic. The correct way to test actual service response time is using our HTTP Headers tool or Ping Test, which measures real HTTP response latency.

Our online traceroute runs from our server — it shows the network path and routing from our infrastructure to the destination. Your local traceroute runs from your device — it shows your personal path including your home router, ISP local network, and the ISP's backbone routing. Both are valuable but answer different questions. Our tool tells you how the destination is routed from the internet generally. Your local traceroute shows your specific ISP's routing path to that destination. For diagnosing your personal connection issues (e.g., why your gaming latency is high), running traceroute from your own machine is more relevant. For checking if a server is reachable from the internet or verifying a server's routing, our tool is more appropriate.

MTR (My Traceroute / Matt's Traceroute) is a network diagnostic tool that combines traceroute and ping into a single continuously running test. While traceroute takes a single snapshot of the path, MTR sends continuous probes and computes statistics for each hop: packet loss percentage, minimum/average/maximum/standard deviation RTT. This reveals intermittent problems invisible to a single-run traceroute — for example, a router that drops 5% of packets will only occasionally appear as * in a standard traceroute, but MTR will clearly show "5.0% loss" at that hop consistently. MTR is available on Linux (apt install mtr), macOS (brew install mtr), and Windows (WinMTR). For diagnosing ongoing connection problems, MTR run for 100–200 cycles gives far better diagnostic data than a single traceroute.

A routing loop occurs when two or more routers send packets to each other in a circle — each router believes the next hop toward the destination is the other router. In a traceroute, this appears as the same IP address repeating at multiple hop numbers, with the hop count increasing indefinitely without reaching the destination. Routing loops are caused by misconfigured routing tables, BGP route withdrawal without proper convergence, or a failure in dynamic routing protocols (OSPF, EIGRP, BGP) that temporarily creates inconsistent routing tables across the network. They typically self-resolve within seconds to minutes as routing protocols reconverge, but while active they make the affected destination unreachable. TTL prevents packets from circulating forever — they are discarded when TTL reaches 0.

Yes — completely free, no signup, no account, no API key required. Our online traceroute runs from our server infrastructure and traces up to 30 hops to any destination, showing each hop's IP address, hostname (from reverse DNS), RTT, ISP information, and country. Results include a per-hop visual RTT bar chart and direct links to IP Lookup and other diagnostic tools for each hop. We do not store traceroute results or log the destinations you query.