Can Anti-DDoS IP and Anti-DDoS CDN Be Used Together? Combined Architectures, Configuration Essentials, and Trade-offs

Yes, they can be used together. Anti-DDoS IP plus CDN (or anti-DDoS CDN) is a relatively mature combination for handling mixed attacks and protecting sensitive origin servers, and mainstream cloud providers document corresponding integration solutions. However, stacking two layers increases latency, troubleshooting difficulty, and costs. For sites running only standard Web/API, if the anti-DDoS CDN already performs scrubbing and acceleration on the same link, adding an extra anti-DDoS IP is usually unnecessary.

The following sections cover: what combination methods exist → what to configure when chaining → the cost of stacking → how to choose for your business.

If your site is currently under attack, don't build a two-layer architecture first. Follow the access sequence for quickly mounting CDN during large-traffic attacks to restore your business, and adjust the architecture once things stabilize.

Two Common Combination Methods

Comparison diagram of anti-DDoS IP and anti-DDoS CDN chained defense-in-depth architecture and protocol-based traffic splitting architecture

1. Chained defense-in-depth: Client → CDN/Anti-DDoS CDN → Anti-DDoS IP → Origin

Each layer handles a different segment:

Outer CDN/Anti-DDoS CDN: Handles edge caching, static content distribution, and blocks application-layer CC attacks and web attacks at the edge.
Middle Anti-DDoS IP: When the CDN back-to-origin traffic reaches the anti-DDoS IP first, it blocks large-traffic network-layer attacks such as SYN Flood and UDP Flood that bypass the CDN or directly target the back-to-origin channel.

This approach primarily solves the problem of origin exposure. The origin only communicates with the anti-DDoS IP, and the real IP is never visible externally. Even if the CDN layer configuration changes or the origin migrates, as long as back-to-origin always goes through the anti-DDoS IP, the origin address won't be exposed. It suits businesses with highly sensitive origins where a breach would cause major losses, such as payment or core transaction systems.

2. Protocol-based traffic splitting or intelligent scheduling: Two parallel paths

This method is not a layer-on-layer setup, but rather separates traffic by type or attack status:

Protocol-based splitting: Web pages, static resources, and HTTP APIs go through CDN; non-Web protocols like TCP/UDP long connections for game clients go through anti-DDoS IP. A common example is mixed business like "web admin panel plus layer-4 game client".
Status-based scheduling: Normally traffic goes through CDN for acceleration; during massive traffic attacks, a scheduler pulls traffic to the anti-DDoS IP for scrubbing.

In a split architecture, each path has only one proxy layer, resulting in lower latency than chaining. The trade-off is maintaining two sets of access configurations and managing scheduling rules.

Three Must-Configure Items for Chained Deployment

Most issues in a chained architecture stem from these three configuration points:

Origin only allows back-to-origin segments from the anti-DDoS IP. Set up a whitelist in the origin's firewall or security group to only allow access from the anti-DDoS IP's back-to-origin IP ranges, and deny all other sources. Without this step, an attacker who obtains the origin IP can bypass the front two layers and directly attack the origin, rendering the previous protection useless.
Anti-DDoS IP allows CDN back-to-origin segments. In the anti-DDoS IP's forwarding rules, add the CDN nodes' back-to-origin IP ranges to the allowlist to prevent CDN back-to-origin requests from being blocked as anomalous traffic. If the CDN back-to-origin ranges change, update this accordingly.
Pass through real client IP at each layer. Each proxy layer must enable real IP passthrough, typically via the X-Forwarded-For header, and the origin reads it accordingly. If any layer is missed, the origin only sees the anti-DDoS IP or CDN node address, and risk control, rate limiting, login anomaly detection, and business statistics will fail.

After configuration, test the full chain with a few real requests to confirm the origin logs record the client IP, and then verify that direct access to the origin IP is denied.

The Cost of Stacking Two Layers

Before deciding to stack, factor in these costs:

Increased latency: Each additional forwarding adds time to the first byte (TTFB). For latency-sensitive APIs, measure the difference before and after chaining.
Longer troubleshooting chain: When 502 or 504 gateway timeouts occur, you need to check CDN, anti-DDoS IP, and origin in sequence to identify which layer's timeout settings, health checks, or back-to-origin rules are causing the issue. If logs are scattered across different consoles, diagnosis becomes slower.
Duplicate costs: CDN bandwidth or traffic fees plus anti-DDoS IP's base protection bandwidth and elastic protection fees result in two simultaneous bills, significantly increasing procurement and O&M costs. For billing differences, refer to How peak-based billing works for anti-DDoS CDN.

Does Your Business Need Stacking?

Judge by business type:

Mixed-protocol business (web backend plus game or other TCP/UDP private protocol clients): Suitable for CDN and anti-DDoS IP splitting, with web going through CDN and layer-4 traffic going through anti-DDoS IP or dedicated layer-4 protection. For whether UDP services can be directly protected by CDN, see Can UDP battle servers under attack use CDN protection.
Extremely sensitive origin requiring defense-in-depth: Consider a chained architecture, provided the team can accept added latency and maintain three layers of configuration.
Standard Web/API sites: If the current product already performs distributed DDoS scrubbing and acceleration on the same link, a single-layer solution is usually more cost-effective in latency, cost, and O&M. No need to add an extra anti-DDoS IP just for "extra safety".

The third case is most common. Take RockCloud as an example: its acceleration and DDoS/CC defense are completed on the same link, covering both with one fee, and defense doesn't require separate procurement; billing is based on fixed peak with unlimited traffic, and logs are centralized in one panel, so troubleshooting doesn't require switching between multiple consoles. For capability scope and access methods, see the DDoS protection product page. If you want to compare latency and blocking effects of a single-layer solution versus your existing architecture using your own business traffic, you can apply for testing via plans and free trials, and decide whether to stack based on measured data.