When should I run traceroute instead of ping?

Run traceroute when ping reports high latency or partial packet loss and you want to know WHERE in the path the problem is. Ping tells you end-to-end RTT, traceroute breaks that number down hop by hop so you can spot the exact router or link that is slow.

What do the stars `* * *` mean in the output?

That hop's router refuses to respond to ICMP probes, a common security setting. Your packets still pass through it just fine, you just can't see the router's reply. The trace continues past the stars to the next responsive hop.

The last line shows `* * *`. Did the trace fail?

Usually not. Many origin servers and CDNs (Cloudflare, Akamai) drop ICMP at their edge, so the destination itself never replies. The trace succeeded if the surrounding hops are visible. To verify the host is actually serving content use HTTP Headers on it.

Hop 5 is 30 ms and hop 6 jumps to 250 ms. Is the router at hop 6 broken?

Almost always no. The router at hop 6 replied fine, but the link BETWEEN hop 5 and hop 6 (a transoceanic cable, a saturated peering link, a low-priority queue) is the slow part. Routers also send ICMP replies at lower priority than user traffic, so a slow ICMP reply does not always mean traffic through that hop is slow.

How does the map know where each router is?

From the router's name first: networks put a city code in it (ffm-bb1 is a Frankfurt router). When the name has none, the address database is used only if it pins a city. Every place is checked against the round-trip time: a reply in 4 ms cannot come from another continent. Hops that cannot be placed are marked "location unknown" and the line through them is dashed.

Why max 30 hops? Any other limits?

The default TTL in IP is 64, but the public internet rarely needs more than 25 hops end-to-end. Capping at 30 keeps the response time bounded. Private IPs are refused, requests are rate-limited per IP.

Free, no signup, rate-limited per IP. Private IPs (RFC 1918, localhost) are refused for security.

Network

Traceroute

Trace route to host

Route

packet.guru server
Router, location known
Location unknown or no reply

Traces the route from the packet.guru server to your target and shows each router on the map.

Terminal

Console ready. Execute a command to see output...

About Traceroute

Visualize the invisible path

Every time you load a website, your data jumps through dozens of routers to get there. Traceroute unveils this journey link by link.

The Magic of TTL

Traceroute hacks the "Time To Live" (TTL) field in IP packets:

It sends a packet with TTL=1. The first router receives it, decreases TTL to 0, kills the packet, and sends back a "Time Exceeded" error. Boom, that is the first hop.
It sends a packet with TTL=2. It passes the first router, dies at the second. That is the second hop.
This repeats until the destination is reached.

Troubleshooting Bottlenecks

Sudden High Latency: If Hop 5 is 10ms and Hop 6 is 200ms, Hop 6 is the problem (or the cable connecting them).
Stars ( * * * ): The router is functioning but configured to ignore ICMP trace packets (Stealth Mode).

How to use Traceroute

Enter the target
Domain or IPv4 address. No protocol, no slash.
Pick max hops
Default 30. Lower it to 10 or 15 if you only want a quick view of the first portion of the path.
Run the trace
Hit Traceroute. Each line is one hop: hostname, IP, the best of three round-trip times and where the router is. The map draws the same hops.
Spot the problem hop
Look for the row where latency jumps up and never recovers, that's where the bottleneck is. Run Whois on the IP of that hop to find which ISP it belongs to.

Frequently Asked Questions

: Run traceroute when ping reports high latency or partial packet loss and you want to know WHERE in the path the problem is. Ping tells you end-to-end RTT, traceroute breaks that number down hop by hop so you can spot the exact router or link that is slow.
: That hop's router refuses to respond to ICMP probes, a common security setting. Your packets still pass through it just fine, you just can't see the router's reply. The trace continues past the stars to the next responsive hop.
: Usually not. Many origin servers and CDNs (Cloudflare, Akamai) drop ICMP at their edge, so the destination itself never replies. The trace succeeded if the surrounding hops are visible. To verify the host is actually serving content use HTTP Headers on it.
: Almost always no. The router at hop 6 replied fine, but the link BETWEEN hop 5 and hop 6 (a transoceanic cable, a saturated peering link, a low-priority queue) is the slow part. Routers also send ICMP replies at lower priority than user traffic, so a slow ICMP reply does not always mean traffic through that hop is slow.
: From the router's name first: networks put a city code in it (ffm-bb1 is a Frankfurt router). When the name has none, the address database is used only if it pins a city. Every place is checked against the round-trip time: a reply in 4 ms cannot come from another continent. Hops that cannot be placed are marked "location unknown" and the line through them is dashed.
: The default TTL in IP is 64, but the public internet rarely needs more than 25 hops end-to-end. Capping at 30 keeps the response time bounded. Private IPs are refused, requests are rate-limited per IP.
: Free, no signup, rate-limited per IP. Private IPs (RFC 1918, localhost) are refused for security.