The new IP address is live and the primary domain points to a DDoS-protected CDN. Two questions remain: Is the new address exposed elsewhere, and does the origin still accept direct requests from outside networks?

To prevent the origin IP address from being exposed again, clean up DNS and application settings, restrict which sources can connect to the origin, check IPv6 and services that bypass the CDN, and test direct connections that retain the domain name.

Changing the IP address addresses the fact that the old one was known. These other settings determine whether the new address becomes a usable attack path.

Keep evidence of two separate outcomes: public configuration no longer reveals the new address, and unauthorized requests cannot reach the application by bypassing the CDN.

Has the new IP address appeared in public configuration?

After changing the IP address, start with the inventory of assets your team maintains.

The primary domain may be behind the CDN while an upload API points straight to the new origin. Production may be updated while a test domain still shares the same server. These omissions can expose the new address without any sophisticated probing.

Cloudflare's origin protection guide also calls out DNS-only records, email infrastructure, and historical DNS records. These areas are worth checking even if you use another CDN.

Start with the full DNS inventory, not just the homepage

Export or review all records in your DNS management console. Check subdomains, wildcard records, geographic routing, and failover settings, then verify the actual answers with external queries.

The following commands require dig on Linux, macOS, or Windows Subsystem for Linux (WSL). As described in BIND's dig documentation , query A records for IPv4 and AAAA records for IPv6:

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

Replace the example domains with your own assets, then check upload, download, administration, test, and backup hostnames.

Look for the new origin address or a hostname that still resolves to the origin. An A record alone does not mean the domain bypasses the CDN; a CDN entry point can also be returned in an A or AAAA record.

No output does not prove there is no risk, either. These options display only the answer section. If it is empty, remove +noall +answer to inspect the query status, then compare with your DNS console, authoritative DNS answers, and results from other networks.

If you use both IPv4 and IPv6, consult how an IPv6 origin connects to IPv4 clients when checking the client-facing entry point and the CDN-to-origin path. Clients reaching the CDN over IPv6 do not need to see the origin's IPv6 address.

Renaming the origin hostname can still leave the address exposed

For ease of administration, some teams create a long, random hostname for the new origin and enter it in the CDN dashboard.

If that hostname resolves to the origin in public DNS, it remains publicly discoverable. A name that is hard to guess may reduce accidental discovery, but it is not access authentication.

If the provider allows you to configure the origin IP address directly, you need not create another public DNS record for origin fetches. If an origin hostname is required, protect the application with source restrictions and origin authentication rather than relying on the name being secret.

Do not temporarily point the production domain directly to the origin just to test the new address. A temporary DNS answer may be cached or recorded; restoring the CDN later cannot retract information that has already been published.

Check the address used for outbound connections from the origin

When your site sends email or application callbacks or downloads external resources, the other party may see the server's outbound IP address.

That address may be the same as the origin's public entry address, or it may belong to a separate egress path, NAT gateway, or proxy. Verify your actual network design. An IP address seen on an outbound connection is not, by itself, proof that it is the website's origin.

For an application that needs to protect its public entry address, consider whether email or outbound traffic should use a separate service or egress path. Even with separate egress, keep inbound origin restrictions in place.

Where should you enforce CDN-only access to the origin?

After cleaning up DNS, tighten access to the origin's application ports.

Requests forwarded through your intended CDN configuration should still reach the origin, while unnecessary direct connections should be denied. Two common mistakes are allowing the wrong address ranges and applying rules at a point the traffic does not traverse.

Use official origin egress ranges, not edge IPs found in a speed test

The address a user connects to at the CDN may differ from the address the CDN uses to connect to the origin.

Build the origin allowlist from the provider's official origin egress ranges or dedicated egress details. Confirm:

• Whether IPv4 and IPv6 each have applicable ranges.
• Whether health checks come from different source addresses.
• Whether egress ranges change when edge locations are added or network routes change.
• Whether a multi-CDN setup, load balancer, or required partner system has a separate entry point.

Do not allow only the handful of addresses observed during one test. Nor should you allow broad, unrelated ranges from an entire cloud provider for convenience.

Before changing rules, retain a trusted administration path and a recovery method. Confirm that the allow rules permit normal origin requests, then deny other sources incrementally. Test login, uploads, API calls, and health checks, not just the homepage.

Apply access restrictions along the actual traffic path

If a load balancer sits in front of the origin, the host may see the load balancer as its connection source rather than the CDN's egress address. Enforce restrictions at a suitable point that can identify the true connection source, and continue to secure the backend path.

The “client IP” shown in application logs is not necessarily the network peer address.

NGINX's Real IP module documentation explains how to recover a client address from headers supplied by a trusted proxy. If you enable this, distinguish the reconstructed visitor IP address from the original connection source. Do not compare the visitor address with the CDN's origin allowlist.

X-Forwarded-For and similar request headers cannot establish a trusted source on their own. Applications should rely on these fields only when the request comes from a verified trusted proxy that handles them correctly.

Check Docker-published ports and IPv6 rules separately

With container deployments, a host firewall rule denying a port may not be the final word.

Docker's firewall and port-publishing documentation explains that, under certain Linux network configurations, published container ports pass through Docker-created forwarding rules and may be redirected before traffic reaches the point where ufw is expected to process it.

Review container port mappings, cloud security rules, and the host's actual packet-filtering path together. An application port still published directly to the internet can bypass the website's reverse proxy.

The same applies to IPv6. Effective IPv4 rules do not mean IPv6 has the same restrictions. Keep only the listeners and access ranges your application needs, and remove unnecessary public entry points.

Why add origin authentication if CDN IP ranges are already allowlisted?

Allowlisting a CDN provider's shared origin egress ranges generally limits which networks can send requests. It does not necessarily prove that a request passed through your own site configuration.

On a shared platform with the relevant forwarding capabilities, requests from other accounts may use those same egress ranges. If your application requires tighter isolation, confirm whether the service supports origin authentication tied to your site.

One option is mutual TLS (mTLS): the CDN verifies the origin server's certificate, and the origin verifies a client certificate presented by the CDN. The connection is encrypted, and the origin can also authenticate the connecting party.

Cloudflare's Authenticated Origin Pulls documentation distinguishes shared certificates from custom certificates: its global shared certificate proves only that a request came from the Cloudflare network. More precise validation of your account or hostname requires the appropriate custom configuration. Check each provider's validation scope, setup process, and plan requirements separately.

If your setup uses a secret origin request header, several conditions still matter: send it over HTTPS, have the trusted CDN configuration set or overwrite the header, validate it at the origin before serving application content, and keep the credential out of public logs, frontend code, and responses.

A fixed secret can be replayed if exposed. Use it as an additional control, not a substitute for network restrictions at the origin.

Two other configurations are easy to confuse with origin authentication:

Installing an HTTPS certificate on the origin does not mean the origin authenticates the CDN.

Restricting access by Host header does not establish where a request came from.

Your public hostname is usually known. Someone with the IP address can send the same hostname in a request. A default site that returns no content addresses only some accidental access.

How can you verify that external traffic cannot bypass the CDN?

A failed attempt to open https://源站IP in a browser may only mean that the certificate name does not match or that the request reached the wrong virtual host. It does not prove that the origin blocks direct access.

A more useful test connects to a specific origin IP while retaining the application's hostname.

Run these tests only against servers you manage or are authorized to test. Use an external network that is not allowlisted, rather than an authorized operations network.

First, confirm that the normal entry point reaches the origin

These examples work on Linux, macOS, or Windows Subsystem for Linux (WSL) with curl installed:

curl -q --noproxy '*' -sS -D - -o /dev/null \
  --connect-timeout 5 --max-time 15 \
  -w '\nhttp=%{http_code} peer=%{remote_ip}\n' \
  'https://example.com/'

The root path is used for illustration. For acceptance testing, use a known, read-only test path that you have explicitly configured to bypass the CDN cache, and check the new origin's logs.

A cached CDN response shows that the edge can still serve content; it does not prove the new origin is working. Adding an arbitrary query parameter to the URL may not bypass the cache either. Check the actual cache rules and logs.

Then connect directly to the new origin while retaining the hostname

If the new origin IPv4 address is 203.0.113.10, test it like this:

curl -q --noproxy '*' -sS -D - -o /dev/null \
  --connect-timeout 5 --max-time 15 \
  --resolve 'example.com:443:203.0.113.10' \
  -w '\nhttp=%{http_code} peer=%{remote_ip}\n' \
  'https://example.com/'

If the origin also has a public IPv6 address, test from a network with working IPv6 connectivity:

curl -q --noproxy '*' -sS -D - -o /dev/null \
  --connect-timeout 5 --max-time 15 \
  --resolve 'example.com:443:[2001:db8::10]' \
  -w '\nhttp=%{http_code} peer=%{remote_ip}\n' \
  'https://example.com/'

The IP addresses above are documentation examples. Replace them when running the tests.

As explained in curl's --resolve documentation , this option supplies a connection address for the specified hostname and port. The URL still uses your application hostname, which curl also uses for the HTTP Host header and the SNI hostname in the HTTPS handshake. This more closely resembles a request to the actual site.

-q disables curl's default configuration file, and --noproxy '*' disables the effect of curl proxy settings. It does not change a system VPN or network route. peer shows the peer IP for this connection, and http shows the HTTP status code received.

The commands display response headers by default. To check whether the response contains actual application content, remove -o /dev/null.

If the CDN rewrites the Host header or SNI hostname for origin requests, also test the name used for those requests. Testing only the public hostname is insufficient.

What do the test results tell you?

http=000 means no HTTP status code was received. It is not a status code called "000" returned by the server.

If the origin uses a private CA or an origin-only certificate, configure the correct trust chain in a controlled test, for example with an appropriate --cacert file, before assessing access controls. A client that does not trust the server certificate is different from a server that requires the client to present an authentication certificate.

Compare external requests against CDN records and origin logs when validating the setup. One timeout, a single 403, or a test screenshot cannot cover every entry point.

How should you retire the old IP, temporary allowlists, and rollback paths?

Even after the new origin works, the old environment can still affect security.

One common leftover is a reverse proxy on the old IP that continues forwarding to the new origin so older clients have more time to migrate. It may not reveal the new IP, but it can still forward malicious requests from the old entry point to the new origin.

If the old address redirects to a URL containing the new IP or directly reveals the new origin hostname, it creates another clear disclosure path.

Before retiring it, check whether clients, scheduled jobs, payment callbacks, uploads, or other integrations still use the old address. Put entry points that must remain during migration behind the required protection and authentication, with a defined retirement condition. Once dependencies have moved, disable forwarding and listeners that are no longer needed.

Prepare a rollback plan in advance, too.

If a CDN configuration causes problems, roll back to a validated configuration or switch to a protected standby origin. Do not make a temporary public DNS record pointing at the new origin your default rollback plan; a single incident response could expose the address again.

Record the purpose and expiration of temporarily allowlisted office IPs, test hosts, and third-party monitors. When adding new CDN origin egress ranges, verify the source and configuration before updating the allowlist. A failed update must not automatically open access to everyone.

After each deployment, recheck three places: DNS records, public ports on containers or load balancers, and fallback addresses sent to clients. Routine changes can easily reintroduce an exposed entry point.

What protection does the origin need if its IP becomes known?

Even after all these checks, you should not promise that a public origin IP can never be discovered.

Source restrictions and origin authentication reduce application requests that bypass the CDN. But if attack traffic saturates the origin's upstream link, dropping it at the server will not restore the consumed bandwidth. Assess separately where the origin provider filters traffic, the scrubbing capacity of the data center, and the available link capacity.

If that is a concern, use protection options for an exposed origin to assess whether you also need IP-layer protection. For servers that serve other ports or continue to face direct attacks, consider whether a DDoS-protected server solution covers the relevant protocols and attack types.

When discussing a DDoS-protected CDN deployment with CDN07, provide the origin addresses, all application hostnames, protocols and ports, IPv6 usage, and existing access restrictions. Our edge locations, bandwidth, and security policies can be adjusted to application needs. The origin egress ranges, health-check sources, and available authentication methods must be confirmed for the specific solution.

If you are considering a private origin connection or tunnel, confirm that the product supports it and plan for failure recovery and operations. Connecting to a DDoS-protected CDN alone does not mean those capabilities are available at the origin.

Frequently Asked Questions

Will historical DNS records reveal the new IP after it changes?

Historical records usually show addresses that were public in the past; they do not automatically reveal a new one. But the new address may be linked to the site again if it appears in public DNS or shares an IP with other identifiable services. Focus on whether the new address has been exposed again and whether direct access can exploit it.

Does giving the origin hostname a random name help?

It can make simple guessing harder, but it is not a security guarantee. If the name resolves publicly to the origin, it may still be discovered. Pair the origin hostname with source restrictions and authentication.

Can a Host header restriction prevent requests from bypassing the CDN?

Not on its own. A requester can send your public hostname, and an HTTPS client can supply the matching SNI. Host restrictions can reduce requests to the wrong site, but you still need to verify the source and identity of origin requests.

Does scanning immediately after an IP change mean the new address has leaked?

Scanning alone is not enough to tell. Public IPs may be probed without any connection to your particular website. Check whether the requests use the correct application hostname, whether they can retrieve actual application content, and whether the new address appears in public configurations.

Can a dedicated CDN IP replace origin access restrictions?

No. A dedicated client-facing CDN IP, the CDN's origin egress IPs, and the origin IP are addresses at different points in the path. What a dedicated CDN IP does depends on the service. The origin still needs checks for bypass routes, origin access permissions, and network-layer protection.

Keep these four validation results after deployment:

• Public DNS and client configurations no longer point to the new origin.
• Normal requests through the CDN do reach the new origin.
• Unauthorized networks cannot directly retrieve protected application content.
• Old entry points, temporary rules, and IPv6 settings have all been reviewed.

If you have only changed the IP and updated DNS so far, contact CDN07 technical support with your hostnames, protocols, and deployment details. Confirm origin access ranges and deployment requirements before hardening and testing the origin.