Verified June 2026 · tested on Windows 11 24H2, Windows 10 22H2 & Server 2022/2025
Quick Reference: Essential Commands
Need to trace a route right now? Here are the most common commands:
# Trace the route to a host (default behaviour)
tracert google.com
# Trace by IP and skip slow reverse-DNS lookups (much faster)
tracert -d 8.8.8.8
# Cap the trace at 15 hops
tracert -h 15 example.com
# Shorten the per-hop wait to 1 second (1000 ms)
tracert -w 1000 example.com
# Force IPv4 or IPv6
tracert -4 example.com
tracert -6 example.com
# Measure packet loss per hop over time (pathping)
pathping -q 50 google.com
Which command do you need?
- See the path and find a slow/broken hop →
tracert - Speed up the trace or change its limits →
tracertswitches - Just check if a host is up →
ping - Prove packet loss at a specific router →
pathping - Trace from macOS or Linux →
traceroute/mtr
Jump to the section you need below.
tracert: Trace the Route
tracert.exe (trace route) discovers the path packets take to a destination by sending probes with an increasing Time To Live (TTL) value. The first probe has TTL 1, so the first router decrements it to 0 and replies with an "ICMP Time Exceeded" message — revealing itself. The second probe uses TTL 2 to reveal the second router, and so on until the packets reach the destination. Each row of output is therefore one router (a hop) on the way.
Windows 10Windows 11Server 2016+Built in — no moduleNo elevation needed
tracert Switch Reference
| Switch | Description |
|---|---|
-d | Do not resolve hop IP addresses to host names — much faster output |
-h {max_hops} | Maximum number of hops to probe (default 30) |
-w {timeout_ms} | Milliseconds to wait for each reply (default 4000) |
-4 | Force IPv4 |
-6 | Force IPv6 |
-j {host-list} | Loose source route along a list of hosts (IPv4 only) |
-R | Trace the round-trip path (IPv6 only) |
-S {srcaddr} | Source address to use (IPv6 only) |
/? | Show built-in help |
tracert Usage Examples
# Standard trace by host name
tracert google.com
# Skip name resolution and trace by IP (fastest, cleanest output)
tracert -d 8.8.8.8
# Limit the trace to 15 hops so it gives up sooner on a dead route
tracert -h 15 example.com
# Drop the per-hop timeout to 1 second instead of 4
tracert -w 1000 example.com
# Combine flags: no DNS, 20-hop cap, 2-second timeout
tracert -d -h 20 -w 2000 cloudflare.com
# Force the IPv6 path to a dual-stack host
tracert -6 ipv6.google.com
Tip: Always reach for
-dfirst when a trace is crawling. Each hop that tracert can't reverse-resolve otherwise stalls the line until DNS times out, which makes a healthy trace look slow even when the network is fine.
How to Read tracert Output
A typical trace looks like this:
Tracing route to google.com [142.250.80.46]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms 192.168.1.1
2 11 ms 9 ms 10 ms 100.64.0.1
3 12 ms 11 ms 12 ms cr1.dllstx.example.net [203.0.113.9]
4 * * * Request timed out.
5 24 ms 23 ms 24 ms 142.250.80.46
Trace complete.
Read it column by column:
- Hop number — the position of the router on the path (1 is your own gateway).
- Three time columns — tracert sends three probes per hop by default and prints each round-trip time in milliseconds. Three readings help you spot a single fluke versus consistent latency.
- Host / IP — the responding router, resolved to a name unless you used
-d.
What to look for:
- A steady climb in latency as you move outward is normal — packets travel farther.
- A sudden jump that persists at one hop and every hop after it points to that router (or the link feeding it) as the source of the latency.
- A jump at one hop that disappears at the next is not a problem — it just means that one router de-prioritised your probe.
What the Asterisk (Request Timed Out) Means
An * means tracert got no reply for that probe before the -w timeout. This is the single most misread part of trace output. It almost always means the router is configured to drop or rate-limit the ICMP "Time Exceeded" replies that tracert depends on — not that your traffic is failing.
- Asterisks at one middle hop, with later hops responding → harmless. The path works; that router simply stays quiet.
- Asterisks from one hop all the way to the destination → a real break or a firewall at the far end. The last hop that did respond is where to focus.
- Asterisks only at the final destination → very common. Many web servers (Google, Cloudflare, and most hardened edge firewalls) deliberately ignore trace probes even though the site loads fine in a browser. The site is up; it just won't answer
tracert.
ping vs tracert vs pathping
All three tools use ICMP-style probes, but they answer different questions. Choosing the right one saves time.
| Tool | Question it answers | How it works | Best for |
|---|---|---|---|
ping | Is this one host reachable, and how fast? | Sends ICMP Echo to a single destination | Quick up/down + latency check |
tracert | Which routers are on the path, and where does it slow down? | Increasing-TTL probes, 3 per hop, one pass | Locating where a problem is |
pathping | How much packet loss happens at each hop over time? | Traces the path, then floods every hop with packets | Proving intermittent loss at a specific router |
A practical workflow:
# 1. Confirm the destination is reachable at all
ping google.com
# 2. If ping fails or is slow, find WHERE on the path
tracert -d google.com
# 3. If a hop looks suspect, measure its real packet loss
pathping -d google.com
Use ping to confirm a symptom, tracert to localise it, and pathping to quantify it. tracert tells you a hop looks bad; pathping proves whether that hop is actually losing packets.
pathping: Measure Packet Loss Per Hop
pathping.exe is the heavyweight. It first runs a trace to discover the route, then sends a burst of packets to every hop and reports the percentage lost at each one. Because it samples each hop for about 25 seconds, a full run can take several minutes — but the per-hop loss statistics are exactly what you need to catch an intermittent, lossy router.
Windows 10Windows 11Server 2016+Built in — no moduleSlow — minutes per run
pathping Switch Reference
| Switch | Description |
|---|---|
-n | Do not resolve addresses to host names (the pathping equivalent of tracert -d) |
-h {max_hops} | Maximum number of hops to search (default 30) |
-q {num_queries} | Number of queries sent to each hop (default 100) |
-w {timeout_ms} | Milliseconds to wait per reply |
-p {period_ms} | Milliseconds to wait between pings |
-4 / -6 | Force IPv4 or IPv6 |
pathping Usage Examples
# Full run with name resolution
pathping google.com
# Skip DNS and send 50 queries per hop (faster than the default 100)
pathping -n -q 50 google.com
# Cap at 20 hops and force IPv4
pathping -h 20 -4 example.com
In the results table, the Lost/Sent = Pct column is the payoff: a hop showing sustained loss (and loss that continues at every hop after it) is the one degrading your connection. Loss at a single hop that clears on the next line is just that router rate-limiting the probes, not real packet loss.
macOS and Linux: traceroute and mtr
The same diagnostics exist outside Windows, with two naming and behaviour differences worth knowing.
- Command name: it is
traceroute(full word) on macOS and Linux, nottracert. - Default protocol: Windows
tracertuses ICMP probes; Unixtraceroutedefaults to UDP. Add-Ito make traceroute use ICMP like Windows, or-Tfor TCP probes (useful when firewalls block UDP/ICMP).
# macOS — traceroute is built in
traceroute google.com
# Use ICMP probes (closest match to Windows tracert)
traceroute -I google.com
# Skip reverse-DNS (the -d/-n equivalent)
traceroute -n 8.8.8.8
# Force IPv4 or IPv6
traceroute -4 example.com
traceroute -6 example.com
On Linux, traceroute may need installing first:
# Debian / Ubuntu
sudo apt install traceroute
# RHEL / Fedora / Rocky
sudo dnf install traceroute
mtr: a live traceroute + ping
mtr ("My TraceRoute") merges traceroute and ping into one continuously updating display, refreshing each hop's loss and latency in real time — ideal for watching an intermittent problem as it happens.
# Install (Debian/Ubuntu)
sudo apt install mtr
# Live report
mtr google.com
# Text snapshot of 100 cycles then exit (great for tickets/logs)
mtr --report --report-cycles 100 google.com
On Windows, the closest equivalent to mtr is the open-source WinMTR or running pathping for its per-hop loss statistics.
Trace Output: What Each Result Means
Each row is deep-linkable — share a specific symptom with …#tr-timeout, and the row highlights on arrival.
| Symptom / Output | Meaning | What to do |
|---|---|---|
* * * Request timed out at a middle hop | That router drops or rate-limits ICMP TTL-expired replies | Usually harmless — if later hops respond, the path is fine. Ignore it. |
| Asterisks from one hop to the destination | Real break, or a firewall at the far end silently dropping probes | Focus on the last hop that replied; confirm reachability with ping or a browser |
| All hops respond but the final destination times out | Destination server/edge firewall ignores trace probes by design | Normal for Google/Cloudflare/hardened hosts — the site still works |
| Latency jumps and stays high from one hop onward | That router or the link feeding it is the bottleneck | Note the hop's owner (often an ISP) and run pathping to confirm loss |
| One hop is slow but the next hop is fast again | That router de-prioritised your probe (control-plane rate limit) | Not a problem — judge a hop by the hops after it, not the hop itself |
| Trace crawls line by line with names appearing slowly | Reverse-DNS lookups are stalling on each hop | Re-run with tracert -d to skip name resolution |
Trace complete never appears; stops at hop 30 | Path is longer than the default 30-hop limit, or never completes | Raise the cap with tracert -h 60; if it still won't finish, the route is broken |
Destination host unreachable on the first hop | No route off the local network — gateway or local link problem | Check the default gateway with ipconfig; confirm the NIC has a valid IP |
Version-Specific and Compatibility Notes
- Windows 11 / 10 / Server:
tracert,ping, andpathpingare identical across all modern versions and ship in the box — no feature install or module needed. None of them require an elevated prompt. - ICMP vs UDP: Windows
tracertandpathpinguse ICMP echo/TTL probes. Unixtraceroutedefaults to UDP — add-I(ICMP) or-T(TCP) to match Windows behaviour or to get past firewalls that block UDP. - IPv4 vs IPv6: Use
-4or-6to pin the protocol on a dual-stack host. Some switches are protocol-specific:-j(loose source routing) is IPv4-only, while-Rand-Sapply to IPv6 only. - Why traces "fail" on healthy sites: A timed-out final hop is the norm for hardened servers that drop trace probes by policy. Always confirm with
pingor a browser before concluding a destination is down. - macOS / Linux: the tool is
traceroute(nottracert); install it withapt/dnfif missing. For a live, continuously updating view, usemtr(Unix) or WinMTR (Windows).
