How to Identify Network Bottlenecks With Traceroute

A network bottleneck is the point on a path where delay or loss begins and never goes away again. Traceroute and mtr can find it, but most of what they show is noise: routers that answer probes slowly, drop the probes, or stay silent, while forwarding real traffic perfectly. This guide uses real traces from our servers, run on 7 October 2026, to show the rule that separates the two, and what to do once you have found a real one.

The rule: it has to last until the destination

Each line of a trace is a separate round trip, answered by a different router. Routers forward traffic in hardware but answer probes in software, at low priority, and most of them limit how many answers they send per second. So a hop that looks slow or lossy only matters if every hop after it, up to the destination, looks the same. TraceMapper applies the same rule when it writes its verdict on a trace: a rise only counts if it persists to the destination.

Real trace 1: 82% "loss" that is not loss

From our server in Falkenstein, Germany, to a Vultr test host in Singapore (mtr -rwz -c 60, 60 probes per hop):

  5. AS1299   hbg-b2-link.ip.twelve99.net                      0.0%    60   11.9  11.7  11.3  12.1   0.2
  6. AS1299   hbg-bb3-link.ip.twelve99.net                    53.3%    60   25.0  25.0  24.7  25.3   0.2
  7. AS1299   ffm-bb1-link.ip.twelve99.net                     0.0%    60   30.2  30.1  29.8  30.5   0.2
  8. AS1299   prs-bb1-link.ip.twelve99.net                     0.0%    60   38.6  38.1  37.7  38.6   0.2
  9. AS1299   mei-b5-link.ip.twelve99.net                      0.0%    60   32.3  32.3  32.0  32.7   0.2
 10. AS1299   sng-b6-link.ip.twelve99.net                      0.0%    60  169.7 178.0 169.5 249.9  16.1
 11. AS1299   sng-b7-link.ip.twelve99.net                      0.0%    60  169.0 169.0 168.0 179.5   2.2
 12. AS1299   sng-b5-link.ip.twelve99.net                     81.7%    60  168.0 190.1 167.6 381.6  64.2
 13. AS1299   constantcompany-ic-379815.ip.twelve99-cust.net   0.0%    60  164.7 165.1 164.7 166.3   0.2
 14. AS???    ???                                             100.0    60    0.0   0.0   0.0   0.0   0.0
 15. AS???    ???                                             100.0    60    0.0   0.0   0.0   0.0   0.0
 16. AS20473  45.32.98.222.vultrusercontent.com                0.0%    60  172.5 172.3 172.0 172.5   0.1
 17. AS20473  45.32.100.168                                    0.0%    60  164.7 165.5 164.3 175.0   1.8

• Hop 6 loses 53% of the probes, hop 7 none. If packets were really lost at hop 6, every hop after it would show the loss too. The router in Hamburg simply rations its answers.
• Hop 12 loses 82%, with a worst time of 381.6 ms and a standard deviation of 64.2 ms. The very next hop answers all 60 probes with a spread of 0.2 ms, and the destination answers all of them too. Alarming numbers, no problem.
• Hop 10 shows jitter (worst 249.9 ms, deviation 16.1 ms), hop 11 almost none. Again the router's answers, not the path.
• Hop 9 answers faster than hop 8 (32.3 ms against 38.1 ms). Latency at intermediate hops does not have to grow: each router takes its own time to reply.

Every alarm in that trace is noise. The destination, which is what you actually connect to, answered 100% of the probes in 165.5 ms on average.

Real trace 2: a big jump that is distance, not a bottleneck

In the same trace, the time goes from 32 ms at hop 9 to about 169 ms at hops 10 and 11, and stays at that level until the destination. It persists, so it is real. But it is not a bottleneck: the router names change from European cities (hbg Hamburg, ffm Frankfurt, prs Paris) to sng, Singapore. The extra 137 ms are the undersea cables between Europe and Asia; Singapore lies about 10,000 km from Falkenstein, which costs at least 100 ms of round trip in fibre before any routing.

A jump that persists is a bottleneck only if it is larger than the distance explains, or if it varies with the time of day. Compare it with the floor: at roughly 1 ms of round trip per 100 km of fibre, 137 ms for an intercontinental hop is normal; 137 ms between two routers in the same city is not.

Real trace 3: a hop in London that answers in 298 ms

To Sydney, from the same server, the same minute:

  6. AS24940  core7.lon.hetzner.com                         0.0%    60   22.2  22.1  21.7  22.4   0.1
  7. AS???    ???                                          100.0    60    0.0   0.0   0.0   0.0   0.0
  8. AS4637   i-1001.ulhc-core03.telstraglobal.net          6.7%    60  299.7 298.8 297.6 302.2   0.8
  9. AS4637   i-1045.paix-core02.telstraglobal.net          0.0%    60  297.6 298.7 297.6 299.6   0.6
 10. AS1221   bundle-ether6.stl-core30.sydney.telstra.net   0.0%    60  346.6 345.7 344.6 346.7   0.6
 ...
 16. AS20473  108.61.212.117.vultrusercontent.com           0.0%    60  341.4 341.2 340.9 341.5   0.1

Hop 6 is Hetzner in London, at 22 ms. Hop 8 is where Telstra Global (AS4637) takes over, also in London according to RIPE IPmap, which geolocates routers, yet it answers in 298 ms. A packet cannot take 276 ms to cross London. What happens is that the router's answer travels back on a different, much longer route. Every time in a traceroute is a round trip, and the return leg is invisible to you. The jump that matters here is the destination's 341 ms, against a floor of 162 ms for the 16,220 km to Sydney: the route, not the cable, doubles the latency.

The patterns at a glance

What you see	What it means	What to do
Loss or delay at one hop, gone at the next	The router rations or delays its answers	Nothing
Loss or delay that starts at hop N and lasts to the destination	A real problem at hop N or on the link just before it	Collect evidence (below) and report it to the network that owns hop N
A big jump that persists and matches the distance	Propagation: an ocean or a continent	Nothing, or move the server closer to the users
A big jump larger than the distance explains, or a city far off the direct line	A routing detour	Try another provider or upstream, a CDN, or report the detour
Delay that only appears at busy hours, from one hop onwards	Congestion: a queue at that hop	Trace at different times and report with time stamps
Asterisks to the end, but ping answers	The destination ignores that probe type	Trace again with -I (ICMP) or -T -p 443 (TCP)
Asterisks from hop N to the end, and no ping	The path stops there, or a firewall drops everything	Test the service port, and trace from another location
The problem starts within hops 1 to 3	Your own network or access line	Test wired, with nothing else running, then call your provider

Locating the hop

• Router names usually carry a city or airport code: nbg Nuremberg, nyk New York, hbg Hamburg, ffm Frankfurt, prs Paris, lon London, sng Singapore, tky Tokyo. Run without -n to see them.
• AS numbers (mtr -z) tell you whose network each hop belongs to. In the traces above: Hetzner AS24940, Arelion AS1299, Telstra Global AS4637, Telstra AS1221, Vultr AS20473. Congestion often shows at the handover between two of them; see how ASN and BGP routing work.
• A map makes detours obvious. TraceMapper places every hop on one, with its network and latency.

Evidence a provider will act on

• An mtr -rwzb -c 100 report taken while the problem is happening, and one taken when everything is fine, for comparison.
• The same test from another location. The same New Jersey host answered our Falkenstein server in 86.4 ms and our Gravelines server in 71.7 ms, through different networks: comparing vantage points tells you whether the problem follows your connection or the destination.
• Both directions if you can: ask the other side for a trace back to you.
• The date, the time with its time zone, your public IP address and the destination.

To read each column of those reports, see how to read an mtr report; for the commands on each system, the traceroute command on Windows, Mac and Linux.