Traceroute: How to Find Exactly Where Your Connection Is Slow

Your site is slow for visitors in a certain region, but when you check the server, everything looks fine. Low CPU, normal memory, application response time at 80 ms. So the problem isn't your server — it's somewhere between the visitor and you.

Between a user's device and your server, there are on average 15 to 20 intermediate routers. Each one is a hop where data can be delayed, congested, or dropped entirely. Traceroute is the tool that maps that path and reveals exactly where the problem is.

What Is Traceroute and How It Works

Traceroute is a network diagnostic tool that discovers the path packets take between two points on the internet and measures the latency at each intermediate hop.

The mechanism is elegant: it uses a field called TTL (Time to Live) in IP packets. TTL is a counter that decrements by 1 at each router the packet passes through. When TTL reaches zero, the router discards the packet and sends an error message back to the origin — and that response is exactly what traceroute captures.

The process works like this:

Traceroute sends the first packet with TTL = 1. The first router on the route decrements it to zero, discards the packet, and replies with a "TTL exceeded" message. This reveals the IP address and latency of the first hop.
Next, it sends a packet with TTL = 2. Now the second router responds. And so on.
This repeats, incrementing TTL each round, until the packet reaches the destination or the maximum hop count is hit (usually 30).

For each hop, traceroute sends three packets and records the response time of each. The result is a timeline of the full route, with the identity and latency of every intermediate point.

How to Interpret Traceroute Results

Understanding what you're looking at is the most important part. A misread traceroute leads to wrong conclusions.

Normal Growing Latency vs. Abnormal Spike

It's completely expected for latency to increase across hops. Each router adds processing time, and the physical distance between points accumulates propagation delay. A route from New York to a server in Europe might show latency growing from 2 ms on early hops to 120 ms near the destination — that's normal.

What you're looking for is an abnormal spike: a hop where latency jumps sharply compared to the previous one.

Example of a healthy route:

Hop  1:   2 ms   2 ms   2 ms  — Local router
Hop  2:   8 ms   8 ms   9 ms  — Regional ISP
Hop  3:  22 ms  22 ms  23 ms  — Backbone gateway
Hop  4:  45 ms  44 ms  46 ms  — Internet exchange point
Hop  5: 120 ms 121 ms 120 ms  — Destination server (Europe)

Example with a problem at hop 4:

Hop  3:  22 ms  22 ms  23 ms
Hop  4: 380 ms 410 ms 395 ms  ← abnormal spike here
Hop  5: 390 ms 388 ms 392 ms

In the second example, the problem is clearly at the hop 4 router. Subsequent hops inherit the high latency, but the culprit is that specific point.

Intermediate Timeouts Aren't Always a Problem

It's common to see asterisks (* * *) instead of response times on some intermediate hops. This means the router at that point didn't respond.

Don't panic. Many backbone routers are configured to not reply to TTL-exceeded packets for security and performance reasons. They simply discard the error message without responding.

What matters is: if the hops after the timeout continue responding with normal latency, there's no problem. The silent router is just a point that doesn't cooperate with diagnostics, but is working correctly.

The real problem is when timeouts appear on the last hops or when the traceroute stops progressing — that means packets are being dropped and never reaching the destination.

High Latency on the Last Hop = Problem at the Destination

If latency only jumps significantly on the last hop (the destination server), the problem is in the server itself or its immediate network — firewall, load balancer, or the application taking too long to respond.

In that case, traceroute has done its job: it ruled out the network as the suspect and pointed the finger at the server.

How to Use FlashMon's Online Traceroute

Running traceroute via command line requires terminal access and can be blocked by corporate network policies. FlashMon's Online Traceroute solves this with a visual interface anyone can use in the browser.

Just type a domain or IP address and click run. The tool performs the traceroute from our servers and presents the result in an interactive visual timeline:

Each hop appears as a point on the timeline, with the IP address, hostname (when available), and all three response times
Hops with latency above expected are visually highlighted, making the problem point immediately obvious
Timeouts are clearly shown as * * *, without being confused with actual failures
The timeline shows how latency progresses along the route, making sudden spikes easy to spot

This is especially useful when you suspect a specific transit provider is causing slowness for visitors in a certain region — you can see exactly which AS (Autonomous System) the delay begins in.

When to Use Traceroute vs. Ping vs. Speed Test

These three tools answer different questions. Using them in the right order saves time.

Use Speed Test first when the symptom is "the site is slow" with no further details. FlashMon's Speed Test measures actual page load time, resources blocking rendering, and overall performance. If the problem is in the server or the application, you'll find it here without needing to dig deeper.

Use Ping when you want to confirm a destination is reachable and measure basic latency continuously. FlashMon's Ping tests from multiple regions simultaneously, which already hints at whether the problem is geographic. If ping from New York is 20 ms but from Frankfurt is 400 ms, you know the route to Europe has something wrong.

Use Traceroute when ping confirms high latency or packet loss and you need to know where on the route it's happening. Traceroute is the second-level diagnostic tool: more detailed, more informative, and it pinpoints the responsible party.

An efficient diagnostic workflow:

User reports slowness → Speed Test to check real page performance
Page loads slowly or times out → Ping from multiple regions to isolate if it's geographic
High ping from a specific region → Traceroute to identify which hop is responsible

This funnel eliminates hypotheses quickly and prevents you from spending hours investigating the server when the problem is actually at a transit ISP.

Traceroute Limitations

Traceroute is powerful, but it has limits you need to know to avoid drawing wrong conclusions.

The tool shows the route from FlashMon's servers to the destination, not from your user's device. If a visitor has a specific problem with their own ISP, you won't see that — only the route from our infrastructure. To diagnose client-side problems, the user needs to run traceroute from their own device.

Also, internet routes aren't static. The path a packet takes can change between runs due to load balancing and dynamic routing. A single anomalous result is less meaningful than a consistent pattern across multiple attempts.

Finally, traceroute uses ICMP or UDP — protocols that may be treated differently by corporate firewalls. Some environments block these protocols while letting HTTP traffic through normally, which means traceroute may show timeouts on routers that are, in practice, working perfectly for your actual traffic.

When your site shows intermittent slowness for users in specific regions, traceroute is often the only tool that points to the responsible party with enough precision to act on. Whether you need to open a ticket with a transit provider, adjust routing policies, or simply confirm the problem isn't yours — knowing exactly where packets are struggling is the first step to fixing it.

FlashMon's Online Traceroute is available now, no installation and no command line required. And if you monitor your site's uptime, FlashMon also alerts you when it goes down — before your users have to tell you.

Keep exploring

Slowness with no network hop responsible? Rule out DNS first with the DNS diagnosis guide and the DNS Lookup tool.
Pair traceroute with the Ping tool to see whether the issue is a single region or global.