Blog / Networking basics

How to Read traceroute and mtr Output: Stars, Loss, Latency Jumps

2026-10-22cdnping editors9 min read

Here is the one rule to remember when reading traceroute: look at the last hop first, then check whether a problem starts at some hop and persists all the way to the end. If a middle hop shows stars, packet loss, or high latency but the hops after it look normal, that router is almost always just declining to answer probe packets. It does not mean your traffic is having trouble there.

#How does traceroute get each hop?

traceroute sends a series of probe packets with TTL (called hop limit in IPv6) set to 1, 2, 3, and so on. Each router the packet passes decrements the TTL by 1. When it reaches 0, that router drops the packet and sends back an ICMP "time exceeded" message. When traceroute receives that reply, it learns the address of hop N and the round-trip time.

This mechanism determines how to read the results:

• Latency at a middle hop is the time the router took to generate an ICMP reply, not the time it takes to forward your traffic. Routers forward data in hardware, but generating ICMP replies is often handled by the control-plane CPU, and it is commonly rate-limited.
• The outbound and return paths can differ. You see each hop on the outbound path, but each hop's latency includes its return trip.
• Only the last hop is the destination itself answering, so its latency and loss are the closest to what real traffic experiences.

#How do you read a traceroute output line by line?

Below is an example output. The addresses come from private, carrier-shared, and documentation-reserved ranges, and the numbers are for illustration, not measured.

$ traceroute -n api.example.com
traceroute to api.example.com (203.0.113.10), 30 hops max, 60 byte packets
 1  192.168.1.1     1.2 ms   1.1 ms   1.0 ms     ← home router
 2  100.64.0.1      4.8 ms   5.1 ms   4.9 ms     ← ISP access (CGNAT range)
 3  * * *                                        ← does not answer ICMP, common
 4  198.51.100.5    9.7 ms   9.9 ms  10.2 ms
 5  198.51.100.33  85.4 ms  12.1 ms  11.8 ms     ← one high sample, rest normal
 6  198.51.100.70 168.2 ms 167.9 ms 168.5 ms     ← cross-border / transoceanic segment, latency step
 7  * * *
 8  203.0.113.10  170.3 ms 169.8 ms 170.6 ms     ← last hop: the destination itself

Line by line:

• Hops 1 and 2 are your own network and your ISP's access network. If hop 1 already shows tens of milliseconds or packet loss, check Wi-Fi and your local devices first.
• Hops 3 and 7 are all stars, but hops 4 and 8 respond normally. That means traffic passed through those two hops; they just do not answer ICMP.
• Hop 5 shows one sample of 85 ms out of three, with the rest normal and no effect on later hops. That is router reply rate-limiting or a busy CPU.
• At hop 6 there is a "step" of about 150 ms, and every later hop stays at that level. This comes from physical distance or a cross-border link, and it is the main source of real latency.
• Hop 8 is the destination at around 170 ms, stable across all three samples. This is the conclusion worth recording.

#What do Loss%, Avg, and StDev mean in an mtr report?

traceroute sends only 3 packets per hop, so occasional glitches are easy to misread. mtr keeps sending packets to every hop and gathers statistics, which makes it better for drawing conclusions. Report mode is recommended:

mtr -r -c 100 -n api.example.com

Here is an example report (again, not measured):

HOST: laptop                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%   100    1.1   1.3   0.9   4.2   0.4
  2.|-- 100.64.0.1                 0.0%   100    5.0   5.2   4.6   9.8   0.7
  3.|-- ???                       100.0%  100    0.0   0.0   0.0   0.0   0.0
  4.|-- 198.51.100.5              60.0%   100   10.1  10.4   9.6  14.0   0.8
  5.|-- 198.51.100.33              0.0%   100   11.9  23.6  11.2 140.3  28.1
  6.|-- 198.51.100.70              0.0%   100  168.1 168.6 167.5 175.2   1.2
  7.|-- 203.0.113.10               0.0%   100  170.2 170.5 169.4 178.9   1.4

In the example, hop 4 shows 60% loss, but hops 5 to 7 are all at 0%, so hop 4's loss is just "reluctance to reply" and can be ignored. Hop 5 has Avg 23.6 and StDev 28.1, which is quite variable, but hop 6 is stable again, so that is also just a device that replies slowly. What you actually record is the last hop: 170.5 ms, 0% loss, StDev 1.4. This path is healthy.

#Stars, mid-path loss, latency spikes: how do you judge them?

Use this table to compare against your own results:

The rule of thumb: loss and latency only count when they persist to the last hop.

#Which commands should you use on each OS?

#Windows

tracert -d api.example.com          # -d skips reverse DNS, much faster
pathping -n api.example.com         # built in, gives per-hop loss stats, but takes a long time

In tracert, stars appear as "Request timed out". If you want continuous statistics like mtr, use the open-source WinMTR GUI tool, or install mtr inside WSL.

#macOS

traceroute -n api.example.com
brew install mtr
sudo mtr -r -c 100 -n api.example.com   # mtr on macOS usually needs sudo

#Linux

sudo apt install mtr-tiny traceroute     # Debian/Ubuntu
traceroute -n api.example.com
mtr -r -c 100 -n api.example.com
mtr -r -c 100 -n -6 api.example.com      # test the IPv6 path separately

If a machine has both IPv4 and IPv6, the two paths can be completely different, so record the conclusions separately. For troubleshooting ideas on this, see IPv6 proxy not working: why IPv4 and IPv6 exits differ on dual-stack networks, and how to troubleshoot.

#Why probe with TCP 443?

By default, traceroute on Linux and macOS sends UDP, and tracert on Windows sends ICMP. Many cloud services and API entry points drop both types of probe at the edge. The result is a string of stars at the end that looks like "unreachable", even though the browser works fine.

AI APIs and web pages use TCP 443. Probing with the same protocol and port gives results closer to real traffic:

sudo traceroute -T -p 443 -n api.example.com     # Linux, needs root
sudo mtr -T -P 443 -r -c 100 -n api.example.com  # note: mtr uses uppercase -P for the port
sudo tcptraceroute api.example.com 443           # available on some distributions

If the ICMP probe ends in stars, but the TCP 443 probe reaches the last hop with 0% loss, the destination simply does not answer ICMP and the path itself is fine. Conversely, if TCP 443 also shows persistent loss after some hop, then the link is worth suspecting.

One more caveat: when a proxy or VPN is on, traceroute usually shows the path from you to the proxy server, or results rewritten by a local virtual network adapter, not the real path your traffic takes to the API. Before tracing, confirm which exit your traffic uses. You can check your current exit IP and routing status on IP and environment check.

#How do you match route-tracing results to application-layer timing?

traceroute and mtr only answer "what are the latency and loss on this network-layer path". What users actually feel is the total of DNS, TCP, TLS handshake, and the request round trip. Comparing both sides tells you which layer the problem is in.

#Step 1: measure application-layer time on the cdnping homepage

Open cdnping online speed test. It measures, in the browser, each API's "first connection" (including DNS and TLS handshake) and "round trip" (the median of 3 requests after the connection is reused). "Round trip" is closest to a pure network round trip and can be compared directly with the mtr last-hop Avg.

#Step 2: compare using the table below

It is normal for "first connection" to be several times higher than "round trip", because the TCP and TLS handshakes take several extra round trips. For how to break the three timings apart and measure them individually with curl -w, see AI API latency breakdown: connection setup, gateway round trip, and time to first token (TTFT).

#Step 3: use edge-side data as a baseline

If your own numbers look high, compare them against the API status page to tell apart "the server is slow right now" from "only my path is slow". The status page probes each official API entry point from the Cloudflare edge every 5 minutes. Here is a snapshot of cdnping data from 2026-10-17 (probe location: the Denver DEN node; cdnping had only started collecting that day, so this snapshot covers a window of about 85 minutes and 242 probes. Treat it as a reference for that moment, not long-term statistics):

These numbers are the time from an edge node to the API entry point, not from your home to the API, so you cannot subtract one from the other. Their use is to show trends. If the edge-side p50 matches its usual level while your side is clearly slower, the problem is most likely in your access network, your exit, or the cross-border segment, so go back to the mtr output and see at which hop the step and the loss appear. If the edge side also slows down or fails at the same time, a server-side problem is more likely, route tracing will not find anything, and you should check the official status page first. For how to read those, see How to read the OpenAI status page and the Claude status page. The collection method and definitions are in Methodology.

#Troubleshooting checklist

1. First confirm the exit: whether a proxy or VPN is on, and whether IPv4 and IPv6 use the same exit.
2. Run mtr -r -c 100 -n once, with at least 100 packets.
3. Look only at the last hop's Loss%, Avg, and StDev; ignore stars and isolated loss at middle hops for now.
4. If the end is all stars, run again with -T -P 443.
5. Find the hop where Avg steps up, and decide whether it is local, the ISP, the cross-border segment, or the destination side.
6. Open the cdnping homepage and measure "first connection" and "round trip", then compare using the table above.
7. Compare with the edge-side data on /status to separate server problems from your own path problems.
8. When you need to contact an ISP or the service provider, attach the original mtr report, the test time, and your exit IP range.

If you are troubleshooting a specific tool that cannot connect, continue with Claude Code connection timeouts and errors: a four-layer network checklist and Is ChatGPT down? Three steps to tell a service outage from your own network problem. To go through exit IP, DNS, and speed testing together, follow the Developer network self-check checklist (2026 edition).