Traceroute discovers responding routers along a path by sending probes with increasing hop limits. A star means that a probe received no expected reply in time; it does not automatically mean that router dropped the traffic it forwards.
How a hop appears in the output
A probe starts with a small IPv4 TTL or IPv6 hop limit. Routers reduce it while forwarding. When it expires, a router may send an ICMP response identifying that point in the path. The tool increases the limit until it receives a destination response or reaches its configured maximum.
Windows tracert and other traceroute implementations can use different probe methods. A firewall may allow one method and filter another, so two tools need not show identical output even on the same connection.
Start with numeric output
# Windows: skip reverse-name resolution
tracert -d example.com
# macOS / Linux, where installed
traceroute -n example.comNumeric output avoids confusing slow reverse DNS with route discovery. Run the trace while the problem occurs and record the destination IP, address family, and time. If the hostname resolves to different servers between tests, you may be comparing different paths.
Interpret three common patterns
| Pattern | Possible explanation | Useful follow-up |
|---|---|---|
| One hop has stars; later hops reply | That router filters or limits replies | Check the destination and application |
| One hop is slow; later replies are faster | Slow generation of that router's own reply | Do not treat it as added delay to all transit traffic |
| Delay begins and persists to the destination | A path segment may add delay | Repeat and compare under similar load |
For example, 200 ms at hop 4 followed by 25 ms at the destination does not mean every packet suffered 200 ms of forwarding delay at hop 4. The responses are separate packets with their own handling and return paths.
Know what the trace cannot prove
Replies can return along a different route. Load balancing may send successive probes through different routers. A hop's hostname or geolocation estimate can be stale, and private or shared addresses inside an ISP path are not by themselves evidence that your own service uses CGNAT.
If all later hops stop responding, the path may be filtered, the destination may ignore the probe type, or a real failure may exist. Test the service directly before deciding which. An HTTPS page loading successfully is stronger evidence of that application's reachability than whether it answers an unrelated probe.
For an ISP report, pair repeated traces with destination ping samples, actual application symptoms, a wired baseline, and times of failure. That combination gives the operator something concrete to compare with its own routing and interface measurements.
Put it into practice
References & further reading
Protocol standards and official documentation supporting this guide. Device menus and provider policies vary; use the documentation for your equipment when applying a change.