How to Read a Traceroute (Hops, Latency Spikes, and the Misread-Hop Trap)

CodexFuse Team · 2026-11-04T05:57:05.903Z · 15 min read min read

How Do You Read Traceroute Output?

Learning how to read a traceroute is simpler than the wall of numbers makes it look: a traceroute lists every router — each one a "hop" — between your computer and a destination, along with the round-trip time to each hop. This traceroute results explained walkthrough covers the columns, the asterisks, and the one misreading that sends people chasing the wrong router.

Reading a trace is a five-step method, and it works on every output you will ever see:

1. Run it the right way for your OS. On Linux or macOS, run traceroute example.com; on Windows, run tracert example.com.
2. Read each line left to right. Hop number, then the router's hostname or IP address, then one round-trip time (RTT) per probe — three probes per hop by default.
3. Do not add the times together. Each RTT is the full round trip from your machine to that hop and back, not the time for one link.
4. Treat asterisks as "no reply," not "broken." If routers after the asterisks answer normally, your traffic flowed straight through the silent one.
5. Look for problems that carry to the end. A latency spike or packet loss that persists through every later hop, including the destination, is real. One that vanishes at the next hop was the router deprioritizing its own replies.

Here is what a typical trace looks like (illustrative example):

$ traceroute example.com
 1  home-router (192.168.1.1)  1.204 ms  0.987 ms  1.112 ms
 2  100.64.0.1 (100.64.0.1)  9.318 ms  8.904 ms  9.105 ms
 3  core-isp.example.net (203.0.113.9)  12.318 ms  11.904 ms  12.055 ms
 4  * * *
 5  edge-isp.example.net (198.51.100.14)  148.211 ms  150.034 ms  149.876 ms
 6  192.0.2.25 (192.0.2.25)  31.402 ms  30.988 ms  31.115 ms

Hops 4 and 5 in that example are the two traps this guide defuses: hop 4's asterisks look alarming but mean nothing by themselves, and hop 5's 148 ms spike looks like the culprit but disappears at hop 6. If you only need the end-to-end number before digging into the path, run a ping test against the same destination first — ping gives you overall latency and loss, and traceroute tells you where along the path they happen.

What Do the Hop, Hostname, and RTT Columns Mean?

Each traceroute line answers three questions: which router answered (the hop number plus its hostname or IP), and how long each probe's round trip took (the RTT values). On Linux and macOS the order is hop number, gateway hostname or IP, then the round-trip time of each probe — the traceroute(8) manual page describes it exactly this way: three probes are sent at each TTL setting by default, and the line shows the TTL, the gateway's address, and each probe's round-trip time.

The three RTT values are not minimum, average, and maximum — they are three separate round-trip measurements, one per probe. Comparing them tells you about consistency: if one probe is slow and the other two are normal, that is usually noise; if all three rise together, the hop deserves a closer look. The hostname comes from reverse DNS, so a line can show a name, a bare IP, or both — the -n flag skips name resolution entirely when you want a faster, cleaner trace.

One rule to internalize early, because it is the most common arithmetic mistake in traceroute reading: never add hop latencies together. Each hop's RTT is cumulative from your machine to that hop, not the time for the link between two consecutive hops. If hop 8 reports 35 ms and the destination reports 42 ms, your end-to-end round-trip time is roughly the destination's 42 ms — not the sum of every line. On Windows the column order is slightly different — hop number, three RTT values in milliseconds, then the IP address or hostname in brackets — but the reading method is identical.

How Does Traceroute Find Each Hop?

Traceroute tricks routers into revealing themselves one at a time using the packet's Time to Live (TTL) field. It sends its first probes with TTL set to 1, then 2, then 3, and so on. Each router decrements the TTL before forwarding; when the TTL reaches zero, the router drops the packet and returns an ICMP "Time Exceeded" message to the sender — and the source IP of that message identifies the hop.

The probe type depends on your OS. Linux and macOS traceroute traditionally send UDP datagrams to "unlikely" destination ports — the first probe targets port 33434 and each subsequent probe increments the port by one — deliberately chosen so no application on the destination will process them. Windows tracert instead sends ICMP Echo Request packets with varying TTL values. That difference is why the end of a trace looks different per OS: a Linux UDP trace ends when the destination answers with ICMP "port unreachable" (nothing listens on those unlikely ports), while a Windows trace ends when the destination returns an ICMP Echo Reply. On IPv6 the same technique applies, except routers decrement the Hop Limit field instead of the TTL.

If one hop line shows several different addresses across its probes, that is not an error — it means the probes took different parallel paths, which happens with load-balanced links. Traceroute prints the address of whichever gateway answered each probe.

What Do Asterisks (* * *) in Traceroute Mean?

Asterisks mean exactly one thing: the router did not answer that probe within the timeout (five seconds per probe by default on Linux). The usual reasons are mundane — the router is configured not to generate ICMP responses, a firewall filters them, the responses are rate-limited, or the router's control plane simply gives traceroute traffic very low priority. None of these prove the path is broken. That is the complete traceroute asterisks meaning in one rule: asterisks report a missing reply, never a failed route — the route's health is decided by what the later hops show.

The decisive test is what happens after the asterisks. If every router beyond the silent hop answers normally, your packets obviously made it through that part of the network — the router forwarded your traffic fine and only declined to chat about it. A row of asterisks that continues all the way to the end, with the destination never reached, is a different story: that usually means a firewall is dropping the probes before they arrive, or the destination is more than 30 hops away (the default maximum).

Linux traceroute also prints ! annotations when a probe gets an ICMP "unreachable" message instead of a Time Exceeded reply: !H for host unreachable, !N for network unreachable, !P for protocol unreachable, !S for source route failed, !F for fragmentation needed, !X for communication administratively prohibited, and !<num> for any other ICMP unreachable code. Windows tracert does not use these symbols; it prints plain text such as "reports: Destination net unreachable" instead.

Why Is One Slow Hop Usually Not the Problem?

A hop's RTT measures how fast the router answers traceroute probes — not how fast it forwards your actual traffic — and routers deliberately give their own ICMP answers low priority. A latency spike at one hop that disappears at the next hop is almost always that deprioritization, not real congestion. This is the misread-hop trap, and misreading traceroute hop latency this way is the single most common beginner mistake in network diagnostics.

To see why, break a hop's RTT into its three real components: the time for your probe to reach the router, the time for the router to generate the ICMP Time Exceeded reply, and the time for that reply to travel back to you. Only the middle component is specific to that router, and it runs on the router's control plane — the same CPU that handles management tasks. Your data packets, by contrast, are switched by dedicated forwarding hardware at line rate without involving that CPU at all. So a busy router can be slow to answer probes while forwarding transit traffic perfectly.

The rule that resolves every ambiguous trace is the carries-to-the-end rule: a real delay persists through all subsequent hops, because every later probe also travels through the slow segment. Look back at the sample trace: hop 5 shows ~149 ms, but hop 6 is back to ~31 ms. If hop 5 were genuinely delaying forwarded traffic by 100+ ms, hop 6's probes — which pass through hop 5 — would show it too. They do not, so hop 5 was only slow at answering. The mtr manual page says the same thing in its BUGS section: modern routers give ICMP ECHO packets lower priority than other traffic, so the reliability a diagnostic tool reports for a router can be significantly lower than the router's actual reliability.

One more subtlety: every RTT is a round trip, and traceroute only shows you the forward path. The return path can be completely different at every hop, so you cannot assign all of a hop's latency to the forward direction shown on screen.

How to Find Which Hop Is Causing Packet Loss

Apply the carries-to-the-end rule to loss as well: if a hop shows packet loss but every later hop — including the destination — shows none, the router was only deprioritizing its own diagnostic replies. If the loss continues through every subsequent hop to the end, you have found a genuine problem on the path.

The classic false alarm is a mid-path hop reporting something dramatic like 40% loss while every hop after it reports zero. That router is not dropping 40% of your forwarded traffic — it is limiting how many ICMP replies it bothers to generate. Ignore it. A real loss signature looks different: loss appears at hop N and stays present at hops N+1, N+2, and the destination. Even then, remember the measurement is round-trip — the loss could be on the forward path before the first affected hop, or on the asymmetric return path, so a single snapshot is a lead, not a verdict.

The reliable methodology is repetition: run the trace several times and compare, because one snapshot only shows what one set of probes experienced. For anything that matters, upgrade to a tool that collects statistics over time — which is exactly what the next section covers.

tracert vs traceroute: What Is Different on Windows?

Same idea, different defaults: Windows tracert sends ICMP Echo Request probes, while Linux and macOS traceroute send UDP probes to unlikely high ports. Because firewalls, routers, and security policies treat ICMP, UDP, and TCP differently, the same path can produce visibly different traces on each OS.

Each OS also offers probe-type overrides for stubborn paths: Linux traceroute supports -I for ICMP ECHO probes and -T for TCP SYN probes, and its per-probe wait defaults to 5.0 seconds (-w). Windows tracert's main dials are -h for maximum hops, -w for the per-reply wait in milliseconds, and -j for a loose source route. When a UDP trace dies at a firewall that permits ICMP, switching probe types often gets you the rest of the path.

MTR vs Traceroute: When Should You Upgrade?

Switch to MTR when a single traceroute snapshot is not enough to trust. MTR — "My Traceroute" — combines the functionality of the traceroute and ping programs in one tool: it continuously re-probes every hop and reports per-hop loss percentage and latency statistics over time, which is exactly what separates a transient control-plane blip from persistent path congestion.

A single mtr example.com replaces a folder of saved traceroute outputs. Its live display shows, per hop, the loss percentage alongside Snt (packets sent), Last, Avg, Best, Wrst, and StDev latencies in milliseconds — updated every second by default. Watching those columns for a few minutes tells you what no single trace can: whether hop 5's scary numbers are a one-off or a pattern. Because MTR probes in an effectively infinite loop, it is also unusually good at revealing multiple parallel paths on load-balanced routes. For scripted checks, mtr -r -c 10 example.com runs ten cycles and prints a final statistics report instead of the interactive display, and --udp / -T switch its probe type the same way traceroute's flags do.

MTR is the upgrade path, not a replacement for understanding the basics — every rule in this guide still applies to its output. If you prefer a live terminal dashboard over MTR's text table, our Trippy beginner guide covers the modern interactive alternative; the reading skills are the same either way.

How to Read a Traceroute From Your VPS

Run the same trace in reverse: from your server toward your home connection or your users. Problems that appear in both directions point at the middle of the path; problems that appear in only one direction point at one of the two ends. If you run services on a VPS hosting plan, traceroute is one of the first tools to reach for when visitors report slowness — it tells you in seconds whether the delay is inside your provider's network, at a transit hop, or on the visitor's own connection.

When a trace ends early at your own server — asterisks or "destination net unreachable" at the final hop — the next diagnostic is usually the server's firewall, not the network. Walk through our guide to check open ports on a VPS to confirm the port you are tracing toward is actually listening and reachable. Between the trace, the port check, and a ping baseline, most "my server is slow or unreachable" mysteries resolve into one of three answers: a transit problem (carries to the end, both directions), a firewall rule (trace dies at your hop), or nothing at all (a lone slow hop that vanishes — the trap from section five).

Sources

Every technical claim in this guide was verified against documentation fetched for this article in November 2026:

• traceroute(8) Linux manual page — UDP probe defaults (ports 33434+), 3 probes per hop, 30-hop and 5.0-second defaults, TTL mechanics, asterisk behavior, and all ! annotation meanings.
• Microsoft Learn: Use TRACERT to Troubleshoot TCP/IP Problems — tracert's ICMP Echo Request probes, TTL handling, -d/-h/-j/-w flags, 30-hop default, output format, and the "reports: Destination net unreachable" format.
• CellStream: How to Use Traceroute for Network Troubleshooting (September 2023) — output columns, the "three values are not min/avg/max" rule, the don't-add-latencies rule, asterisk semantics, the single-hop-spike trap, and the carries-to-the-end rule.
• Netskope Technical Documentation: Traceroute Analysis — the three RTT components, ICMP prioritization as the cause of single-hop spikes, the persist-to-the-end verification rule, and round-trip (not one-way) latency.
• mtr(8) manual page — MTR's traceroute-plus-ping design, per-hop Loss%/Snt/Last/Avg/Best/Wrst/StDev fields, the 1-second default interval, report mode, probe-type options, and the BUGS warning on ICMP deprioritization.

Frequently Asked Questions

Why does my traceroute show * * * but the website still loads?

Because asterisks only mean the router declined to answer the diagnostic probes — usually due to ICMP filtering, rate limiting, or low control-plane priority — while it kept forwarding your real traffic normally. If every hop after the asterisks answers and the destination responds, the path is healthy; the silent router simply does not chat with traceroute.

Can I use traceroute to measure my internet speed?

No. Traceroute measures latency — round-trip times in milliseconds — not throughput, so a 30 ms hop says nothing about how many megabits per second your connection carries. Use a dedicated speed test for bandwidth; use traceroute (and ping) to find where delay or loss enters the path.

Why do my traceroute results change between runs?

Internet routing is dynamic, and load-balanced links spread probes across parallel paths — you will sometimes see different gateway addresses on the same hop line between runs. Treat one trace as a snapshot of one moment. For a stable picture, run the trace several times and compare, or use MTR to collect continuous per-hop statistics.

Is tracert the same as traceroute?

They use the same TTL trick but differ in defaults: Windows tracert sends ICMP Echo Request probes, while Linux and macOS traceroute send UDP probes to unlikely high ports. Their flags differ too (-d/-h/-w on Windows versus -n/-I/-T/-m/-q on Linux). Because networks treat ICMP and UDP differently, the same path can look different on each OS.

What should I do once I find the problem hop?

First, confirm it is real: the latency or loss must carry through to the destination, and it should reproduce across several traces or a few minutes of MTR. Then run the trace from the other end if you can — problems visible in both directions sit in the middle of the path. If the problem hop is your own server, check its firewall and listening ports before blaming the network. Take the collected output to your hosting provider or ISP; a trace showing exactly where degradation starts is the evidence their network team needs.