Using the Enterramon Traceroute (Hop Test)

What is traceroute

Traceroute is what you reach for when ping has already told you something is slow, but not why. Where ping only measures the round trip to a single target, traceroute maps every single network it passes through along the way, hop by hop, and times each one individually.

It works by sending packets with a slowly increasing time-to-live value, one hop, then two, then three, and so on. Each router along the path that the packet expires at sends a small message back, and that’s how the tool builds up the full path one hop at a time. The result is a list, starting at the region you tested from and ending at the target, showing everything the traffic passed through to get there.

Our Hop Test does exactly this, from five regions, with three separate timing samples per hop instead of just one.

Using the Enterramon Hop Test

Head to enterramon.com/traceroute  and enter a domain or IP address.

Same two settings as Ping, and for the same reasons.

Hit Run Test and we map every hop between the chosen region and the target, with three timing samples per hop rather than one.

Understanding the traceroute results

The results break down into a few blocks:

How traceroute can help you

Ping tells you a server is reachable and gives you a rough sense of how fast. Traceroute tells you where along the way any delay is actually happening.

When ping times come back high, traceroute is how you find out whether the problem sits at the destination server itself, several networks upstream, on a congested transit link somewhere in the middle, or because traffic is being routed through a longer physical path than it needs to be. Those are four very different problems with four very different fixes, and ping alone can’t tell you which one you’re looking at.

This is especially useful for anything international. A visitor connecting from one continent to a server on another crosses several networks to get there, and every so often one of those networks has a bad day. Traceroute shows you exactly which hop that is, rather than leaving you to guess whether it’s your server, your host’s network, or something entirely outside anyone’s control.

It’s also worth running before and after any routing-relevant change, a new CDN, a BGP update on your provider’s side, a change in upstream transit. Comparing a trace from before the change to one after is usually the clearest way to confirm traffic is taking the path you expect, and to catch it quickly if a change has quietly sent visitors somewhere less direct than before.

Running a traceroute yourself on a Mac

Macs already ship with traceroute built into Terminal, no install needed. Open Terminal and run traceroute example.com, swapping in whatever domain or IP you’re chasing. Below is a real run against a Cloudflare-fronted domain, home network and ISP hops generalised out since there’s no reason to publish that part.

The default macOS traceroute sends UDP probes, not ICMP. That trips people up if they’re used to Windows, where tracert only ever uses ICMP. To match ICMP behaviour on a Mac, add the -I flag, traceroute -I example.com. Documentation for this flag often notes it needs root, but that’s not something to take on faith either, so here’s the same target run with -I straight after the one above, same terminal session, no separate sudo prompt appeared either time.

Same six hops both times, same hostnames, only the RTTs shift a little between runs, which is normal and not something either protocol choice caused here. That won’t hold on every network. Some routers treat UDP and ICMP probes differently, replying to one and silently dropping the other, so a hop that times out under the default UDP mode is worth re-running with -I before you assume anything’s actually broken there. Whether -I asks for a password on your machine depends on your sudo timeout settings, run sudo -k first if you want to check honestly rather than relying on a cached credential from something else you ran earlier.

Terminal only shows you the path from your Mac, on your network, at that moment. Running the same target through the Hop Test from Cape Town, Frankfurt, Singapore, St Louis, or Sydney adds the regions your own connection can’t reach, and gives you three timing samples per hop instead of the one Terminal defaults to.

Linux and Windows behave differently again

Linux traceroute matches macOS in the way that matters most, UDP by default, ICMP behind a flag. Same target, same two commands, run on a Linux box instead of a Mac.

Same command shape as macOS, but a real difference showed up running it, not reading about it. The plain traceroute needed no elevated privileges at all, -I did, a password prompt every time. On the Mac test earlier neither command asked for one in that session, likely a cached credential rather than a real platform difference, but on this Linux box the distinction was explicit and repeatable. Worth checking on your own system rather than assuming either way.

Windows doesn’t give you a choice between UDP and ICMP in the first place. tracert has always been ICMP-only, no flag needed or available to switch it. What it will do without warning, if the target has an IPv6 address and the machine has working IPv6 connectivity, is trace over IPv6 automatically. Been the default behaviour since Vista and Server 2008, still catches people out. Here’s a real run from an older Server 2012 box.

Five hops over IPv6 rather than the longer IPv4 path Linux and macOS showed to the same domain. If you actually wanted the IPv4 route, tracert -4 example.com forces it on versions that support the flag, worth checking yours does before relying on it. Nothing wrong with the IPv6 result on its own, but it’s a different path to a different address family than the other two traces in this article, not a like-for-like comparison unless you force the protocol on all three.

Two other commands worth knowing

tracepath ships on most Linux systems and needs no root at all, not even for its ICMP-style probing. What it adds over plain traceroute is live path MTU discovery, shown right in the output. Real run below, including a few silent hops near the end, tracepath keeps going and reports them rather than stopping.

The asymm notes mean the return path likely has a different hop count than the outbound one, common on the internet and not a fault by itself. pmtu 1500 on hop one confirms the path can carry a full-size Ethernet frame without fragmenting, worth knowing if something further downstream is dropping oversized packets silently.

mtr takes a different approach entirely, instead of one pass it sends repeated probes to every hop continuously, then shows loss percentage and timing spread rather than three samples once. Real output below, ten pings per hop against the same target.

Zero loss on every hop, but hop 4 swings from a best of 6.2ms to a worst of 52.3ms, nearly a 9x spread, with a StDev of 15.7 to match. The average, 15.4ms, sits right in the middle and tells you almost nothing about how erratic that hop actually is. A single traceroute pass would have shown one number and moved on. This is the real case for repeated sampling over a one-off trace, and it’s the same reasoning behind the Hop Test running three timing samples per hop instead of one, a single reading can’t tell a real pattern from a momentary blip. For chasing an active issue rather than just illustrating one, running mtr for longer, a few hundred pings instead of ten, gives a steadier picture of whether a hop like this is consistently unstable or just had a rough few seconds.

What traceroute is not

Traceroute maps the path. It doesn’t tell you anything about what happens once the traffic actually arrives at the server, that’s a job for Server Check or a full page load test instead.

It’s also not a perfect map of every path every visitor takes. A trace shows you the specific path from one test region at one moment in time. Real users are scattered across many networks and locations, and routing can change between tests, sometimes hop to hop, sometimes for the whole path, depending on how the networks in between are configured. Treat a single trace as a sample of the route, not a permanent guarantee of it.

And timeouts need reading carefully rather than taken at face value. A silent hop in the middle of an otherwise clean trace usually means that router just doesn’t respond to this type of probe, not that anything is actually failing. It’s the pattern across the whole trace that tells the real story, not any single line in isolation.

If ping alone already gave you a clean result with no packet loss, a trace usually won’t add much, since there’s no delay to go hunting for. Traceroute earns its place once ping has already shown you something’s off and you need to know where.