Finding the Origin IP Behind a CDN: Limits and Ethics

You look up a website's IP address and the result belongs to a large CDN, not to a hosting company. People then search for a way to find the "real" IP behind it. This article explains what you are actually looking at, why the origin address generally cannot be determined from outside, why trying to unmask somebody else's origin is a bad idea, and, for site owners, how to check that your own origin is properly protected.

We do not provide a method for uncovering third parties' origin servers. The legitimate needs people have in this situation are all met more reliably in other ways, described below.

What a CDN does to DNS

A CDN or reverse-proxy service sits between visitors and the server that holds the site (the origin):

visitor ──► CDN edge (203.0.113.10, anycast) ──► origin (address not published)

The site's DNS records point at the CDN, either directly or through a CNAME:

$ dig +short www.example.com
www.example.com.cdn-provider.example.
203.0.113.10
203.0.113.11

Those addresses belong to the CDN's network. They are typically anycast: the same address is announced from many locations, and each visitor reaches the nearest one. The edge terminates TLS, serves what it has cached, and fetches the rest from the origin over a separate connection whose destination is known only to the CDN and the site owner.

So the answer to "where is this site hosted?" has two layers, and a public lookup can honestly report only the first: the site is delivered through this CDN. That is a true and useful result, not a failed one. How to read it is covered in finding where a website is hosted.

Why the origin usually cannot be found

It is not in the DNS. The mapping from hostname to origin lives in the CDN's configuration, not in any public record.
There may be no public origin at all. Modern setups connect the origin to the CDN through an outbound tunnel or private interconnect; the server has no inbound public address. Others use object storage, serverless functions or several origins behind a load balancer. "The" origin IP is sometimes a question without an answer.
A properly configured origin does not answer strangers. Its firewall accepts connections only from the CDN, or it requires a client certificate or secret header that only the CDN has.
Sites that promise to reveal it are guessing. They show historical DNS data from before the CDN was enabled, or addresses that once had some association with the name. The result may be years old, may now belong to somebody entirely unrelated, and comes with no indication of which of these is the case. Acting on it means pointing at a stranger.

No lookup tool, including ours, can see through a correctly configured CDN, and any tool that claims certainty here is overstating what it knows.

Why you should not try on someone else's site

Hiding the origin is a deliberate security control. It is what makes DDoS protection and web application firewalls effective, since an attacker who knows the origin address simply goes around them. Working to defeat that control on a system you do not own is reconnaissance against that system. Depending on what you do and where you are, probing and connecting to infrastructure without authorisation can breach computer misuse laws and the terms of service of the networks involved, and it is outside the scope of any honest "just curious" use.

If you are doing security testing, the rule is the usual one: written authorisation from the owner, a defined scope, and then the owner can simply tell you the origin address.

What people actually need, and the right way to get it

You want to…	Do this instead
report phishing, malware or fraud on a site behind a CDN	Use the CDN's abuse form. Large CDNs forward complaints to the hosting provider and, for valid legal or abuse processes, can disclose the host to the complainant. Report to the domain's registrar too; its abuse contact is in the registration data.
pursue copyright or trademark infringement	The CDN's and registrar's legal/abuse channels, or counsel. Disclosure of the operator happens through those processes, not through scanning.
know which hosting company a competitor uses	Accept "behind a CDN" as the answer. Public hints such as job ads or technology pages are fair; probing is not.
investigate a crime against you	Report to the police or your national CERT; they can request data through legal channels.
debug your own site	You already have the origin address in your CDN dashboard and hosting panel. See the next section.

For owners: is your own origin exposed?

This is the legitimate version of the question, and it is worth asking, because the default state of many setups is "CDN in front, origin wide open".

Places where your origin address tends to leak

Review these on your own domain:

Your own DNS records. Subdomains that bypass the CDN and point straight at the server: direct, origin, ftp, cpanel, dev, staging, an old mail. Go through the zone line by line.
Mail. If the web server also sends or receives mail, the MX record and the Received: headers of outgoing messages carry its address. SPF records with ip4: entries list your servers in plain text.
History. If the domain pointed at the same server before you enabled the CDN, that address is in passive-DNS archives forever. Enabling a CDN does not make an old address secret.
Certificates. A server that answers HTTPS on its bare IP address with the site's certificate identifies itself to anyone who connects, and internet-wide scanners connect to everything.
The application itself. Error pages, debug output, redirects to an IP, outbound requests (webhooks, link previews, image fetching) that originate from the server.

Hardening checklist

Firewall the origin so that ports 80/443 accept only the CDN's published address ranges, and automate updates of that list. This is the single most effective step.
Authenticate the CDN to the origin: mutual TLS ("authenticated origin pulls"), or a secret header verified by the web server. An IP allowlist alone admits every other customer of the same CDN.
Prefer an outbound tunnel or private link if your CDN offers one; then the origin needs no inbound rule at all.
Move to a new IP address after the protections are in place, if the old one has been public. Otherwise the history item above defeats everything else.
Separate mail from web. Use a mail service or a different server for MX and outbound mail.
Configure a default virtual host that serves nothing meaningful and a certificate that does not name your site, for requests that arrive by IP address or with an unknown Host.
Remove or proxy stray subdomains. If a name must bypass the CDN, host that service elsewhere.

Verify your own setup

From a machine that is not in the CDN's ranges, with your own origin address:

$ curl -m 5 -sv --resolve www.example.com:443:198.51.100.20 https://www.example.com/ -o /dev/null
* connect to 198.51.100.20 port 443 failed: Operation timed out

A timeout or refusal is what you want. If you get your site back, the origin is reachable directly and the CDN's protections are optional for anyone who learns the address. Check your public records too:

$ dig +short example.com MX
$ dig +short example.com TXT | grep spf1
$ dig +short -x 198.51.100.20        # PTR naming your site?

A PTR record on the origin's address that names your domain is an easy one to miss; see reverse DNS and PTR records.

Common mistakes

Treating the CDN as a privacy feature. It hides an address; it does not hide the operator from the CDN, the registrar, or a court.
Turning on the CDN and leaving the origin firewall open to the world.
Keeping the same IP address the domain used publicly for years.
An SPF record or MX that points at the web server.
Trusting a "real IP finder" result and sending an abuse report, or worse, traffic, to an unrelated party.

Check it with OrbitProbe

The OrbitProbe IP lookup resolves a hostname to its IPv4 and IPv6 addresses and shows reverse DNS, ASN, network owner and announced prefix for each, and it flags addresses that belong to CDN edge networks. When it says "CDN edge", that is the complete, truthful answer available from outside; it will not guess at an origin. As an owner, run it on every hostname in your zone: any name that resolves to your hosting provider's network instead of the CDN is a name that gives your origin away. The mail side of the same audit is covered in MX, SPF, DKIM and DMARC explained.