How to Read Traceroute Without Misdiagnosing the Route

Traceroute shows intermediate points that respond to its probes toward a destination. It is not a complete physical network map, and the first row containing asterisks is not automatically the location of a fault.

Each round starts with a larger forwarding limit

The tool starts with a small TTL or IPv6 Hop Limit and sends new probes with progressively larger initial limits. Returned expiry messages can reveal intermediate points. A destination response, hop limit or another termination condition ends the trace. The TTL guide explains the forwarding mechanism.

Windows tracert uses ICMP Echo probes. A common Linux traceroute implementation defaults to UDP and offers other methods, including ICMP and TCP. Different tools can therefore produce different visibility without proving that the underlying route changed: networks may handle their probe protocols differently.

Remove reverse-name lookup from the display

Replace this documentation address with a real destination you are authorized to test. On Windows:

tracert -d 192.0.2.10

On Linux or macOS with traceroute installed:

traceroute -n 192.0.2.10

These options suppress name lookups for intermediate addresses. Consult the tracert documentation and Linux traceroute manual; check local documentation for advanced macOS options rather than assuming they all match Linux.

A missing response is not a stopped path

This shortened display is illustrative:

1   192.168.1.1   1 ms
2   * * *
3   192.0.2.10   18 ms

No reply appeared for the second row, yet the destination answered later. That does not support a claim that all forwarding stopped at hop two. Diagnostic responses may be filtered or limited. Tunnels and internal topology can also separate the visible hop count from the number of physical devices involved.

The times are round trips to responding points, not delays on individual links between adjacent routers. A slow intermediate response followed by faster downstream responses can reflect how that router generates its own replies. Subtracting adjacent rows does not produce a dependable physical-link delay.

Turn the trace into useful evidence

Record the destination IP, address family, time, command and VPN state. Compare a few short traces taken under similar conditions. Load balancing and asymmetric return paths mean one display is not a permanent description of every flow's route.

If the destination is absent, check the actual application separately. An incomplete trace does not prove HTTPS is broken. For recurring loss, combine end-to-end measurements with application symptoms from the same time window rather than blaming the first silent router.