Trace a Website to the Edge of the Internet

Most explanations of how the web works are diagrams. Boxes, arrows, a cloud labeled "Internet." They're fine, but they ask you to take the interesting parts on faith. This article takes the opposite approach: we'll point three standard command-line tools at a website and read what they actually say, layer by layer, until we've followed a single request from a laptop all the way to the machine that answers it.

The three tools are dig (ask the DNS system a question), curl (make an HTTP request and inspect the response), and traceroute (map the network path packets take). Everything below uses example.com as a neutral stand-in; the output is representative of what a CDN-hosted site returns, lightly trimmed for clarity. Run the same commands against any busy site and you'll see the same patterns.

Step 1 — A name is not an address

Computers don't route to names; they route to numbers. Before anything else happens, your device has to translate the human-friendly domain into a machine-friendly IP address by asking the Domain Name System. dig lets you ask that same question directly and see the raw answer, with no browser caching in the way:

$ dig example.com +short
93.184.216.34

The +short flag strips the formality and returns just the answer. One name, one address. But busy sites usually return several addresses, and that detail turns out to matter:

$ dig cdn-hosted-site.example +short
151.101.0.10
151.101.64.10
151.101.128.10
151.101.192.10

Four addresses for one name. Your computer will try the first and fall back to the others if needed — that's the first layer of redundancy. But here's the twist that makes the modern web work, and it's invisible in this output: those addresses are very likely anycast. The same number is announced from data centers all over the planet at once, and the network quietly routes you to the nearest one. We'll prove that in Step 3.

The alias chain

Ask about the www version of a site and you'll often see a second record type appear — a CNAME, which is DNS for "this name is just another name for that name, go look that one up instead":

$ dig www.example.com

;; ANSWER SECTION:
www.example.com.    3600  IN  CNAME   target.cdn-provider.net.
target.cdn-provider.net.  60   IN  A      151.101.0.10

The lookup resolves in a chain: www is an alias for the CDN's hostname, and that name carries the real address. The reason this exists is maintenance — an alias follows its target forever, so if the provider renumbers its servers, the alias updates itself automatically. One canonical record holds the truth; any number of aliases ride along for free. (A quirk worth knowing: DNS rules forbid a CNAME on the bare root domain, which is why the root usually carries hard-coded address records while only www gets the elegant alias.)

Step 2 — The address is a cache, not the website

Now we have an address. You might assume it points at "the server with the website on it." It almost never does. For any site behind a CDN, that address belongs to a cache server at the edge of the network — close to you geographically — and the real site lives somewhere else entirely. curl can show us the evidence, because the response headers confess the whole arrangement:

$ curl -sI https://example.com | grep -iE "x-cache|age|x-served-by|cache-control"
cache-control: max-age=600
age: 0
x-served-by: cache-sea-xxxx
x-cache: MISS

Read those four lines like a witness statement:

• x-served-by: cache-sea-xxxx — the request was answered by a cache node in a Seattle-area point of presence. Not the origin; an edge.
• x-cache: MISS — that edge did not already have the page in local storage, so it reached back to the origin server over the network, fetched the file, served it to me, and kept a copy.
• age: 0 — the copy is zero seconds old. Freshly fetched, just now.
• cache-control: max-age=600 — the origin's instruction to every cache: keep this copy for 600 seconds, then check back.

The interesting part is what happens on the second request. Run the exact same command again within those 600 seconds:

$ curl -sI https://example.com | grep -iE "x-cache|age"
age: 42
x-cache: HIT

Now it's a HIT — served straight from the edge's memory, with an age counting up the seconds since that first fetch populated it. The origin server never heard about this second request at all. This is the entire economic model of the modern web: populate a cache once, near each cluster of users, then serve thousands of requests from local memory without ever bothering the origin. It's the same idea as a DNS resolver caching answers — content delivery is just that pattern applied to web pages, with the time-to-live deciding how fresh "fresh" has to be.

Step 3 — Following the packets to the edge

We've claimed the address is anycast and the server is nearby. traceroute lets us watch the packets actually travel there, printing each network hop along the way. With the -a flag it also annotates each hop with the autonomous system number — the identifier for the network that owns that router — which is what makes the path legible:

$ traceroute -a example.com
 1  [AS0]      10.0.0.1                          3 ms     # home router
 2  [AS0]      10.x.x.x                          12 ms    # ISP private network
 3  [AS7922]   xxx.seattle.isp-backbone.net      14 ms    # ISP, local metro
 4  [AS7922]   xxx.seattle.isp-backbone.net      15 ms    # still the ISP
 5  [AS7922]   xxx.seattle.isp-backbone.net      14 ms    # ISP edge / peering
 6  [AS54113]  cdn-edge.cdn-provider.net         16 ms    # handoff to the CDN
 7  [AS54113]  served-from-here                  16 ms    # the edge that answers

Read the autonomous-system numbers in brackets and the whole journey becomes obvious. Hops 1–2 are inside your home and your ISP's access network (the [AS0] just means private, unrouted address space). Hops 3–5 stay inside a single ISP — and notice the hostnames name a specific city, all in your own metro area, all under 15 milliseconds away. Hop 6 is the moment your packets cross from your ISP into the CDN's network — a single handoff between two organizations. Hop 7 is the edge server that answers.

The headline: two networks, about seven hops, sixteen milliseconds, and the packets never left the metropolitan area. A website "on the internet" turned out to be served from a building a few miles away. That's anycast doing its job — the globally-announced address delivered you to the topologically nearest edge, which for most people is startlingly close.

When the trace goes dark — and why that's not a failure

Run traceroute against a CDN and you'll often see something alarming: the early hops resolve, then the rest of the output is nothing but asterisks.

$ traceroute example.com
 5  xxx.seattle.isp-backbone.net   14 ms
 6  * * *
 7  * * *
 8  * * *

This does not mean the site is unreachable — you just loaded it with curl a moment ago. It means the diagnostic plane is filtered, not that the data plane is down. The default traceroute sends UDP probes and listens for "time exceeded" replies; many CDN edges simply decline to send those replies, because they cost CPU and reveal internal structure to strangers. The page still loads perfectly; the network just stops narrating the path. Switch the probe type to ICMP and the edges often answer again:

$ traceroute -aI example.com   # -I uses ICMP echo instead of UDP

The distinction between "the path is broken" and "the path won't describe itself" is one every network engineer internalizes early, usually after filing one false outage ticket. The control plane and the data plane are independent: silence on one says nothing about the health of the other.

What you've actually seen

Three commands, and the abstract diagram became concrete and specific. A name resolved to four anycast addresses through a chain of DNS records. Those addresses turned out to be edge caches, not the website, populating themselves on first request and serving everyone after from local memory under a 600-second freshness contract. And the packets themselves traveled two networks and a handful of milliseconds to reach an edge server practically next door.

None of this required special access or privileged tools — just curiosity pointed at the response headers and routing tables that are sitting there in plain sight on every request you make. The next time a page loads in the blink of an eye, you'll know it isn't magic. It's a cache near your house, answering on an address that exists in a hundred places at once, backed by an origin it only bothers when it has to. That's the architecture serving the entire web — and now you can watch it work.