What Is Traceroute? A Detailed Guide to How It Works and How to Use It

Your website loads fine, but some regions experience slow access; on the same server, telecom users see latency of just tens of milliseconds, while mobile users suddenly see it jump to one or two hundred milliseconds; the server is deployed in Singapore, but the actual access path detours through Japan or even the US. When facing such issues, just looking at Ping often makes it hard to determine the cause. That's when you need Traceroute.

Traceroute is a very common tool in network troubleshooting. It displays the network path from your local device to the target server, hop by hop. For website operations, server management, CDN routing, and cross-border network optimization, mastering the basics of traceroute is often more valuable than just looking at a Ping latency.

This article starts with how Traceroute works, explains how to read the results, how to use it on different systems, and how to interpret timeouts, detours, and high latency.

1. What Is Traceroute?

When you type www.example.com in your browser, it seems like a direct connection between your computer and the server, but in reality, data packets traverse multiple layers of forwarding in the internet:

Your computer ➔ Home router ➔ ISP access network ➔ Provincial backbone ➔ ISP interconnect/international gateway ➔ Target data center ➔ Web server

Each router the packet passes through counts as one "hop." Traceroute's job is to identify these intermediate nodes as much as possible.

With a single Traceroute test, you can clearly see:

• How many hops it takes to reach the target;

• The IP address of each hop;

• The round-trip time (RTT) for each node;

• At which node the latency suddenly spikes;

• Whether the route crosses provinces, ISPs, or international borders;

• Whether the CDN has routed you to an odd node.

In short, Ping answers "is it reachable and fast?" while Traceroute answers "how does the data actually travel, and where is the congestion?"

When using different operating systems, the command name differs slightly:

• Windows command: tracert

• Linux / macOS command: traceroute

2. How Does Traceroute Work?

Traceroute might seem like it has a map to look up the entire network path, but its implementation is quite clever, using a basic field in IP packets—TTL (Time To Live).

To prevent packets from looping indefinitely due to routing loops, every packet is sent with a TTL value (e.g., 64). Each router decrements the TTL by 1. Once TTL reaches 0, the router discards the packet and sends an ICMP Time Exceeded message back to the source.

Traceroute exploits this "TTL reaches 0 triggers an alert" mechanism with a "throw a stone to test the road" approach:

1. Probe hop 1: Send a packet with TTL = 1. It reaches the first router, TTL becomes 0, and that router returns an ICMP timeout message. Your computer records the IP and latency of the first router.

2. Probe hop 2: Send a packet with TTL = 2. It passes the first router (TTL becomes 1), reaches the second router, TTL hits 0, and the second router returns a timeout. You get the IP and latency of hop 2.

3. Continue: Send TTL = 3, 4, 5... until the packet actually reaches the target server.

That's the essence of Traceroute: it doesn't get the full path at once; it deliberately causes timeouts step by step to force out the nodes along the way.

3. Why Does Each Hop Usually Show Three Latencies?

When you run Traceroute, you often see results like:

5    18 ms    20 ms    19 ms    202.97.xx.xx

Many newcomers think, "Are there three different nodes here?" Actually, no. These three times are typically RTTs from multiple probes to the same hop, i.e., round-trip delays.

For example:

18 ms
20 ms
19 ms

This indicates the three probes are close, so the hop is stable. If the result becomes:

20 ms
86 ms
21 ms

It means at least one probe had significant fluctuation.

However, note that a single RTT spike doesn't directly prove the router is faulty. You need to consider the entire path.

4. How to Use tracert on Different Operating Systems

1. Windows

Press Win + R, type cmd to open the command prompt, and enter: tracert www.example.com or test a specific IP: tracert 8.8.8.8

For troubleshooting, it's highly recommended to add the -d parameter: tracert -d www.example.com -d disables reverse DNS resolution of IP to hostname. Skipping hostname resolution significantly speeds up the test, making the output smoother.

2. macOS and Linux

On macOS Terminal, type: traceroute www.example.com

Linux uses the same command. If it says command not found, install it via the package manager:

• Ubuntu/Debian: sudo apt install traceroute

• CentOS/RHEL: sudo yum install traceroute

5. How to Read Traceroute Results

When actually using traceroute, the most important thing isn't "knowing how to run the command," but being able to interpret the results. Suppose you get this data:

1    <1 ms    <1 ms    <1 ms    192.168.1.1
2     5 ms     4 ms     5 ms    100.64.0.1
3     8 ms     9 ms     8 ms    202.96.xx.xx
4    15 ms    14 ms    16 ms    202.97.xx.xx
5    38 ms    41 ms    39 ms    203.xx.xx.xx
6    42 ms    43 ms    41 ms    103.xx.xx.xx
7    44 ms    45 ms    44 ms    8.8.8.8

Focus on the following.

1. What Does Hop Mean?

The numbers 1, 2, 3, 4, 5 represent Hop, i.e., the hop count. Roughly, it's the nth Layer 3 network node the data passes through.

For example:

1    192.168.1.1

This is often your local router. Subsequent nodes may gradually enter:

• ISP access network;

• Metropolitan area network;

• Backbone network;

• Inter-ISP interconnect;

• International links;

• Target data center.

However, note: More hops don't necessarily mean a worse route. A stable 15-hop route can be faster than an 8-hop route with severe congestion. So don't immediately judge line quality just because you see 20 hops.

2. How to Read RTT

For example:

18 ms
40 ms
120 ms

This shows the approximate round-trip time for the probe packet to reach that node and return.

What you should really focus on is:

From which hop does latency start to consistently increase significantly.

For example:

4     16 ms
5     18 ms
6     20 ms
7    185 ms
8    188 ms
9    191 ms

From hop 7 onward, latency stays above 180 ms.

This usually indicates:

A significant network change occurred between hop 6 and hop 7.

Possible causes include:

• Entering a cross-border link;

• Entering a long-distance backbone link;

• Inter-ISP interconnect;

• Congestion at international gateway;

• BGP routing detour.

This is much more valuable than just seeing:

Ping = 190 ms

Because Ping only tells you "it's slow," while Traceroute starts to tell you "where the slowness might be."

6. Common Misconceptions and Anomaly Troubleshooting

When reading traceroute results, beginners often fall into several traps, leading to misdiagnosis.

Misconception 1: Seeing * * * means the network is down 

Sometimes you see a hop with all asterisks: 7 30 ms 29 ms 31 ms 202.xx.xx.xx8 * * *9 35 ms 36 ms 34 ms 203.xx.xx.xx Many people's first reaction is "hop 8 router is down." That's not the case at all. As long as hops 9 and 10 still respond, it means packets passed through hop 8 fine. The asterisks appear because that router has firewall policies that refuse to respond to ICMP timeout packets, or it rate-limits such diagnostic packets.

Misconception 2: A middle hop has high latency, but later hops recover 

For example: 4 18 ms 17 ms 19 ms 202.97.xx.xx5 210 ms 190 ms 205 ms 202.97.xx.xx6 22 ms 21 ms 23 ms 202.97.xx.xx Hop 5 spikes above 200ms, but hop 6 returns to 20ms. This is also not a network failure. A router's core job is to "forward data." When its CPU is busy, it prioritizes user traffic and deprioritizes responding to diagnostic packets like Traceroute. This just means the router's ICMP response is slow; actual business traffic through that router isn't slow at all.

7. Why Testing Locally Isn't Enough

Running tracert from your own computer only represents the path "your broadband ➔ target server."

If you're doing website operations or network troubleshooting, that's far from sufficient. Because:

• Guangzhou Telecom users go through the Guangzhou gateway;

• Beijing Unicom users might go through the Beijing gateway;

• Mobile users might get stuck at inter-ISP interconnect nodes.

If you're facing "slow access in some regions" or "specific ISP lag," you can use Chahu, which sends packets from dozens of test points nationwide or even globally, allowing you to compare paths from different regions and ISPs to your server side by side.

Often, the comparison reveals the truth: Shanghai Telecom uses a direct route, arriving in 30ms; Beijing Unicom, for some reason, detours through Japan, pushing latency to 150ms. Once you find the detour node, you can specifically ask the ISP to adjust routing or change node configuration.

8. The Correct Order for Troubleshooting Network Issues

When your website or service experiences slow access, relying on a single tool is one-sided. The most scientific approach is to use these four steps in order on Chahu:

1. DNS Lookup: First, confirm the IP resolved from the domain is correct and hasn't been misdirected to a distant CDN node.

2. Ping Test: Check basic connectivity, packet loss rate, and overall latency range.

3. Traceroute: If latency is high or there's packet loss, use it to pinpoint where the problem starts (local network, ISP backbone, international gateway) and whether there's an odd detour.

4. HTTP Speed Test / API Analysis: If the network path and latency are completely normal but the site still won't load, the problem isn't the network. Check server CPU, database queries, TLS handshake, or code performance (TTFB).

​

The real value of traceroute isn't just displaying a list of IP addresses; it makes the invisible network access path observable. When your website experiences cross-region latency, abnormal access from a specific ISP, overseas routing detours, or unreasonable CDN node routing, Ping often only tells you "it's slow," while Traceroute can dig deeper: where exactly does it go, and where does it start to slow down.

However, Traceroute isn't the only basis for diagnosing network faults. Non-responsive intermediate nodes, single-hop latency spikes, or path changes don't necessarily mean real business traffic is affected. In actual website troubleshooting, the more reliable method is to combine DNS lookup, Ping, Traceroute, and HTTP speed tests.

DNS confirms resolution and node routing, Ping assesses basic network quality, Traceroute shows the full access path, and HTTP speed tests further pinpoint issues with TCP, TLS, TTFB, and page load stages. This way, from "domain resolution" to "network path" and "website response," you can truly find the cause of slow website access, rather than just staring at an anomalous millisecond number.

FAQ

Q1: Why can I ping successfully, but the website won't open in the browser? 

A: Ping uses the ICMP protocol, which only indicates the network layer is reachable. Browsers access websites via HTTP/HTTPS, which involves the application layer and specific server business logic. If the server's port 80/443 is blocked by a firewall, Nginx/Apache is down, SSL certificate is misconfigured, or the database times out, you'll see "ping works, but the webpage won't load."

Q2: What's the difference between MTR and Traceroute? 

A: Traceroute performs a one-time static "scan" of the path at a specific moment. MTR (My Traceroute) is a combination of Ping and Traceroute. MTR continuously sends packets to every node along the path, dynamically and in real-time, calculating packet loss and latency jitter for each node. When troubleshooting intermittent lag or persistent packet loss, MTR is more valuable than Traceroute.

Q3: As a website administrator, how do I resolve BGP routing detours or cross-border latency spikes? 

A: Ordinary users or single servers can't directly influence ISP backbone BGP routing policies. If a routing detour occurs, the most effective solutions include: enabling a CDN service with premium global routes (such as CN2 GIA, 9929, CMIN2); using SD-WAN or relay nodes for traffic ingress; or submitting a ticket to your data center provider to request assistance in optimizing upstream BGP route announcements.

Q4: What's the difference between UDP, TCP, and ICMP modes in Traceroute? 

A: Different operating systems use different default protocols (e.g., Windows tracert uses ICMP by default, while Linux/macOS traceroute uses UDP). Many network devices and firewalls block UDP traffic or drop ICMP timeout packets, resulting in many asterisks. If the default probe fails, you can use traceroute -T or tcptraceroute on Linux to force TCP (e.g., port 80/443), which has the highest success rate in penetrating firewalls.