How Ping and Traceroute Work Together: Confirm the Endpoint First, Then Inspect the Hops

Ping and traceroute work best when used in sequence: first confirm what is happening at the destination, then look at the path in between. Doing it the other way around—declaring a line failure the moment you see an asterisk at one hop—makes it easy to mistake a device that simply doesn't reply to probe packets for an actual interruption of user traffic.

Step 1: Fix the destination and capture a set of pings

Record the actual IP, address family, source network, and time. When you enter a domain name, save the resolution and selection result first so later tracing doesn't switch to a different CDN address. Run a limited sample against a target you're authorized to test, and keep both the replies and the non-responses.

The example uses Windows commands and a reserved example domain; replace it with an actual authorized target:

ping -4 -n 6 example.com
tracert -4 -d -h 20 example.com

The two commands may resolve the domain separately, so you still need to verify the output IP; to fix the destination, use the target address you just confirmed. The count and maximum hop values are only example settings.

Step 2: View the path from the same source

Windows tracert discovers the path by incrementally increasing TTL and using the corresponding replies; see the official Microsoft documentation. The default probe protocol for traceroute may differ across systems, so record the tool and parameters before comparing.

An online ping originates from some remote node, and a tracert from your local machine cannot directly represent that remote path. You need tracing capability from the same starting point; if you don't have it, state the evidence gap rather than stitching two reports into a single chain.

Step 3: Work backward from the destination to judge the clues

If one hop shows an asterisk but later hops and the destination still respond, you can't simply conclude that the service breaks at that hop. Intermediate devices may not return the corresponding messages. If one hop shows high latency but later hops recover, it's also unwise to treat that value as the actual service latency for that segment of the link.

Replies at each hop come from independent probes; they should not be added together into a total delay, nor simply subtracted to derive the time spent on a particular link segment. Focus on whether there is a repeatable change that persists to the destination and matches the service symptoms.

Step 4: Align network clues with application symptoms

If the destination ping is stable but HTTPS returns errors, keep investigating the application layer; if the destination and the service are both abnormal, then combine the path, target changes, and service logs to narrow it down. A trace that doesn't reach the destination doesn't necessarily mean the web page failed—the target may simply not respond to the corresponding probe.

Google Public DNS's troubleshooting documentation also separates network path tools from DNS query tests. If you need to verify a particular service, add that service's own request.

Keep both raw results when handing off

Save the ping, trace, target address, and service error from the same time, and note whether the sources are the same. IP geolocation and reverse names are only clues—don't judge detours based solely on city abbreviations, and don't assume fewer hops always means faster.

For more on the limits of intermediate hops, see Explaining traceroute asterisks and detours; for how to read destination latency, refer to the difference between averages and spikes.