Traceroute explained: hops, timeouts and network routes
Traceroute is a diagnostic view of the possible path packets take towards a destination. It lists responding hops and the time taken for probe responses. A trace is a snapshot under particular network conditions, not a permanent map of the Internet or proof of where every application packet travels.
How traceroute discovers hops
The program sends probes with progressively larger hop limits: TTL for IPv4 and Hop Limit for IPv6. A router that reduces the limit to zero may send an ICMP Time Exceeded response. Repeating the process reveals a sequence of responding devices on the forward path.
Depending on the operating system and options, probes may use UDP, ICMP or TCP. Firewalls and network policies treat these differently, so switching probe types can produce different traces. A TCP probe towards the service port can sometimes be more informative than a default UDP probe.
Reading times and asterisks
Each line represents a hop number; several times on that line refer to separate probes, not a single continuous measurement. An asterisk usually means no response arrived before the timeout. The router may still forward normal traffic while declining to answer or rate-limiting diagnostic messages.
High response time at one intermediate hop is not necessarily a bottleneck. Check whether later hops and the final destination show a similar increase. Return traffic can take another route, and load balancing can send probes over different forward paths. These effects make a single trace easy to misinterpret.
A practical troubleshooting sequence
On Linux and many macOS systems, try traceroute example.com; on Windows use tracert example.com. Record the destination, protocol choice, time and network used. Run several traces and compare them with a direct application test. Use a domain you control or are authorised to diagnose.
If all probes stop at one hop but the website works, the missing responses are a diagnostic limitation. If the destination fails as well, compare traces from another network and examine DNS, firewall rules and the service itself. Share concise results with your provider; a trace alone cannot establish who caused a fault.
Save the complete output rather than only the last responding hop: missing intermediate replies and a successful final reply tell a different story from a destination that never responds.