Can a CDN Stop DDoS? Most Site Owners Get This Wrong

Many site owners assume a CDN means they are safe. DDoS still takes them down. Eight Q&As on how CDN DDoS mitigation actually works, which attacks it stops, why origin IP leaks void protection, and how to choose CDN vs anti-DDoS IP.

I put a CDN in front. Am I done with DDoS? Highest-frequency question from site owners. Answer: a CDN stops some DDoS. It is not a universal shield. Wrong setup still gets you knocked over. Eight Q&As on the real capability boundary and the correct onboarding.

Q: How does CDN DDoS mitigation work?

Core: spread the attack surface. No CDN, global attack traffic only needs to hit one server. With a CDN, the domain resolves to edge nodes. Attack traffic hits many CDN nodes first, is absorbed and scrubbed, and traffic that punches through to origin drops sharply. CDN nodes also hold far more bandwidth than a typical server. With Anycast, small-to-medium volumetric floods (a few Gbps to tens of Gbps) are digested at the edge. That is why many sites feel more stable after a CDN—large volumes of stray floods and scans get dropped as a side effect.

Q: What can a CDN stop, and what can it not?

What it can stop: mid-size SYN Flood, UDP Flood, and similar volumetric attacks, absorbed across nodes; ordinary HTTP Flood, a substantial share filtered by cache and request-rate limits; scattered scans and probes almost never get in.

What it cannot stop, or struggles with: massive DDoS (hundred-Gbps clustered floods) can saturate the CDN nodes themselves; the vendor may cap your traffic or require an anti-DDoS plan upgrade. Direct attacks on the origin IP: CDN has no visibility. This is the most common failure. Precision CC that mimics normal browsing at low per-IP frequency: basic CDN rules cannot distinguish it. Needs WAF-layer intelligence.

Q: Why did the site still go down with CDN enabled?

90%+ of cases: origin IP leak. A CDN only protects names that resolve to it. If the attacker has the real origin IP and attacks the IP directly, the CDN is a no-op. Common leak paths:

• Historical DNS records: the pre-CDN IP is still queryable (plenty of historical-resolution databases);
• Subdomains straight to origin: apex on CDN, but mail.xxx.com, api.xxx.com still point at the real IP;
• Origin-initiated outbound: origin sends mail or calls external APIs and exposes its IP;
• SSL certificate metadata; internet-wide search engines (FOFA, Shodan, etc.) fingerprint-scan the origin.

A CDN in place and still down almost never means the CDN is useless. The attack path bypassed the CDN.

Q: How do you prevent origin IP leaks?

Do these, or hiding origin is pointless:

• Audit every subdomain: all records through the CDN. No direct-to-origin records. Mail via third-party enterprise mail if possible;
• Origin firewall allowlist: server accepts 80/443 only from CDN origin-pull IP ranges. Drop every other source. Even with an IP leak, 80/443 is unreachable;
• Check historical resolution: search historical-DNS sites for your domain. If the old IP is still in records, rotate origin IP;
• Do not leak network fingerprints: origin does not send outbound mail; avoid leaving HTTP fingerprints in space-mapping engines.

iptables allowlist example (use your cloud vendor's origin-pull ranges; replace the CIDR):

iptables -A INPUT -p tcp --dport 443 -s 162.62.0.0/16 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP

Q: CDN or anti-DDoS IP?

Different jobs. CDN: hide origin + edge filter. Fits always-on content, adds acceleration, enough for small-to-medium floods, low cost. Anti-DDoS IP: dedicated bodyguard. All traffic, including massive floods, is steered to a scrubbing facility then forwarded to origin. Can absorb hundreds of Gbps. No acceleration in peacetime. Billed by protected bandwidth—clearly more expensive.

Decision rule: content-display business, mostly small stray floods → CDN is enough. High-value (finance, gaming, e-commerce promotions), known large-flood target, or already hit by massive floods → anti-DDoS IP. Can stack: CDN for daily traffic; cut over to anti-DDoS IP under sustained large floods.

Q: CDN traffic bill exploded under attack?

Real problem with CDN mitigation: attack traffic lands on the CDN. Even when mitigation succeeds, some billing models still charge you for that traffic. Response:

• Prefer plans with a DDoS mitigation quota. Know overage billing rules before you buy;
• Enable traffic caps or usage alerts. Auto-pause or notify past threshold. Avoid overnight debt;
• Confirm vendor protection SLA: reputable vendors do not bill successfully mitigated attack traffic, or they count it against plan quota. Ask this before you sign.

Q: Under DDoS right now. First move?

Three steps, in order. First, confirm the target—IP or domain, volume, type. Read monitors and traffic data. Do not rush changes. Second, switch protection—if origin IP is already under fire, cut DNS to CDN / anti-DDoS so attack traffic enters a scrubbing path. Third, stop the bleed at origin—for traffic that already punched through, iptables rate limits plus ISP suppression:

# Limit concurrent connections per IP
iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 50 -j DROP
# SYN parameters to mitigate SYN Flood
sysctl -w net.ipv4.tcp_syncookies=1

Then retro how the origin IP leaked. Apply the anti-leak steps from the previous Q.

Q: Additional notes?

Summary: a CDN can stop DDoS if the origin IP stays hidden. CDN value is hide origin, spread traffic, scrub at the edge. Clear effect against small-to-medium floods. Defense is layered—CDN for daily hide-and-filter, WAF for CC and application-layer, anti-DDoS IP for massive floods. Do protection work in peacetime. Studying configs on the day you are hit is too late. Audit subdomain DNS and historical IP exposure every quarter. Hiding origin is a required prerequisite for CDN protection.