Trace Network Routes to Diagnose Latency

When a website loads slowly, a video call keeps dropping, or a game server feels laggy, the issue is often not your internet speed but a problem at a specific point along the route your data travels. Traceroute is the diagnostic tool that maps every hop between your device and a destination, measuring the delay at each one. By identifying exactly where latency spikes or packet loss occurs, you can determine whether the problem is on your local network, your ISP, or the destination’s infrastructure — and take the right action to fix it.

How Traceroute Works

Every packet sent across the internet carries a Time to Live (TTL) value. Each router along the path decrements the TTL by one. When it reaches zero, the router drops the packet and sends back an ICMP “Time Exceeded” message. Traceroute exploits this behavior by sending a series of packets with incrementally increasing TTL values — first 1, then 2, then 3, and so on. Each response identifies one router in the path and records the round-trip time.

The result is a hop-by-hop map of the route, with latency measurements at each point. This is fundamentally different from a simple ping, which only tells you the total round-trip time to the destination. Traceroute shows you where the delay is happening. The technique was originally described in Van Jacobson’s RFC 1393 and has been a standard network diagnostic tool since the late 1980s.

When to Run a Traceroute

Traceroute is most useful when problems are intermittent or destination-specific. If everything is slow, the issue is likely your local connection or ISP-wide congestion. But if only certain sites or services are affected, traceroute will reveal the exact bottleneck.

• Slow connections to a specific server — other sites load fine, but one particular service is sluggish. Traceroute shows whether the delay is in your network, your ISP, or the destination’s infrastructure.
• Packet loss during VoIP or gaming — dropped packets cause choppy audio, video freezes, or lag spikes. Traceroute with packet loss detection identifies the lossy hop.
• Routing anomalies — traffic taking an unexpected geographic path, such as packets from New York to Los Angeles routing through Europe. This indicates a routing misconfiguration or a suboptimal peering agreement.
• Before and after network changes — comparing traceroutes after a DNS change, ISP switch, or CDN migration confirms the change took effect and did not introduce new latency.
• Verifying VPN or proxy paths — traceroute through a VPN shows whether traffic is correctly tunneled or leaking outside the VPN. Use the VPN check guide alongside traceroute for a complete picture.

Step 1: Run a Visual Traceroute

Open the Visual Traceroute tool and enter the hostname or IP address of the destination you are troubleshooting. The tool sends traceroute packets from the server and maps each hop on a visual timeline, showing the IP address, hostname, geographic location, and latency at every point along the route.

For comparison, you can also run a traceroute from your own machine. On macOS or Linux, open a terminal and run traceroute example.com. On Windows, use tracert example.com. Comparing the results from your machine with the server-side traceroute helps isolate whether the issue is specific to your local network or affects the broader route.

Step 2: Read the Results

Each line in the traceroute output represents one hop — a router that forwarded your packet. The key fields to examine are:

• Hop number — the position in the route, starting from 1 (the first router after your device).
• IP address and hostname — identifies the router. Hostnames often reveal the ISP and geographic location (e.g., ae-5.r02.nycmny01.us.bb.gin.ntt.net indicates an NTT backbone router in New York).
• Round-trip times (RTT) — typically three measurements per hop. Look for consistency. If all three are similar, the measurement is reliable. If one is much higher, it may be a transient spike.
• Asterisks (*) — indicate a timeout. The router either dropped the ICMP packet or is configured not to respond. A few timeouts at intermediate hops are normal and do not indicate a problem if the final destination responds.

To identify the geographic location and network operator for any hop, copy its IP address into the IP Lookup tool. This shows the city, country, ASN, and organization — helping you understand whether the hop is on your ISP’s network, a transit provider, or the destination’s infrastructure.

Step 3: Identify Where the Problem Lives

Traceroute results typically divide into three zones, each pointing to a different responsible party:

First 1-3 Hops: Your Local Network

High latency or packet loss on the first few hops indicates a problem between your device and your router or modem. Common causes include Wi-Fi interference, an overloaded home router, a faulty Ethernet cable, or too many devices sharing the connection. Try restarting your router, switching from Wi-Fi to a wired connection, or checking for firmware updates.

Middle Hops: Your ISP and Transit Networks

If latency spikes in the middle of the route, the congestion is on your ISP’s network or at the handoff between your ISP and a transit provider. This is especially common during peak evening hours when residential networks are heavily loaded. ISP peering disputes can also cause persistent issues at specific handoff points. Contact your ISP with the traceroute data — it provides concrete evidence of where the bottleneck is.

Final Hops: The Destination Network

If latency only spikes at or near the destination, the problem is on their end — an overloaded server, a saturated uplink, or a misconfigured load balancer. There is little you can do except report the issue to the service provider. If the destination uses a CDN, the problem may resolve itself as the CDN routes traffic to a less congested edge server.

Common Traceroute Patterns

Experienced network administrators recognize several common patterns in traceroute output:

• Sudden latency jump that persists — a hop goes from 20ms to 150ms, and all subsequent hops remain around 150ms. This means the bottleneck is at that transition point. The routers beyond it are not adding significant delay; they are just reflecting the latency already accumulated.
• Single hop spike that recovers — latency jumps at one hop but returns to normal afterward. This usually means the router deprioritizes ICMP packets (used by traceroute) in favor of real traffic. It is not a real problem — the router is busy forwarding production packets, which is its job.
• Geographic jumps — latency increases from 30ms to 120ms often indicate traffic crossing a continent or an ocean via undersea cable. This is normal physics, not a fault. According to TeleGeography’s Submarine Cable Map, the propagation delay across the Atlantic is roughly 60-80ms round-trip.
• Asymmetric routing — the return path from the destination may differ from the outbound path. If your traceroute looks clean but you still experience issues, the problem may be on the return route. Unfortunately, standard traceroute only maps the outbound path.
• Routing loops — the same router appears multiple times in the trace, or the TTL increases without reaching the destination. This indicates a routing misconfiguration, usually at the ISP level.

Advanced Traceroute Techniques

The basic traceroute command works for most situations, but there are variations that provide additional insight:

• TCP traceroute — uses TCP SYN packets instead of ICMP. This bypasses firewalls that block ICMP but allow TCP traffic. On Linux, use tcptraceroute example.com 443 to trace the path to an HTTPS server.
• MTR (My Traceroute) — combines traceroute with continuous ping, showing real-time statistics including packet loss percentage and jitter at each hop. Install with brew install mtr on macOS or apt install mtr on Linux. MTR is particularly valuable for diagnosing intermittent issues because it runs continuously.
• Paris traceroute — standard traceroute can show multiple paths when load balancers distribute packets across different routes. Paris traceroute (paris-traceroute.net) controls for this by ensuring all probes follow the same path, giving more consistent results.
• Reverse traceroute — traces the path from the destination back to you. This is useful for diagnosing asymmetric routing issues but requires access to the destination server or a looking glass service operated by the destination’s ISP.

Combining Traceroute with Other Tools

Traceroute is most powerful when used alongside other network diagnostic tools. Each tool answers a different question:

• DNS Lookup — verify the destination domain resolves to the correct IP address. A DNS misconfiguration can send your traffic to the wrong server entirely.
• Port Checker — confirm the target service is accepting connections on the expected port. If the port is closed, the issue is not latency but a firewall or service outage.
• IP Lookup — identify the network operator and geographic location of any suspicious hop in the traceroute output.
• ASN Lookup — determine which autonomous system operates the network where the bottleneck occurs. This helps you identify whether the issue is with your ISP, a transit provider, or the destination’s hosting provider.
• SSL Certificate Checker — if you are experiencing TLS handshake timeouts, verify the destination’s SSL certificate is valid and not expired.

Frequently Asked Questions