How to Use Traceroute to Find Where a Connection Drops
When a website will not load, the failure may be somewhere between your device and the destination server. Your Wi-Fi could be unstable, your NBN connection may be having trouble, or a routing problem could affect traffic in another city or country. Traceroute helps show the path packets take and indicates where delays or timeouts begin.
The tool does not repair a broken connection or prove that a particular network operator is at fault. It provides evidence: the names or addresses of intermediate routers, the response time at each step, and the point where replies stop. This makes it useful when a page remains unreachable after basic checks such as restarting the modem or trying another browser.
For Australian users, the route may pass through an exchange or data centre in Sydney, Melbourne, Brisbane, Perth or Adelaide before reaching an overseas host. Someone in regional Queensland or Western Australia may see a longer path than a person in inner Melbourne. That extra distance can affect latency without meaning the service is failing.
If a page is unavailable, the connection troubleshooting guide can help with simple checks before you collect diagnostic results. Once you know the issue is worth investigating, traceroute gives you a clearer picture of where the journey breaks down.
What Traceroute Reveals
Traceroute sends a series of test packets with gradually increasing “time to live” values. Each router reduces that value by one. When it reaches zero, the router usually sends a response back, allowing the program to record that hop. The result is a numbered path from your computer towards the target hostname or IP address.
A typical result includes a hop number, one or more router names or addresses, and several round-trip times in milliseconds. The first hop is often your home router, followed by your internet provider’s access network. Later hops may belong to national carriers, content delivery networks or the destination’s hosting provider.
The output is a snapshot rather than a permanent map. Internet routes can change because of congestion, maintenance, peering arrangements or automatic traffic management. A route that looks normal in the morning may use different infrastructure in the evening, particularly during busy periods on residential broadband.
How Hops And Timeouts Work
Asterisks usually represent a probe that received no reply before the timeout. One silent hop is not automatically a fault. Many routers are configured to ignore traceroute probes, limit replies, or treat diagnostic traffic as a low priority. If later hops respond normally, the silent device is probably forwarding traffic successfully.
The important pattern is where the loss begins and whether it continues. If every later hop times out and the website also fails, the last responding section may deserve attention. If a middle router shows high times but later routers return to normal speeds, that router may simply be delaying diagnostic replies rather than delaying ordinary traffic.
Compare all three or four timing columns instead of focusing on one large number. Repeated high latency across subsequent hops is more meaningful than a single spike. For example, 15 ms, 16 ms, 17 ms followed by 180 ms, 182 ms and 185 ms suggests a sustained delay. A lone 300 ms response followed by 18 ms results is usually not enough evidence.
Running It On Windows
Open Command Prompt by searching for cmd, then run:
tracert example.com
Replace example.com with the hostname that will not load. Windows sends several probes per hop and may take a minute or two to finish. The command also resolves many router addresses into names, so the display can pause while it performs reverse DNS lookups.
For a quicker result without name lookups, use:
tracert -d example.com
Copy the complete output, including the first hop and any rows containing asterisks. Avoid editing out unusual entries, as the pattern is often more useful than an individual address. Private addresses such as 192.168.1.1 or 10.0.0.1 generally identify local equipment and do not reveal a public internet route.
Windows may show different results for IPv4 and IPv6. To test IPv4 specifically, use tracert -4 example.com; for IPv6, use tracert -6 example.com when the destination supports it. This distinction matters when an NBN provider has a healthy IPv4 path but an unstable IPv6 route.
Running It On macOS And Linux
On macOS or most Linux distributions, open Terminal and enter:
traceroute example.com
Some systems do not include the command by default. On Ubuntu, for example, it may be available after installing the traceroute package. macOS and Linux can use different probe methods from Windows, so the hop count and exact output may not match even when the underlying route is similar.
If the command is missing, ping can provide a basic reachability check, while mtr combines repeated ping tests with route information. A command such as mtr -rw example.com can show packet loss and latency over time. Run it for long enough to capture a meaningful sample, especially if the problem appears only during the evening peak.
Test the hostname rather than relying only on an IP address. A website may use a content delivery network, and DNS can send your device to a different server depending on your location. A route from a Perth connection may differ from one from Sydney, even for the same domain.
Reading Results Carefully
Start by testing the local network. If the first hop is slow or unreachable, inspect the modem, Ethernet cable or Wi-Fi signal before blaming the ISP. Move closer to the router, pause large downloads and repeat the command. Public Wi-Fi in a hotel, library or airport can also block diagnostic traffic, making its traceroute less informative.
If the first few hops look stable but the route fails after leaving your provider, repeat the test at different times. Save the date, time, destination and command used. A pattern seen at 8 pm on a congested residential service carries more weight than a single test during a brief outage.
Names in the output are clues, not proof. A hostname containing “mel”, “syd” or a carrier abbreviation may suggest a location, but naming conventions are not guaranteed to be precise. A router can respond slowly to traceroute while forwarding normal web traffic promptly, and some providers intentionally hide their internal topology.
Security filters can affect the result as well. Corporate networks, school networks and some VPNs may block or alter traceroute packets. If safe and permitted, compare results with the VPN disconnected, then test from mobile data. Do not scan networks that you do not own or administer.
Choosing The Right Diagnostic Tool
Different tools answer different questions. Traceroute is useful for identifying the approximate point where a path changes or stops. Ping is better for checking whether a host responds consistently. MTR is better for observing intermittent loss over several minutes. A browser test confirms the practical issue: whether the page actually loads.
| Tool | Best use | Main limitation |
|---|---|---|
ping |
Checking reachability and basic latency | Does not show the route |
tracert or traceroute |
Viewing each network hop | Routers may ignore probes |
mtr |
Monitoring loss and delay over time | Requires installation or extra familiarity |
| Browser test | Confirming the user-facing failure | Gives little network detail |
| DNS lookup | Checking name resolution | Does not test the full connection |
Use at least two forms of evidence before reporting a fault. For example, a failed browser request plus repeated traceroute timeouts is more useful than traceroute alone. A DNS lookup can reveal that the name resolves to an unexpected address, while a browser test can show whether only one service is affected.
When contacting an Australian provider such as Telstra, Optus or TPG, provide the exact destination, local time, connection type and several test results. If the issue affects only one website, the problem may sit with that site’s host, filtering system or content delivery network rather than with your home service.
Practical Checks Before Escalating
Run these checks in a consistent order so that each result can be compared fairly:
- Restart the modem or NBN connection equipment, then wait until all service lights stabilise.
- Test the same website over Ethernet if possible, rather than relying only on Wi-Fi.
- Compare your home connection with mobile data from a different network.
- Run traceroute to the affected hostname and to a reliable site such as your provider’s domain.
- Repeat the test at another time, recording the date, time and observed symptoms.
- Check whether a VPN, security filter or workplace network is changing the route.
- Keep the full command output, including timeouts and router names, before contacting support.
These steps help separate a local wireless problem from an ISP routing issue or a remote hosting failure. In regional areas, a fault affecting a backhaul link may influence several towns, while a problem limited to one household is more likely to involve local equipment or signal quality.
Traceroute cannot identify every cause. It will not reliably detect a faulty browser, an expired certificate, a blocked account or a web application that is returning an error. It is one diagnostic layer within a broader process, and its evidence becomes stronger when paired with browser behaviour, DNS results and repeated tests.
Save a short record of what changed and when the problem began. Clear notes make it easier for a support team to compare your evidence with network logs. They also prevent repeated troubleshooting if the issue returns after a temporary outage.
Run traceroute patiently, interpret patterns rather than isolated asterisks, and compare the results with a direct browser test. When a connection drops, clear evidence can turn a vague “the internet is broken” report into a useful description of the affected link, timing and destination. Use those results to decide whether to wait for a wider outage to clear, adjust your local setup, or pass the findings to the relevant network or hosting provider.