The one-line idea

traceroute discovers the path a packet takes from your host to a destination by sending packets with deliberately small TTL (Time To Live) values and reading the ICMP Time Exceeded messages that come back from each router that drops one.

Each router that decrements the TTL to zero is required to send back an ICMP message saying "your packet died here." That's how traceroute builds the hop list.

How it works

sequenceDiagram
    participant U as Your host
    participant R1 as Router 1
    participant R2 as Router 2
    participant R3 as Router 3
    participant D as Destination
    U->>R1: TTL=1
    R1-->>U: ICMP Time Exceeded (R1's IP)
    U->>R2: TTL=2 (via R1)
    R2-->>U: ICMP Time Exceeded (R2's IP)
    U->>R3: TTL=3 (via R1, R2)
    R3-->>U: ICMP Time Exceeded (R3's IP)
    U->>D: TTL=N (full)
    D-->>U: response (or ICMP Destination Unreachable)

traceroute sends three probes per TTL value by default, so each line shows three round-trip times.

When to reach for it

• "Is the problem on my end?" Run a traceroute to a known-good destination (e.g. 1.1.1.1 or google.com). If the first couple of hops look fine, your local network is healthy.
• "Where in the path does it break?" If a service is unreachable, traceroute shows whether the trouble is in the first hop (your router), in your ISP, in some transit network mid-path, or at the destination side.
• "Is the latency from far away, or from one hop?" Each hop shows its own RTT. A sudden jump from 15 ms to 180 ms between hop 4 and hop 5 usually means an undersea cable or a deliberately long path, not packet loss.

traceroute, tracert, mtr — three near-synonyms

• traceroute (Linux, macOS, BSD) — UDP probes by default to high-numbered ports, or use -I for ICMP, -T for TCP SYN. The default port-unreachable trick can be blocked by middleboxes.
• tracert (Windows) — same idea, ICMP echo by default. Different defaults than traceroute, otherwise the same protocol.
• mtr ("my traceroute") — a continuous traceroute that updates in place. Sends probes repeatedly so packet-loss percentages and average RTTs per hop become visible. Much more useful than a single-shot traceroute when you are diagnosing flapping or intermittent issues.

For most real diagnosis, mtr is the better tool. A one-shot traceroute can miss a problem that shows up as 30% loss over a minute.

Reading the output without overreading

Traceroute output is full of footguns. The common misreads:

• "This hop has high latency, so it is the problem." The latency you see is the RTT to that specific hop, replying with an ICMP message. Routers process ICMP at lower priority than data plane traffic. A hop in the middle showing 200 ms while the destination shows 80 ms usually means that router is slow to generate ICMP, not slow to forward packets. Look at the destination's latency, not the slowest middle hop.
• "A row of stars means the path is broken." Often it means the router on that hop refuses to send ICMP Time Exceeded (rate-limited, filtered, or just disabled). If subsequent hops respond normally, the path is fine; one specific router is silent.
• "The route changed between probes." Asymmetric and load-balanced paths are common. Two consecutive probes can reach the destination through different intermediate routers. mtr with --no-dns --report mode is more stable for this reason.
• "I see IP addresses, not hostnames." Reverse DNS for transit routers is patchy. The IP is the reliable identifier; the hostname (when it exists) is often a useful hint about the operator (*.cogent.com, *.he.net, *.ntt.net).

When traceroute is the wrong tool

Traceroute walks the forward path only. Many issues are on the return path, which you cannot see from your side without running a traceroute from the destination back to you. If you have shell access to both ends, run traceroute in both directions; the asymmetric routing in modern networks frequently means the path is different each way.

For TCP-specific problems — e.g. a particular service is unreachable but ICMP works fine — use tcptraceroute or mtr --tcp --port 443. The path your TCP traffic takes can be different from the path ICMP takes.

A useful default workflow

# Quick one-shot, ICMP, full hostnames
traceroute -I example.com

# Continuous, statistics over time
mtr -n example.com

# When a specific port matters (e.g. HTTPS)
mtr --tcp --port 443 example.com

Most network diagnosis sessions start with mtr rather than traceroute for the simple reason that flapping is more common than a hard break.