Can a CDN Protect Your Website from DDoS Attacks?

Short answer: A CDN solves the parts of a DDoS that most often kill a site: your origin’s public address, concentrated volumetric traffic, and repeated identical requests. It does not solve four others — non-HTTP services on bare IPs, application-layer floods made of legitimate-looking requests, your own backend capacity once requests do reach it, and any path that bypasses the edge. Three preconditions must hold for CDN-based protection to be real: DNS resolves to the CDN and is proxied, the origin accepts only CDN IP ranges, and no DNS history or backup path still exposes the origin.

The honest answer: yes for the parts that usually kill you, no for four others

A CDN in the DDoS conversation is not really a cache. It is a reverse proxy with an anycast network in front of it, and that combination fixes the three things that most often take a site offline:

1. Origin exposure. Behind a proxy, the documentation’s framing holds: a service never needs to reveal the IP address of its origin servers, so attackers can only target the reverse proxy itself. An attack that cannot find your origin cannot exhaust it.
2. Concentration. An anycast network announces the same addresses from many locations, so a flood is spread across the edge instead of arriving at one data centre on one link.
3. Repetition. Cacheable responses are served at the edge and never consume origin capacity. For a flood of identical requests, this is the difference between a slowdown and nothing happening at all.

Add unmetered layer 3, 4 and 7 protection on every plan and the answer to “does a CDN help” is clearly yes. The more useful question is where it stops.

What a CDN does not solve

Gap	Why the CDN cannot fix it	What actually helps
Non-HTTP business on TCP/UDP	A reverse proxy terminates HTTP(S); it cannot parse or forward arbitrary protocols	Spectrum for ports, Magic Transit for whole prefixes (Enterprise)
Application-layer floods that look valid	Valid requests are served, not filtered — capacity is not the problem, classification is	WAF custom rules, rate limiting, caching, Turnstile
A leaked origin IP	Attackers bypass the hostname entirely and go straight to the address	Replace the origin IP and accept traffic only from Cloudflare’s published ranges
Downstream or third-party dependencies	Your payment provider, SMS gateway or upstream API can be attacked independently of you	Contractual and architectural redundancy; a second provider

The third row deserves emphasis because it silently undoes the first. Hiding the origin only works while the address is genuinely unknown and unreachable; one leaked A record, one forgotten subdomain, one old mail server entry and every other control is bypassed.

Three preconditions that make the rest true

1. DNS is fully delegated and every relevant record is proxied. Protection applies to traffic that traverses the network. A hostname left on DNS-only resolution receives nothing — the most common reason a purchased protection appears not to work.

2. The origin accepts nothing from the public internet. Restrict it to Cloudflare’s published IP ranges. Without this, the proxy is a detour rather than a gate.

3. Your expensive responses are actually cacheable. Cache rules let you match on path, query string, header or cookie, but they can only cache what your application allows. Personalised HTML on every request removes the highest-leverage layer you have.

Where the line falls

Cloudflare capabilities vs. what your team must own

Item	What Cloudflare provides	What your team must do
Hiding the origin	Reverse proxy; attackers see only the proxy	Replace leaked IPs; allowlist Cloudflare ranges
Spreading the attack	Global anycast network	Nothing — this is the platform’s job
Absorbing repetition	Cache rules matched on path, query, header, cookie	Make responses cacheable
L3/4/7 mitigation	Unmetered protection on all plans	Confirm traffic actually traverses the edge
Application-layer floods	HTTP DDoS ruleset, WAF custom rules, rate limiting	Tune, and own quotas in the application
Non-HTTP services	Spectrum (paid plans), Magic Transit (Enterprise)	Confirm protocol and prefix needs before signing

Boundaries and non-applicable cases

• A CDN in front of static assets protects those assets only. If your application’s dynamic paths bypass the CDN, the attack will find them.
• Caching is not available for personalised responses. When every response is unique, the strongest layer is unavailable; compensate with WAF rules and rate limits instead.
• Rate limiting is not a precise counter. Counters accumulate per data centre and mitigation applies after a delay of seconds; absolute ceilings belong in your application.
• Under Attack Mode is a last resort. It inserts an interstitial of roughly five seconds and distorts analytics; use it to buy minutes, then revert.
• Multi-CDN setups need an explicit answer for traffic that does not traverse this edge. “Most of it does” is not an answer.

FAQ

So is a CDN enough on its own? For most websites, close to it — provided the three preconditions hold. The exceptions are architectural: non-HTTP services, personalised responses that cannot be cached, and origins that still answer the public internet.

Does a bigger plan absorb more attack volume? Not in the way the question implies. Unmetered L3/4/7 protection is on every plan. Higher tiers change visibility and control — more DDoS overrides with custom expressions, the Log action, richer adaptive rules and advanced alerts — and unlock Spectrum and Magic Transit.

What if the attacker knows our origin IP? Then the CDN is bypassed. Replace the address, allowlist Cloudflare’s ranges at the origin firewall, and check for historical DNS records, subdomains and mail entries that still point at it.

Will the site stay fast during an attack? Usually yes for cached content, and it depends for dynamic content. The visible risk during a flood is rarely raw bandwidth — it is origin capacity and the expensive endpoints behind it.

Related reading

• How to Choose DDoS Protection for Global Businesses
• How to Mitigate HTTP Flood and Layer 7 Attacks
• How to Choose an Enterprise Web Application Firewall
• CDN capabilities