Skip to content
shellmap

traceroutetraceroute equivalents — Unix UDP/ICMP probes, Windows tracert ICMP, pwsh Test-NetConnection -TraceRoute, mtr realtime hop loss across all 5 shells

Equivalents in every shell

Bashunix
traceroute google.com

Linux: default UDP probes to ports 33434+ — usually needs no root since Linux 2.6.18+ via unprivileged sockets, but some distros restrict and need `sudo`. `-I` switches to ICMP echo (matches Windows tracert behavior — more likely to traverse routers that filter UDP). `-T` switches to TCP SYN to a specific port (`-T -p 443`) — most likely to succeed through firewalls that only allow established HTTP/HTTPS. `-n` skip reverse-DNS for hop IPs (faster). `-m <hops>` max hops (default 30). `-w <sec>` per-probe timeout. `-q <count>` probes per hop (default 3). On Alpine/minimal images, install `traceroute` or `iputils-tracepath`; on Ubuntu 22.04+ it ships in main but not as a default.

Zshunix
traceroute google.com

Same Linux binary. On macOS, `traceroute` is BSD-derived (slightly different flags) — `-P` instead of `-T -p` for TCP probe port specification, `-A` shows ASN per hop (BSD-only extension). macOS `traceroute` typically does NOT require sudo for UDP probes; it WILL require sudo for `-I` (ICMP) on older macOS.

Fishunix
traceroute google.com

No fish-specific wrinkle — `traceroute` is a separate binary. CAVEAT: fish does NOT auto-load distro-specific `iputils-traceroute` vs `inetutils-traceroute` — both implementations are in apt repos with slightly different flags. Check with `traceroute --version` first to confirm which you have (iputils is `iputils-traceroute`; inetutils is the older GNU implementation).

PowerShellwindows
Test-NetConnection google.com -TraceRoute

pwsh-native cmdlet (Windows-only — lives in the `NetTCPIP` module). `-Hops 30` caps depth (default 30). Output exposes a `.TraceRoute` property as `string[]` of IP addresses — easy to pipe into other cmdlets. CAVEAT: `Test-NetConnection -TraceRoute` is SIGNIFICANTLY SLOWER than `tracert.exe` for the same trace (waits the full timeout on every hop even when reply arrives quickly). For cross-platform pwsh 7.4+: `Test-Connection google.com -TraceRoute` is the cross-platform-aware cmdlet (works on Linux/macOS pwsh too). For interactive use, shell to `tracert.exe -d google.com` from pwsh — much faster.

cmd.exewindows
tracert google.com

`tracert.exe` is the Windows builtin — uses ICMP echo-request (Type 8) probes, not UDP like Unix default. Flags: `-d` skip DNS resolution of hop IPs, `-h <count>` max hops (default 30), `-w <ms>` per-probe timeout in milliseconds, `-j <hostlist>` loose source routing. For richer per-hop statistics: `pathping google.com` — combines tracert + ping, gathers per-hop packet-loss stats over ~25 seconds. Much slower (~25s startup) but invaluable for "WHERE in the path am I losing packets" diagnosis.

Worked examples

Trace path to a host (default protocol)

Bash
traceroute google.com
Zsh
traceroute google.com
PowerShell
Test-NetConnection google.com -TraceRoute
cmd.exe
tracert google.com

Trace using ICMP probes (matches Windows tracert; better through UDP-filtering firewalls)

Bash
sudo traceroute -I google.com
Zsh
sudo traceroute -I google.com
PowerShell
Test-Connection google.com -TraceRoute
cmd.exe
tracert google.com

Trace TCP to port 443 (cross stateful firewalls that allow HTTPS)

Bash
sudo traceroute -T -p 443 google.com
Zsh
sudo traceroute -T -p 443 google.com
PowerShell
Test-NetConnection google.com -Port 443 -InformationLevel Detailed
cmd.exe
tracert google.com

Diagnose per-hop packet loss

Bash
mtr -n google.com
Zsh
mtr -n google.com
PowerShell
Test-NetConnection google.com -TraceRoute -InformationLevel Detailed
cmd.exe
pathping google.com

Gotchas

  • **Unix `traceroute` defaults to UDP; Windows `tracert` defaults to ICMP — same protocol gives different results.** Linux `traceroute google.com` sends UDP probes to high ports (33434+); routers reply with ICMP TIME_EXCEEDED as TTL hits 0. Windows `tracert google.com` sends ICMP echo requests directly. If your network blocks UDP > 1024 (common on corporate firewalls), Unix `traceroute` shows all stars from hop 2+ while Windows `tracert` may show the full path — symptom of UDP-filtering, not connectivity. Force ICMP on Linux: `sudo traceroute -I google.com` (matches tracert behavior). Force UDP on Windows: not built-in to `tracert.exe`; use `tracetcp` (community tool) or WSL Linux `traceroute`.
  • **Stars in the middle do NOT mean packet loss.** Every internet path includes routers configured NOT to respond to traceroute probes — for rate-limiting, ICMP filtering, or simply not configured to send TIME_EXCEEDED. A row of `* * *` in the middle means "this router doesn't talk to traceroute"; if the FINAL hop succeeds with full RTT, your end-to-end connectivity is fine. Stars at the END usually mean either the destination filters ICMP/UDP, or the path is broken upstream. Diagnostic rule: focus on the LAST responding hop and how far past it the trace goes before stars-forever.
  • **`-T` TCP probes are the most reliable through modern firewalls.** Most internet paths today are gated by stateful firewalls that allow ESTABLISHED TCP to common ports (80, 443, 22) but drop UDP and limit ICMP. `sudo traceroute -T -p 443 host.example.com` sends TCP SYN probes to port 443 — these reach further than UDP or ICMP probes because firewalls cannot distinguish them from legitimate HTTPS traffic. CAVEAT: requires sudo (raw socket access). On Windows: `tracetcp.exe` (community tool) provides this. Use TCP probing when UDP/ICMP show "destination unreachable" but you know the service IS reachable on the real port.
  • **TTL exhaustion is the mechanism — and asymmetric paths confuse the picture.** traceroute sends probes with TTL=1, 2, 3, …, n. Each router decrements TTL; when TTL hits 0, the router sends back ICMP TIME_EXCEEDED revealing its identity. CRITICAL: the REVERSE path from each hop back to your machine MAY differ from the forward path. So hop 7's RTT can be LARGER than hop 8's — that's asymmetric routing, not "hop 7 is slow". For true forward-path-only timing, you need both endpoints under your control + tools like `mtr --raw` with route-decoding.
  • **`mtr` is the better tool for ongoing diagnosis.** `traceroute` is one-shot — fires probes once per hop. For "is hop 5 LOSING packets right now", use `mtr -n google.com` (My Traceroute) — runs continuously, accumulating per-hop loss percentage and RTT statistics over time. UI updates every second. Pause: lowercase `p`. Quit: lowercase `q`. Report mode (one-shot, scriptable): `mtr -nrwc 100 google.com` (`-n` numeric, `-r` report mode, `-w` wide format, `-c 100` 100 probes per hop). Native on Linux + macOS (`brew install mtr`); Windows alternative: `winmtr` (community GUI) or `pathping` (built-in, similar but slower).

WSL & PowerShell Core notes

pwsh`Test-NetConnection -TraceRoute` is Windows-only. For cross-platform pwsh, `Test-Connection -TraceRoute` (pwsh 7.4+ added the flag to the cross-platform `Test-Connection`). On Linux/macOS pwsh, you can also shell out to the system `traceroute` / `mtr` binaries.
WSLInside WSL, `traceroute` traces from the WSL VM's perspective — hop 1 is the WSL2 NAT gateway (the Windows host's virtual switch). To trace from the Windows host's perspective, run `tracert.exe google.com` (the `.exe` works directly from WSL bash). Difference matters for "is the slow hop inside my LAN or upstream" — WSL adds one virtual hop.

Common tasks using traceroute

Related commands