Traceroute (called tracert on Windows) maps the path a packet takes from your computer to a server, listing every intermediate router (hop) and how long each takes to respond. You read the output top to bottom: a sharp jump in latency or a run of asterisks * * * points to the hop where network or routing trouble begins.
This article explains how traceroute works at the TTL and ICMP level, how to run it on Windows, Linux, and macOS, how to read each output column (hop number, three RTT values, asterisks), and how the location of a problem hop tells you who is at fault — your network, your ISP, or the target server. We also cover the classic trap: why intermediate hops "lie" about latency.
What traceroute is and why it matters
Traceroute is a diagnostic tool that builds a list of routers along the path to a destination and measures the delay to each one. Unlike ping, which only answers "is the host up or not," traceroute shows where exactly along the route the connection is lost or latency climbs. It is the key tool when a site loads slowly but a simple ping reveals nothing obvious.
Every OS ships with it: tracert on Windows, traceroute on Linux and macOS. The advanced version, mtr, combines traceroute and ping, continuously probing each hop and showing packet-loss percentage in real time.
How traceroute works: TTL and ICMP
The mechanism relies on the TTL (Time To Live) field in the IP packet header. Each router along the path decrements TTL by one; when TTL reaches zero, the router discards the packet and sends back an ICMP "Time Exceeded" message (Type 11, per RFC 792).
Traceroute exploits this cleverly: it sends the first packet with TTL=1, which "dies" at the first router, and that router reveals its address. Then TTL=2 reaches the second hop, and so on. By incrementing TTL, the tool coaxes each router along the path to identify itself in turn. Windows uses ICMP Echo requests; classic Unix traceroute uses UDP packets to high ports, but the TTL-expiry principle is identical.
How to run traceroute
The command is nearly identical across systems — only the tool name differs. Open a terminal (on Windows, Command Prompt or PowerShell) and type one of the commands below, replacing example.com with your target domain or IP.
# Windows
tracert example.com
# Linux / macOS
traceroute example.com
# mtr — traceroute + ping in real time (Linux/macOS)
mtr example.comUseful flags: on Windows, tracert -d skips name resolution (faster, IP only) and tracert -h 30 sets the max hop count. On Linux, traceroute -n also skips DNS, traceroute -I switches to ICMP (like Windows), and traceroute -T switches to TCP, which helps when a firewall drops UDP.
How to read the output: columns and asterisks
Each line of output is one hop. On the left is the hop number, then the router's hostname and/or IP, and on the right three round-trip time (RTT) values in milliseconds — traceroute sends three probes per hop for reliability. The table below decodes each element of a line.
| Line element | What it means |
|---|---|
| Hop number (1, 2, 3…) | Sequential router position from you to the target; hop 1 is usually your router/gateway |
| Hostname / IP | Address of the router that answered at this hop; the name comes from reverse DNS |
| RTT ×3 (ms) | Three round-trip measurements; some variation is normal — watch the overall trend |
* (asterisk) | A probe got no reply within the timeout: packet lost OR the hop simply ignores traceroute |
* * * | All three probes went unanswered at this hop |
A real output example, explained
traceroute to example.com (93.184.216.34), 30 hops max
1 192.168.1.1 1.2 ms 1.1 ms 1.3 ms
2 10.0.0.1 8.5 ms 9.1 ms 8.7 ms
3 91.200.15.1 12.4 ms 11.9 ms 13.0 ms
4 * * *
5 213.248.65.9 24.6 ms 25.1 ms 24.9 ms
6 152.195.44.1 88.2 ms 90.5 ms 87.9 ms
7 93.184.216.34 89.1 ms 88.7 ms 89.4 msBreakdown: hop 1 (192.168.1.1) is the home router, latency around 1 ms. Hop 2 is the ISP gateway. Hop 4 shows * * *, but hops 5–7 respond normally — meaning the fourth router simply does not answer probes (this is not a connectivity loss). The jump from 25 to 88 ms between hops 5 and 6 is a long backbone leg (likely an intercontinental link), not a fault: latency stays stable all the way to the target.
What the asterisks and high RTT mean
The classic beginner mistake is to panic at a * or a high RTT on an intermediate hop. In most cases it is normal. Let's look at two scenarios.
Asterisks * * * in the middle of the route
If a hop does not answer but the hops after it respond normally, there is no problem. Many routers deliberately deprioritize or block ICMP "Time Exceeded" replies for security and to reduce load — they forward your traffic just fine but won't spend resources answering traceroute. The alarming pattern is only when asterisks run from some hop all the way to the end: that means packets genuinely stop getting through.
Why intermediate hops "lie" about latency
A high RTT on a single intermediate hop, when later hops show lower latency again, is not a problem. An intermediate hop's RTT does not reflect end-to-end delay; it reflects how quickly that specific router found time to reply to a housekeeping ICMP. Forwarding transit traffic is higher priority for it, so the traceroute reply can lag. Look at the RTT of the last hop (the target) and the overall trend, not a single "bump" in the middle.
How to find the culprit
The location of the problem hop tells you whose responsibility it is. Use the table below as a guide.
| Where latency / loss appears | Likely cause | What to do |
|---|---|---|
| Hop 1–2 (your router, gateway) | Your local network, Wi-Fi, or cable | Check the router, switch to a wired connection, reboot |
| First ISP hops (3–5) | Your internet provider's network | Capture the output and contact ISP support |
| Backbone/transit hops in the middle | An intermediate carrier (usually beyond your control) | Often temporary; rarely fixable on your side |
| Last hop (target) or second-to-last | The target server or its hosting/data center | Problem is on the site's side; notify its owner/host |
| Loss from the middle to the end | Route breaks at that hop | Problem lies with that hop's operator |
Key rule: loss must persist to the end of the route to count as real. Loss on a single hop that recovers on the next is ICMP deprioritization, not a fault. Run traceroute several times, or use mtr, to see a sustained loss percentage rather than a random spike.
How to check your route
Don't want to deal with the command line? Use the free route traceroute tool right in your browser: it shows every hop and RTT in a clean table. To separate a latency problem from packet loss, also run a ping check to the target host. If ping is steady but the site is slow, look for the bottleneck in traceroute; if ping jumps and drops packets, the link itself is the problem.
Worth reading on the topic: how to fix high ping and packet loss, the difference between latency and throughput, and how TCP differs from UDP.
Frequently Asked Questions
What is the difference between tracert and traceroute?
They are the same tool on different operating systems. tracert is the Windows command and uses ICMP Echo requests. traceroute is the Linux and macOS command and sends UDP packets by default. The underlying logic via TTL expiry is identical; only the command name, default protocol, and set of flags differ.
Why does traceroute show asterisks but my internet works?
Asterisks * * * mean a particular router did not reply to traceroute's housekeeping probe. Many routers deliberately ignore or deprioritize such replies for security and performance, while still forwarding your real traffic normally. If the hops after the asterisks respond fine, there is nothing to worry about.
What RTT counts as normal?
It depends on distance. To sites within your own country, 5–40 ms is normal; to other continents, 100–250 ms is expected because of physical distance and the speed of light in fiber. The absolute number matters less than stability: sharp spikes and rising loss are more worrying than a consistently high but even latency.
Traceroute showed high latency on a middle hop — is that a problem?
Most likely not. If later hops show lower latency again, a high RTT in the middle is just one router's slow reply to a housekeeping ICMP, not real delay for your traffic. Judge by the RTT of the last hop (the target) and the top-to-bottom trend, not by a single "bump."
How do I tell who is at fault — me, my ISP, or the site?
Look at which hop the sustained problems begin on. The first or second hop is your local network. Early hops with your ISP's hostnames are its network. The last or second-to-last hop is the target server and its hosting. Problems on backbone hops in the middle are usually beyond your control.
Why use mtr instead of plain traceroute?
mtr combines traceroute and ping: it continuously probes each hop and shows the loss percentage and average latency in real time. That is more reliable than a single traceroute run, because one stray * may be random, whereas a sustained loss percentage across dozens of probes is a genuine signal of a problem.