Cloudflare DDoS Protection: How It Works and Setup

Cloudflare automatically detects and blocks DDoS attacks at the L3, L4, and L7 levels. To activate it, just connect your site to Cloudflare — basic protection works without any configuration.

DDoS Protection Levels by Plan

Security Level

Security → Security Level controls how aggressively Cloudflare checks visitors:

I'm Under Attack Mode

During an active attack, enable emergency mode:

Security → Security Level → I'm Under Attack!

Every visitor will see Cloudflare's 5-second check page. Bots won't get through, real users will.

Rate Limiting

Security → WAF → Rate Limiting Rules → Create. Limit the number of requests from a single IP:

# Example: no more than 100 requests per 60 seconds
Matching rule: http.request.uri.path contains "/api/"
Rate: 100 requests per 60 seconds
Action: Block (or Challenge)

Managed Challenge, JS Challenge, and CAPTCHA

When Cloudflare decides to check a visitor, it shows one of several challenge types. They differ in how much friction the visitor feels and how resistant they are to bots:

Managed Challenge is the recommended option almost everywhere: Cloudflare itself picks the level of scrutiny based on IP reputation and browser behavior.

Breaking down attack messages

"This website is under a DDoS attack" on the visitor's screen

This is an interstitial page that Cloudflare shows automatically during an abnormal traffic spike, even without manually enabling I'm Under Attack Mode. It stays up from a few minutes until traffic returns to a normal level. You cannot turn it off manually — it is part of the automatic network-level defense.

Legitimate users complain about being blocked

A frequent cause: Security Level is set to High, or I'm Under Attack Mode has been left on longer than needed, or a Rate Limiting rule is tuned too strictly for a shared NAT address used by an office or mobile carrier, making many real users look like one IP with an abnormal request rate.

Verifying the protection works

# Check the header that shows which check the request passed
curl -I https://example.com/ | grep -i cf-mitigated

# Values:
# cf-mitigated: challenge   — the visitor passed a challenge
# (header absent)           — the request was handled without extra checks

When built-in protection is not enough

• You need application-level protection against slow, low-and-slow attacks that never create a visible traffic spike — that needs a WAF with precise rules, not just the automatic DDoS layer.
• The attack bypasses HTTP entirely and hits the server's IP directly around Cloudflare — proxied mode does not protect against that; you need Spectrum or a new real IP with direct access closed off.
• You need SLAs and guaranteed response times — the baseline protection works best-effort, and formal guarantees exist only in Enterprise-level contracts.

Security → Events shows not just blocked requests but also ones that were passed after a check — the Action column lets you filter for exactly the requests caught by automatic DDoS protection, and see which countries or ASNs the bulk of the attack traffic came from.

After turning on I'm Under Attack Mode, keep it on for a few hours at most: every unique visitor has to pass the challenge, including search engine crawlers — leaving the mode on for a long time can temporarily hurt the site's search visibility because crawlers cannot get past the challenge.

Managed Challenge and the automatic DDoS protection work independently of Bot Fight Mode — turning both on at once does not conflict and usually gives a better result than either tool alone.

To check whether current load is normal, compare the Analytics → Traffic graphs for the last 24 hours against the previous week — a sharp, unexplained jump in requests from one ASN is usually the first sign of an attack starting, even before the interstitial page appears.

Frequently asked questions

Does I'm Under Attack Mode turn off automatically once the attack ends, or do you have to disable it manually?

No, the mode never turns off by itself: it is switched on and off only manually through Security Level. Leaving it active once an attack ends makes every visitor and every search crawler pass the check needlessly, adding delay and hurting normal site operation. Switch the level back to Medium as soon as traffic settles down.

Will Cloudflare protection still work if the domain is set to DNS-only mode, without proxying?

Basic protection against large volumetric attacks at the network level still works without proxying, since the server's IP address is visible in DNS regardless. Application-level protection, such as Security Level, Rate Limiting, and Managed Challenge, only applies to traffic passing through Cloudflare. Full protection against HTTP attacks requires proxying the domain, meaning the cloud icon switched on.

Can aggressive protection settings block legitimate API requests and payment webhooks?

Yes, at a high security level or with the emergency mode on, the challenge can catch automated requests too: payment webhooks, integrations, and server-side API clients cannot solve a browser check. The fix is an access rule exception based on the sender's IP address or a specific path, so protection leaves service traffic alone while still checking ordinary visitors.

Do you also need to configure protection on the server itself if the domain is already behind Cloudflare?

Cloudflare cannot fully replace server-side protection: it filters outside traffic before it reaches your IP address, but it does not guard against attacks happening inside the application itself or against requests that hit the server directly, bypassing the proxy. A basic firewall and access restrictions on the server itself remain a sensible extra layer.