Tracert Route Command: Reading Hops, Spotting Real Loss, and What to Send Your Host

The tracert command on Windows and traceroute on Linux and mac show every network hop between your machine and a destination, along with the round-trip time to each one. Reading the output correctly means knowing that an asterisk at a hop is a timeout in replying to the trace probe, not necessarily packet loss on the real path — routers frequently deprioritize or block the probes traceroute uses while forwarding your actual traffic normally. The tool that actually distinguishes the two, mtr, runs the trace continuously and reports real loss percentages per hop.

Most tracert tutorials stop at here is the command and here is what the columns mean, useful for five minutes and useless the moment you are staring at a hop full of asterisks trying to decide if your connection is broken or just being ignored. This post covers running it on every platform, reading a hop line correctly, telling a timeout from real loss, and turning the output into something you can actually hand to a hosting provider’s support team.

Table of contents

• Running it on Windows, Linux, and mac
• Reading a hop line
• Timeouts (asterisks) versus real packet loss
• mtr: the tool that actually answers the question
• Diagnosing a slow or unreachable site with it
• What to actually send your host’s support team
• How this fits the rest of the stack
• FAQ

Running it on Windows, Linux, and mac

The command name differs by platform; the concept does not.

C:\> tracert example.com

$ traceroute example.com
$ traceroute -n example.com    # skip reverse DNS, faster output

On Windows, tracert uses ICMP echo requests by default. On Linux, traceroute defaults to UDP probes to high ports unless you pass a flag for ICMP, which matters because some firewalls treat the two differently — a trace that dies at the destination with UDP can complete cleanly with ICMP if the destination blocks UDP but answers ICMP.

On mac, traceroute behaves like the Linux version. All three accept a hop-count limit and a per-hop timeout flag if the defaults, 30 hops and several seconds per hop, are too slow for a quick check.

Reading a hop line

Each line is one router along the path, in order, with three round-trip time samples.

 6  be3410.ccr21.mia01.atlas.cogentco.com (154.54.6.85)  77.7 ms  76.0 ms  74.0 ms

Left to right: the hop number, the reverse-DNS hostname if one resolves, the IP address, and three separate probe timings. A jump in latency at one specific hop that stays elevated for every hop after it usually marks where a slow link actually is — the hops after it inherit the delay, they did not cause it fresh. A single high number surrounded by normal ones is more often noise than a real bottleneck.

Timeouts (asterisks) versus real packet loss

This is the distinction that determines whether you should worry. An asterisk means the probe got no reply within the timeout — it does not mean the packet was dropped.

• A router configured to deprioritize or silently drop trace probes while forwarding ordinary TCP traffic completely normally. Very common on routers in the middle of the path that have nothing to do with your actual connection quality.
• Rate-limiting on trace-specific traffic, which some networks apply deliberately to reduce load from constant traceroute scanning.
• Actual congestion or a dead link, which is what you are hoping to distinguish from the two above.

One trace cannot tell these apart. Consistent asterisks at the same hop across many traces, especially combined with high latency at the hop just before it, lean toward a real problem. Asterisks at one hop with everything after it perfectly normal almost always means that one router just does not answer probes.

mtr: the tool that actually answers the question

mtr (WinMTR on Windows) combines traceroute and ping into a continuous, updating report, sending repeated probes to every hop and calculating an actual loss percentage per hop over time — the number a single tracert cannot give you.

mtr --report --report-cycles 100 example.com

A hop showing loss that disappears by the final destination is the deprioritization pattern from the section above: normal, ignore it. A hop showing loss that persists all the way to the destination is real, and it tells you approximately where the problem sits — your ISP, a transit provider, or the last hop before the destination server.

Diagnosing a slow or unreachable site with it

Run the trace from more than one place if you can — your own connection, a VPS in another region, an online traceroute tool — because a problem specific to your ISP looks identical to a server-side problem until you compare against a second vantage point.

1. Trace completes fully, low latency throughout, site still slow. The network path is fine; look at the application or the server’s own response time instead.
2. Trace dies partway with consistent loss at one hop across repeated runs. A real network problem at that point, likely upstream of both you and the destination.
3. Trace completes but the last hop or two show high, consistent latency. Points at the destination network or the server itself, not the path to it.
4. Trace does not even start. DNS is not resolving, which is a different problem than routing entirely — check nslookup or dig first.

What to actually send your host’s support team

A support ticket that says the site is slow gets a slow, generic answer. One that includes the trace gets routed to someone who can act on it.

• The full mtr report, not a single tracert, since loss percentages over time are what a network engineer actually needs.
• The vantage point — your location and ISP, or the region of a VPS if you ran it from one.
• The time the problem occurred, since transient congestion at a specific hour is common and disappears by the time anyone looks.

Attach that and most hosts can tell within minutes whether the problem is on their network, yours, or somewhere in between neither of you controls.

How this fits the rest of the stack

A trace is a diagnostic, not a fix — once it points at where the slowdown actually is, the fix is usually a network change, a route around a bad transit provider, or moving the workload closer to where it is slow. If the destination end of that trace is a server you run yourself, a managed web service with logs and metrics in one place removes half the guesswork about whether the problem is the network or the application. Services on RunxBuild covers what that visibility looks like, the RunxBuild hosting calculator prices a service in the region your users actually are, and the dashboard is where the runtime logs live next to the metrics.

Useful related references:

• ip Command Linux Ubuntu: addr, route, link, and the Right Defaults
• AWS Route 53: DNS, Routing Policies, and Domain Registration
• 504 Gateway Time-out in Nginx: Your Upstream Was Too Slow, Not Nginx
• Services on RunxBuild

FAQ

What is the difference between tracert and traceroute?

Same concept, different platform and default probe type. Tracert is the Windows command and defaults to ICMP echo requests. Traceroute is the Linux and mac equivalent and defaults to UDP probes unless you pass a flag for ICMP. Both list every hop between you and a destination with round-trip times.

What do the asterisks mean in a tracert or traceroute?

An asterisk means that specific hop did not reply to the trace probe within the timeout — it does not mean a packet was lost on your real connection. Many routers deprioritize or silently drop trace probes while forwarding ordinary traffic normally, which is why asterisks mid-path are usually harmless.

How do I tell if a slow site is a network problem or the server?

Run mtr from your connection. If the trace completes with low, consistent latency all the way to the destination but the site is still slow, the problem is the application or server response time, not the network path getting there.

Is mtr better than tracert for diagnosing network issues?

For anything beyond a quick check, yes. mtr repeats the trace continuously and reports an actual loss percentage per hop over time, which distinguishes a router that ignores trace probes from a hop with genuine, persistent packet loss — a single tracert run cannot make that distinction.

What should I include when reporting a network problem to my host?

A full mtr report rather than a single tracert, the vantage point you ran it from, and the time the problem occurred. That combination lets a network engineer see loss patterns over time and narrow down whether the issue is on their network, yours, or the path between.