How Does Traceroute Work? | Map A Network Hop By Hop

When a site feels slow, you want one simple truth: where does the delay start? Traceroute is the classic tool for that. It doesn’t fix the issue. It shows the path your traffic takes, hop by hop, and it times each step so you can spot where latency jumps or where replies stop coming back.

This article explains traceroute from the packet level up. You’ll see why it sends multiple probes per hop, what those stars mean, and how to turn output into a clear next step.

What Traceroute Is Measuring

Traceroute is a controlled test with one moving part: the packet’s hop limit. In IPv4 that’s the Time To Live (TTL) field, and in IPv6 it’s Hop Limit. Each router that forwards the packet reduces it by at least one. When it hits zero at a router, that router drops the probe and sends an error reply back to you.

By starting with TTL 1 and then increasing it one hop at a time, traceroute coaxes each router along the route to identify itself via its reply source IP. The timing shown for a hop is the round-trip time from your machine to that hop and back.

If you want the exact packet rules behind this, the TTL field is defined in RFC 791 (Internet Protocol), and the ICMP Time Exceeded message is defined in RFC 792 (Internet Control Message Protocol).

How Does Traceroute Work? Step-By-Step Packet Flow

Most traceroute runs follow the same loop. The probe type can differ, but the logic stays steady.

Step 1: A Probe Packet Is Chosen

• Classic Unix traceroute: UDP probes to a high destination port that is unlikely to be open.
• Windows tracert: ICMP Echo Request probes (the same family used by ping).
• Many modern builds: optional ICMP, UDP, or TCP probes.

This choice matters because networks often filter ICMP, UDP, and TCP in different ways.

Step 2: Three Probes Are Sent Per Hop

That “three timings per hop” layout comes from sending multiple probes at the same TTL. It gives you a tiny sample so a one-off spike doesn’t trick you into blaming the wrong link.

Step 3: Routers Reply When TTL Runs Out

Routers forward packets normally: receive, reduce TTL, route onward. When TTL reaches zero, the router discards the probe and sends an ICMP Time Exceeded message back to you.

Step 4: The Destination Ends The Trace

When the probe finally reaches the destination host, the destination replies in a way that depends on the probe:

• UDP traceroute: often returns “Port Unreachable.”
• ICMP traceroute: returns an ICMP Echo Reply.
• TCP traceroute: may return SYN-ACK (open) or RST (closed).

Once traceroute sees a destination-style reply, it stops increasing TTL.

Reading Traceroute Output Without Guessing

A typical line shows a hop number, a host name or IP, then several timings in milliseconds. A clean read comes from comparing hop to hop, not staring at a single scary number.

Look For A Sustained Step Up

The strongest signal is a step change that persists. If hop 5 sits near 12 ms, hop 6 sits near 85 ms, hop 7 is also near 85 ms, and the destination stays near 85 ms, the delay likely starts near hop 6. If hop 6 is high but hop 7 drops back down, that hop may just be replying slowly while forwarding traffic normally.

Know What The Stars Mean

Stars (often shown as “*”) mean a probe timed out. That can happen when a router is configured not to send ICMP replies, a firewall drops probes or replies, or rate limiting kicks in. A full line of stars can still be normal if later hops answer.

Treat Names As Hints

Many hop names come from reverse DNS and can be stale, generic, or missing. The IP is the dependable data point.

What A “Hop” Really Represents

A hop is not “a box on a shelf.” It’s the interface IP of a device that chose to reply to your probe. On big routers, the reply often comes from the interface that faced you, not the interface that forwarded the packet onward. So the hop IP can be a link IP, a loopback IP, or a management-style IP, depending on the vendor and config.

This also explains why the same physical router can show up as two different hops on different traces. Your probes may enter the router through one interface today and a different interface tomorrow. The forwarding device may be the same, but the IP that replies can change.

Why Some Hops Don’t Reply At All

Many networks silence ICMP errors on purpose. It reduces noise, it limits abuse, and it keeps busy routers focused on forwarding. Traceroute then shows “*” at that hop. If later hops answer, the path is still usable. You just have a quiet segment in the middle.

Why The Last Hop May Look Odd

CDNs, DDoS filters, and load balancers can answer traceroute on behalf of the origin server. You might reach an edge node that is “close enough” to reply, even if your HTTP request later goes deeper into a private network. Treat the final hop as “where the probe ended,” not a guarantee that your application stack lives there.

Common Traceroute Patterns And What They Point To

Use this table to scan output faster. It’s a shortlist of likely causes and the next check that tends to pay off.

Why Traceroute Can Look Wrong

Traceroute measures replies to its probes, not your app packets. Three common reasons for confusing output are:

• ICMP rate limits: routers cap how many ICMP errors they generate, so timings inflate or probes time out.
• Asymmetric paths: the reply can return by a different route than the probe took.
• Load balancing: probes may follow different parallel links, so hop IPs can vary.

Running Traceroute On Windows, macOS, And Linux

Built-in tools are enough for most checks.

Windows

Run tracert example.com. It uses ICMP Echo by default.

macOS And Linux

Run traceroute example.com. Many builds default to UDP, and some allow ICMP (-I) or TCP SYN probes (-T).

When A TCP Trace Helps

If the goal is “can users reach my site,” a TCP probe to port 443 often matches real traffic better than ICMP, since many networks allow HTTPS while blocking diagnostic ICMP.

Options That Change The Result

A few settings are worth knowing because they fix the most common dead ends.

Turning Output Into A Clear Next Step

If you need to hand traceroute to an ISP, hosting team, or cloud provider, add three bits of context:

• The time and time zone of the test
• The source network (home fiber, office LAN, mobile hotspot)
• Two runs taken a minute apart

Then write one plain sentence that points to the pattern: “latency steps up from ~15 ms to ~90 ms starting at hop 6 and stays high through the destination,” or “the trace stops after hop 9 on both runs.” That single line often gets you to the right queue faster.

Send us your feedbackTell us what you thought about this post

Name * Email *

Your comment *

Quick check — what is …? *

Send feedback