Your domain is behind a CDN, but the server's bandwidth is still saturated. You switch CDN providers, yet the origin remains under attack. First, determine whether the attack is bypassing the CDN and reaching the server IP directly.

If your origin IP is exposed, a website may benefit from a DDoS-protected CDN combined with origin access restrictions. If the attack is already congesting the origin's upstream connection, or your service requires public TCP/UDP ports, also evaluate upstream traffic scrubbing, a DDoS-protected IP service, or a DDoS-protected server. Changing the IP can be part of the fix, but close the exposure path first.

Find where the attack lands before choosing a service

The origin is the server that runs your website, API, or game service. A known IP address does not mean the server has been compromised. What matters is which connections that address accepts and where attack traffic can exhaust resources.

Blackholing usually means a provider drops traffic destined for a particular IP to protect its network. Legitimate access may also stop. The provider's policies determine when blackholing starts, how long it lasts, and how it is lifted.

If your service is down, first ask your current provider to confirm the attack window, target IP, inbound traffic, and any blackholing before discussing a migration. High CPU usage, website timeouts, or CDN alerts alone do not establish which layer is under attack.

Why can an exposed origin IP still be attacked behind a DDoS-protected CDN?

A website CDN generally sits between users and the origin. Users reach an edge location, which processes the request and fetches from the origin when necessary.

Once attackers know the origin IP, they may connect to it directly. Traffic that bypasses the CDN should not be assumed to receive protection from its website proxy service.

Separate two types of load:

• Application request load: Large numbers of requests to login, search, or query endpoints consume application, database, or connection pool resources.
• Network and connection load: Large volumes of packets or connections consume link capacity, network equipment, or server resources, potentially causing an outage before requests reach the application.

AWS explains in its infrastructure-layer attack guidance that UDP reflection and SYN flood attacks can exhaust network capacity or system resources and require capacity to filter or absorb the traffic. This is why a website returning a 403 response and an origin withstanding a high-volume attack are separate matters.

A 403 only shows that a particular HTTP request was rejected. If traffic has already saturated the connection ahead of the origin, rejecting requests with Nginx rules or a host firewall cannot reclaim the consumed upstream capacity. Filtering before the bottleneck is different. Ask prospective providers exactly where traffic is dropped or scrubbed.

How can you identify exposed origin entry points before buying?

Inventory domains, addresses, and service ports

Check more than the primary domain. Inventory your public IPv4 and IPv6 addresses, subdomains, and services. Look for:

• Old DNS records, test sites, admin sites, or backup domains that still point to the origin.
• Other A or AAAA records that still permit direct access while the primary domain uses a CDN.
• Mail services sharing the website's public IP address.
• Origin addresses embedded in page assets, API configurations, or publicly shared callback URLs.
• SSH, remote desktop, databases, or management panels unnecessarily open to the entire internet.

Cloudflare's origin protection documentation recommends checking unproxied DNS records, mail deployments, and historical DNS records, and considering an origin IP rotation after enabling its proxy. The practical point: removing the origin from current DNS records does not erase records of its old address.

If you have not mapped these entry points, use our article on how origin IPs are exposed and ways to protect them as an inventory guide, then verify each current setting.

On a Linux origin with ss installed, start with this read-only command:

ss -lntup

As defined in the ss manual, this command lists listening TCP ports and relevant UDP sockets, displays numeric addresses and ports, and attempts to show the associated processes. Some process details require appropriate privileges.

Focus on Local Address:Port. Check the access scope of services bound to 0.0.0.0 or [::], but a local listener alone does not prove public reachability. Cloud security groups, firewalls, and port forwarding also matter. Conversely, checking only IPv4 may miss an IPv6 entry point.

Use the correct hostname when testing direct access

A failed browser visit to “https://源站IP” does not prove the CDN cannot be bypassed. The server may select a site and certificate based on the hostname, so visiting the IP directly can show the default site instead.

The following command works in a Linux or macOS terminal with curl installed. Test only an origin you own or are authorized to manage. Replace the sample domain and documentation IP 192.0.2.10 with your actual configuration, and make one request from an external network outside the allowed origin access list:

curl --noproxy '*' -sS --connect-timeout 5 --max-time 10 \
  --resolve 'www.example.com:443:192.0.2.10' \
  -D - -o /dev/null \
  -w '\nstatus=%{http_code} remote=%{remote_ip}\n' \
  'https://www.example.com/'

As the curl documentation for --resolve explains, the option supplies a target address for a specified host and port. This test preserves the hostname in the URL and the server name used for the HTTPS handshake while directing the connection to the specified origin IP. --noproxy '*' bypasses local proxy settings, and the two timeout options bound the wait time.

Confirm that remote is the target origin address, then interpret the response headers alongside the origin logs:

If the origin uses a Cloudflare Origin CA certificate, Cloudflare's Origin CA documentation notes that direct browser access may produce an untrusted certificate error when the proxy is disabled. If you switch to another CDN, check its origin certificate validation requirements separately; do not assume it will trust the existing certificate.

These low-frequency checks verify reachability. They do not test DDoS mitigation capacity, and one success or failure cannot establish the result for every region and protocol.

When should you consider a DDoS-protected CDN and origin isolation first?

If you primarily serve a website or HTTPS API, the existing server is functioning, and your main concerns are malicious requests and an exposed entry point, consider keeping the application server. A DDoS-protected CDN can handle the website entry point while you restrict access to the origin.

This generally reduces application migration work, but requires three steps.

Route every relevant service through the protection.

Check login APIs, image domains, uploads, downloads, and WebSocket endpoints, as well as the homepage. Confirm provider support and any timeout or size limits for each endpoint. Do not cache private user data in dynamic responses merely to improve the cache hit ratio.

Restrict which connections the origin accepts.

Get the provider's actual origin-facing egress addresses and update process. Distinguish origin requests from health checks and administrative access. Allowing CDN-origin traffic does not mean opening management panels and databases to the same CDN addresses.

Evaluate origin request authentication.

An IP allowlist narrows the sources, but shared egress IPs may not distinguish one customer's requests from another's. Ask whether dedicated origin credentials or mutual TLS authentication are available and appropriate, and confirm how secrets are protected, rotated, and revoked. Checking the Host header alone does not prove a request came from your CDN.

Before tightening access rules, confirm that normal origin requests, administrative access, monitoring, and certificate renewal still work. Applying a blanket "deny all other sources" rule directly in production could cut off your own service.

CDN07's DDoS-protected CDN service combines content delivery and DDoS protection, with options to tailor the deployment by edge location, bandwidth, and security policy. Websites with an existing international origin can evaluate these settings against their architecture. Confirm the specific origin authentication methods, egress address management, and supported ports before deployment.

When should you focus your budget on upstream origin protection or a DDoS-protected server?

Attacks directly affect origin network availability

If your provider confirms sustained high-volume attacks against the origin IP, and network congestion or blackholing disrupts origin requests, upgrading the website CDN plan alone may not resolve the outage.

Compare whether your current provider can add upstream protection, whether a DDoS-protected IP service can support your application, whether an IP change can be paired with complete isolation, and whether migration to a suitably protected server is more appropriate.

Moving to a DDoS-protected server is not the only option. If your existing platform can provide adequate upstream scrubbing, you may avoid moving databases, switching storage, and reconfiguring networking. If it cannot provide sufficient protection or the connectivity your service needs, migration has a stronger case.

When buying a DDoS-protected server, ask where attack traffic is handled, which IPs and ports are protected, and what happens when agreed limits are exceeded. More CPU and memory can support the application, but they do not replace network protection.

CDN07 also offers DDoS-protected servers in Hong Kong. If you need to relocate your origin, evaluate server resources, network connectivity, and protection terms together. The quote and service agreement should specify the protection scope, application bandwidth, and rules for exceeding limits.

Your service uses ports a website CDN cannot handle directly

Multiplayer game traffic, voice traffic, and custom TCP/UDP protocols are not ordinary website traffic simply because they use a domain name. Check the protocol, ports, connection duration, and client connection method.

For example, a game's website may use a website CDN, while its game connection ports need a different form of protection. If you can modify the client, our comparison of a game security SDK and DDoS-protected IP service can help assess integration effort. If you cannot change the client, verify that the server-side option supports the existing protocol.

Nor should you assume a DDoS-protected server covers every application. Confirm specific ports, protocols, connection limits, scrubbing policies, and service commitments during an attack.

Will changing the IP help, and how do you keep the new one from being exposed?

Changing the IP removes the original service from the known address and reduces opportunities to keep targeting it. It does not automatically fix exposure through domains, mail services, or API configurations, or guarantee that the new address will remain undiscovered.

Work through the change in this order:

1. Map dependencies. Identify applications, third-party callbacks, database allowlists, and monitoring that rely on the old IP. Back up configurations and prepare a rollback plan.
2. Prepare the new address and access rules. Configure the necessary origin and administrative access before it takes production traffic, checking both IPv4 and IPv6.
3. Verify CDN connectivity to the new origin. Test certificates, origin hostnames, login, uploads, APIs, and long-lived connections, rather than only loading the homepage.
4. Switch traffic in stages and monitor it. Compare CDN and origin logs, checking unexpected status codes, request volumes, and successful application transactions.
5. Remove the old address and missed entry points. Retire the old entry point after confirming the migration, so a backup domain does not preserve a bypass route indefinitely.

Do not temporarily publish the new origin IP in public DNS for debugging and then remove it. If a cutover fails, do not point all user traffic directly at an unprotected origin without assessing the consequences.

If there are signs of compromise, such as an unknown administrator, modified files, or exposed credentials, handle that incident separately. An IP change and DDoS protection do not replace an intrusion investigation.

How do you compare quotes for the right protection?

Asking only about mitigation capacity in Gbps and monthly price is not enough. Share your application entry points and evidence of the outage with providers so their proposals address the same problem.

A website facing both malicious requests and attacks against its origin IP may use a DDoS-protected CDN with a protected origin. Buying two layers should not be the default, though. Identify the missing protection first, then add the layer that addresses it.

Keep application authentication, sensible rate limits, and vulnerability remediation in place. Our article on how WAF, bot management, and DDoS protection work together discusses the roles of these controls. When comparing services, ask which policies handle network attacks, malicious requests, and application abuse, rather than attributing everything to a generic DDoS protection label.

Frequently asked questions

Is a DDoS-protected CDN useful if my origin IP is exposed?

Yes. Traffic passing through the CDN can still benefit from its content delivery and protection. Direct access to a known origin IP requires separate attention, which may involve access restrictions, origin request authentication, changing the address, or upstream origin protection.

Will allowing only CDN edge locations to reach the origin stop all DDoS attacks?

No. This primarily limits where the origin accepts application connections from. If filtering happens on the host and an attack has congested the upstream connection, legitimate origin requests may still fail. Consider the filtering location, upstream capacity, and the provider's scrubbing mechanisms.

If I cannot change the server IP, do I have to migrate?

Not necessarily. First ask your current provider whether it can protect the existing address upstream, and check whether application and management access can be tightened. If its protection, protocol compatibility, or network conditions fall short, compare the cost of migrating.

Do I still need a DDoS-protected CDN after moving to a DDoS-protected server?

It depends on whether the website still needs content delivery, performance acceleration, or more granular policies at its entry point. The server and CDN have overlapping but distinct roles. There is no need to buy the same coverage twice if a requirement is already met.

If I cannot ping the origin, is its IP successfully hidden?

No. Ping uses ICMP, while a website uses HTTPS. Verify direct application access using the actual hostname, port, and protocol. Ping also cannot tell you whether the IP was exposed historically.

How do I verify that the changes worked?

Check separately that legitimate users can access the service, the CDN can connect reliably to the origin, unauthorized sources cannot bypass access controls, and old domains and IPv6 entry points are restricted. High-volume mitigation capacity must be evaluated against the service terms, scrubbing mechanisms, and a test plan authorized by both parties; a few curl requests cannot prove it.

What should I do next after my origin IP is exposed?

• A DDoS-protected CDN primarily protects traffic that passes through it. Assess direct attacks on the origin separately.
• Access controls can reduce bypass paths but cannot replace upstream network protection.
• Pair an IP change with an exposure review, origin connectivity checks, and retirement of old entry points.
• Whether to migrate to a DDoS-protected server depends on network protection, application protocols, and what your current platform can provide.

Gather your application domains, protocols and ports, target user regions, origin location, and attack records from your provider. Share origin addresses and logs through a controlled channel rather than publishing sensitive configuration details.

If you need to compare a CDN deployment with an origin migration, take this checklist and contact CDN07 to review your protection options. Map the entry point, origin connection, and origin separately before settling on a product combination and quote, so new spending addresses an actual gap in protection.