Why Is the Origin IP Still Visible When Using a CDN? A Guide to Origin Hiding and Bypass Prevention Checks

The domain is already using the CDN. When you rundigornslookupyou also see a CDN edge IP. However, the origin IP may still be found in historical DNS records, a subdomain, mail configuration, or a cloud platform address.

This is not a contradiction.

A CDN proxy lets normal visitors connect to CDN edge nodes instead of reaching the origin directly, but it does not automatically delete DNS records left from the past, nor does it protect subdomains, mail servers, admin panels, or other public entry points that are not behind the CDN.

More importantly, “can someone find the origin IP” and “can someone bypass the CDN to reach the origin” are two different questions.

A truly reliable origin protection standard should be:

Even if the origin address is known, public requests that are not forwarded or authenticated by the CDN still cannot retrieve business content, nor can they bypass the CDN’s WAF, rate limiting, and DDoS protection to directly consume origin resources.

Therefore, hiding the IP is only the first layer. Restricting access and verifying origin pull identity are the core of origin protection.

What normal DNS queries should show after a domain is on a CDN

For reverse-proxy CDNs, a public business domain usually points to a CNAME or edge address provided by the CDN:

www.example.com
        ↓
www.example.com.cdn-provider.example
        ↓
CDN边缘IP

Users connect to CDN edge nodes:

访客 → CDN边缘节点 → 源站

At this point, querying the business domain:

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

usually returns the CDN entry address, not the origin address.

But this only proves that the public DNS for the current business domain points to the CDN; it does not prove that the origin is not exposed through other paths.

For the difference between CDN edge IPs, origin IPs, and speed-test probe IPs, seeWhat is the difference between a CDN edge IP and an origin IP?.

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

Historical DNS records have already exposed the origin address

Before the website was placed behind a CDN, the business domain may have used A or AAAA records pointing directly to the origin:

www.example.com → 203.0.113.10

Later, it may have been changed to the CDN:

www.example.com → CDN CNAME

But the old records may already have been stored by passive DNS, asset search platforms, monitoring systems, or third-party databases. Deleting the current record does not make that historical data disappear automatically.

If the old IP still hosts the same website and allows direct public access, attackers may still bypass the CDN.

In this case, the most important thing is not to keep asking third parties to delete records, but to make the old address no longer able to serve the business directly:

• Restrict access sources in the origin firewall or security group;

• Enable authenticated origin pulls or mTLS;

• Change the origin public address if necessary;

• Confirm that the old address has stopped listening or no longer points to the business server.

Changing only the IP without adding access controls means the new address may still be exposed again later.

Some subdomains are not behind the CDN

The primary domain andwwwbeing on the CDN does not mean all subdomains are proxied.

Common oversights include:

origin.example.com
direct.example.com
api.example.com
admin.example.com
staging.example.com
download.example.com
mail.example.com

If even one subdomain resolves directly to the origin, it may expose the address.

You can check domains you manage:

dig www.example.com A +short
dig api.example.com A +short
dig admin.example.com A +short
dig mail.example.com A +short

If the origin also has IPv6 enabled, check AAAA records as well:

dig www.example.com AAAA +short
dig api.example.com AAAA +short

Many websites restrict only IPv4 but forget that the origin still has a publicly accessible IPv6 address. Even if attackers cannot connect directly over IPv4, they may bypass the CDN over IPv6.

It is not recommended to rely on guessing subdomain names to complete the check. A more reliable approach is to maintain a complete DNS asset inventory and confirm item by item which records should go through the CDN, which should be moved to dedicated services, and which should no longer exist.

Mail services and the website share the same IP

If the website and mail server are deployed on the same public IP, MX, SPF, or mail transport records may indirectly disclose the origin address.

Check MX and TXT records:

dig example.com MX +noall +answer
dig example.com TXT +noall +answer

Pay attention to:

• Whether the MX target ultimately resolves to the website origin IP;

• Whether the origin IP appears directly in SPF records;

• Whether mail headers expose the same public egress address as the website;

• mail.example.comWhether mail shares the same server as the web origin.

A more reliable approach is usually to move mail sending and receiving to a dedicated mail service or dedicated IP, so the web origin does not also serve as the public mail entry point.

Note that the egress IP seen in email is not necessarily the web origin entry IP. A direct association may exist only if the website and email use the same public NAT or the same server for outbound traffic.

The origin-specific domain uses public DNS

To let the CDN pull from origin, administrators may create:

origin.example.com → 203.0.113.10

If this domain can be resolved by public DNS, it directly exposes the origin address.

The origin domain does not necessarily need to be public to the entire internet. Depending on the architecture, consider:

• Using private origins supported by the CDN provider;

• Using internal DNS or a private hosted zone;

• Connecting through a dedicated line, tunnel, or private network;

• Keeping the public origin domain but allowing only the CDN at the network layer;

• Using a cloud load balancer domain and applying authentication and access restrictions to the entry point.

Making the origin domain very random only reduces the chance of accidental guessing; it cannot replace a firewall, mTLS, or a private network.

Public certificates expose the origin domain

If you request a public CA certificate fororigin.example.comthe certificate and the domain names in it may enter Certificate Transparency logs.

Certificate Transparency, defined in RFC 9162,uses auditable append-only logs to record issued TLS server certificates. Its goal is to detect mistaken or unauthorized certificate issuance, not to keep the domain names in certificates secret for a website.

Certificate Transparency logs usually do not directly show the origin IP, but if the origin domain in the certificate still publicly resolves to the origin, the two may be correlated.

Therefore:

• Do not treat “the domain does not appear on website pages” as a security measure;

• Do not configure unnecessary public DNS for private origin domains;

• You can use origin certificates or a private CA provided by the CDN provider, but you must confirm how the CDN trusts them;

• Even with private certificates, you must still restrict public access to the origin.

Cloud load balancer or managed platform entry points are still public

When using AWS ALB, cloud server load balancing, Kubernetes Ingress, or a managed application, the origin may not be a fixed IP but a public domain:

project.region.provider.example

Even if this address does not directly show the real server IP, as long as external users can use it to retrieve business content, a path to bypass the CDN still exists.

The goal of origin hiding is not necessarily to make all infrastructure have no public addresses, but to ensure that public entry points cannot directly serve the business without authorization.

Error pages, response headers, or application configuration leak addresses

Origin addresses may also appear in:

• Debug error pages;

• Application log downloads;

• HTML comments;

• JavaScript configuration files;

• API responses;

• Redirect addresses;

• LocationResponse headers;

• Email notification templates;

• Monitoring or status pages;

• WebSocket, upload, and download interface configurations.

For example, an error redirect returns:

Location: https://203.0.113.10/login

or:

Location: https://origin.example.com/login

both may expose the origin entry point.

When handling such issues, you should modify the application’s external URLs, proxy trust, and redirect configuration, rather than simply hiding error pages. A mismatch between the origin pull Host and the application domain can also produce incorrect redirects. For details, seeWhat happens if the origin pull HOST is set incorrectly? Troubleshoot 404s, certificates, and multiple sites one by one.

Is hiding DNS records enough?

No.

Origin protection can be divided into four layers:

Ordinary enterprise websites should at least implement layer three.

If users know the origin IP and can still open the website directly with the correct Host, then the CDN’s WAF, bot protection, access controls, and rate-limiting policies may all be bypassed.

How to confirm whether the origin can be bypassed

Do not access it directly in a browser:

https://203.0.113.10/

Such a test may use the wrong Host and TLS SNI. If the origin returns a certificate error or default 404, that does not prove the business domain cannot be bypassed.

When testing origins you manage or are authorized to test, preserve the correct domain:

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

--resolveHave curl connect to the specified IP while continuing to usewww.example.comcompleting TLS SNI, certificate validation, and HTTP Host sending more realistically simulates bypassing the CDN to connect directly to the origin.

Results can be interpreted as follows:

“Returns 403” is safer than directly returning business content, but it still means public requests have reached the origin. If the goal is to withstand high-volume attacks, returning 403 only at the application layer may not prevent bandwidth, connection count, and TLS compute resources from being consumed.

During testing, do not expose real origin IPs, private domains, authentication headers, or cookies in articles, ticket screenshots, or chat records.

How should the origin firewall restrict access?

For origins that still have public addresses, the most common practice is to allow access to ports 80 and 443 only from the CDN’s published origin-facing address ranges.

Logically, this can be expressed as:

允许：CDN回源地址 → 源站80/443
允许：受控运维网络 → 管理端口
拒绝：其他公网地址 → 源站业务端口

But during implementation, note:

• CDN origin-facing IP ranges may change;

• Health check addresses may differ from business origin-facing addresses;

• IPv4 and IPv6 must be configured separately;

• A multi-CDN architecture must allow the origin-facing ranges of all currently active providers;

• Do not open SSH, databases, or admin panels to the entire CDN address range;

• Retain controlled operations channels and a rollback plan;

• Confirm current request sources before making changes, so you do not block the CDN as well;

• It is best to automatically sync the provider’s official address ranges rather than maintain a static copy long term.

Cloudflare’sofficial origin protection documentationlists restricting origin connections, authenticating requests, and using outbound tunnels as protections of different strength. Cloudflare Tunnel, for example, has the origin initiate an outbound connection, so the origin does not need a publicly routable inbound address.

Different CDNs have different origin-facing addresses, product capabilities, and configuration methods. Always follow the current provider’s official documentation and do not directly copy another provider’s address ranges.

Is verifying a single secret request header enough?

The CDN can add a secret request header to origin requests:

X-Origin-Verify: 随机且保密的值

The origin processes only requests carrying the correct value and returns 403 to all others.

This method is relatively simple to deploy, but it should not be treated as the only line of defense:

• The origin is still exposed to the public internet;

• Large volumes of traffic can still reach the origin network;

• The secret value may leak through logs, debug information, or misconfiguration;

• Multiple proxy layers may remove or overwrite request headers;

• A rotation and revocation mechanism must be designed.

AWS’sofficial solution for restricting CloudFront access to an Application Load Balanceralso uses a custom origin request header, while explicitly warning that the header name and value must remain confidential, and recommending that you further restrict network sources with the CloudFront managed prefix list.

A more reliable approach is to combine:

网络来源限制
+ HTTPS回源
+ 秘密请求头或签名
+ 源站日志与告警

What mTLS authenticated origin pulls solve

Ordinary HTTPS only verifies the origin’s identity:

CDN验证：连接的是正确源站

mTLS, or mutual TLS, also requires the CDN to present a client certificate when pulling from origin:

源站验证：请求来自持有受信任客户端证书的一方

If the origin accepts only client certificates from the specified CDN or your own proxy, attackers cannot complete a trusted TLS connection even if they know the origin IP and business domain.

Cloudflare’sAuthenticated Origin Pulls official documentationexplains that this feature uses mTLS to help the origin confirm that origin pull requests come from the Cloudflare network, adding a layer of identity verification to ordinary HTTPS origin pulls.

When using mTLS, still note:

• Correctly validate the client certificate chain;

• Plan for certificate expiration and rotation;

• Do not merely check that “the client submitted a certificate”; validate the trusted issuer;

• A multi-CDN environment requires separate planning for certificates and trust relationships;

• Health checks and disaster recovery channels must also use compatible authentication;

• Certificate private keys must not be written to public code repositories or logs.

Private origins are more thorough than hiding public IPs

If the architecture allows, the origin can be closed to the public internet and connected to the CDN through:

• A CDN-to-cloud VPC private origin feature;

• An outbound tunnel initiated by the origin;

• A dedicated line or private network;

• A private load balancer;

• Private access controls for object storage;

• Origin access identities provided by the CDN provider.

AWS’sCloudFront VPC Origins documentationallows some load balancers or EC2 origins to be placed in private subnets, with service-managed security groups controlling access.

The advantage of this architecture is that the public internet cannot directly connect to the origin’s business ports, so it no longer depends on “the origin address has not been discovered.”

But private origins also increase operational complexity and require planning in advance for:

• A backup entry point when the CDN fails;

• Management and deployment channels;

• Health checks;

• Multi-CDN access;

• Logging and monitoring;

• Emergency rollback.

You must not temporarily expose the entire origin to the public internet during a failure just to hide the IP.

Does a default site returning 404 count as successful hiding?

No.

If connecting directly to the origin with the correct Host returns normal content, what the default site returns is meaningless. Attackers or testers can actively send the business domain as the Host.

Even if connecting directly with the correct Host also returns 404, that only means the application layer did not find content; it does not prove the origin network is unreachable.

Rejecting unknown Hosts at the default virtual host is still worth configuring because it can:

• Prevent other domains from being bound to the business site by mistake;

• Reduce default page leakage;

• Block some Host header abuse;

• Reduce the chance of an incorrect site being indexed by search engines.

But it is only an additional measure, not origin access control.

After the origin IP is exposed, should it be changed immediately?

You do not necessarily need to change the IP first.

If you can immediately block direct public connections through security groups, firewalls, a private network, or mTLS, attackers cannot normally bypass the CDN to retrieve content even if the old IP is public.

Consider changing the origin address in the following cases:

• The old IP is under continuous direct DDoS attack;

• The upstream network is already congested before traffic reaches the firewall;

• Reliable source restrictions cannot be implemented in the old environment;

• There are too many historical services and ports to confirm cleanup is complete;

• You are migrating to a private origin or a new cloud network;

• The old entry point needs to be fully retired.

The correct order is usually:

建立新源站或新入口
→ 配置网络限制和认证回源
→ 验证CDN回源正常
→ 切换CDN源站配置
→ 关闭旧源站业务端口
→ 再处理旧地址退役

If you change the IP first and consider protection later, the new IP may still be exposed again through DNS, logs, certificate domains, or application configuration.

After firewall restrictions, why still consider upstream DDoS?

A server’s local firewall can drop disallowed requests, but attack traffic may still traverse the data center or cloud provider’s public network links first.

If attack traffic has already saturated upstream bandwidth, normal CDN origin pull requests may fail to arrive even if the server ultimately drops packets.

Therefore, high-risk workloads also need to confirm:

• Whether the cloud provider or data center offers upstream scrubbing;

• Whether the origin’s public bandwidth will be directly saturated;

• Whether a private origin or tunnel can be used;

• Whether the old origin IP is still being advertised;

• Whether CDN origin pulls use an independent link;

• Whether the entry point can be changed or revoked during an attack;

• Whether multiple origins have isolation capability.

“The server firewall allows only CDN IPs” mainly addresses direct access and some application-layer bypasses; it does not automatically provide upstream high-volume protection.

How to validate after origin hiding is complete

You can check in the following order:

1. 公开业务域名只返回CDN入口
2. 所有A、AAAA、CNAME、MX和TXT记录完成审计
3. 未代理子域名不再指向Web源站
4. IPv4和IPv6都实施来源限制
5. 使用正确Host和SNI直连源站无法取得业务内容
6. 源站只接受CDN地址、mTLS或其他认证请求
7. 未知Host进入拒绝型默认站点
8. 管理端口不向CDN地址段或整个公网开放
9. 历史源站地址已经关闭或完成访问限制
10. CDN正常回源、健康检查和证书续期不受影响
11. 防火墙规则变更和认证失败都有监控
12. CDN故障时已有受控灾备方案

You can also use CdnChart’sCDN detection toolto confirm the business domain’s current CNAME, response IP, ASN, and CDN provider clues, and combine it withCDN node lookup methodsto inspect public entry points seen from different regions.

However, external CDN detection can only observe the current public path; it cannot prove that the origin firewall, mTLS, or private network is correctly configured. That part must be validated through your own origin tests, logs, and cloud security group configuration.

FAQ

If the origin IP can still be found after using a CDN, does that mean the CDN is not working?

Not necessarily. The business domain may already be correctly going through the CDN, but the origin address is exposed through historical DNS, an unproxied subdomain, mail records, or a cloud platform entry point. Check the current access path and origin bypass-prevention configuration separately.

If the origin IP is leaked, are CDN caching and acceleration still effective?

When normal users access through the CDN, caching and acceleration may still be effective. The risk is that others can bypass the CDN and access the origin directly, rendering WAF, rate limiting, bot protection, and DDoS protection ineffective.

Is changing the origin domain to a random string enough for security?

No. A random domain only reduces the chance of being guessed; it cannot prevent historical records, certificate logs, configuration leaks, or network scanning. Even if the address is known, the origin should reject unauthenticated public requests.

If the origin returns 403, does that count as successful hiding?

It means the application layer may have blocked access, but the origin network is still reachable. This helps against ordinary bypasses but provides limited protection against bandwidth consumption and connection attacks. A more reliable solution is to add network source restrictions or mTLS.

After allowing only CDN IPs, are secret request headers still needed?

It is recommended to keep them for defense in depth. IP restrictions address the source range, while secret request headers or mTLS further verify origin pull identity. Multiple layers reduce the risk from a single configuration mistake.

Why can’t I just access the origin IP over HTTPS to test?

HTTPS requires the correct TLS SNI and HTTP Host. Directly accessing the IP may result in a certificate error or default site and cannot simulate real business traffic. In an authorized environment, usecurl --resolvewhile preserving the correct domain.

After origin hiding, can a direct-access disaster recovery entry point still be kept?

Yes, but you should not treat a fully public, long-term available direct domain as disaster recovery. A more reasonable approach is to use a backup CDN, controlled VPN, identity-authenticated gateway, or a temporary emergency entry point enabled with strict authorization.

How should a multi-CDN architecture restrict origin access?

You need to allow all currently used CDN origin-facing networks and, where possible, configure separate mTLS certificates, signatures, or secret request headers for different CDNs. Before switching, also confirm that the backup CDN can pass the origin firewall and authentication rules; otherwise DNS switching may succeed but origin pulls will still fail.