skip to content
PingTraceSSH Logo
Donate

Traceroute Map

Runs on your machine and shows every hop. Unknown/private hops are placed approximately and labeled.

Traceroute Map helps you understand the network path between you and a destination by showing each hop and the time it takes to reach it. This is the fastest way to debug “the site is slow” problems that aren’t actually caused by the server—many performance issues start with routing detours, congested upstream links, or a bad handoff between ISPs.

Use this tool when you see high latency, random spikes, or regional connectivity problems. It’s especially useful when comparing multiple targets (e.g., two data centers) or when one user location is impacted and another isn’t. The map view makes it easy to spot unexpected geography (traffic hairpinning across regions) and to communicate the problem clearly to a carrier or provider.

known approx (unlocated) known→known segment with approx hop(s)
Idle

Hops

    Debug
     

    Unknown/private “*” hops are spaced between nearest known points (or near origin if at start) and marked as approximate.

    How to read traceroute results

    A traceroute shows a sequence of hops (routers) between you and the destination. Look for the hop where latency noticeably increases and stays elevated for the rest of the path—this often indicates where congestion begins or where the route changes. If you see a single hop with a high RTT but the following hops are normal, that hop may simply be deprioritizing traceroute probes rather than forwarding traffic slowly.

    Unknown or private hops (often shown as * or RFC1918 addresses) are common inside ISP cores and enterprise networks. This page places those hops approximately between known points so the path remains readable. Treat “approx” hops as a visualization aid, not a precise geolocation.

    Practical workflow: run Ping Monitor during the slowdown to capture spikes or loss, then run this traceroute to find where the path changes. If the destination is a hostname, validate resolution with DNS Checker. If you suspect an upstream incident, cross-check with Outage Detector and include the hop where latency begins when opening a provider ticket.