How CDNs Work: Why the IP You Look Up Isn't the Origin Server

Look up a big website with an IP lookup and the geolocation is all over the place: Singapore, Virginia, Frankfurt — and run it again from a different network and the result changes. The lookup isn't inaccurate; what you found simply isn't "that company's server" but the CDN's nearest node.

The essence of a CDN: move content close to you

In a world without CDNs, all users hit the same datacenter and physical distance dictates latency — a European user reaching a US origin waits 80ms or more per round trip, so pages naturally load slowly.

A CDN (Content Delivery Network) deploys edge nodes around the world and caches static assets (images, JS, CSS, video) on them. When a user visits, DNS resolves the domain to "the node nearest you"; you're actually pulling data from a nearby datacenter, and RTT drops from hundreds of milliseconds to tens. That's the practical effect of the ECS scheduling described in DNS leaks explained: the resolver tells the CDN's authoritative DNS your subnet, and the CDN picks a node accordingly.

So the "geolocation of the IP you looked up" answers "which CDN node your traffic enters and exits through" and has nothing to do with the site operator's physical location. For large sites behind Cloudflare, the geolocation you get is often the Cloudflare node near your own city — which is precisely proof the CDN is working.

How to tell "this IP is a CDN"

A few reliable signals:

• Owning organization: when the lookup's ASN/organization shows Cloudflare, Akamai, Fastly, CloudFront (Amazon), Alibaba Cloud CDN, and the like, it's a CDN edge node
• IP type: registered as datacenter (Hosting/Datacenter) — every CDN node is a datacenter IP; there's no such thing as a "residential" node
• Different results from different locations: resolving the same domain from different networks yields different IPs — the signature behavior of CDN scheduling (compare with DNS resolution diagnostics)
• Response headers: CDNs leave headers like X-Cache: HIT/MISS, CF-Ray, and X-Served-By, marking which node was hit

Conversely, a lookup showing a residential IP for a site claiming to be a big-name service is the suspicious one. A real origin IP is invisible from the outside — it hides behind the CDN, and only the CDN's origin-pull requests ever touch it. That's the second value the CDN delivers along the way: hiding the origin and absorbing attacks (DDoS hits the CDN nodes; the origin never feels it).

Cache hits and origin pulls: why the same page is sometimes fast and sometimes slow

Cache on a CDN node has a lifetime (TTL). When a request arrives, three things can happen:

• HIT: the node has it cached and returns it directly — milliseconds
• MISS: the node has no cache, so it fetches from the origin once on your behalf (origin pull), stores the result, and returns it to you — the first access to a resource from a region is noticeably slower
• EXPIRED: the cache is stale and needs revalidation or another origin pull

That's one root of the "first load slow, second load instant" phenomenon, and it explains why the cache hit rate (the HIT proportion) in CDN reports is a core operational metric — the higher the hit rate, the less origin pressure and the faster the average user experience.

What this means for IPchase tool results

Once you understand CDNs, the readings from several tools become clear:

• IP geolocation lookup: looking up a CDN domain returns an edge node IP, and the geolocation is the node's location. Want the origin? Public channels essentially can't find it — that's part of the CDN's design goals
• Speed test: for a site behind a CDN, you're measuring your speed to the CDN edge, much faster than to the real origin — this site itself sits behind the Cloudflare CDN by default, so an optimistic speed-test result is normal and expected
• Ping: pinging a CDN domain gives you the node's latency, which happens to be the real network distance users experience
• Disguise score check: an exit IP showing as datacenter type doesn't necessarily mean "on a proxy" — if you're testing an access path that goes through a CDN, seeing the CDN node's datacenter IP is perfectly normal

Origin leaks: the exception to CDN protection

The CDN's ability to hide the origin has one precondition: the origin IP was never publicly exposed. Historical DNS records (the real IPs resolved before the CDN was deployed), historical SSL certificate records, direct-connect services on the server (e.g., mail.example.com without a CDN in front), misconfigured subdomains — any of these channels can leave the real IP discoverable in deep-web records. Sites already behind a CDN should verify that historical resolution records never leaked the origin IP; otherwise the CDN's DDoS protection is mere decoration.

Summary

• The IP you look up is usually a CDN edge node; its geolocation ≠ the operator's location
• How to tell: the ASN shows a CDN vendor, datacenter type, different resolutions from different networks, X-Cache response headers
• HIT/MISS/origin pulls explain "first load slow, second load fast"
• Want to see it once yourself: first check IP geolocation, then trace the resolution path with DNS diagnostics, and finally ping that node — three tools chained together make one complete CDN observation experiment.