Cloudflare DDoS Protection: Setup, Limits, Origin Lockdown

A common support story goes like this: a site moves behind Cloudflare, gets hit a month later, and goes down anyway. Cloudflare did its job. The attacker simply found the origin server’s IP address and sent traffic straight to it, never touching the proxy.

So the setup has two halves. Turning Cloudflare DDoS protection on is the easy one. Making sure nobody can go around it is where most of the work is.

What Cloudflare DDoS protection includes on the free plan

According to Cloudflare’s DDoS protection documentation, standard DDoS mitigation for layers 3 to 7 is available on every plan and is unmetered. Two managed rulesets run by default: one for network-layer floods (SYN, UDP and similar) and one for HTTP floods at layer 7. You don’t switch them on. You can override them, with the number of overrides depending on the plan (one on Free).

Where plans differ is control, not core mitigation:

For a typical marketing site or blog, Free is enough. It gets tight when you run an API with several sensitive endpoints, because one rule with a fixed 10-second counting period, counting only by IP and matching only on path, won’t cover them all.

Setting it up: nameservers, proxy status and DNSSEC

Adding a zone takes minutes. Cloudflare scans your existing records and proposes them for import, and that scan regularly misses things: TXT records for SPF, DKIM, DMARC and third-party verification are the usual casualties. Export your current zone first and compare.

Then you swap the nameservers at your registrar. If DNSSEC is active, order matters. Turn it off at the old provider, wait until the DS record is gone from the parent zone, switch nameservers, enable DNSSEC in Cloudflare and publish its DS record at your registrar. Skipping a step means validating resolvers return SERVFAIL for your whole domain. If your registrar makes DS records awkward, a domain registrar with built-in DNSSEC support makes this a two-minute job.

Proxy status is the switch that matters. Only records set to Proxied (orange cloud) are filtered. A www record left on DNS only publishes your server IP to anyone with dig.

Hide your origin IP or the rest is pointless

Ways origin IPs typically leak:

1. MX records pointing at the same machine as the website
2. Unproxied subdomains such as staging., dev., ftp. or a control panel host
3. Historical DNS data from before you moved to Cloudflare
4. Outbound traffic: password reset emails, webhooks and pingbacks sent from the server carry its IP
5. Certificates in Certificate Transparency logs for hostnames that resolve directly to the server

If the IP was ever public, change it. Most VPS providers will assign a new one, sometimes for a small fee.

Then make the origin refuse anything that isn’t Cloudflare. Cloudflare publishes its ranges at https://www.cloudflare.com/ips-v4 and https://www.cloudflare.com/ips-v6. A simple ufw version:

for net in $(curl -s https://www.cloudflare.com/ips-v4) $(curl -s https://www.cloudflare.com/ips-v6); do
  ufw allow proto tcp from "$net" to any port 80,443
done
ufw deny 80/tcp
ufw deny 443/tcp

Re-run it monthly from cron. The ranges rarely change, which is exactly why a change catches people out.

Your logs will now show Cloudflare addresses for every request. Restore real client IPs in nginx:

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 2400:cb00::/32;
real_ip_header CF-Connecting-IP;

Save it as something like /etc/nginx/conf.d/cloudflare-realip.conf and list every range; the example is shortened. Without this, any per-IP limit you set on the server throttles Cloudflare’s edge rather than the attacker. Reading those logs during an incident is covered in how to detect a DDoS attack.

Cloudflare Under Attack mode: useful, blunt, temporary

Under Attack mode puts a JavaScript check in front of every page. Visitors briefly see “Checking your browser before accessing…” and, per Cloudflare, a decision is made within five seconds. Once passed, they aren’t challenged again until the Challenge Passage period runs out.

You can enable it for the whole zone from Quick Actions on the zone overview, or for specific paths through a configuration rule. Cloudflare’s own docs describe it as one of the last resorts during an attack and note that it affects analytics.

My view: path-scoped is almost always better. Anything that isn’t a browser fails the check, including mobile apps, API clients, payment provider webhooks, RSS readers and your own monitoring. If you must go zone-wide, carve out /api/ and webhook endpoints, and set a reminder to switch it off.

Rate limiting and WAF rules on Cloudflare

Managed DDoS rules catch big, obvious floods. They may not flag a few hundred requests per second against an uncached search endpoint, even though that’s enough to pin your database at 100 % CPU.

That’s what the single Free-plan rate limiting rule is for. A sensible first rule:

Tune the numbers against your real traffic; the rate limiting guide shows how to derive them from logs. Custom rules (available on Free too) can add a Managed Challenge for countries or networks you never serve. It’s crude, but in the first hour of an attack, crude and fast beats elegant and late.

After any incident, open Security Events and check what got blocked. Uptime monitors and payment webhooks turn up there more often than you’d think.

What Cloudflare won’t cover

• Non-HTTP services (SSH, mail, game servers, custom UDP) unless you pay for Spectrum.
• Attacks on authoritative DNS hosted elsewhere; see DNS DDoS attacks.
• Origin exposure, as above.
• Expensive application paths. A page that needs two seconds of CPU per request falls over long before anything looks like an attack. Caching helps more than any filter here.

If you’re reading this mid-incident with nothing set up, start with what to do during a DDoS attack and come back later.

Plan the nameserver switch before you need it

The nameserver change is the one step that can briefly destabilise your domain, so do it in a quiet week, not at 2 a.m. during an attack. Check that you can actually reach your registrar’s nameserver settings, whether DNSSEC is on, and whether a lock blocks changes. Keep the old zone running for at least two TTL cycles afterwards.

If your domain sits with a host that makes nameserver changes painful, compare fixed renewal prices for .com and 490 other endings and move it somewhere you control. The registrar’s guides cover DNSSEC and nameserver changes step by step.

Step by step

1. Add the site to CloudflareCreate the zone, choose a plan and compare the imported DNS records line by line with an export of your current zone.
2. Change nameservers at your registrarDisable DNSSEC at the old provider first, then set the two Cloudflare nameservers and add Cloudflare's DS record once the zone is active.
3. Proxy the web recordsSet A, AAAA and CNAME records for the site and www to Proxied. Leave mail-related records as DNS only.
4. Lock the origin to CloudflareAllow ports 80 and 443 only from the ranges published at cloudflare.com/ips and restore real visitor IPs from the CF-Connecting-IP header.
5. Prepare rules before you need themCreate a rate limiting rule for your most expensive path, review Security Events and note where the Under Attack toggle lives.