What Is the Difference Between a CDN Node IP and an Origin Server IP?

Use a tooldigto look up a domain that uses a CDN, and one or several IPs will quickly appear on the screen. Many people's first reaction is: Is this the website server's real IP?

Most of the time, it is not.

If the domain is already proxied through a CDN, users usually connect tothe CDN node IP; the location where the website content is actually stored or generated isthe origin server. Both sit on the same access path, but perform completely different roles.

There is another concept that can easily be mixed in: the speed test platform'sprobe node IP. It is neither a CDN node nor an origin server, but the address of the machine that initiates the test request.

To put it clearly up front:

A CDN node IP is the edge entry point that visitors connect to on the public internet; an origin IP or origin address is the backend that the CDN connects to when fetching from the origin; a probe node IP is the source address from which a speed test request originates. For websites already using a reverse proxy CDN, public DNS queries and ordinary website speed tests can usually only see the user-facing CDN edge entry point, and they cannot be used to determine the website's true origin IP.

During a single visit, what locations are actually involved?

The most common request path can be simplified as follows:

访客或测速探针 → CDN边缘节点 → 源站服务

The user first obtains an accessible address through DNS, then connects to a CDN edge node. After the edge node receives the request, it first checks the local or upstream cache:

• On a cache hit, the content can be returned directly from the CDN, and this request may not access the origin server at all;

• On a cache miss, or if the request is for dynamic content, the CDN then fetches the content from the configured origin server;

• After the content is returned, the CDN may cache it and then respond to the user.

In AWS'sCloudFront content delivery process,the same basic path is also described: DNS directs the request to the appropriate edge location, responds directly on a cache hit, and only fetches the object from the origin on a miss.

This is also the most critical point for understanding the two types of IPs:Users face the CDN; the origin server lies behind the CDN.

What are CDN node IPs, origin IPs, and probe node IPs, respectively?

1. CDN node IP: the edge entry point users connect to

A CDN node IP usually belongs to the CDN provider or its partner networks. It is closer to users, terminates connections, enforces caching and security rules, and initiates origin fetch requests when needed.

A CDN IP does not necessarily correspond to a single physical server, nor does it necessarily serve only one website. Shared IPs and Anycast are both common: the same IP can serve multiple domains, and it may be announced simultaneously from multiple data centers, with the network directing users to a more suitable entry point.

Take Cloudflare as an example; its officialproxy status documentationstates clearly that a proxied record returns Cloudflare's Anycast addresses to the querier, not the origin address configured in the record.

Therefore, “finding a Cloudflare IP” and “finding the website's origin” are two different things.

2. Origin IP: the backend that the CDN connects to during origin fetch

The origin server is the authoritative source of website content, but “origin server” does not necessarily mean “a fixed public IP of a single server.”

It may be:

• an Nginx or Apache server;

• a group of application servers behind a load balancer;

• an object storage bucket;

• an API gateway or container ingress;

• a backend service represented by another domain;

• a service that only allows the CDN to connect over a private network.

So a more accurate term isorigin address or origin endpoint.

In modern cloud architectures, you may see only an origin domain in the CDN console, while the IPs behind it change dynamically. AWS'sCloudFront origindefinition also includes S3 buckets and HTTP servers, and is not limited to a single IP.

3. Probe node IP: where test requests originate

If you use a multi-region speed test service, the page often also shows “probe region,” “ISP,” or “monitoring point.” These nodes are responsible for initiating requests while simulating users in different regions.

Take CdnChart as an example: after a probe node initiates a visit, the result'sresponse IPindicates the target address actually connected to in that test; it is usually a CDN edge IP. The probe node's own outbound IP is the request source, and the two should not be swapped.

Why does querying a domain usually only show the CDN node IP?

After using a reverse proxy CDN, public DNS must direct users to the CDN network; otherwise, caching, protection, and traffic scheduling cannot take effect.

So when you run:

dig www.example.com A +noall +answer
dig www.example.com AAAA +noall +answer
dig www.example.com CNAME +noall +answer

what you see is often a CDN A/AAAA address, or a CNAME chain pointing to a CDN scheduling domain.

These records can help you determinewhether the traffic entry point is directed to a CDN, but they cannot prove where the origin server is. Even if you continue to query IP ownership and ASN, it only shows who operates that public entry point.

If you do not want to manually piece together the evidence, you can useCdnChart CDN Detectionto enter a domain and combine public signals such as CNAME, response headers, and IP/ASN to determine whether a website is behind a CDN.

Note: the identification result is an evidence-based assessment, not an “origin IP lookup.” For the specific logic, seeHow to Identify the CDN a Website Uses.

Does the CDN response IP equal the origin IP?

Usually not.

Browsers,curlor speed test platforms show “remote address,” “connection IP,” or “response IP,” which indicate the peer that the client established a connection with for this hop. When a website is behind a CDN, this peer is generally the CDN edge node.

Response headers alone also cannot prove the origin IP.ServerCache status, request ID, and other fields can provide clues, but response headers may be added, removed, or rewritten by the CDN.

To determine whether a CDN is in use, you should look at the DNS chain, IP ownership, response headers, and multi-region results together.

To observe which public entry points the same domain connects to from different regions, useCdnChart Website Speed Test. If different regions return different response IPs, this usually reflects CDN regional scheduling and does not mean the website has multiple “leaked origins.”

How should website owners verify their own origin server?

The methods below apply only to sites you own or are explicitly authorized to test. Verify the origin based on your own configuration, not by scanning other people's infrastructure.

Step 1: Check the CDN console and deployment configuration first

The most reliable source is not a public lookup tool, but your own:

• CDN accelerated domain configuration;

• cloud load balancer, object storage, or host console;

• DNS hosting records;

• Terraform, Ansible, or other deployment configurations;

• architecture documentation maintained by your team.

First confirm the origin type, origin domain or address, origin port, origin Host header, and HTTPS/SNI settings. All subsequent tests should be based on this configuration.

Step 2: Check where the user side connects

dig www.example.com A +noall +answer
dig www.example.com AAAA +noall +answer

curl -sS -D - -o /dev/null https://www.example.com/

digto view the current DNS answer;curlto view the status code and response headers returned by public access.

This step tests the normal user path, not the direct origin connection path.

Step 3: Perform targeted verification only against your own origin

If you have already confirmed your origin IP from the console, you can usecurlto temporarily connect the domain to that IP while keeping the hostname in the URL:

curl -sS -D - -o /dev/null \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/

In this example,203.0.113.10the IP is a documentation example address and cannot be used directly for real tests; replace it with your own origin IP.

--resolveSpecifying the address for “hostname + port” only for this request, rather than directly accessinghttps://IP/is more appropriate, because HTTPS certificate validation and virtual hosts still use the original domain. For exact semantics, see the official curl manual.

During testing, focus on comparing:

• whether the HTTP status codes match;

• whether the certificate, SNI, and origin Host header match;

• whether the page or API content is consistent;

• whether direct origin access works when requests on the CDN side fail;

• whether this test request appears in the origin logs.

Do not leave public access to the origin open long-term for “testing convenience.” After verification, restore the original access controls.

A failed direct origin connection is not necessarily a fault

If the origin only allows access from CDN egress, requires mutual TLS, uses a private network, or the object storage is only authorized for the CDN, then a 403, timeout, or handshake failure on an external direct connection may actually be the expected result.

In this case, do not jump to the conclusion that “the origin is down.” Check the time, Host, and request ID of the same request in the CDN logs, origin logs, and firewall logs.

Why are the origin logs full of CDN IPs?

Because from the network connection's perspective, it is the CDN origin fetch node that actually connects to the origin. The peer address recorded by the origin by default may naturally be the CDN egress IP, not the end visitor IP.

Most CDNs pass the original visitor address through trusted HTTP headers. For example, Cloudflare usesCF-Connecting-IPand providesofficial configuration documentation for restoring the visitor's real IP. Other providers may use different fields and configuration methods, so refer to their respective documentation.

There is a security prerequisite here that is easy to overlook:These headers can be trusted only when the request actually comes from a trusted CDN proxy.

If the origin allows anyone to connect directly, clients can forge common forwarding headers themselves, potentially misleading logs and rate-limiting rules. The correct approach is usually to:

1. allow only official CDN origin fetch addresses or controlled connections in the firewall or origin access policy;

2. configure trusted proxy ranges in the web server;

3. then restore the visitor IP from the request header specified by the provider;

4. and continuously sync the address ranges published by the provider rather than hardcoding a single edge IP.

How should common symptoms be assessed?

Can CDN node IPs be added directly to an allowlist?

Do not casually take an edge IP from a single DNS query and permanently add it to an allowlist.

The reason is simple: the edge addresses users access and the egress addresses the CDN uses to connect to the origin are not necessarily the same set; scheduling addresses may also change.

You should use the IP ranges officially published by the CDN provider for “origin fetch access,” dedicated origin fetch mechanisms, or private network connectivity.

Cloudflare'sIP address documentationalso emphasizes that its proxy addresses are shared by multiple domains, that origins receive Cloudflare addresses, and recommends configuring allow rules based on the official IP ranges while blocking unauthorized direct traffic.

Frequently Asked Questions

Can CDN detection tools find the real origin IP?

Legitimate CDN detection mainly answers “whether a CDN is used, which one it might be, and what the evidence is.”

If the proxy and origin protection are configured correctly, public queries can usually only see the CDN entry point and cannot reliably obtain a hidden origin address. Any result that claims to have found the real origin based on a single response IP should be carefully verified.

Are CDN node IPs dedicated?

Not necessarily.

Shared IPs are very common, and the same address can host multiple domains; some providers or products also offer dedicated, static, or bring-your-own-IP capabilities. Whether an IP is dedicated depends on the specific product configuration and cannot be determined by reverse DNS alone.

Can a website have multiple origins?

Yes.

A site can configure multiple origins by path, region, or business type, and can also set up primary and backup origins. There may also be load balancing in front of the origins, so “one domain corresponds to one fixed origin IP” is not a universal rule.

Why does the page differ when connecting directly to the origin versus through the CDN?

Common causes include the CDN cache not yet being refreshed, a different origin Host header, incorrect origin virtual host configuration, edge rules rewriting content, or the two paths hitting different release versions.

First compare the status codes, response headers, and content versions, then check the cache and origin configuration.

Finally, remember these three points

To understand CDN node IPs and origin IPs, you do not need to memorize many terms; just remember:

1. The response IP in DNS or speed test results usually indicates the current connection entry point and is not necessarily the real origin.

2. The origin is not necessarily a single server, nor does it necessarily have a fixed public IP.

3. To confirm your own origin, rely on the console and deployment configuration, then verify with logs and authorized testing.

If you want to first determine whether a domain is behind a CDN, useCdnChart CDN Detectionto view CNAME, response headers, and IP/network signals; if you want to compare the nodes actually connected to from different regions and the access latency, you can also useCdnChart Website Speed Test.

The platform's detection methodology and capability boundaries can be found on theCdnChart Methodologypage.