Traceroute answers a question that a ping cannot: when a connection is slow or broken, where along the path does it break down? Running one takes a single command, and the output gives you a hop-by-hop map from your machine to the destination, with timing at every router in between.
To trace a route, open Command Prompt on Windows and run tracert example.com, or open Terminal on macOS or Linux and run traceroute example.com; each numbered line that comes back is one router between you and the target, with three round-trip times in milliseconds. That is the whole mechanic. The skill is reading what those numbers mean without blaming the wrong hop.
Most people misread traceroute output the first few dozen times. A row of asterisks looks like a failure and often is not one. A 180 ms spike at hop 6 looks like a bottleneck and often is not one either. PacketTools builds and maintains free browser-based diagnostics used in live production networks to verify VPNs, analyze routing, and harden infrastructure, and the interpretation habits below come from that work.
By the end, you will be able to run a trace on any operating system, tell a real routing problem from a router that simply deprioritizes probe traffic, and hand your ISP evidence they cannot wave away.
Run a Trace From Windows, macOS, or Linux
Every major operating system ships a trace route utility, though Windows names its command differently and defaults to a different protocol than the Unix versions. Both accept either a hostname or a raw IP address as the target, and both walk outward one hop at a time until they reach the destination or hit the default 30-hop ceiling.
Use Tracert in Windows Command Prompt
Windows calls the utility tracert. Press the Windows key, type CMD, press Enter, then run:
tracert packettools.com
The console prints one line per hop and ends with Trace complete. Useful flags:
-dskips reverse DNS lookups, which makes a slow trace finish much faster-h 15caps the trace at 15 hops-w 500shortens the per-probe timeout to 500 ms-4or-6forces IPv4 or IPv6
Windows tracert sends ICMP Echo requests, which matters when you compare its output against a Linux trace of the same target.
Use Traceroute in macOS and Linux Terminal
macOS includes traceroute in Terminal with no installation. On Ubuntu and Debian it is not present by default, so install it first with sudo apt install traceroute, then run traceroute packettools.com.
The Unix version defaults to UDP probes on high-numbered ports. Add -I for ICMP probes to match Windows behavior, -T for TCP, and -n to suppress hostname resolution. Combining them (traceroute -In) gives clean, fast output that lines up with tracert results.
macOS also exposes a Traceroute tab inside Network Utility for anyone who prefers a GUI, per this walkthrough of running traceroute across all three platforms.
Choose a Domain Name or IP Address to Test
Trace the exact thing that is broken. When a web app times out, trace its hostname, since that resolves through DNS and tests the same address your browser uses. When you suspect DNS itself, trace a known-good IP such as 8.8.8.8 and compare.
Tracing a URL with https:// in front will fail. Strip it down to the bare hostname or IP. Also remember that a hostname behind a CDN resolves to whichever edge node is nearest you, so two people tracing the same domain legitimately reach different endpoints.
Confirming which public address you are testing from helps too, and a what is my IP lookup takes two seconds before you start.
When an Online Trace Is More Useful Than a Local Command
A local trace only shows the path from your machine outward. When you need to know whether a server is reachable from elsewhere, run the trace from a different vantage point.
Browser-based diagnostics answer three situations a local command cannot:
- Your own link is the suspect. If your uplink is saturated, every local measurement inherits that congestion.
- You need an outside-in view of your own server. Customers reach it from the public internet, not from your LAN.
- You are on a locked-down corporate network. Egress filtering frequently blocks ICMP and UDP probes entirely.
PacketTools runs its traceroute and related network tools in the browser with no sign-in, no logging of IPs or queries, and no analytics cookies.
How Traceroute Reveals the Network Path
Traceroute works by deliberately sending packets that expire early. It manipulates the time-to-live field in the IP header so each router along the way is forced to discard a packet and report back, which is how the tool discovers devices it was never told about.
What a Hop Represents Between Source and Destination
A hop is one Layer 3 device that decremented your packet’s TTL and forwarded it, so hop 1 is almost always your local gateway. Hop count is the number of routers between source and destination, and a typical path across the United States runs 10 to 18 hops.
Higher hop counts do not automatically mean worse performance. A 16-hop path over well-provisioned backbone links routinely beats an 8-hop path that detours through a congested peering point.
How TTL Expiration Produces Router Replies
Every IP packet carries a TTL value, a hop limit that each router reduces by one. When TTL reaches zero, the router drops the packet and returns an ICMP Time Exceeded message to the sender, which reveals that router’s address.
Traceroute exploits this by sending probes with TTL=1, then TTL=2, then TTL=3, and so on. Each round provokes a reply from one hop further along. The TTL-and-ICMP mechanism is documented in detail here. Most implementations send three probes per TTL value and print all three round-trip times, which is why each line has three timing columns.
Why ICMP, UDP, and TCP Traces Can Differ
Protocol choice changes results because firewalls treat protocols differently. UDP probes to high ports get dropped by edge ACLs constantly. ICMP is often rate-limited or deprioritized. TCP probes to port 443 slip through filters that block everything else, since that traffic looks like ordinary HTTPS.
| Probe type | Default on | Best for |
|---|---|---|
| ICMP Echo | Windows tracert |
Matching what most networks expect |
| UDP high port | Linux/macOS traceroute |
Standard Unix baseline |
TCP SYN (-T) |
Neither | Reaching hosts behind strict firewalls |
Run at least two protocols before declaring a hop dead.
Why the Same Destination Can Follow Different Routing Paths
Routing tables change, and carriers load-balance across parallel links. Two traces run 30 seconds apart can list different hop 7 addresses without anything being wrong.
Return paths add another wrinkle. The route back to you may not mirror the route out, so an RTT measured at hop 9 includes a return leg you never see in the output.
Read Traceroute Output Without Misdiagnosing a Hop
Read traceroute output as a cumulative measurement, where each line’s timing includes everything before it. A single ugly row in the middle of an otherwise healthy trace is usually a router being polite to real traffic and rude to your probes.
What Round-Trip Times and Response Times Measure
Each of the three numbers on a line is the round-trip time in milliseconds for one probe: your machine to that router and back. These are not per-hop delays; hop 9’s RTT already contains hops 1 through 8.
For nearby networks, RTT values sit below 100 ms, while distant international paths reach up to 300 ms. Watch the trend across hops. Rising, stable numbers describe a normal path. Numbers that jump and stay high mark a real transition point.
How to Interpret Hostnames and IP Addresses
The last column shows the responding router’s IP and, when reverse DNS resolves, its hostname. Carrier hostnames encode geography and link speed in abbreviations: ae-3.chi01, dal-edge-12, ten0-0-0-1.nyc.
Reading those city codes tells you when traffic crossed from Dallas to Chicago, which explains a legitimate 25 ms increase. A missing hostname means no PTR record exists, which says nothing about that router’s health. If IP address basics are shaky, the private ranges at the start of a trace are your own network.
What Asterisks and Request Timed Out Messages Actually Mean
Three asterisks and Request timed out mean no reply came back within the timeout window. Four causes produce that identical output:
- The router is configured not to return traceroute responses
- A firewall filters ICMP traffic at that boundary
- ICMP rate limiting kicked in on a busy control plane
- The router is genuinely down
Here is the test that settles it: if hops after the starred hop respond normally, that hop is forwarding traffic fine and simply declined to answer. Asterisks at the end of a trace, continuing to hop 30, are the ones worth investigating.
When Destination Net Unreachable Signals a Route Failure
Destination net unreachable is different from a timeout. A router actively sent back an ICMP Destination Unreachable message, saying it has no route to the target network.
That points to a routing problem: a missing or withdrawn route, a BGP issue upstream, or an ACL rejecting the traffic. Note which hop returned it, because that device is the last one with a decision to explain.
Use Trace Evidence to Isolate Latency and Reachability Problems
Isolating a fault means assigning it to a network segment you can name: your LAN, your ISP’s access network, a transit carrier, or the destination host. Traceroute output splits into those zones, and the hop where behavior changes tells you which team owns the ticket.
Identify a Sustained Latency Increase Rather Than One Slow Reply
Look for a jump that persists through every subsequent hop. A path that reads 2, 9, 11, 14, then 86, 88, 91 has a real problem between hops 4 and 5.
One inflated probe surrounded by normal ones is control-plane noise. A hop showing 140/12/13 ms across its three probes is a router that answered one probe slowly while forwarding everything else at 12 ms.
Latency that climbs at a hop and drops back down at the next hop is the clearest signature of probe deprioritization. Real congestion never gets faster downstream.
Separate Local Gateway, ISP, Transit, and Destination Issues
Traceroute output falls into five recognizable groups, as this operating-system-agnostic breakdown describes: your local network, your ISP, the internet backbone, the destination’s host network, and the destination itself.
- Hop 1 slow or timing out: your router, cabling, or Wi-Fi. Fix it locally.
- Hops 2 to 4 degraded: your ISP’s access network. Open a ticket with the trace attached.
- Middle hops degraded: transit or peering congestion, which neither you nor your ISP controls directly.
- Final hop slow, everything before it clean: the destination server is loaded, not the network.
When hop 1 is fine but nothing beyond it works, the pattern described in Wi-Fi connected but no internet applies.
Investigate a Trace That Stops Before the Destination
A trace that runs to hop 30 with nothing but asterisks after hop 12 means one of two things: packets stop being forwarded past hop 12, or the destination network filters probe traffic entirely.
Distinguish them by testing reachability directly. If a ping or an HTTPS request to the destination succeeds while the trace dies at hop 12, the path works and the filtering is cosmetic. When both fail, you have a genuine reachability break, and hop 12 is where to point.
Run tracert -T -p 443 on Linux against a web host before concluding anything, since many production edges answer TCP on 443 and drop everything else.
Compare Paths by Time, Location, and Protocol
A single trace is one sample. Run the same trace three times over ten minutes, and the hops that degrade consistently are your suspects.
Then vary the other two axes. A trace from a second location isolates whether the fault is on your access link. A protocol switch from UDP to ICMP to TCP tells you whether a “dead” hop is filtered or broken. Comparing a trace to a working destination against the failing one narrows the divergence point to a specific hop.
Corroborate a Trace With PacketTools Network Diagnostics
A traceroute tells you about the path, and it stays silent on name resolution, certificate validity, and whether the problem is intermittent. Pairing it with two or three other checks converts a suspicion into evidence.
Check Name Resolution Before Escalating a Route Problem
Confirm DNS first. When a hostname resolves to a stale or wrong address, your trace faithfully maps the path to the wrong server, and the routing looks broken when the record is the fault.
Run a lookup, note the returned IP, then trace that IP directly. Matching results clear DNS from the investigation. A recent record change calls for a DNS propagation checker across global resolvers, and resolver-side failures follow the patterns covered in DNS server not responding.
Use Ping and Repeated Tests to Establish a Baseline
Traceroute gives you three probes per hop at one moment. Sustained testing shows whether the degradation is constant or bursty.
Ping the destination and the last clean hop side by side. If both show the same packet loss percentage, the loss originates at or before that hop. A ping test run for several minutes establishes the normal RTT range for that path, which makes tomorrow’s spike measurable against a number instead of a memory.
Validate HTTPS and Email Services Alongside Reachability
Reachability and service health are separate questions. A path can be perfect while TLS negotiation fails on an expired certificate or a broken chain.
An SSL/TLS check confirms the handshake and certificate validity at the endpoint your trace reached. For mail problems, delivery failures more often trace to SPF, DKIM, or DMARC records than to routing, and the SuperTool runs DNS, MX, SPF, DKIM, DMARC, blacklist, and SSL tests against a domain in one pass. Tenant-specific records get their own check through the M365 domain checker.
Capture Useful Evidence for an ISP or Hosting Provider
Support desks act on specifics. Save raw output rather than describing it: tracert 8.8.8.8 > result.txt on Windows, or traceroute 8.8.8.8 > results.txt on Linux and macOS.
Include in the ticket:
- Timestamps for each trace, with at least three runs showing the same hop degrading
- Both a failing trace and a working trace to a comparable destination
- Ping statistics with loss percentage and RTT range
- Your public IP and the exact target hostname or address
- The protocol used, since a UDP-only failure means something different from an ICMP failure
Further diagnostic walkthroughs live in the PacketTools network troubleshooting library.
Build Better Troubleshooting Decisions From the Full Path
A traceroute test earns its value when you read it as a whole path instead of hunting for the single worst-looking line. Run the command, note where round-trip times rise and stay risen, and check whether hops after a starred row still respond.
That reading assigns a routing issue to a segment: your gateway, your ISP’s access network, a transit carrier, or the destination host. Confirm it with DNS and repeated ping tests before you escalate, and attach the saved output with timestamps.
Three traces to the same target ten minutes apart, plus one trace to a known-good destination, give any provider enough to open an engineering ticket on the network connection instead of asking you to reboot your router.
Leave a Reply