tracert — Trace Network Route

What it is

tracert (Trace Route) is a built-in Windows command that maps every router hop between the local machine and a target host. It works by sending ICMP Echo Request packets with a Time-To-Live (TTL) of 1, then 2, then 3, and so on: each router that decrements TTL to zero returns an ICMP Time Exceeded message, revealing its IP and RTT. The result is an ordered list of hops with three RTT measurements per hop. Use tracert when ping confirms a host is unreachable and you need to identify where the path fails. The Linux/macOS equivalent is traceroute.

Availability

tracert ships as C:\Windows\System32\tracert.exe on every Windows version.

tracert /?

Output:

Usage: tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout]
               [-R] [-S srcaddr] [-4] [-6] target_name

Syntax

tracert [options] target

Output: (hop-by-hop route listing)

Essential options

Basic trace

A basic tracert to a hostname shows each hop's IP, resolved hostname, and three RTT measurements. * means that hop did not return a reply within the timeout.

tracert example.com

Output:

Tracing route to example.com [93.184.216.34]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     8 ms     7 ms     8 ms  10.0.0.1
  3    12 ms    11 ms    12 ms  100.64.0.1
  4    14 ms    13 ms    14 ms  72.14.215.165
  5    15 ms    14 ms    15 ms  142.250.214.142
  6    14 ms    14 ms    14 ms  93.184.216.34

Trace complete.

Skip DNS resolution (-d)

-d suppresses reverse DNS lookups at each hop, making the trace significantly faster on paths with slow or absent PTR records. Use it when you care about IP addresses rather than names.

tracert -d 8.8.8.8

Output:

Tracing route to 8.8.8.8
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     8 ms     7 ms     8 ms  10.0.0.1
  3    12 ms    12 ms    11 ms  100.64.0.1
  4    13 ms    13 ms    13 ms  72.14.215.165
  5    14 ms    14 ms    14 ms  8.8.8.8

Trace complete.

Limiting hop count (-h)

-h stops the trace after a given number of hops. Useful when you already know the problem lies within the first few hops and don't want to wait for 30 timeouts.

tracert -h 5 example.com

Output:

Tracing route to example.com [93.184.216.34]
over a maximum of 5 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     8 ms     8 ms     8 ms  10.0.0.1
  3    12 ms    12 ms    12 ms  100.64.0.1
  4    14 ms    13 ms    14 ms  72.14.215.165
  5    15 ms    15 ms    14 ms  142.250.214.142

Trace complete.

Adjusting timeout (-w)

The default timeout is 4000 ms per hop. On slow or lossy links, increase it; on a LAN, reduce it to speed up the trace.

tracert -w 1000 192.168.1.1

Output:

Tracing route to 192.168.1.1
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1

Trace complete.

Forcing IPv4 or IPv6 (-4, -6)

When the target resolves to both A and AAAA records, specify -4 or -6 to trace the exact path used by each protocol.

tracert -4 example.com

Output:

Tracing route to example.com [93.184.216.34]
...

tracert -6 example.com

Output:

Tracing route to example.com [2606:2800:220:1:248:1893:25c8:1946]
...

Saving output to a file

Redirect to a file for inclusion in a support ticket or comparison across time.

tracert -d example.com > C:\Logs\tracert_%COMPUTERNAME%.txt
type C:\Logs\tracert_%COMPUTERNAME%.txt

Output:

Tracing route to example.com [93.184.216.34]
...
Trace complete.

Interpreting the output

Each row of the trace means:

A hop showing * * * does not necessarily mean that hop is broken — many routers silently discard TTL-exceeded messages. The path is broken only if all subsequent hops also show * * *.

How tracert works internally

tracert exploits the IPv4 Time-To-Live field, which every router decrements by one. When TTL reaches zero, the router drops the packet and sends an ICMP Time Exceeded (type 11) back to the source — revealing its own IP. By sending a sequence of probes with TTL=1, 2, 3, ..., the source builds an ordered list of routers. The final hop returns ICMP Echo Reply (type 0) instead, terminating the trace.

The probe protocol differs between operating systems:

This matters because firewalls and ISPs filter each protocol differently — Windows tracert may show all timeouts where Linux traceroute -T (TCP) succeeds.

Source address (-S) and IPv6 (-6)

-S srcaddr pins outgoing probes to a specific source IP, which matters on multi-homed hosts where the default routing decision would pick the wrong interface. -6 forces ICMPv6 with the same TTL mechanism (the IPv6 field is called Hop Limit but behaves identically).

rem Force the trace to leave via the 10.0.0.5 interface
tracert -S 10.0.0.5 -d 10.0.0.1

Output:

Tracing route to 10.0.0.1 from 10.0.0.5
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  10.0.0.1

Trace complete.

tracert -6 -d ipv6.google.com

Output:

Tracing route to ipv6.l.google.com [2607:f8b0:4004:c08::8a]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  fe80::1
  2     8 ms     7 ms     8 ms  2001:db8::1
  ...

Loose Source Routing (-j)

-j host-list requests Loose Source Routing — packets are forwarded through the listed gateways before reaching the destination. This option is almost universally blocked on the public Internet (RFC 7126 explicitly recommends dropping it) because it can be used to bypass routing policies. It remains useful inside controlled MPLS or lab networks.

rem Route through 10.0.0.1 and 10.0.0.2 on the way to 192.168.99.10
tracert -j 10.0.0.1 10.0.0.2 192.168.99.10

Output:

Tracing route to 192.168.99.10
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  10.0.0.1
  2     2 ms     2 ms     2 ms  10.0.0.2
  3     3 ms     3 ms     3 ms  192.168.99.10

Trace complete.

If the option is filtered, you will see * * * for every hop — switch to TCP or UDP traceroute alternatives.

Reading reverse-DNS hints in the path

When DNS resolution is enabled (the default), router PTR records often encode useful context: geographic location, interface type, ASN, and customer. Learn to read them.

A trace with lax01, sjc01, nrt01, hkg01, sin01 shows traffic exiting LA, hopping to San Jose, then Tokyo, Hong Kong, Singapore — useful when diagnosing why latency spikes mid-path.

PowerShell equivalent: Test-NetConnection -TraceRoute

PowerShell exposes a traceroute capability via Test-NetConnection -TraceRoute, returning a structured object that is easier to script against than text-parsing tracert.

Test-NetConnection -ComputerName 8.8.8.8 -TraceRoute

Output:

ComputerName     : 8.8.8.8
RemoteAddress    : 8.8.8.8
TraceRoute       : {192.168.1.1, 10.0.0.1, 100.64.0.1, 72.14.215.165...}
PingSucceeded    : True

# Extract a clean list of hops
(Test-NetConnection 8.8.8.8 -TraceRoute).TraceRoute

Output:

192.168.1.1
10.0.0.1
100.64.0.1
72.14.215.165
8.8.8.8

# Pair hops with reverse DNS in one command
(Test-NetConnection 1.1.1.1 -TraceRoute).TraceRoute |
    ForEach-Object {
        $name = try { [System.Net.Dns]::GetHostEntry($_).HostName } catch { '' }
        [PSCustomObject]@{Hop=$_; PTR=$name}
    }

TCP traceroute alternatives

When ICMP is filtered along the path (extremely common in the public Internet today), the standard tracert fails. Windows does not ship a native TCP tracer, but the technique is available through third-party tools and through PowerShell with raw sockets. Two practical options:

• tcping.exe — free third-party TCP ping/trace tool
• paping — Python-based, cross-platform
• WSL + traceroute -T -p 443 — easiest for any Linux-savvy admin
• Wireshark + manually crafted TTL-increment packets

# Inside WSL — TCP traceroute to port 443
sudo traceroute -T -p 443 -n example.com

Output:

traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
 1  192.168.1.1  0.5 ms  0.4 ms  0.5 ms
 2  10.0.0.1  8.0 ms  8.1 ms  8.0 ms
 ...
 6  93.184.216.34  14.0 ms  13.9 ms  14.0 ms

Interpreting the trace deeper

A few common patterns worth recognising on a problem trace:

1. Sudden latency jump mid-path — usually a long-haul link; check geographic PTR labels to see if traffic took a roundabout route.
2. All hops * * * after hop N — packets reach a router that drops further TTL-exceeded; not necessarily a break (test the destination with ping).
3. Same router responding to multiple hops — ECMP load-balancing or a router with multiple interfaces; consider Paris-traceroute for path stability.
4. High loss only on tracert but ping works — routers rate-limit ICMP-generated traffic; the loss is the router's CPU policy, not real packet loss.
5. Last hop unreachable but penultimate fine — destination host's firewall drops ICMP; the network path is healthy.
6. Trace ends at a private RFC1918 address — destination is behind a NAT; the trace stops at the public ingress.

Tracing through specific paths in cloud networks

Cloud networks (AWS, Azure, GCP) often hide intermediate routers behind anycast or SDN. AWS shows the customer side of the VPC route but not the underlay; Azure NAT gateways and Application Gateways appear as a single hop. Use:

• Test-NetConnection -TraceRoute -DiagnoseRouting for richer diagnostics on Azure VMs
• AWS VPC Reachability Analyzer for inside-cloud paths
• Cloudflare's 1.1.1.1 and Google's 8.8.8.8 are anycast — the trace may end at the closest PoP, not a single fixed datacentre

Common pitfalls

1. * * * at a hop is not always a break — routers commonly deprioritise or drop ICMP TTL-exceeded messages; the path may still work end-to-end if later hops respond.
2. Long traces on lossy paths — tracert sends three probes per hop and waits 4 s each; a 30-hop trace can take minutes. Use -d and -w 1000 to speed it up.
3. ICMP blocked by firewalls — some corporate firewalls block outbound ICMP, making tracert return all * * * even on a healthy path; use pathping, Test-NetConnection -TraceRoute, or a TCP-based tracer instead.
4. Asymmetric routing — tracert shows only the forward path; the return path may be different and could be the source of latency.
5. Comparing traces — always combine with -d for consistent IP-based comparison across runs; DNS names can change between traces.
6. Load balancers and ECMP cause path flapping — successive probes to "the same hop" may actually go through different routers, producing jittery RTTs that look like loss; Paris-traceroute (Linux) fixes this but Windows tracert does not.
7. MPLS hides hops — providers using MPLS may not decrement TTL inside the cloud (the no-propagate-ttl config), so a 6-hop trace might really cross 20 internal routers.
8. NAT/Carrier-Grade NAT — paths starting with 100.64.x.x indicate the ISP is using CGNAT (RFC 6598); your "first public hop" may actually be three routers in.
9. -h too low — defaulting to 30 hops covers almost everything; lower values prematurely end traces to distant destinations.
10. tracert is not a packet-loss tool — three probes per hop is insufficient sampling; reach for pathping when loss measurement matters.
11. DNS lookups slow the trace — every hop triggers a PTR query that may time out; -d is almost always the right choice for diagnostic work.
12. IPv4 fragmentation can confuse the output — large probes hitting a low-MTU link may show inconsistent RTTs; default 32-byte probes are usually fine.

Real-world recipes

Quick route check with fast settings

tracert -d -h 15 -w 1000 8.8.8.8

Output:

Tracing route to 8.8.8.8
over a maximum of 15 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  ...
  5    14 ms    14 ms    14 ms  8.8.8.8

Trace complete.

Compare routes to two endpoints

@echo off
echo === Route to 8.8.8.8 === > C:\Logs\routes.txt
tracert -d -h 20 8.8.8.8 >> C:\Logs\routes.txt
echo. >> C:\Logs\routes.txt
echo === Route to 1.1.1.1 === >> C:\Logs\routes.txt
tracert -d -h 20 1.1.1.1 >> C:\Logs\routes.txt
echo Done. See C:\Logs\routes.txt

Output:

Done. See C:\Logs\routes.txt

Find the first hop that introduces high latency

tracert -d example.com | findstr /R "[0-9][0-9][0-9] ms"

Output:

  8   142 ms   138 ms   140 ms  203.0.113.45

Extract hops as structured objects

When you need to feed the trace into a script (alerting, comparison, visualisation), parse with PowerShell into a typed array.

$hops = Test-NetConnection 8.8.8.8 -TraceRoute -InformationLevel Detailed |
    Select-Object -ExpandProperty TraceRoute
$hops | ForEach-Object -Begin { $i = 0 } -Process {
    $i++
    $ping = Test-Connection -ComputerName $_ -Count 1 -ErrorAction SilentlyContinue
    $ms = if ($ping) { $ping.Latency } else { 'N/A' }
    [PSCustomObject]@{Hop=$i; IP=$_; Latency=$ms}
}

Output:

Hop IP             Latency
--- --             -------
  1 192.168.1.1          0
  2 10.0.0.1             8
  3 100.64.0.1          12
  4 72.14.215.165       14
  5 8.8.8.8             14

Schedule a daily trace and diff against yesterday

A daily snapshot detects route changes that often correlate with new latency or loss problems.

@echo off
set TS=%date:~-4,4%-%date:~-10,2%-%date:~-7,2%
set OUT=C:\Logs\trace_%TS%.txt
tracert -d 8.8.8.8 > %OUT%
if exist C:\Logs\trace_yesterday.txt (
    fc %OUT% C:\Logs\trace_yesterday.txt > C:\Logs\trace_diff_%TS%.txt
)
copy /Y %OUT% C:\Logs\trace_yesterday.txt
echo Trace recorded: %OUT%

Output:

Trace recorded: C:\Logs\trace_2026-05-25.txt

Trace through a specific source interface

On multi-homed hosts (VPN client, container host), check the path each interface uses by binding -S to its IP.

tracert -d -S 192.168.1.100 8.8.8.8 > C:\Logs\trace_lan.txt
tracert -d -S 10.8.0.5      8.8.8.8 > C:\Logs\trace_vpn.txt
fc C:\Logs\trace_lan.txt C:\Logs\trace_vpn.txt

Output:

Comparing files trace_lan.txt and trace_vpn.txt
***** trace_lan.txt
  1    <1 ms  192.168.1.1
***** trace_vpn.txt
  1     5 ms  10.8.0.1
*****

TCP traceroute via PowerShell using raw sockets

A pure-PowerShell TCP traceroute that works through ICMP-blocking paths. Sends a TCP SYN to the target port with increasing TTL; relies on the local stack returning ICMP type 11 errors to user-mode (visible via the asynchronous Connect timeout).

function TCPTraceroute {
    param([string]$Target, [int]$Port = 443, [int]$MaxTTL = 20)
    1..$MaxTTL | ForEach-Object {
        $ttl = $_
        $client = New-Object Net.Sockets.TcpClient
        $client.Client.Ttl = $ttl
        $sw = [Diagnostics.Stopwatch]::StartNew()
        try {
            $async = $client.ConnectAsync($Target, $Port)
            $done = $async.Wait(2000)
            $sw.Stop()
            $ip = if ($client.Connected) { $Target } else { '*' }
            "{0,3}  {1,4} ms  {2}" -f $ttl, $sw.ElapsedMilliseconds, $ip
            if ($client.Connected) { return }
        } catch {
            "{0,3}  {1,4} ms  {2}" -f $ttl, $sw.ElapsedMilliseconds, $_.Exception.Message
        } finally { $client.Close() }
    }
}
TCPTraceroute -Target www.example.com -Port 443

Output:

  1     1 ms  *
  2     8 ms  *
  3    12 ms  *
  4    13 ms  *
  5    14 ms  93.184.216.34

(* rows mean the intermediate router did not produce a usable ICMP response in user-mode; the final hop's Connected = True terminates the search.)

Compare two paths side-by-side

A quick diff identifies any divergence between two destinations — useful when one site is slow and another is fast.

$a = (Test-NetConnection 8.8.8.8 -TraceRoute).TraceRoute
$b = (Test-NetConnection 1.1.1.1 -TraceRoute).TraceRoute
0..([Math]::Max($a.Count,$b.Count)-1) | ForEach-Object {
    [PSCustomObject]@{Hop=$_+1; To_8888=$a[$_]; To_1111=$b[$_]}
}

Output:

Hop To_8888         To_1111
--- -------         -------
  1 192.168.1.1     192.168.1.1
  2 10.0.0.1        10.0.0.1
  3 100.64.0.1      100.64.0.1
  4 72.14.215.165   141.101.65.1
  5 8.8.8.8         1.1.1.1

The point at which the columns diverge identifies the first router making different routing decisions for the two destinations.

See also

• ping — quick reachability test before tracing
• pathping — combines tracert with sustained loss measurement
• nslookup — verify the destination resolves to the expected IP
• route — inspect the local routing table that decides which interface tracert leaves on
• arp — Layer 2 view of the first hop
• netsh — netsh trace start is the kernel-level packet trace

Sources

• Test-NetConnection — Microsoft Learn (Windows Server 2025) — PowerShell equivalent combining ping, tracert, and TCP port checks via -TraceRoute.
• Test-Connection — Microsoft Learn (PowerShell 7.5) — ICMP echo request cmdlet; ships in PowerShell 7+.
• What's the PowerShell equivalent of tracert — PDQ — comparison of tracert.exe, Test-NetConnection -TraceRoute, and parsing patterns.
• Using Test-NetConnection for IPv4 Connectivity Testing — OneUptime (Mar 2026) — current syntax and PowerShell 7.5 guidance.