Understanding Traceroute

Traceroute maps the network path from a source to a destination, revealing every router along the way and how long each hop takes. It turns an opaque "the internet is slow" problem into a specific, locatable bottleneck.

What Is Traceroute?

Traceroute is a diagnostic tool that discovers the sequence of routers (hops) between a source and a destination. For each hop, it measures the round-trip time (RTT) — giving you a hop-by-hop latency profile of the entire network path.

While ping tells you whether a host is reachable and roughly how long it takes, traceroute tells you where along the path the latency is being introduced — and where it breaks entirely.

Traceroute is available on all major operating systems: traceroute on Linux/macOS and tracert on Windows. This tool runs a server-side traceroute using ICMP, streaming each hop to your browser as it is discovered.

How Traceroute Works

Traceroute exploits the Time To Live (TTL) field in IP packets. Every IP packet carries a TTL value that starts at some number and is decremented by 1 at each router. When a router decrements TTL to zero, it drops the packet and sends back an ICMP "Time Exceeded" message to the sender — and that message reveals the router's IP address.

2.1 The TTL Mechanism

Traceroute sends packets with progressively increasing TTL values — starting at TTL=1, then TTL=2, TTL=3, and so on. Each value forces a different router to send back a "Time Exceeded" response, exposing the router's identity and measuring its RTT:

TTL sent	Which router responds	What we learn
TTL = 1	Your first-hop router (usually your gateway)	Local network RTT
TTL = 2	The second router in the path (ISP edge)	ISP access latency
TTL = 3	Third router	ISP backhaul latency
TTL = n	The nth router	Cumulative path latency to hop n
TTL = destination	The target host replies with Echo Reply	Total end-to-end RTT

2.2 Three Probes Per Hop

For each TTL value, traceroute sends three probes and records each RTT separately (RTT 1, RTT 2, RTT 3). Sending multiple probes gives a more reliable picture — a single probe result can be a statistical outlier. If all three RTTs are similar, the hop is stable. If they vary widely, the hop is experiencing jitter or load balancing across different paths.

Reading the Results

The results are displayed as a table, one row per hop. Here is what each column means:

Column	Meaning
Hop	Sequential hop number. Hop 1 is your closest router; the last hop is the destination.
Host	The hostname (if PTR record exists) and/or IP address of the router at this hop.
RTT 1 / RTT 2 / RTT 3	Round-trip times for each of the three probes sent at this TTL. An asterisk (*) means that probe received no response.

Hop hostnames often encode geographic and network information. An ISP might name a router core1.lon.isp.net — revealing it is a core router in London. Cloud providers use structured naming conventions that identify the region and function of each router.

🔁 RTT should increase monotonically — usually

In a well-functioning network, RTT generally increases with each hop as packets travel further. However, it is completely normal for a later hop to show a lower RTT than an earlier one — this happens when routers deprioritise ICMP responses under load, or when asymmetric routing causes replies to take a shorter path back. What matters is the final destination RTT and any sudden large jumps between specific hops.

Understanding Asterisks (* * *)

An asterisk means a probe received no response within the timeout window. A hop showing * * * does not necessarily mean the hop is broken. There are several common and benign reasons for asterisks:

ICMP rate limiting

Many routers prioritise forwarding traffic over generating ICMP Time Exceeded responses. Under load, ICMP replies are throttled or dropped entirely — the router still forwards packets normally.

Firewall filtering

Network operators often block inbound ICMP to their infrastructure for security reasons. The router is present and forwarding, but it simply refuses to respond to traceroute probes.

Asymmetric routing

The forward path may traverse a router that does not send ICMP responses on the return path, causing asterisks even though the end-to-end path is functional.

Actual packet loss or unreachability

If asterisks appear at a specific hop and all subsequent hops also show asterisks, the path is genuinely broken at that point — the destination is unreachable beyond that router.

✅ The key rule for asterisks

If the destination hop responds (the final row shows a real RTT), then all the asterisks along the way are harmless — those routers simply chose not to reply to ICMP probes. Only be concerned about asterisks if the destination itself is unreachable or if subsequent hops never recover after a run of * * * rows.

Analysing Latency Patterns

The shape of RTT values across hops tells you a lot about where problems exist. Here are the key patterns to look for:

Gradual, steady increase

Normal

RTT climbs smoothly from hop 1 (2ms) to the destination (45ms). This is healthy — each hop adds a small amount of propagation delay reflecting physical distance. No action needed.

Large jump at one hop

Investigate

RTT is flat at 20ms for hops 1–5, then jumps to 120ms at hop 6 and stays elevated. This indicates a slow or congested link between hop 5 and hop 6. The problem is locatable — contact the operator of hop 6's network.

High RTT at mid-hops, lower at destination

Usually benign

A router at hop 8 shows 200ms, but the destination at hop 12 shows only 40ms. This is ICMP deprioritisation — the router at hop 8 processed your probe slowly but forwarded actual traffic at normal speed. The destination RTT is what matters.

Asterisks followed by recovery

Usually benign

Hops 6–8 show * * * but hops 9–12 respond normally and the destination is reached. The routers at hops 6–8 are simply not responding to ICMP. The path is intact.

Asterisks that never recover

Problem

From hop 7 onwards, every row shows * * * and the destination is never reached. Traffic is being dropped or routed incorrectly beyond hop 6. The network path is broken at that point.

How to Use This Tool

1
Enter a target
Type any hostname (e.g., google.com, 1.1.1.1) or IP address. The tool pre-fills your public IP so you can immediately trace the path back to your own connection.
2
Set max hops
The default is 30 hops, which is sufficient for most internet paths. Increase to 40–64 if tracing to distant destinations or if the path seems to be truncated before reaching the target.
3
Click Traceroute
The server starts probing the path and streams each hop to your browser in real time as it is discovered — you will see hops appear one by one.
4
Watch RTT values
Look for the hop where RTT jumps significantly — that is usually the bottleneck. Note the hostname to identify which network operator is responsible.
5
Click Stop if needed
If the trace is taking too long or has clearly stalled on a run of asterisks, click Stop to end the test early.

🔍 Traceroute vs MTR

Traceroute takes a single snapshot of the path. MTR (My TraceRoute) runs continuously and builds a statistical picture — showing packet loss and average latency per hop over many probes. If you need to detect intermittent issues or characterise a path over time, use the MTR tool instead of a one-shot traceroute.

Practical Use Cases

Pinpoint where latency is introduced

When a destination feels slow, traceroute shows you exactly which hop is adding the delay. A sudden RTT jump at hop 8 means the problem is between hop 7 and hop 8 — narrowing the scope from 'somewhere on the internet' to a specific link.

Identify routing inefficiencies

Traffic should take an efficient geographic path. Traceroute can reveal traffic being routed through unexpected countries or continents — a common cause of high latency that has nothing to do with congestion.

Diagnose ISP handoffs

Each time traffic crosses from one AS to another, latency often jumps. Traceroute makes peering points visible — if latency spikes at a specific AS boundary, that peering link may be congested.

Detect where packet loss starts

If hops 1–6 respond cleanly but hops 7+ show asterisks, loss begins at hop 7. Knowing the first hop where loss appears is essential for opening a useful support ticket with your ISP or hosting provider.

Confirm CDN and anycast routing

Traceroute to a CDN hostname shows which edge node you are being served by. If you are routing to a distant PoP instead of a nearby one, a CDN misconfiguration or DNS issue may be responsible.

Verify VPN and proxy paths

Traceroute confirms that traffic is actually flowing through your VPN exit node or proxy. If the first external hop is your VPN server's IP, the tunnel is working as expected.