Owen Bradley Two commands built into every computer you own can tell you more about a misbehaving connection than an hour on hold with support. Ping measures whether packets reach a destination and how long the round trip takes. Traceroute maps every router your traffic passes through on the way there and times each one. Used together, they turn “the internet is broken” into a specific claim: the fault is in this room, on this line, or at this hop three networks away. This guide teaches you to run both properly, read the output the way a technician reads it, and avoid the classic misreadings that send people chasing problems that were never there.
What Each Command Actually Measures
Ping sends a small echo request to an address and waits for the reply. It reports round-trip time in milliseconds and counts how many requests went unanswered. Repeat it enough times and you get four useful figures: minimum time, average time, maximum time, and loss percentage. The gap between minimum and maximum is jitter, and the loss percentage is packet loss.
Traceroute, called tracert on Windows, discovers the path. It sends probes with deliberately short lifespans so each router along the route is forced to announce itself, building a numbered list of hops from your router out to the destination. Each hop shows three timings, which reveals where delay is introduced rather than just how much there is in total.
The Numbers That Matter
To a nearby server, expect 5 ms to 40 ms on fibre or cable and 25 ms to 70 ms on DSL or fixed wireless. To your own router expect under 2 ms wired, and 2 ms to 8 ms over healthy Wi-Fi. Loss should be zero inside your home. Across the internet, under 0.5 percent is normal. A spread of more than 30 ms between minimum and maximum on a wired link is a real stability problem.
Before You Type Anything
- Test from a wired computer where possible, so Wi-Fi noise does not contaminate your results.
- Close video calls, cloud backups, and game downloads so nothing else is competing for the line.
- Know your router’s local address, usually 192.168.1.1 or 192.168.0.1, printed on the router label.
- Open Command Prompt on Windows, or Terminal on macOS and Linux.
- Keep a notepad open. Timestamped results are what turn a hunch into evidence.
Step by Step: Working Outward From Your Desk
- Ping your own router. On Windows run ping -n 100 192.168.1.1; on macOS or Linux run ping -c 100 192.168.1.1. This traffic never leaves the building. Any loss or wild timing variation here is your own equipment, and nothing further out is worth testing until it is clean.
- Repeat the same test wirelessly. Unplug the cable, reconnect over Wi-Fi from the same seat, and run the identical command. Clean wired numbers alongside messy wireless numbers isolate the fault to the radio link immediately, which saves you from rebooting a modem that was never the problem.
- Ping a reliable public address. Send 200 packets to a major public resolver such as 1.1.1.1. Record all four figures. A low, tight range with zero loss means your connection to the wider internet is fundamentally healthy and the trouble lies with a specific service.
- Run a traceroute to that same address. Use tracert 1.1.1.1 on Windows or traceroute 1.1.1.1 elsewhere. Read down the list and find the first hop where timings jump substantially and stay high for every hop after it. That transition point is where delay is being introduced.
- Identify what each early hop represents. Hop 1 is almost always your own router. Hop 2 or 3 is typically your provider’s local equipment. Beyond that you are in regional and backbone networks. Knowing which hop belongs to whom tells you instantly whether a fix is yours to make or theirs.
- Ping the suspicious hop directly. Copy the IP address at the hop where delay began and ping it 200 times. Traceroute’s three quick probes per hop are a tiny sample; a sustained ping tells you whether that router is genuinely struggling or merely answered slowly once.
- Traceroute to a second, unrelated destination. Pick a target on a completely different network. If both routes share the bad hop, the fault is on a path you always use. If the second route is clean, the first destination or its chosen route is at fault, not your line.
- Test the actual service that is failing. Ping and traceroute the hostname of the game server, conferencing platform, or site that misbehaves. General internet health does not guarantee a good path to one particular provider, and this step often reveals a single bad peering link.
- Repeat at a quiet hour. Run your two best tests again late at night. Problems that vanish when the neighbourhood sleeps are congestion. Problems that persist at 3 am are hardware or line faults, and the two require completely different conversations with support.
Reading Traceroute Without Being Misled
Traceroute output confuses people because it looks like a health report for every router on the path, and it is not. Many core routers deliberately deprioritise or block the probe traffic that traceroute relies on, because answering probes is the least important job they have. The result is a middle hop showing asterisks or a 200 ms spike while every hop beyond it responds in 25 ms.
The rule is simple: a hop only matters if the damage continues past it. High latency at hop 6 that returns to normal at hop 7 is a busy router being polite about low-priority traffic, not a fault. High latency at hop 6 that persists through hops 7, 8, and the destination is a genuine problem. The same applies to loss. Loss shown at a middle hop with a clean endpoint is an artefact and should be ignored entirely.
Also remember that traffic can take a different route on the way back than it took on the way out. Traceroute only maps the outbound path, so an asymmetric return route can produce timings that look impossible. That is another reason to trust end-to-end results over any single intermediate reading.
What Each Pattern Usually Means
- Loss pinging your own router: a failing cable, a bad port, or Wi-Fi interference. Entirely within your control.
- Clean router, loss at hop 2 or 3: the line between your home and the exchange. Report it with your logs.
- Latency that climbs only in the evening: local congestion on an oversubscribed segment.
- Fine to most places, terrible to one service: a routing or peering issue between your provider and that service.
- Latency that spikes only when someone uploads: queue buildup at your own router, fixable with better traffic management.
- Timeouts at the final hop only: the destination blocks ping. Not a fault at all.
Fixing What the Tests Reveal
If the fault turned out to be your own Wi-Fi, start with placement and band selection before spending anything. Raise the router, move it away from metal and mirrors, and push demanding devices to 5 GHz. If the trouble only appears during heavy transfers, the fix is queue management rather than more bandwidth, and our roundup of the best QoS routers explains which models handle that well. There are also plenty of tweaks worth trying first, which is why it is worth reading how to fix a slow home network without upgrading your plan before you call anyone.
If latency spikes matter more to you than raw throughput, hardware choice genuinely helps. Options in our list of the best gaming routers prioritise interactive traffic automatically, and the best routers for esports go further with per-device rules for competitive play. For a general household upgrade where stability matters more than headline speed, the best Wi-Fi routers cover balanced all-round choices.
Common Mistakes
- Using the default four-packet ping. Intermittent faults hide easily in four samples. Use 100 to 200.
- Testing only over Wi-Fi. Wireless adds its own variability, making every result ambiguous.
- Blaming a red middle hop. The single most common misreading, and it sends people to support with a non-issue.
- Watching the average only. The maximum figure is where stutter lives; a good average hides terrible spikes.
- Testing one destination. One slow target proves nothing. Always compare at least two unrelated routes.
- Rebooting first. A restart often hides the symptom for hours and destroys the evidence you needed to prove it.
Frequently Asked Questions
Why does a hop show asterisks?
That router is configured not to answer probe traffic. It is a deliberate configuration choice and completely normal. As long as hops beyond it respond, the path is fine.
Should I use ping or traceroute first?
Ping first, always. It answers whether there is a problem at all. Traceroute answers where it is, and is only worth running once ping has confirmed something is genuinely wrong.
Does high latency to one game server mean my connection is bad?
Not necessarily. Distance and routing dominate. A server on another continent will always show high latency no matter how good your line is. Compare against a nearby server before concluding.
How long should I run a ping test?
Long enough to catch the fault. For steady problems, 100 packets is plenty. For faults that appear every few minutes, run a continuous ping for 15 to 30 minutes and review the loss summary at the end.
Final Thoughts
Ping and traceroute reward patience and a fixed method. Start at your own router, compare wired against wireless, work outward hop by hop, and always test a second destination before drawing a conclusion. Ignore middle hops that recover, watch the maximum time rather than the average, and log everything with a timestamp. Do that consistently and you will identify the true source of most connection problems in under an hour, which is faster than any support queue and considerably more satisfying.
