Why Is the Origin IP Still Exposed When Using a CDN? How Far Should Origin IP Hiding Go?

The website is already behind a CDN and DNS lookups return CDN nodes. Why can a suspected origin IP still be found in historical DNS records, a subdomain, or server records?

The reason is that using a CDN and protecting the origin server are not the same thing.

Once CDN proxying is active, normal users visiting the primary domain connect to CDN edge nodes first. Current DNS no longer returns the origin address directly, but a CDN does not automatically clean up past DNS records, nor does it close unproxied subdomains, mail services, management ports, or public origin entry points for you.

Truly reliable origin protection should not focus only on preventing others from discovering the IP; it should ensure that:

Even if the origin IP is known, unauthorized requests still cannot bypass the CDN to access the business.

That is the final standard origin hiding should meet.

First, confirm whether what you are seeing is actually the origin IP

Many apparent “origin IP leaks” are simply CDN node IPs mistaken for the origin.

With a reverse-proxy CDN in place, a normal request typically goes through:

用户 → CDN边缘节点 → 源站或源站负载均衡

Browser,curlPing tools, or website speed test platforms, usually show only the remote IP of the peer the client is currently connected to. If the domain is correctly proxied, this address normally belongs to the CDN edge network, not the origin.

You can first check:

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

Then check the actual connection address:

curl -sS -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_code=%{http_code}\n' \
  https://www.example.com/

If the response IP belongs to a CDN provider or its partner network, it only means the current request reached the CDN entry point; it does not mean the origin is exposed.

For the differences between these address types, seeWhat is the difference between a CDN node IP and an origin IP?.

The situation that truly warrants attention is a suspected IP that, with the correct hostname and TLS SNI, can bypass the CDN and return normal website content directly.

Why the origin IP can still be exposed after using a CDN

Reason 1: Historical DNS records already contain the old IP

Before the website used a CDN, the domain usually resolved directly to the origin. Even if it now points to a CDN CNAME or Anycast address, past DNS answers may still appear in:

• Historical DNS databases;

• Search engine caches;

• Operations documentation and code repositories;

• Monitoring platform records;

• Third-party asset management platforms;

• Old screenshots or incident reports;

• Short-term caches in local and recursive DNS.

A CDN can change only current DNS results; it cannot delete historical records already stored across the internet.

If the same origin IP was used before and after CDN adoption, the old address may have been recorded for a long time even if it no longer appears in current DNS.

Reason 2: A subdomain does not go through the CDN

Putting the primary domain behind a CDN does not mean all subdomains are automatically protected.

Common bypass entry points include:

origin.example.com
direct.example.com
api.example.com
admin.example.com
test.example.com
dev.example.com
old.example.com
upload.example.com

For example:

www.example.com → CDN
api.example.com → 源站IP
admin.example.com → 源站IP

If these domains share the same server IP as the website, the origin can be linked.

The easiest things to miss are not official business domains but test records created years ago, temporary origin-facing domains, and old records that are no longer used but were never deleted.

Cloudflare'sorigin protection documentationalso recommends checking unproxied DNS records, including origin addresses that may appear in TXT, SPF, and other records.

Reason 3: Mail services share the same IP as the website

Mail systems usually cannot sit behind an HTTP CDN the way ordinary web pages do.

If the following services share an IP with the website origin, the address may be exposed through mail-related records:

• MX records;

• mail.example.com;

• SMTP servers;

• in SPF recordsip4orip6;

• Email headers;

• Webmail;

• Bounce or tracking services.

For example:

example.com.      MX 10 mail.example.com.
mail.example.com. A  203.0.113.10

If203.0.113.10is also the website origin address, then even ifwww.example.comis already behind a CDN, the mail records still expose the same server.

A safer approach is to use a different IP for mail services and the web origin, or use a separate email provider. Do not put mail, website, database administration, and remote login all on the same public address.

Reason 4: Certificate records expose origin hostnames

Certificate Transparency logs publicly record issuance information for trusted certificates, which may include the domains covered by the certificate.

Certificate Transparency itself usually does not directly tell a querier what the origin IP is, but it may reveal previously unknown subdomains, such as:

origin.example.com
backend.example.com
server01.example.com
direct.example.com

If these hostnames still resolve to the origin's public IP, they form an exposure chain:

证书透明度记录
→ 发现源站子域名
→ 查询当前或历史DNS
→ 找到源站IP

The official Certificate Transparency website explains that CT logs are publicly queryable, append-only certificate records that show which certificate authorities issued certificates for which domains and when.

Therefore, certificate asset audits should not look only at the primary domain; they should also check every subdomain that has appeared in historical certificates.

Note, however, that hiding certificate names is not the core defense. Even if the origin domain is discovered, the origin should deny unauthorized access through firewalls, mTLS, or private connections.

Reason 5: The origin allows direct access from any public address

This is the most critical issue.

Many websites change only DNS after adopting a CDN, without adjusting cloud security groups, host firewalls, or web server access policies. As a result, there are two request paths:

正常路径：用户 → CDN → 源站
旁路路径：用户 → 源站IP

Once attackers find the origin address, they can bypass the CDN's:

• DDoS scrubbing;

• WAF rules;

• Bot management;

• Rate limiting;

• Geographic restrictions;

• Authentication;

• Caching and traffic surge mitigation.

Cloudflare's official guidance explicitly recommends allowing only Cloudflare's official addresses and trusted partners to access the origin and blocking all other public sources. If the origin IP is discovered through historical DNS or mail configuration, an unrestricted public entry point lets requests bypass Cloudflare directly.

Changing only DNS without restricting the origin entry point is merely “directing normal users to the CDN,” not “completing origin protection.”

Reason 6: The origin still exposes other public services

Even if ports 80 and 443 are restricted, other public services may still expose the same IP:

• SSH;

• RDP;

• FTP;

• Database ports;

• Redis;

• Elasticsearch;

• Operations panels;

• Kubernetes management interfaces;

• Monitoring systems;

• Development and testing services;

• Object storage management endpoints.

These services may appear in asset mapping, logs, error pages, or public configurations.

Origin concealment cannot rely only on checking website ports. Confirm at the cloud account, security group, load balancer, host listening port, and management network levels which services truly need public internet access.

Management ports are better exposed through VPN, bastion hosts, zero-trust access, or a dedicated management network rather than sharing the website's internet-facing entry point.

Why “the origin IP cannot be found” is not the final goal

Basing origin security entirely on IP secrecy is essentially “relying on a secret remaining undiscovered.”

That secret may leak again due to any of the following changes:

• A DNS record is added;

• Operations staff create a temporary test domain;

• Mail services are moved back to the origin;

• A certificate adds an origin hostname;

• An application initiates connections to external services;

• Logs or error pages reveal internal information;

• There is a brief direct connection during a CDN switch;

• The cloud platform assigns a new public entry point;

• Firewall rules are modified by mistake.

Origin protection should therefore follow a two-layer approach:

1. Minimize opportunities for the origin address to appear in public information;

2. Assume the IP may eventually become known and restrict it to accept only trusted CDN requests.

The second layer is more important than the first.

How far should origin concealment go?

Origin protection can be divided into five levels.

For a typical website, at least L3 should be achieved.

For high-defense CDN, finance, gaming, APIs, login systems, and services prone to DDoS attacks, L4 is recommended, along with L5 continuous checking.

Step 1: Put all external business domains truly behind the CDN

Start by compiling a complete domain list instead of checking onlywww.

At minimum, include:

• Apex domain;

• www;

• API;

• Images;
  Static assets;

• Downloads;
  Uploads;

• WebSocket;

• Login and payment;

• Admin console;

• Legacy domains;

• Test domains;

• IPv4 and IPv6 records.

For records that should be proxied, confirm they are actually in proxied status, not merely using DNS hosting provided by the CDN.

Use CdnChart's CDN check to view CNAME, response IP, ASN, and response header evidence, then combine it withIs CDN acceleration actually working? Check it this way after setupConfirm that actual business requests go through the CDN.

Keep in mind:

• Using a CDN provider's DNS service does not mean traffic necessarily passes through the CDN;

• A domain appearing in the CDN console does not mean the configuration is active;

• Static assets going through the CDN does not mean APIs and dynamic pages also do;

• IPv4 going through the CDN does not mean IPv6 is also configured correctly.

Step 2: Clean up public records that may link to the origin

Audit starting from the assets you manage:

1. Export current DNS zone records;

2. List all A, AAAA, CNAME, MX, and TXT records;

3. Check unproxied subdomains;

4. Check IP addresses in SPF;

5. Check subdomains in historical certificates;

6. Check code, deployment files, and public documentation;

7. Check old load balancers and old servers;

8. Check whether mail, FTP, and management services share an IP with the origin;

9. Check whether old origin addresses still return business content.

If an origin IP has been public for a long time, deleting DNS records alone will not make all historical records disappear.

A safer sequence is:

1. First complete the new origin access restrictions;

2. Confirm that CDN origin fetches are working normally;

3. Then replace the exposed origin public IP;

4. Shut down the old address;

5. Verify the old address no longer returns business content;

6. Continue monitoring for new exposure records.

Do not replace the IP before setting up the firewall. If exposure paths are not cleaned up, the new IP will soon reappear.

Step 3: Allow only CDN origin fetches at the network layer

This is the most important step in origin protection.

Access controls can be configured at the following locations:

• Cloud security groups;

• Network ACLs;
  Hardware or cloud firewalls;

• Host firewalls;

• Load balancer access rules;

• Kubernetes ingress policies;

• Web server access controls.

The basic policy is usually:

允许：CDN官方回源地址段
允许：可信运维与监控网络
允许：必要的内部服务
拒绝：其他公网来源访问业务端口

Do not take a few CDN edge IPs from a single DNS query and add them to an allowlist.

The edge IPs users connect to are not necessarily the same as the egress IPs a CDN uses to access the origin. Use the provider's officially published origin fetch ranges, a dedicated origin fetch network, or an official automatic synchronization mechanism.

Also note:

• CDN address ranges may change;

• Handle IPv4 and IPv6 separately;

• With multiple CDNs, allow all providers currently in use;

• External monitoring, payment callbacks, and partners must be listed separately;

• Before deleting rules, confirm they will not interrupt origin fetches;

• After changes, check website availability from multiple regions.

Step 4: Do not rely on IP allowlists alone

IP allowlists are important, but not every environment is suited to relying on them alone.

For example:

• CDN origin fetch ranges are large;

• Multiple customers share an origin fetch network;

• An enterprise uses multiple CDNs;

• Cloud platform entry IPs change dynamically;

• Internal services need stronger request identity verification.

In these cases, add origin authentication.

Method 1: Mutual TLS (mTLS)

In ordinary HTTPS, the client mainly validates the server certificate. mTLS also requires the CDN to present a client certificate when connecting to the origin, so the origin can verify that the request truly comes from a trusted CDN.

Cloudflare's Authenticated Origin Pulls is one form of mTLS origin authentication. Its official documentation states that this feature ensures requests reaching the origin come from Cloudflare's network.

Note that different levels of mTLS configuration may prove different scopes:

• A shared client certificate may prove only that the request comes from that CDN network;

• Account-, domain-, or customer-specific certificates can provide stronger isolation;

• The origin must correctly validate the client certificate, not merely require “any certificate”;

• Certificate expiration, rotation, and revocation must be included in operations processes.

Method 2: Custom origin secret header

The CDN adds a random secret header when fetching from the origin, and the origin responds only to requests containing the correct value, for example:

X-Origin-Verify: 长随机值

Amazon CloudFront's official documentation explains that you can add a custom header to origin requests and make the origin accept only requests containing that header, reducing the chance of users bypassing CloudFront to access the origin directly.

This method is simple to deploy, but note:

• The secret must be sufficiently random;

• Origin fetches must use HTTPS;

• Do not output it in public code or logs;

• Rotate it regularly;

• The origin must not echo it in error pages;

• Use it together with firewall rules where possible.

A custom header is a supplementary authentication measure and should not be treated as a complete replacement for network access control.

Method 3: Private connection or reverse tunnel

A stricter architecture can leave the origin with no public web entry point at all.

Common forms include:

• A private connection from the CDN to a cloud VPC;

• A dedicated origin fetch link;

• A reverse tunnel;

• The origin initiates outbound connections;

• A private load balancer;

• Origin Access Control for object storage;

• A service mesh or private network entry point.

With Cloudflare Tunnel, for example, the origin connects to Cloudflare through an outbound tunnel it initiates, with no need to open public inbound ports.

If business conditions allow, “the origin has no public web port” is usually closer to true origin concealment than “it has a public IP but we hope no one finds it.”

Step 5: Correctly handle real visitor IPs

After restricting origin access to the CDN, the network peer in origin logs usually becomes a CDN origin fetch node rather than the end visitor.

You can then use trusted request headers provided by the vendor to recover visitor IPs; different vendors may use, for example:

CF-Connecting-IP
True-Client-IP
X-Forwarded-For

However, these headers cannot be trusted unconditionally.

If the origin still allows direct public access, clients can forgeX-Forwarded-For. The correct order should be:

1. First restrict origin access to trusted CDNs only;

2. Configure trusted proxy address ranges in the web server;

3. Accept only real IP fields written by trusted proxies;

4. Then use the recovered addresses for logging, rate limiting, and risk control.

Otherwise, even if origin protection is half complete, logs and security policies may be misled by forged requests.

How to verify that the origin really cannot be reached bypassing the CDN

The following operations should be performed only on servers you manage or are explicitly authorized to test.

Check 1: Confirm the normal domain goes through the CDN

curl -sS -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nstatus=%{http_code}\n' \
  https://www.example.com/

The remote IP in the result should be a CDN entry point, not a known origin address.

Check 2: Test the origin with the correct hostname and SNI

Do not simply run:

curl https://203.0.113.10/

Accessing the IP directly may return the default site because the Host and TLS SNI do not match, which does not accurately test whether the real business can be reached directly.

Use:

curl -I \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/

Here,203.0.113.10is a documentation example address; replace it during testing with an origin IP you know and are authorized to verify.

This command will:

• Connect to the specified origin IP;

• Preservewww.example.comas the Host;

• Use the correct TLS SNI;

• More closely approximate a real request that bypasses the CDN.

What results count as a pass?

When testing from an external network not on the origin allowlist, reasonable results include:

• Connection timeout;

• Connection refused;

• HTTP 403;

• A dedicated denial page;

• TLS client certificate validation failure;

• A default response that does not contain real business content.

The following results usually mean the CDN can still be bypassed:

• HTTP 200 and the normal homepage;

• Login or API calls work normally;

• Both static and dynamic content are fully available;

• Reliance only on an easily forged Host check;

• The origin's public entry point can still serve the business directly after the CDN is disabled.

Do not test only the homepage. Also check:

• APIs;

• Login;

• Uploads;

• WebSocket;

• Dynamic pages;

• IPv4 and IPv6;

• HTTP and HTTPS;

• Alternate ports;

• Primary and standby origins.

Check 3: Review origin logs

After restrictions are in place, request sources on origin business ports should mainly include:

• The CDN's official origin fetch network;

• Internal load balancers;

• Authorized monitoring systems;

• Partners explicitly included in the allowlist;

• Controlled operations networks.

If many unknown public IPs still access the origin directly, check for missing ports, IPv6 rules, or alternate entry points.

The most easily missed IPv6 issue

Many origins restrict only IPv4 and forget IPv6.

Possible cases include:

www.example.com 的IPv4 → CDN
www.example.com 的IPv6 → 源站

It is also possible that the primary domain has no origin AAAA record, but the server itself has a public IPv6 address and is discovered through a subdomain or other asset.

During audits, check both:

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

Cloud security groups and host firewalls also need separate IPv4 and IPv6 rule checks. Applying “allow only CDN origin fetches” to IPv4 alone does not complete origin protection.

How to protect the origin when using multiple CDNs

In a multi-CDN environment, the origin must accept origin fetch requests from multiple providers, making access control more complex.

You need to handle:

• Origin fetch IP ranges for multiple CDNs;

• Automatic updates of address ranges;

• Independent origin authentication for each CDN;

• Different real visitor IP headers;

• Rule consistency during primary/standby failover;

• Health check sources;

• Temporary scaling or failback;

• Rule cleanup after exiting a CDN provider.

Use separate authentication credentials for each CDN; do not have all providers share one permanent key. Then if one provider is discontinued, its credentials can be revoked independently without affecting other paths.

Also keep a controlled emergency access method, but do not leave the origin open to the entire public internet long-term for the sake of “convenient direct access during failures.”

Origin concealment acceptance checklist

Before launch, confirm each item:

• Primary domain,wwwAPI, image, and static asset domains all go through the CDN as designed;

• No A, AAAA, or CNAME records unexpectedly point directly to the origin;

• Unproxied subdomains and legacy test domains have been checked;

• Mail services do not share a public IP with the web origin;

• SPF, MX, and TXT records do not unintentionally expose the origin address;

• Domain assets appearing in historical certificates have been checked;

• Whether historical DNS ever recorded the current origin IP has been assessed;

• The origin firewall allows only the CDN and trusted networks;

• IPv4 and IPv6 rules are both configured;

• Management ports are not directly exposed to the entire public internet;

• The origin uses HTTPS for origin fetches;

• mTLS, a dedicated origin fetch header, or a private connection is configured;

• Real visitor IPs are recovered only from trusted proxy headers;

• External networks usingcurl --resolvecannot directly obtain normal business content;

• Old origin IPs are disabled or no longer return business content;

• There are update mechanisms for CDN address ranges, certificates, and origin fetch secrets;

• Configuration changes and abnormal direct requests have logging and alerts.

If only the first two checks are complete, CDN proxying may be active, but origin protection is still incomplete.

What level counts as true origin concealment?

It is difficult to promise in absolute terms that “no one can ever know the origin IP,” especially when the origin still has a public address and open ports.

A more realistic and safer acceptance standard is:

1. Normal DNS shows only CDN entry points;

2. Public subdomains, mail, and certificate assets are no longer directly linked to the origin;

3. Management and business entry points are isolated from each other;

4. The origin accepts only CDN or trusted network connections;

5. Origin fetch requests have additional authentication;

6. Even if the IP is known, normal business cannot be accessed bypassing the CDN;

7. IPv4, IPv6, primary and standby origins, and alternate ports all follow the same protection principles;

8. New DNS records, certificates, and servers are checked as they are added.

This is especially important for high-defense CDN. If attack traffic can bypass scrubbing nodes and reach the origin directly, even a high nominal mitigation capacity cannot protect a bypass entry point. When choosing a high-defense service, also considerHow to choose a high-defense CDN: protection capability, nodes, and testing methodsCheck whether the provider offers origin fetch IP allowlists, mTLS, private network origin fetches, and origin protection guidance.

Whether origin concealment is adequate is not ultimately judged by “whether a lookup tool can find an IP,” but by whether that IP can directly access the business even after it is found.

FAQ

1. After using a CDN, can DNS still reveal the origin IP?

With normal proxy configuration, the primary business domain usually returns CDN node IPs or a CDN scheduling domain. However, unproxied subdomains, mail records, historical DNS, and misconfigurations can still expose the origin.

2. Does changing the origin IP solve the leak?

It only solves the exposure of the current address. If unproxied subdomains, shared mail IPs, or open firewall rules are not addressed, the new IP may be exposed again.

3. Is allowing only CDN IPs to access the origin enough?

This is the most important baseline measure, but high-security services should also add mTLS, a dedicated origin fetch header, private connections or tunnels, and establish CDN address range updates and abnormal access monitoring.

4. Why does accessing the origin IP directly fail, but work with the Host header set?

The web server may select a virtual host based on Host. Accessing the IP directly reaches only the default site; preserving the correct Host and TLS SNI is required to hit the real business. Therefore, verification should usecurl --resolve.

5. Does using an HTTPS certificate on the origin expose the IP?

Certificate Transparency logs usually expose the domains in certificates rather than the origin IP directly. However, origin subdomains in those certificates may resolve to public addresses, so certificate asset audits are still necessary.

6. Why do mail servers expose the website origin?

If mail and the website share the same IP, MX records, mail subdomains, SPF records, or email headers may all expose that address. It is best to deploy the mail system separately from the web origin.

7. If the origin has no public IP, is a firewall still needed?

Yes. Private network security groups, tunnel authentication, internal access control, and least-privilege policies remain important. Having no public IP reduces the public attack surface, but it does not mean internal access can be fully opened up.

8. Can CdnChart directly look up the real origin IP?

CdnChart's CDN check is mainly used to see whether a domain goes through a CDN, which CDN provider it may use, and public evidence such as CNAME, response IP, ASN, and response headers. It is not a tool for bypassing the CDN to find the real origin; when the origin is configured correctly, public checks usually see only the CDN entry point.