Traceroute to a host
Map the network path to a destination — for diagnosing latency spikes, ISP-level routing problems, and "where exactly is this packet getting dropped".
How to traceroute to a host in each shell
traceroute example.comDefault probe mode: UDP on BSD/macOS, UDP on Linux. `-I` switches to ICMP (closer to `tracert` semantics — many firewalls allow ICMP but block traceroute's default UDP). `-T -p 443` does TCP traceroute to port 443 (best for firewalled paths).
traceroute example.comtraceroute example.comTest-NetConnection -ComputerName example.com -TraceRouteReturns objects with each hop's IP. Slow — equivalent to `tracert -d -h 30` (max 30 hops, no DNS reverse-lookup). For ICMP-only and shell-style output, `tracert example.com` is fine.
tracert example.comWindows uses ICMP echo (NOT UDP like Linux). `-d` skips reverse DNS (much faster). `-h 30` limits hops. `-w 1000` per-hop timeout. UDP/TCP traceroute is not available natively — install `mtr` or use `pathping`.
Equivalents listed for Bash, Zsh, Fish, PowerShell, cmd.exe.
Gotchas & notes
- **Probe mode divergence is the most-asked traceroute question**: Linux/BSD `traceroute` defaults to UDP (ports 33434+), Windows `tracert` uses ICMP. Many corporate firewalls block UDP traceroute by policy → "traceroute hangs after hop 3 on Linux but tracert works on Windows" is almost always this. Force ICMP on Linux: `sudo traceroute -I example.com` (`-I` requires raw sockets → setuid or sudo). For paths through firewalls that block ICMP too, **TCP traceroute** is the answer: `sudo traceroute -T -p 443 example.com` — probes look like normal HTTPS traffic and traverse most policies.
- **`mtr` (My Traceroute) is what you actually want for diagnostics** — combines traceroute + ping in one continuously-updating screen. Shows packet loss % per hop, last/avg/best/worst RTT, jitter. `mtr example.com` for ASCII UI; `mtr -r -c 10 example.com` for a report-mode snapshot suitable for paste-into-ticket. Available on macOS (`brew install mtr`), all Linux distros (`apt install mtr` or `mtr-tiny`), and Windows (`choco install mtr` or `winget install mtr`). Modern engineers reach for `mtr` first; classic `traceroute` only for "I need one paragraph and zero deps".
- **Hops with `* * *` are NORMAL** — they don't mean "broken". Many routers are configured to RATE-LIMIT or refuse to emit `TIME_EXCEEDED` ICMP messages (RFC 1812 §4.3.2.8 allows it). Common at large ISP edges (Tier 1 backbones) and inside cloud provider networks (AWS, GCP, Azure deliberately suppress ICMP from many internal hops). If the FINAL hop responds but middle hops show `*`, the path is healthy — only if the final destination also fails should you suspect a path problem.
- **Asymmetric routing trap**: traceroute shows the FORWARD path only. Return-path issues (which often cause real symptoms) are INVISIBLE in a one-way traceroute. If you suspect asymmetric routing, run traceroute from BOTH ends (your laptop to the server, AND the server to your laptop's public IP). `mtr` from both sides reveals whether packet loss is symmetric or one-directional. On corporate VPNs, asymmetric routing is the norm — outbound goes through the VPN, return comes through the user's ISP.
- **Windows `pathping` combines both worlds**: `pathping example.com` does an initial traceroute, then sends N packets per hop and reports loss + latency statistics — basically `mtr -r` in cmd. Takes ~5 minutes by default (long sampling window). Reduce: `pathping -q 50 -p 100 example.com` (50 packets per hop, 100ms apart). Not as polished as mtr but no install required on any Windows since 2000.
Related commands
Related tasks
- Check if a URL is reachable— Test whether a URL returns 2xx/3xx — useful for healthchecks, wait-for-it scripts, and CI smoke tests.
- Test a TCP connection with nc— Confirm whether you can open a TCP socket to host:port — the basic "is this thing reachable" check before debugging deeper protocol issues.
- Look up a hostname's IP address— Resolve a hostname (e.g. example.com) to its A / AAAA record from the shell.
- Flush the DNS cache— Wipe the local DNS resolver cache — so a freshly-changed record actually resolves to the new IP instead of the stale one.