Traceroute: a beginner's guide
Real ICMP traceroute from 18 global cloud regions
Traceroute: how to see exactly which routers your traffic crosses
Traceroute is a network diagnostic that reveals the exact path a packet takes from your computer to a remote server, listing every intermediate router along the way. Where ping tells you the round-trip latency, traceroute tells you the entire route — every hop, every router's IP address (and often its hostname), and how long each hop takes. The clever trick that makes traceroute work is the Time-To-Live (TTL) field in IP packets. Every IP packet has a TTL counter that decreases by one at every router it passes; when the counter hits zero, the router throws the packet away and sends back an error. Traceroute exploits this by sending a packet with TTL=1 first (which dies at the first router and reveals it), then TTL=2 (dies at the second), and so on, mapping out the entire path one hop at a time.
You should care because **traceroute is the only tool that tells you where in the network a problem is happening**, not just that it is happening. The classic story is the customer reporting that your website is slow only from their region. A ping test confirms the slowness but doesn't explain it. A traceroute reveals that there is a 200 ms hop right in the middle of the path — usually at the boundary between two ISPs — and now you know it is a peering issue, not a server issue, and you can stop blaming your CDN. Traceroute is the difference between guessing where the slowness is and actually pointing at the broken router.
The five things every traceroute reveals:
The list of routers (hops). Each hop along the path, with its IP address and (often) its hostname.
The latency at each hop. How long the round-trip to that specific router takes.
The total path length. A typical internet path is 8–15 hops; longer paths are usually a sign of inefficient routing.
Timeouts and stars. Routers that don't respond are shown as ` *` — sometimes intentional (some routers don't reply to traceroute), sometimes a sign of a broken hop.
The autonomous system at each hop. Combined with ASN data, every hop can be tagged with the network it belongs to (Cogent, Level 3, NTT, Hurricane Electric, etc.).
Three questions a traceroute answers:
Which router or network segment is responsible for the latency I'm seeing?
Is the path my traffic is taking sensible, or is it going through Mars?
For an outage, where in the path is the failure happening?
The cost of not understanding traceroute is debugging network problems without ever pinpointing them. The fix is to learn to read traceroute output once — the basics take about ten minutes — and then keep a traceroute tool handy. Traceroute is built into every major operating system (`tracert` on Windows, `traceroute` everywhere else), and the underlying technique is unchanged since the 1980s.
The Traceroute endpoint, in plain language
In one sentence: Real ICMP (Internet Control Message Protocol) traceroute from 18 global cloud regions
Performs real ICMP (Internet Control Message Protocol) traceroute from up to 18 geographically distributed cloud regions via the Globalping network. Returns hop-by-hop path data with router IPs, hostnames, per-hop RTT, median end-to-end latency, and average hop count from AWS, GCP, or Azure datacenters. Identify routing asymmetries, peering points, and network bottlenecks across regions.
Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.
What is actually happening when you call it
Here's what's actually happening behind the scenes when you call this endpoint:
Creates ICMP (Internet Control Message Protocol) traceroute measurements via the Globalping network from cloud provider regions (AWS, GCP, Azure). Returns real hop-by-hop path data including router IP (Internet Protocol address) addresses, reverse DNS (Domain Name System) hostnames, per-hop round-trip times, and destination reachability status. Computes median end-to-end latency and average hop count across zones. Note: Internet routing is asymmetric (the official internet standard) — forward and reverse paths often differ, and ICMP rate limiting at intermediate hops may show timeouts that don't indicate actual packet loss.
If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.
Why this specific tool matters
Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the Traceroute tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.
Traceroute reveals the actual network path between cloud regions and your service, exposing routing inefficiencies, peering bottlenecks, and geographic detours invisible to simple latency testing. Essential for debugging regional performance issues, verifying CDN (Content Delivery Network) edge routing, identifying ISP congestion points, and understanding how traffic traverses autonomous systems. Compare paths from multiple regions simultaneously to detect routing asymmetries.
Picture this in real life. Imagine a network engineer. Here's the situation they're walking into: Analyze routing paths from all major regions to identify suboptimal routes, unexpected geographic detours (e.g., Asia traffic routing through US), or missing peering. Compare AS paths to detect hot-potato routing issues. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the Traceroute tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.
Three questions this tool answers in plain English. If any of these have ever crossed your mind, the Traceroute tool is built for you:
Where in the world is this server actually located, and who runs the network it sits on?
How fast does traffic move between my users and my service?
Is the IP address I am looking at part of a residential network, a data center, or something suspicious?
You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.
Who gets the most out of this. Network engineers, IT admins, sales teams qualifying enterprise prospects, and product teams building geo-personalization or fraud rules. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.
What happens if you skip this entirely. Skip it and you can't tell where your users actually are, who runs the network they're on, or why they're seeing slow page loads. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.
Available on the pro plan. The technical details: `GET /v1/network/traceroute`.
When would I actually use this?
If you're still on the fence about whether the Traceroute tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a network engineer, a devops engineer, and an SRE — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.
Story 1: Regional Routing Analysis
Imagine you're a network engineer. Analyze routing paths from all major regions to identify suboptimal routes, unexpected geographic detours (e.g., Asia traffic routing through US), or missing peering. Compare AS paths to detect hot-potato routing issues.
Why it matters: Pinpoint regional routing inefficiencies and negotiate peering improvements with data.
Story 2: CDN & Anycast Path Verification
Imagine you're a devops engineer. Verify that your CDN (Content Delivery Network) or anycast deployment correctly routes traffic from each region to the nearest edge location. Detect cases where routing bypasses nearby PoPs.
Why it matters: Confirm CDN (Content Delivery Network) edge locality across all geographic regions with traceroute evidence.
Story 3: Latency Root Cause Analysis
Imagine you're an SRE. When users in a specific region report high latency, trace the route from that region to identify the exact hop where latency spikes — whether it's a congested peering point, an ISP backbone, or a last-mile issue.
Why it matters: Isolate network-level bottlenecks to the specific hop, ISP, or peering exchange causing the problem.
Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the Traceroute tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:
When a customer reports that your site is slow specifically from their region.
When you need to know whether traffic is coming from a residential network or a data center.
When planning a CDN, points of presence, or geographic expansion.
During an outage, to see exactly where in the route packets are getting lost.
If you can see yourself in even one of those bullets, the Traceroute tool will pay for itself the first time you use it.
Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the Traceroute tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.
The easiest way: just ask your AI assistant
If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:
"Use the Traceroute tool to check example.com and explain anything that looks wrong in plain language."
The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.
MCP (Model Context Protocol) access is free on every plan, including the free tier. One API key works for both REST and AI — you do not have to choose.
The technical way: call it from code
If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.
# Replace edns_live_YOUR_KEY with your real API key from the dashboard
curl -H "Authorization: Bearer edns_live_YOUR_KEY" \
"https://api.edgedns.dev/v1/network/traceroute?host=example.com"What you need to provide
You need to provide 5 pieces of information when you call this tool. The table below lays them out side by side, with a real example for each one so you can see exactly what to send.
| Field | Type | Required? | What it means | Example |
|---|---|---|---|---|
host | string | Yes | Target hostname or IP (Internet Protocol address) address to traceroute | example.com |
provider | string | Optional | Cloud provider for region filtering: "aws", "gcp", or "azure". Defaults to "gcp". | aws |
region | string | Optional | Cloud provider region code. When combined with provider, traceroutes from the nearest probe zone for that region. | us-east-1 |
zones | string | Optional | Comma-separated probe zone IDs (e.g., us-east,eu-west,ap-northeast). Use /ping/locations to see available zones. | us-east,eu-west |
geography | string | Optional | Filter by geography: North America, South America, Europe, Asia Pacific, Oceania, Middle East, Africa | Europe |
What you get back
When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.
| Field | Type | What you'll see in it |
|---|---|---|
host | string | The target host that was traced |
trace_method | string | Trace method: "ICMP" |
results | array | Per-zone traceroute results with hop-by-hop data, latency, and probe network info |
results[].hops | array | Hop-by-hop data: hop_number, hostname, ip_address, timings (RTT array), avg_rtt, is_destination |
results[].total_hops | number | Total number of hops in the trace |
results[].total_latency_ms | number | End-to-end latency (last hop RTT) |
results[].reached_destination | boolean | Whether the trace reached the target destination |
results[].resolved_address | string | Resolved IP (Internet Protocol address) address of the target |
results[].probe_network | string | Network name of the probe (e.g., "Amazon.com", "Google") |
results[].probe_asn | number | ASN (Autonomous System Number) of the probe network |
zones_tested | number | Number of probe zones tested |
successful | number | Number of zones that reached the destination |
failed | number | Number of zones that failed to reach the destination |
avg_latency_ms | number | Mean end-to-end latency across all successful zones |
median_latency_ms | number | Median (p50) end-to-end latency across zones |
avg_hops | number | Average hop count across successful traces |
min_latency | object | Zone with lowest end-to-end latency (zone, city, latency_ms) |
max_latency | object | Zone with highest end-to-end latency (zone, city, latency_ms) |
available_zones | object | Available probe zones grouped by geography |
available_providers | object | Count of regions per cloud provider (aws, gcp, azure) |
Words you might be wondering about
If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.
DNS (Domain Name System) — The internet's address book. When you type a website name, DNS turns it into the actual numeric address computers use to find each other.
IP (Internet Protocol address) — A unique number that identifies a computer on the internet, like a phone number for a server.
CDN (Content Delivery Network) — A worldwide network of servers that store copies of your website close to your visitors so pages load fast.
ICMP (Internet Control Message Protocol) — The "knock-knock" of the internet. Tools like ping use it to check whether a server is reachable and how long the round trip takes.
RFC (Request for Comments) — The official internet standards documents. When someone says 'RFC 8484' they mean a specific numbered standards document — in that case, the one defining DNS over HTTPS.
Need Programmatic Access?
Automate domain intelligence with 100+ API endpoints and a free MCP server for AI integration.