Traceroute Online traces the path of packets from our infrastructure to your target host, hop by hop. For each hop it captures the IP, hostname (PTR), round-trip time, ASN, organization, and approximate geographic location. Visualizes the route on a world map and presents the hops as a latency chart so you can see exactly where packets slow down, drop, or take an unexpected detour. Better than the raw `traceroute` command output — same data, infinitely more readable.
Six independent classes of output per traceroute. The hop list and latencies are the standard output; the per-hop ASN/org enrichment, the geographic map, and the path-anomaly detection are what make this more useful than a raw command-line traceroute.
Each hop reveals the router IP that decremented the TTL plus its reverse-DNS hostname where set. PTR records often encode the carrier and city (`ae-3.r03.lsanca07.us.bb.gin.ntt.net` → NTT, Los Angeles). Hops without PTR are usually privately-administered routers or backbone equipment with no reverse-DNS.
Three TTL-incremented probes per hop, averaged. Surfaces jitter (high variance between the three) and helps distinguish 'always slow' (consistent high latency) from 'sometimes slow' (some probes time out). Median is the headline number; min/max captured for detail.
Each hop's IP resolved to its AS number and the operator's name. You see exactly when packets transition between networks — your ISP → tier-1 transit → destination CDN. AS-path changes are often the most informative part of a trace.
Each hop geolocated to a city. Visualized on a world map. Surfaces the absolute path length (some 'short' traces actually loop through three continents) and identifies physical-distance latency that can't be optimized away.
Detects routing loops (the same hop appearing more than once), persistent packet loss at a specific hop, asymmetric routing (the path varies between consecutive probes), and ICMP-rate-limited hops (stars for some probes, not others). Each anomaly is flagged with the likely cause.
Categorizes latency by the network layer where it accumulates. First few hops = your local network and ISP. Middle hops = transit / backbone. Final hops = destination ISP / CDN. Knowing where the latency happens tells you whether you can do anything about it.
Network issues hide behind generic 'slow' or 'flaky' symptoms. Traceroute is the single most informative cheap diagnostic — it tells you whether the problem is local, in transit, or at the destination, and approximately where. Five reasons it matters:
Traceroute exploits IP's TTL field. Each router decrements TTL by 1; when TTL reaches 0, the router drops the packet and sends back an ICMP Time Exceeded. By sending packets with TTL=1, then TTL=2, and so on, we collect a response from each router on the path.
A traceroute is just data; interpretation comes from recognizing patterns. Five common ones:
Every hop's IP, hostname, latency, ASN, organization, and geolocation is available as JSON. Useful for continuous path monitoring, customer-incident triage, and CDN-routing verification.
curl 'https://api.domainscan.in/v1/ip/traceroute?host=cloudflare.com'const res = await fetch(
'https://api.domainscan.in/v1/ip/traceroute?host=example.com'
);
const trace = await res.json();
console.log(trace.target); // 'example.com (93.184.216.34)'
console.log(trace.summary.hopCount); // 14
console.log(trace.summary.totalLatencyMs); // 87
console.log(trace.summary.reachedTarget); // true
// Find slowest hop
const slowest = trace.hops
.filter(h => h.responseMs != null)
.sort((a, b) => b.responseMs - a.responseMs)[0];
console.log(`Slowest hop: ${slowest.hop} · ${slowest.ip} · ${slowest.responseMs}ms`);
// AS transitions
let prevAsn = null;
trace.hops.forEach(h => {
if (h.asn && h.asn !== prevAsn) {
console.log(`Hop ${h.hop}: enter AS${h.asn} (${h.org})`);
prevAsn = h.asn;
}
});{
"target": "example.com",
"resolvedIp": "93.184.216.34",
"summary": {
"hopCount": 14,
"totalLatencyMs": 87,
"reachedTarget": true,
"anomalies": []
},
"hops": [
{
"hop": 1,
"ip": "10.0.0.1",
"hostname": null,
"responseMs": 1,
"asn": null,
"org": null,
"location": null
},
{
"hop": 7,
"ip": "4.69.143.214",
"hostname": "ae-2-3604.ear1.washington-dc2.level3.net",
"responseMs": 22,
"asn": 3356,
"org": "Level 3 Parent, LLC",
"location": { "country": "US", "city": "Washington, DC" }
}
]
}Six patterns we see most often:
Customer complains your service is slow from their region. Run a traceroute from a vantage point in that region to your service. The hop-by-hop latency profile either confirms a network issue (and tells you where) or rules it out — pointing investigation at the application layer.
Your CDN should be serving users from the nearest edge. Verify by traceroute from multiple regions and confirming the final hop is at a geographically reasonable PoP. Misrouted CDN edges are surprisingly common.
Cron a traceroute from key vantage points to your critical endpoints. Alert on AS-path changes (new transit involved, peering shift), latency regressions, or new packet loss. Catches routing changes that may not surface as outages but degrade performance.
Your ISP is dropping packets somewhere upstream. Traceroute output is the data they need to file a ticket with their transit carrier. Without it, escalation goes nowhere.
Verify that traffic to your protected endpoint actually traverses your DDoS-scrubbing provider. Traceroute should show the scrubbing AS in the path; if not, your protection is bypassable.
Comparing two cloud regions for hosting a service. Run traceroutes from representative user regions to candidate hosting locations. The hop count and latency profile inform the choice.