Knowing how to read traceroute comes down to one habit: follow the latency trend from the first hop to the destination instead of reacting to individual lines. A jump that persists to the last hop, or asterisks that never stop, marks where trouble begins; a single slow or silent hop in the middle usually means nothing.
In short. Read the trend, not the individual hops. Routers deprioritise the ICMP replies traceroute depends on, so a middle hop showing high latency or asterisks means nothing if the hops after it are fast — a problem is only real when it persists to the destination.
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) in both the Linux and the Windows layout, what the !H-style annotations mean, 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 is traceroute in networking?
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 desktop OS ships with a version of it: tracert on Windows, traceroute on macOS and most Linux distributions (minimal server images sometimes lack it — install it with sudo apt install traceroute or sudo dnf install traceroute). 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 (starting at 33434), but the TTL-expiry principle is identical.
The trace ends when the destination itself answers: with an ICMP Echo Reply for ICMP probes, with ICMP "Port Unreachable" for UDP probes (nothing listens on those high ports), or with a SYN-ACK or RST for TCP probes. If the destination never answers, the tool keeps going until it hits the hop limit — 30 by default on both Windows and Linux.
Traceroute protocol: UDP, ICMP or TCP
Which probe type a tool sends matters, because firewalls treat the three protocols differently. A trace that dies with asterisks over UDP can finish cleanly over TCP port 443, since almost every web server's firewall lets that port through.
| Tool | Platform | Default probe | Switch protocol | Best for |
|---|---|---|---|---|
tracert | Windows | ICMP Echo | Not available | Quick path check |
pathping | Windows | ICMP Echo | Not available | Per-hop loss statistics on Windows |
Test-NetConnection -TraceRoute | Windows PowerShell | ICMP | Not available | Scripts; lists hop addresses without per-hop timings |
traceroute | Linux | UDP | -I ICMP, -T TCP (both usually need sudo) | Flexible tracing, firewalled targets |
traceroute | macOS | UDP | -I ICMP, -P tcp | Same as Linux, BSD syntax |
tracepath | Linux | UDP | Not available | No root needed; also reports path MTU |
mtr | Linux, macOS | ICMP | -u UDP, -T TCP | Loss and jitter over many probes |
How do I use 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.
Traceroute command on Windows 10 and 11
# IP addresses only, no reverse DNS lookups (much faster)
tracert -d example.com
# Force IPv4 or IPv6
tracert -4 example.com
tracert -6 example.com
# Wait 1000 ms per reply instead of the default 4000 ms
tracert -w 1000 example.com
# Per-hop loss statistics (runs for several minutes)
pathping -n example.com
# PowerShell alternative
Test-NetConnection example.com -TraceRouteThe full flag list is in Microsoft's tracert command reference. pathping first prints the route, then spends a few minutes sending many probes to every hop and reports loss per hop — it is the closest thing Windows has to mtr.
Traceroute command on Linux
# Numeric output, no DNS lookups
traceroute -n example.com
# ICMP probes, like Windows (needs root)
sudo traceroute -I example.com
# TCP SYN probes to port 443 — gets through most firewalls (needs root)
sudo traceroute -T -p 443 example.com
# Limit to 20 hops, 5 probes per hop, 2-second wait
traceroute -m 20 -q 5 -w 2 example.com
# No root at all; also shows path MTU
tracepath example.com
# 100-probe mtr report, wide hostnames, suitable for pasting into a ticket
mtr -rwc 100 example.comTraceroute command on macOS
macOS ships the BSD traceroute, so the basics match Linux: traceroute -n example.com for numeric output, traceroute -I example.com for ICMP, and traceroute -P tcp -p 443 example.com for TCP probes to port 443. mtr is not preinstalled; after brew install mtr run it with sudo mtr example.com, since it needs raw sockets.
How to read traceroute 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.
How to read tracert output on Windows
Windows prints the same information in a different order: the three RTT columns come first and the router address last. Replies faster than a millisecond show as <1 ms, and a silent hop prints Request timed out. instead of a hostname.
Tracing route to example.com [93.184.216.34]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 8 ms 9 ms 8 ms 10.0.0.1
3 12 ms 11 ms 13 ms 91.200.15.1
4 * * * Request timed out.
5 25 ms 24 ms 25 ms 213.248.65.9
6 88 ms 90 ms 88 ms 152.195.44.1
7 89 ms 88 ms 89 ms 93.184.216.34
Trace complete.The reading rules do not change: Request timed out. on hop 4 followed by healthy hops is a router that ignores probes, and Trace complete. means the destination answered. Two other messages are worth recognizing. reports: Destination host unreachable. or reports: Destination net unreachable. means the router named on that line has no route onward — a real routing failure at that point. A trace that runs to hop 30 with nothing but timeouts, and never prints the destination, means your probes stop getting answers from some point on.
Annotations after RTT values on Linux and macOS
Unix traceroute sometimes appends a flag after a time value. These come from ICMP "Destination Unreachable" replies and are far more specific than asterisks, because a router is explicitly telling you why the packet stopped.
| Annotation | Meaning | Typical cause |
|---|---|---|
!H | Host unreachable | The last router cannot reach the target host (host down, ARP failure on its subnet) |
!N | Network unreachable | No route to the destination network at that router |
!P | Protocol unreachable | The target does not accept the probe protocol |
!X | Communication administratively prohibited | A firewall or ACL is rejecting the probes |
!F | Fragmentation needed | Packet larger than the path MTU with "don't fragment" set |
!S | Source route failed | Rare; source routing is disabled almost everywhere |
Reading the hostnames and IP addresses
The addresses themselves tell you whose network a hop belongs to. Private ranges from RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) on the first hops are your home or office network, or your ISP's internal access network. Addresses in 100.64.0.0/10 are carrier-grade NAT space defined in RFC 6598, which means your ISP shares public addresses between customers. Reverse DNS names of backbone routers often encode the interface, the router role, and a city or airport code, such as xe-0-0-1.cr1.nyc1.example.net. Treat those names as hints, not proof: they are maintained by hand and are sometimes out of date. To see which organization owns a hop's IP, look up its autonomous system number.
What does * mean in traceroute output?
An asterisk means that one probe got no reply before the timeout expired. That is all it proves: the reply may have been lost, the router may have been too busy to generate it, or the router may be configured never to send it. The classic beginner mistake is to panic at a * or a high RTT on an intermediate hop. In most cases it is normal. Where the asterisks appear is what tells you which case you are in.
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.
Asterisks from one hop to the end of the trace
When every hop after a certain point times out and the destination never appears, either the path is broken right after the last responding hop, or a firewall past that point drops your probe type. Test the second explanation before blaming the network: repeat the trace with TCP to port 443 (sudo traceroute -T -p 443 example.com) and check whether the site loads in a browser. If the site works and only UDP or ICMP traces die, it is a filter, not an outage.
Only the last hop times out
If every router answers but the destination line stays * * *, the target host or its cloud firewall simply drops ICMP and unused UDP ports. Many cloud servers are configured this way. A TCP trace to the port the service actually listens on will normally complete.
One asterisk among three values
A line like 5 213.248.65.9 24.6 ms * 24.9 ms means one of three probes went unanswered. On its own it is noise — usually the router rate-limiting its ICMP replies. It becomes meaningful only if the same kind of loss shows up on every hop after it, including the destination.
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.
Two more effects distort individual hops. First, asymmetric routing: traceroute shows only the forward path, but every reply travels back by whatever route the router chooses, which can be longer. A hop can look slow because its reply took a detour you cannot see. If you can, run a trace from the server back to your IP as well. Second, MPLS tunnels in carrier backbones can hide several physical routers behind one line, so a single hop may show a large jump that is really the combined distance of a long tunnel.
Distance explains a lot of latency. Light in optical fiber travels at roughly two-thirds of its speed in a vacuum, about 200,000 km per second, which works out to roughly 1 ms of round-trip time for every 100 km of cable between you and the router. A sudden jump of 70–80 ms that persists to the destination is usually an ocean crossing, not congestion.
How to analyze a tracert: a step-by-step method
- Start at the bottom. Check whether the destination answered and what its RTT is. If it answered with stable, reasonable latency, the path is basically healthy regardless of what the middle looks like.
- Find the first hop where latency rises and stays up. Compare each hop with the ones after it. A jump counts only if every later hop keeps the higher value.
- Find the first hop where loss starts and never recovers. Isolated asterisks and single slow hops are ignored.
- Identify the owner of that hop. Use the address range, the reverse DNS name, and an ASN lookup to decide whether it belongs to you, your ISP, a transit carrier, or the target's host.
- Repeat the test. Run it several times or use
mtrorpathping, and try TCP probes to rule out firewall filtering. - Compare with a second vantage point. A trace from another network or an online traceroute tool shows whether the problem is on your side or near the destination.
Common traceroute patterns and what they mean
| Pattern in the output | What it means | Next step |
|---|---|---|
| Silent or slow hop, later hops normal | Router deprioritizes ICMP; no real problem | Ignore it |
| Latency jumps at hop N and stays high to the end | Long link or congestion starting at hop N | Check distance; if the link is short, report it with an mtr report |
* * * from hop N to hop 30 | Path broken after hop N-1, or probes filtered | Retry with TCP 443; test the site in a browser |
| Only the destination times out | Target drops ICMP/UDP probes | Trace with TCP to the service port |
| The same two addresses alternate until hop 30 | Routing loop | Contact the operator that owns those addresses |
!H, !N, !X or "Destination net unreachable" | A router explicitly refuses or has no route | Owner of that hop must fix routing or ACLs |
| Loss already at hop 1 or 2 | Local Wi-Fi, cable, or router problem | Retest over Ethernet, reboot the router |
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.
When you contact an ISP or a hosting provider, send a text copy of the output rather than a screenshot, the time the test ran with the time zone, your public IP, and ideally an mtr -rwc 100 or pathping -n report. A single run of plain traceroute is easy for support to dismiss; a 100-probe report showing loss that persists to the destination is not.
How do I check my traceroute?
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.
An online traceroute runs from a server, not from your computer, so it is a second vantage point: if the trace from the server reaches the site cleanly while yours stalls, the problem is on your side of the internet. To find out which organization runs a suspicious hop, paste its IP into the ASN lookup.
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. If distance is the issue, see why a website is slow abroad; if you are not sure the network is to blame at all, work through isolating a web outage by layer.
FAQ
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, output layout, 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. Within one region a few milliseconds to a few tens of milliseconds is typical; 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.
