How to Read Traceroute Results and Find Network Problems

What Traceroute Shows

Traceroute maps the route between your device and a destination such as a website, game server, or DNS service. It lists each router, or hop, that handles the traffic and measures how long that router takes to reply. On Windows, the command is usually called tracert; on Linux and macOS, it is usually traceroute.

A typical result contains a hop number, a hostname or IP address, and several time measurements in milliseconds. The hop number shows the position in the path, while the time values show the round-trip latency for individual probes. The final hop is normally the destination, but some networks hide router names or do not respond to diagnostic probes.

Traceroute is a diagnostic view rather than a direct measurement of download or upload speed. A high value at one hop does not automatically mean that your broadband connection is slow. The important question is whether the delay continues at later hops and whether it affects the final destination.

How to Read Latency and Packet Loss

Read traceroute from top to bottom. The first hop is often your router or modem, followed by your ISP access network, regional routers, transit providers, and finally the destination network. Low and stable times near the beginning generally indicate that your local network is responding normally.

Each hop commonly shows three measurements. Small differences between them are normal because probes may take different paths or be processed at different times. Focus on a consistent increase, repeated timeouts, or a change that remains visible through the following hops.

An asterisk means that a probe did not receive a reply before the timeout. Asterisks do not always indicate packet loss for ordinary traffic. Many routers intentionally limit or block traceroute responses while continuing to forward packets normally. Packet loss is more concerning when it starts at a hop and continues through every later hop, especially at the final destination.

Common Causes of a Slow or Unusual Traceroute

Wi-Fi interference or a weak local connection

Wireless interference, distance from the router, crowded channels, and obstacles can increase latency at the first hop. A damaged Ethernet cable, unstable modem, or overloaded router can produce a similar pattern. If the first hop is consistently slow or unstable, test with Ethernet, move closer to the router, restart the modem and router, and compare the result with a second device.

Local network congestion

Large downloads, cloud backups, video uploads, and multiple active users can fill the connection queue. This creates bufferbloat, where latency rises sharply while download or upload traffic is running. Traceroute may show a slow first hop or early ISP hop during the busy period. Pause heavy traffic and test again; if latency falls, enable suitable queue management or quality-of-service settings on the router.

ISP access or routing problems

A fault in the ISP access network can appear as increased latency or packet loss in the first few provider-owned hops. Routing changes can also send traffic through a longer regional or international path. Compare results to several destinations and test at different times. If the issue begins inside the ISP network and persists toward multiple destinations, provide the ISP with timestamps, destination addresses, and repeated traceroute results.

Congestion in a transit network

Internet traffic may cross one or more independent transit providers before reaching the destination. A congested exchange point or transit link can increase latency after the local ISP portion of the route. The responsible hop may show a high value, but the key evidence is that later hops also remain high. If only one destination or region is affected, the issue may be outside your home network and ISP access line.

Router response-rate limiting

Some routers prioritize forwarding user traffic over answering diagnostic probes. They may reply slowly, intermittently, or not at all, creating a high value or asterisks at a single hop. If the next hops return to normal and the final destination has stable latency, that hop is probably not causing a user-facing problem. Do not treat an isolated timeout as proof of packet loss.

Firewall or protocol filtering

Firewalls, security systems, and destination networks may block the probes used by traceroute. This can make the final hop appear incomplete even when a website or application works correctly. Test the service itself and compare with tools such as ping, a browser request, or an application connection. A blocked traceroute response is a visibility limitation, not necessarily a broadband fault.

Problems near the destination server

If latency or loss begins close to the final hops, the destination network, data center, server, or remote access provider may be responsible. This is common when one website, game region, or cloud service performs poorly while other destinations remain normal. Contacting the service operator may be more useful than changing your router or broadband plan.

How to Locate Where the Problem Begins

Run several tests instead of relying on one result. Test your router, a nearby ISP or public DNS address, and the affected destination. Repeat the tests when the connection is normal and when the problem is visible. Record the local time, destination, connection type, and whether other devices are using the network.

1. Check the first hop for stable latency and repeated loss.
2. Identify the first hop where latency or loss increases.
3. Look at all later hops to see whether the change persists.
4. Compare the final hop with other destinations and services.
5. Repeat the test at different times to detect congestion patterns.

A problem that begins at the first hop usually points to Wi-Fi, the router, modem, or the local network. A problem that begins in the ISP section may require provider support. A problem that appears only near the destination is more likely to involve remote routing or server infrastructure.

Why a High Hop Value May Not Be a Real Problem

Traceroute measures how quickly each router answers a control message, not how quickly it forwards every packet. Routers can delay diagnostic replies while forwarding normal traffic at full capacity. For this reason, an isolated high hop is often harmless.

Use the final destination and the persistence of the change as the main evidence. If hop 6 reports 150 milliseconds but hops 7 through 12 return to 25 milliseconds, hop 6 is probably rate-limiting its replies. If hop 6 rises to 150 milliseconds and every later hop remains near 150 milliseconds, the route may have a genuine latency increase beginning there.

Practical Ways to Improve the Connection

• Use Ethernet when testing latency-sensitive services or troubleshooting Wi-Fi.
• Stop large downloads, uploads, backups, and peer-to-peer transfers during testing.
• Restart the router and modem, then check firmware and cable connections.
• Move the router to a central location and reduce wireless interference.
• Enable queue management or quality-of-service features if bufferbloat is present.
• Compare IPv4 and IPv6 paths when both are available.
• Try another destination to separate local issues from remote service problems.
• Contact your ISP when loss or persistent latency begins within its network.

Changing DNS may improve name lookup time, but it usually does not change the route used after a connection is established. A VPN can choose a different path, but it may also add encryption overhead and latency, so use it as a comparison test rather than a guaranteed fix.

What to Send to Your ISP or Service Provider

Support teams can investigate more effectively when the report includes several samples. Send the destination hostname or IP address, the date and local time, your connection type, whether you used Wi-Fi or Ethernet, and results from both a normal period and an affected period. Include screenshots or copied text showing the full route.

Explain the user-facing symptom, such as slow downloads, unstable uploads, high gaming latency, or intermittent disconnections. Avoid claiming that an isolated asterisk proves packet loss. Instead, describe where persistent loss or latency begins and whether it continues to the final hop. This gives the ISP or destination operator enough context to check routing, congestion, access equipment, and server-side conditions.

Key Takeaways

To read traceroute accurately, follow the route from your device to the destination and look for changes that persist across later hops. A slow first hop suggests a local network issue, a persistent increase inside the ISP points toward access or routing conditions, and degradation near the destination may be remote. Asterisks and isolated high values often reflect filtering or response-rate limiting. Repeated tests across multiple destinations provide much stronger evidence than a single traceroute run.