Traceroute Tells You Where, Not Just How Much

A ping test gives you one number: total round-trip time. A traceroute breaks that number down hop by hop, so you can see where along the path the latency appears. That distinction matters because the fix for a bad first hop (your own Wi-Fi or router) is completely different from the fix for a bad second hop (your ISP's access network) or a bad mid-path hop (a congested peering point nobody in your house controls). The catch is that traceroute output is widely misread — most of the alarming-looking numbers in a trace mean nothing at all.

Running the Trace

Every desktop platform ships a traceroute tool. Use the target that matters to you: a game server address if you know it, or a well-known public address like 1.1.1.1 for a general path check.

Platform	Command	Notes
Windows	`tracert 1.1.1.1`	Uses ICMP echo requests. Add `-d` to skip reverse DNS lookups, which makes the trace finish much faster.
macOS / Linux	`traceroute 1.1.1.1`	Sends UDP probes by default. Add `-n` to skip name resolution. On many systems `-I` switches to ICMP, which often gets fewer blocked hops but usually needs sudo.
Windows (with loss stats)	`pathping 1.1.1.1`	Runs a trace, then spends several minutes sampling every hop and reports per-hop loss. Slow but far more informative than a single trace.
macOS / Linux (continuous)	`mtr 1.1.1.1`	A live, continuously updating trace with loss and latency statistics per hop. The best single tool for this job. Use `mtr -rwc 100 1.1.1.1` for a fixed 100-cycle report you can paste into a support ticket.

A single traceroute is a snapshot of one moment. For anything you plan to argue with your ISP about, use pathping or mtr so you have sampled statistics rather than three probes per hop. Run the test wired, with other devices idle, or you will be diagnosing your own household.

How Traceroute Actually Works (and Why That Matters for Reading It)

Traceroute sends packets with a deliberately small time-to-live value. TTL 1 expires at the first router, which replies with an error message; TTL 2 expires at the second router, and so on. Each reply reveals one hop along the path, and the timing of that reply becomes the latency figure for that hop.

Two consequences follow directly, and they explain almost every misreading of traceroute output:

Each hop's number is a round-trip to that router, not a segment time. Hop 7 showing 40ms does not mean hop 7 added 40ms. It means a packet reached hop 7 and came back in 40ms total.
Generating those TTL-expired replies is a low-priority task for a router. Its actual job is forwarding traffic. Replying to diagnostic probes is handled by a slower control-plane path, is often rate-limited, and is sometimes disabled entirely. That work has nothing to do with how fast it forwards your game traffic.

The Two Things Beginners Always Get Wrong

1. A high-latency middle hop is usually not a problem

The classic panic: hop 6 shows 180ms while hops 7 through 12 all show 45ms. This looks like a broken router, and it is nearly always a red herring. Hop 6 deprioritized your probe; it forwarded the real traffic through at normal speed, which is why every hop after it is fast. The rule is simple: latency at a hop only matters if every subsequent hop stays high too. If the number comes back down afterwards, it was never real.

2. Starred hops are usually not a problem either

Seeing * * * at a hop means no reply came back within the timeout. That normally means the router is configured not to answer TTL-expired probes, or a firewall filters them. It does not mean packets are being dropped. Again the test is what comes after: if the hops beyond the stars respond normally and the final hop looks healthy, the path is fine. Stars only matter if they continue all the way to the destination — that means the trace never completed and traffic really is not getting through.

The same logic applies to packet loss shown in mtr or pathping: loss at one middle hop that vanishes at later hops is ICMP rate limiting. Loss that appears at a hop and persists through every hop to the destination is real. Our packet loss troubleshooting guide goes deeper on separating the two.

An Illustrative Trace, Read Line by Line

The following table is a hypothetical example for teaching purposes — the addresses and timings are invented, not captured from a real network. It shows the shape of a healthy trace with one genuine problem in it.

Hop	Address	Latency	What It Is	Verdict
1	192.168.1.1	1ms	Your router	Healthy. Under about 5ms wired is normal.
2	10.x.x.x	9ms	ISP access network / CMTS or OLT	Healthy. A single-digit to low-teens figure is typical.
3	ISP regional router	12ms	ISP core, your city or region	Healthy. Small increase over hop 2.
4	ISP backbone	* * *	Router not answering probes	Ignore. Later hops respond normally.
5	Peering exchange	140ms	Handoff to another network	Suspicious — check hop 6 before concluding.
6	Transit provider	138ms	Long-haul carrier	Now confirmed. The elevated latency persisted, so it is real.
7	Destination network edge	142ms	Game or content provider network	Still elevated. The step happened at hop 5.
8	Game server	145ms	Final destination	145ms end to end, of which roughly 128ms appeared at one handoff.

Reading this correctly: hops 1 through 3 are fine, hop 4 is noise, and the jump from 12ms to 140ms between hops 3 and 5 is the entire problem. Everything after inherits it. If that step corresponded to a plausible geographic distance — a trans-Atlantic or trans-Pacific link — it would be physics and not a fault. If both endpoints are in the same country, it is a routing or congestion issue worth reporting.

Locating the Fault by Hop Position

Where the latency starts	What it means	What to do
Hop 1 (your router)	The problem is inside your home: Wi-Fi, a bad cable, or an overloaded router.	Test wired, swap the cable, reboot the router. Our Wi-Fi vs Ethernet guide covers the wireless side.
Hop 2 or 3	Your ISP's access network — the line into your home or the local aggregation equipment.	This is an ISP fault. Collect an `mtr` or `pathping` log and open a ticket with the evidence.
A mid-path hop, persisting to the end	Congestion or a poor route at a peering or transit point.	Report it to your ISP with the trace. Nothing local will fix it. A different game server region may route around it.
Only at the final hop	The destination server is loaded, distant, or deprioritizing your probes.	Compare against another server in the same region. If only one target is slow, it is not your connection.
Everywhere, all at once	Local saturation — something is using your line.	Check for downloads and uploads first, then read our causes of high ping rundown.

Step-by-Step: A Trace That Produces a Usable Answer

Baseline first. Run our browser ping and jitter test and note the figures. It measures warm HTTPS round-trip time to nearby cloud endpoints — a proxy for network latency rather than an ICMP measurement — but it tells you quickly whether the problem is present right now.
Go wired and quiet. Connect by Ethernet and stop downloads, streams, and cloud sync on every device. Otherwise you will find your own traffic and call it an ISP fault.
Run the trace to the target that is actually slow. Use the game server address if you can find it in the client, otherwise trace to a public address in the same region. Tracing to a fast target proves nothing.
Run it again while the problem is happening. Intermittent evening congestion will not show in a trace taken at 10am. Capture during the bad window.
Switch to continuous sampling. Run pathping on Windows or mtr -rwc 100 on macOS and Linux against the same target. Three probes per hop is not evidence; a hundred is.
Read it with the rules above. Find the first hop where latency or loss rises and stays risen to the destination. That hop is your answer; everything before it is fine and everything after it is downstream of the same problem.
Also run a trace in the other direction if you can. Internet paths are frequently asymmetric — the route back to you may differ from the route out. If a friend or a looking-glass server can trace toward your address, compare the two.
Report it with data. Send your ISP the log, the timestamps, the target, and the statement that it was captured on a wired connection with other devices idle. That single sentence moves a ticket past the standard reboot script faster than anything else.

What Traceroute Cannot Tell You

Traceroute maps the outbound path and measures control-plane responses. It does not measure your game's actual UDP traffic, it does not show the return path, and it cannot distinguish a router that is slow to reply from a router that is slow to forward. Use it to localise a problem, then confirm with a sustained measurement to the endpoint that matters. For the day-to-day check, a plain ping to the destination and a jitter reading tell you whether the connection is currently healthy; the trace tells you who to talk to when it is not. If you are on macOS, our Terminal ping guide covers the companion commands you will want alongside a trace.