--- title: Free Traceroute description: Trace the network path hop by hop, with packet loss and average latency at each hop (MTR-style). canonical: https://watchfor.io/traceroute-online --- [Back to all free tools](/free-tools) # Traceroute Trace the network path hop by hop, with packet loss and average latency at each hop (MTR-style). [How to use this tool](/blog/how-to-run-a-traceroute-online) Result No result yet Fill in the form above and run it — the result appears here. Monitor this 24/7 — get alerted when a failure is confirmed. [Start free](/auth/sign-up) Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our [Terms](/legal/terms). ## What is Traceroute ? Traceroute reveals the hop-by-hop network path packets take from us to your target — which routers they cross, how long each hop takes, where loss starts. When a service "works from here but not from there," traceroute is the diagnostic that tells you where in the path things go wrong. Not just that they go wrong. This tool runs an MTR-style probe (RFC 1393 spirit): sequential probes with incrementing TTLs, multiple probes per hop, percentages computed per hop. The output shows you a clean per-hop table — hostname/IP, round-trip time, packet loss at that hop and beyond — instead of the single-shot, often misleading classic traceroute output where one bad packet looks like a black hole. ## How it works MTR-style probing is just clever use of the TTL field: - 1 Send a packet with TTL=1 — Every IP packet has a Time-To-Live field. Each router decrements it; when it hits 0, the router drops the packet and sends back an ICMP TTL Exceeded reply. By starting with TTL=1, we force the first hop to identify itself. - 2 Increment TTL, repeat — TTL=2 reveals the second hop, TTL=3 the third, etc. Continue until either the target replies (we've reached the destination) or we hit the 30-hop limit. - 3 Multiple probes per TTL — Default 3 probes per hop (you can set 1–10). This is why MTR-style is more useful than classic traceroute — one probe might miss, three give you a percentage. A hop that drops 1/3 probes consistently is doing rate limiting on ICMP, not actually broken. - 4 Aggregate per-hop statistics — For each hop we report: hostname (or IP when it has no reverse DNS), loss% (probes that didn't return) and average RTT. A hop that answered none of its probes shows as "no reply". Some hops report no hostname — that's normal, many routers don't publish PTR records. ## When you'd use it ### "Why is the site slow only for some users?" A customer in Frankfurt says your US-hosted site is slow. Traceroute from a similar geographic origin to your service. The latency jump usually shows up at one specific hop — the transatlantic cable hand-off, a congested ISP peering point, a misconfigured BGP route. Now you know where to point the network team. ### Spotting routing changes Things were fine yesterday, broken today. Same target. Traceroute reveals a new hop in the path — usually means a BGP change rerouted you through a different ISP. Sometimes that's intentional (failover); sometimes it's a misconfigured route that needs reverting. ### Verifying CDN edge selection Your CDN is supposed to serve users from the nearest edge. Traceroute from a target region — does the final hop's IP belong to a CDN node geographically close to the source? If not, your CDN's routing isn't doing what you think, and you'll want to investigate the GeoDNS or BGP anycast configuration. ### Tracking packet loss to specific hops End-to-end you see 5% packet loss. Where? Run traceroute. If hops 1-4 are 0% and hop 5 starts showing 5%+ loss that persists through hop 6, 7..., the problem is at or near hop 5. Contact whoever runs that hop — they're usually an ISP whose abuse address is in Whois on their IP block. ### Verifying inter-region cloud latency Multi-region application, trying to decide whether to run regional or to fall back to a central database. Traceroute between your regions tells you the physical path latency — much more honest than the cloud provider's advertised "low-latency inter-region links." ## Reading the result ### Hop number The position in the path, starting at 1 (your direct upstream). Hops 1-3 are usually your prober's ISP. Middle hops are tier-1 backbone providers. Last few hops are the destination network's ISP and the destination itself. ### Hostname / IP Reverse DNS lookup of each hop's IP. Some routers don't publish PTR records and show as just IP. Sometimes the hostname embeds useful info — ae-1.cr1.fra.de tells you Frankfurt; xe-0-1-0.r01.lax02 tells you LA. ISPs often follow naming conventions you can decode. ### Per-hop loss % Probes sent to this TTL that got no reply. Cumulative reading : 50% loss at hop 5 followed by 0% at hop 6 means hop 5 is rate-limiting ICMP (responding only sometimes) but actually forwarding traffic fine. If loss is 0% at hop 5 and 50% at hop 6 onward, hop 5 is the breaking point. ### Average RTT The mean round-trip time of the probes this hop answered, with a bar scaled to the slowest hop. The table shows the average only, not best and worst; to see the spread for a hop, run mtr yourself, where best and worst sit next to the average. ### Why hop latency sometimes drops mid-path You'll see RTT increase up to a peak then drop back. That's because the prior router is generating the ICMP TTL Exceeded reply on its slow control plane while the actual data plane is fast. The dropped RTT at the next hop is more representative of actual forward latency. ## Common pitfalls ### "Traceroute shows huge latency at hop X — is X the problem?" Not necessarily. Routers handle ICMP-generating tasks on a slow control-plane CPU; data-plane forwarding is on dedicated ASICs that are much faster. A 200ms RTT at hop X doesn't mean traffic through X takes 200ms — it means X took 200ms to generate the diagnostic reply . Look at whether hop X+1's RTT also jumps; if not, X is fine, it just hates ICMP. ### Path has timeouts at hops 5-7 then resumes Some routers drop or ignore ICMP TTL Exceeded entirely (security policy). Doesn't mean the packet didn't make it through — the next hop with a sensible config will reply normally. If your target ultimately responds, the path works despite the diagnostic gap. ### Path different than traceroute from your laptop Expected. Your laptop's path starts from your ISP; ours from our prober's ISP. They merge at some backbone provider but the first hops differ entirely. Free runs use the probe location nearest you; to diagnose your users' path, plans with location choice can run it from a region close to them. ### Traceroute completes without reaching the target Either: (1) target blocks ICMP entirely (so our probes get to it but it doesn't reply) — verify with a TCP port check; (2) target is more than 30 hops away, the limit this tool stops at (rare in practice); (3) there's a routing black hole en route. ## Run Traceroute on every change, not just once. Get alerted when an outage is confirmed — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 15 monitors. No card. [Start free](/auth/sign-up) ## Frequently asked questions What's the difference between traceroute and MTR? Classic traceroute sends one or three probes per hop and shows you a single snapshot. MTR runs continuously, accumulating statistics over many probes per hop, so transient packet drops don't look like permanent failures. We use MTR-style: multiple probes per hop, percentage statistics per hop. Why do some hops show as * * * or "no reply"? The router at that hop didn't reply to any of our probes within the timeout. Classic traceroute prints * * * and mtr prints ??? ; this tool shows "no reply" with no loss or latency figures, because nothing was measured. Three usual reasons: (1) the router is configured to silently drop ICMP TTL Exceeded for security, (2) the router is overloaded and rate-limiting ICMP, (3) the probe was lost in transit. If hops before and after respond normally, the unresponsive hop is usually just policy, not broken. Can traceroute help me debug a slow website? Partly. It shows network-level latency along the path to the server. If the path itself is slow or has loss, that's part of the story. But application-level slowness (slow database queries, large page weight) won't show up in traceroute — use HTTP Headers tool for the application response timing breakdown. Why does the same traceroute give different paths on different runs? ECMP routing. Many ISPs use Equal-Cost Multi-Path routing — multiple equally-good paths exist between two points, and traffic is balanced across them, often hashed by 5-tuple (src IP, dst IP, src port, dst port, protocol). Different runs can hash to different paths. What does 100% loss at the final hop mean? The destination IP isn't responding to ICMP. The path to it works (all middle hops respond) but the target itself blocks ICMP or doesn't reply. Verify the host is actually serving on its real ports with a TCP check. How do I know if a high-latency hop is the actual problem? Check the hop after it. If hop 5 shows 200ms and hop 6 shows 30ms, hop 5 is just slow to generate ICMP replies — actual traffic passes through fast. If hop 5 shows 200ms and hop 6 also shows 200ms+, then yes, that hop is genuinely adding latency to all traffic. Can I traceroute to an IPv6 address? Not in this tool: it traces over IPv4 only. IPv6 traceroute (using ICMPv6 Hop Limit Exceeded) works the same way, and MTR monitors can already run over IPv6. How many hops does the trace go? Up to 30, which covers nearly every internet path — most paths between two endpoints are 10 to 20 hops. A longer path (several VPN or tunnel layers) ends without reaching the target. ## Related network tools - [PingICMP echo request — round-trip time, jitter, packet loss.](/ping-test) - [Port CheckerTest TCP port reachability and optionally grab the server banner.](/port-checker) - [Blacklist CheckCheck an IPv4 address against the Spamhaus ZEN, SpamCop and Barracuda blocklists (a domain is checked through the address it resolves to).](/blacklist-checker) - [What Is My IPSee your public IPv4 / IPv6 address, approximate location (city, region, country), timezone and map coordinates — detected instantly from your connection, no signup.](/whats-my-ip) --- Canonical page: https://watchfor.io/traceroute-online · Site guide: https://watchfor.io/llms.txt