Traceroute Command Builder

Build a tracert command — and read the trace correctly

Running tracert is easy. Interpreting the output is where almost everyone goes wrong, and where a bad reading turns into an escalation to the wrong team. This builder assembles the exact command for tracert, pathping, traceroute or mtr from the options you tick, and the notes below explain what the resulting output does and does not tell you. Everything happens in your browser — the tool writes a command string, it does not trace anything itself, so no hostname you type leaves the page.

The command most people want is:

tracert -d example.com

Add -d and the trace stops doing a reverse DNS lookup on every hop, which is the single biggest speed difference you will notice. The builder enables it by default.

What the flags do

One conversion detail worth knowing: the builder’s timeout box is in milliseconds because that is what Windows uses, but Unix traceroute takes seconds, so the builder divides by 1000 and rounds, with a floor of one second. A 4000 ms timeout becomes -w 4. The builder does not emit tracert’s source-routing (-j), timestamp (-R, -S) or address-family (-4, -6) switches; add those by hand if you need them.

An asterisk is not a broken hop

This is the misconception that causes the most wasted time. A * in the output means only one thing: no reply arrived within the timeout for that probe. It does not mean the packet was dropped, and it does not mean the router is down.

Routers are not obliged to answer traceroute probes. Generating the ICMP Time Exceeded message that makes traceroute work is handled by the router’s control plane, and on a core router forwarding traffic at line rate, that control plane deliberately rate-limits or ignores such requests so it can keep forwarding real traffic. Many providers also filter ICMP at their edge as a matter of policy.

The test that settles it: if hops after the asterisks respond normally, and the final hop responds, traffic is passing through that router perfectly well. A trace that shows three timeouts in the middle and then reaches the destination is a healthy trace. The only asterisks that mean something are the ones that continue all the way to the end of the trace — that tells you the path stops being traversable somewhere around the last hop that did reply, though even then the failing device may be one or two hops beyond the last responder.

Latency at an intermediate hop is not a problem at that hop

The second big misreading. When hop 6 shows 180 ms and hop 7 shows 40 ms, people conclude hop 6 is congested. It is not. Every number in the output is a round-trip time from your machine to that hop and back, measured by a reply the router generated as a low-priority side task. A busy router will take its time producing that reply while forwarding your actual data with no delay at all.

So read the column this way:

• A single high hop, with lower numbers after it — ignore it. Latency cannot decrease along a path; the later, lower figure proves the earlier one was an artefact of reply generation, not transit.
• A step up that persists to the end — this is real. Something between the previous hop and this one added genuine delay, typically a long-haul link or a congested peering point.
• The final hop’s number — this is the figure that matters to your users, and it is the only one that directly reflects their experience.
• Wildly varying values across the three probes at one hop — jitter worth noting if it persists to the destination, meaningless if it does not.

Windows sends three probes per hop, which is why you see three timing columns. Three samples is enough to spot a gross problem and nowhere near enough to characterise packet loss.

When to stop using tracert and run pathping

That last point is the reason pathping exists. tracert gives you three samples per hop and prints them immediately. pathping traces the route first, then sends a large number of probes to every hop along the way and reports per-hop loss percentages. If your complaint is “the connection drops packets” or “it is fine most of the time”, three probes will never show it and pathping will.

The cost is time. With the default 100 queries per hop and pathping’s default 250 ms period, the statistics phase spends 25 seconds on each hop — so a 12-hop path takes about five minutes. That is why the builder exposes the query count: dropping -q to 20 cuts the wait to a fifth while still giving you far more samples than tracert does.

Note that pathping’s per-hop loss column has the same caveat as tracert’s latency column: loss reported at a hop that does not persist to later hops is the router deprioritising replies, not dropping traffic. Loss that appears at a hop and continues to every hop after it is the real thing.

Why a Windows trace and a Linux trace disagree

They use different probes by default. Windows tracert sends ICMP Echo Requests. Unix traceroute sends UDP datagrams to high, unlikely ports and waits for an ICMP Port Unreachable from the destination. Firewalls treat those very differently, so it is entirely normal for tracert to complete while traceroute stalls at the last hop, or the reverse.

That is what the protocol selector in the builder is for on the Unix tools. -I makes traceroute behave like tracert. -T -p 443 is more useful still: it probes with TCP SYN packets to the port your application actually uses, so the trace follows the same firewall and load-balancer treatment as real traffic. If a service is unreachable but ICMP traces complete cleanly, a TCP trace to the service port is the next thing to run. Both -I and -T generally require root, so expect to prefix them with sudo.

mtr is not installed by default on either macOS or most Linux distributions; the builder says so and points at apt install mtr or brew install mtr. The --report flag it emits runs a fixed number of cycles and prints a summary, which is what you want when pasting results into a ticket rather than watching a live display.

Things that make a trace look worse than it is

• The trace ends at the hop before your destination. Very common. Many hosts and CDNs drop ICMP Echo entirely while serving traffic normally. Test the actual service before concluding anything.
• Hop names look alarming. Reverse DNS on carrier routers is arbitrary and often stale. Names containing words like “fail” or an old provider’s brand are naming conventions, not diagnoses. Use -d and stop reading them.
• The path changes between runs. Expected. Load balancing across equal-cost links means consecutive probes can take different routes, which also explains hops that appear to belong to two different networks.
• The first hop is not your router. On a VPN, corporate network or hypervisor, the first responder is whatever terminates your virtual interface.
• Everything times out from hop one. That is usually your own host firewall or endpoint agent blocking outbound ICMP, not the network.

Trace before you conclude, and confirm with a second tool before you escalate. A tracert plus a pathping, read with the rules above, will tell you honestly whether the problem is inside your network, at your provider, or at the far end — which is the only distinction that determines who can actually fix it.

Capturing a trace for a ticket

Traces are evidence, so save them rather than screenshotting them. On Windows, redirect to a file with tracert -d example.com > trace.txt, and note the time you ran it — a routing problem that has since cleared is indistinguishable from one that never existed if nobody recorded when the trace was taken. Run the trace from the affected machine, not from your own, and run it while the fault is happening; a clean trace collected an hour later proves nothing.

Two traces are worth far more than one: one from the affected network and one from somewhere known-good, to the same destination. If both look the same, the problem is at the destination or in the middle. If only one is broken, the difference between them usually points straight at the hop where the paths diverge. Include both, plus the raw text of each, when you escalate to an ISP — a provider will act on a trace they can read and will usually ignore a description of one.