The three tools, and what each is for
| Command | Answers | Time |
|---|---|---|
| ping | How bad is it, and is it stable? | Seconds |
| tracert | What path do my packets take? | ~30 s |
| pathping | Which specific hop is losing packets? | ~2–5 min |
You want all three, in that order. Open Command Prompt or PowerShell — none of this needs administrator rights.
Step 1: find something to test against
Test against the actual game server if you can find its address. In many games the server IP appears in a network or console overlay. If you cannot get it, use a well-connected host in the same region as the server as a proxy for the route — it will not be exact, but the shape of the path will be representative.
Also test against your own router (usually 192.168.1.1 or 192.168.0.1). That measurement is your local baseline and it should be excellent. Anything above ~5 ms on Wi-Fi, or above ~1–2 ms on Ethernet, means you have a problem before your traffic even leaves the building.
Step 2: ping, with enough samples to be meaningful
The default four packets tell you almost nothing. Send 50 and watch the spread:
ping -n 50 8.8.8.8
Read the summary line at the end. What matters is the gap between Minimum and Maximum, not the Average:
Minimum = 24ms, Maximum = 31ms, Average = 26ms ← healthy: tight spread Minimum = 22ms, Maximum = 340ms, Average = 61ms ← jitter: the average is lying to you
A 7 ms spread is a stable connection. A 300 ms spread is a connection that will feel awful in a match even though the average looks acceptable. Any value in the "Lost" figure other than 0% needs explaining.
Once with the line idle, and once while a large download runs. If the numbers are fine when idle and terrible under load, you have bufferbloat — a problem on your own equipment, fixable for free. There is no need to read any further into route diagnostics.
Step 3: tracert, to see the path
tracert -d 8.8.8.8
The -d flag skips reverse DNS lookups, which makes it finish far faster. You get a numbered list of hops with three timing samples each. A typical shape looks like this:
1 1 ms 1 ms 1 ms 192.168.1.1 ← your router 2 9 ms 8 ms 9 ms 10.20.0.1 ← ISP access network 3 12 ms 11 ms 12 ms 81.x.x.x ← ISP core 4 38 ms 39 ms 38 ms 195.x.x.x ← exchange point / transit 5 87 ms 88 ms 87 ms ... ← long haul 6 89 ms 88 ms 89 ms ... ← destination network
Read it as a cumulative curve, not as six separate measurements. Each number is the round trip from you to that hop. What you are looking for is the step where the number jumps and then stays up.
A single hop showing 200 ms while the hops after it show 90 ms is not a problem. Routers generate these replies in their control plane, which is deliberately low-priority — the router is slow to answer you while forwarding real traffic at full speed. Asterisks (* * *) at a middle hop mean the same thing: that router is configured not to reply at all.
Only a rise that persists through every subsequent hop to the destination is real. If the number comes back down at the next hop, ignore it and move on.
Locating the jump
- Hop 1 already bad. The problem is inside your home — Wi-Fi, cabling, or the router. Nothing beyond your front door is involved.
- Rises within the first 2–3 hops. Your ISP's access network or your last mile. Worth a support ticket.
- Rises in the middle, then stays high. Transit or peering. This is the case where you have no control and where rerouting can help.
- Gradual climb across a long path. Usually just distance. Check where the server actually is before treating it as a fault.
Step 4: pathping, for packet loss
tracert shows latency but is poor at showing loss. pathping traces the route, then sends a long series of probes to every hop and reports statistics per hop and per link.
pathping -n 8.8.8.8
Per Microsoft's documentation, the defaults are 100 queries per hop at 250 ms intervals, so it pauses for a couple of minutes at "computing statistics" before printing anything. Let it finish.
The output has two loss columns, and the distinction between them is the entire point of the tool:
- Source to Here — cumulative loss from you to that hop.
- This Node/Link — loss attributable to that specific router, or to the link leading into it. Link figures appear on the separate rows marked with a vertical bar |.
Microsoft's own guidance on interpreting it is worth stating plainly: loss reported against a router's own address often does not matter, because it "doesn't affect their ability to forward traffic that isn't addressed to them" — again, control-plane deprioritisation. Loss reported on a link row is the one that indicates real congestion affecting traffic passing through.
So the reading procedure is: ignore the router rows, scan down the | link rows, and find the first one with a non-trivial percentage that then persists to the destination. That link is your fault location.
Step 5: turn the location into an action
| Where it goes wrong | Who owns it | What you can do |
|---|---|---|
| Hop 1 / your router | You | Ethernet instead of Wi-Fi, enable SQM, replace the router |
| Only under load | You | Bufferbloat — fix with SQM/QoS, costs nothing |
| Hops 2–3, ISP network | Your ISP | Open a ticket and attach the pathping output; escalate or switch provider |
| Middle hops, transit | Nobody you can call | Change the route: different ISP, or rerouting software |
| Last hop only | The game operator | Change server region; the datacentre or the game itself is the issue |
| Nothing wrong, high total | Physics | The server is far away. Pick a closer region. |
Send the raw pathping output and say which link row shows the loss. Support scripts start from "have you rebooted the router", and concrete hop-level evidence is the fastest way past that. Note that if the loss is outside their network they genuinely cannot fix it — that answer is legitimate, not a brush-off.
When the diagnosis points at transit
The one row in that table with no free fix is a bad route through the transit network. Your ISP chose that path for commercial reasons, you cannot change it from your side, and no amount of router tuning touches it.
That is the specific case a game booster addresses — it carries your game traffic over a different path to the server. If your traceroute shows a clean local network and the damage happening five hops out, it is a reasonable thing to test. If your problem was at hop 1 or only under load, it will do nothing for you and you should fix the free thing instead.
The trial runs 3 days; checkout takes a payment method and schedules the first charge on day 4, so cancel within the trial if your numbers do not change. We earn a commission if you subscribe — see our disclosure.