Cloudflare DDoS Protection and Under Attack Mode: What to Do When Your Site Is Flooded
Your site is behind Cloudflare and suddenly flooded with traffic. Here is how DDoS protection, Under Attack mode, rate limiting rules and origin lockdown fit together, plus an incident checklist.
If your business website is suddenly slow, timing out or drowning in requests, and it sits behind Cloudflare, you already have DDoS protection: Cloudflare's documentation lists standard, unmetered DDoS protection for layers 3 to 7 on every plan, including Free. What you do in the first few minutes is mostly about tuning, not buying: switch on Under Attack mode if real visitors cannot get through, add a rate limiting rule for the page being hammered, and make sure attackers cannot bypass Cloudflare by hitting your server's IP address directly. This guide explains each control in plain language and ends with an incident checklist you can print.
For the basics, see our guide to protecting your website with Cloudflare WAF; this article covers what to do once an attack is underway.
What a DDoS or bot flood looks like for a small business
A distributed denial-of-service (DDoS) attack sends more traffic than your site can handle, from many sources at once. For most small and mid-sized businesses, the problem is not a record-breaking network attack. It is an application-layer (layer 7) flood: thousands of requests per second to your home page, your search page, a login form or a contact form, often from rented servers or compromised devices.
Typical symptoms:
- The site loads slowly or returns 5xx errors (502, 503, 504, or Cloudflare's 52x errors).
- Your hosting provider warns about CPU or connection limits, or suspends the account.
- Server logs show a burst of requests to one URL from many IP addresses.
- Contact forms fill with junk submissions, or login pages see waves of failed attempts.
Cloudflare's network absorbs much of this before it reaches you. The pieces below decide how much gets through to your server.
Always-on protection: the HTTP DDoS managed ruleset
Cloudflare runs a managed ruleset called HTTP DDoS attack protection. According to Cloudflare's documentation it is always enabled for zones on all plans; you cannot turn it off, only adjust how it behaves.
Sensitivity and action
You can create an override that changes two things for the whole ruleset:
| Setting | Options | What it means |
|---|---|---|
| Ruleset sensitivity | High (default), Medium, Low, Essentially Off | Higher sensitivity means a lower threshold, so Cloudflare mitigates sooner |
| Ruleset action | Block, Managed Challenge, Interactive Challenge | What happens to traffic flagged as part of an attack |
In the dashboard, go to Security rules, open the DDoS protection tab and select Create override under HTTP DDoS attack protection. On plans other than Enterprise with Advanced DDoS Protection you get one override, and it applies to all traffic.
Our advice: leave sensitivity at High. If one legitimate integration keeps getting mitigated, fix that integration rather than weakening protection for everything.
Protection for your origin's error rate
Cloudflare also documents an Adaptive DDoS Protection for Origins rule that watches for traffic causing an unusual number of errors at your server, and it is available on any plan.
Under Attack mode: the emergency switch
Under Attack mode adds an extra check to every visit. Visitors see a short interstitial page while Cloudflare evaluates the browser; validated visitors continue to the site, suspicious traffic is blocked. Cloudflare describes it as one of the last resorts when a zone is under attack.
How to turn it on and off
- For the whole site: open your domain in the Cloudflare dashboard and turn on Under Attack Mode in the Quick Actions panel on the overview page. In the new security dashboard, the API and Terraform, the same thing is controlled through the security level setting.
- For one part of the site: create a configuration rule that matches a path (for example, URI path starts with
/login) and sets the security level to I'm Under Attack. This is a good option when only one page is being targeted.
Turn it off as soon as the attack subsides. Visitors who pass the check are not challenged again until the Challenge Passage time expires.
Side effects to plan for
Cloudflare warns that Under Attack mode can affect API traffic and analytics, because the check needs a browser that runs JavaScript. Before you flip the switch, think about what talks to your site without a browser:
- Payment and form webhooks (Stripe, PayPal, form services) that post to your server.
- Mobile apps and integrations that call your API.
- Uptime monitors and scheduled jobs that fetch pages.
The fix is the same configuration rule feature in reverse: if Under Attack mode is on for the whole site, add a rule that turns it off for /api/ or your webhook path, and protect that path with a rate limiting rule instead. Test a webhook delivery after any change.
Rate limiting rules: slow down the noisy few
A rate limiting rule counts requests that match an expression and acts when a client goes over the limit, for example by blocking or challenging it for a period of time. It is the right tool for login pages, search pages, contact forms and APIs.
What you get depends on the plan. Cloudflare's documentation lists these limits for the Free plan:
| Free plan feature | Limit |
|---|---|
| Number of rules | 1 |
| Fields you can match on | Path and Verified Bot |
| Counting by | IP address |
| Counting period and mitigation timeout | 10 seconds |
One rule is enough to protect the page that matters most. A practical starting point is a rule on your login or contact form path that blocks an IP sending far more requests in 10 seconds than a person filling in a form ever would. Paid plans add longer periods, more rules and more ways to count.
Lock down the origin so attackers cannot go around Cloudflare
Cloudflare only protects traffic that passes through it. If an attacker finds your server's real IP address, they can skip Cloudflare entirely. Cloudflare's own guidance on protecting the origin server covers the main leaks and fixes.
Common ways the origin IP leaks
- Old DNS history. Public DNS history services keep records from before you moved to Cloudflare. Cloudflare recommends changing your origin IPs after onboarding for this reason.
- Mail on the same server. If your website and email share a server, mail headers and bounced messages can reveal the address. Cloudflare advises not hosting mail on the same server as the protected website.
- DNS-only records. Grey-clouded records, and SPF or other TXT records that list the web server's IP, give it away. Audit every record that is not proxied.
- Subdomains such as
ftp,cpanelordevpointing to the same IP without the proxy.
Ways to close the door
- Proxy every web record (orange cloud) that serves your site.
- Allow only Cloudflare's IP ranges on ports 80 and 443 in your server firewall. Cloudflare notes this is moderately secure on its own.
- Authenticated Origin Pulls, which lets your server verify that a request really came through Cloudflare. It requires the Full or Full (strict) SSL/TLS mode.
- Cloudflare Tunnel, which connects your server to Cloudflare through outbound-only connections, so the server needs no publicly reachable IP address for the site. It requires installing the
cloudflaredservice.
Ask your hosting provider which of these are in place; our web hosting management work covers this as part of a standard setup.
Incident checklist: when the site is under attack
- Confirm it is an attack. Check Cloudflare's security events and analytics, and your server load, before assuming.
- Identify the target. One URL, the whole site, or the server's IP directly (traffic that does not appear in Cloudflare at all)?
- If visitors cannot get through, turn on Under Attack mode, either site-wide or with a configuration rule for the targeted path.
- Exempt machine traffic (webhooks, API, monitors) with a configuration rule, and test one webhook.
- Add or tighten a rate limiting rule on the targeted path.
- If traffic bypasses Cloudflare, restrict the server firewall to Cloudflare IP ranges and plan an origin IP change.
- Tell your team and key customers if forms, payments or the portal are affected, and record times and actions for later.
- Turn Under Attack mode off once traffic returns to normal, then review what worked.
- Afterwards, fix the leaks you found and write down who has dashboard access. If the attack may have covered something else, follow our first 24 hours after a breach guide.
A DDoS attack is disruptive but rarely a data breach on its own. The businesses that recover fastest are the ones that already know where the switches are and which integrations will break when they flip them.
If you would like a second pair of eyes on your Cloudflare and server setup before you need it, request a free IT assessment. Core Florida IT is an independent IT provider that configures Cloudflare and protects business servers for companies across Miami-Dade and South Florida, as part of our cybersecurity services.
Sources
- DDoS Protection overview and plan availability (Cloudflare Docs)
- HTTP DDoS Attack Protection managed ruleset (Cloudflare Docs)
- HTTP DDoS ruleset parameters: sensitivity and actions (Cloudflare Docs)
- Under Attack mode (Cloudflare Docs)
- Security Level (Cloudflare Docs)
- Rate limiting rules (Cloudflare Docs)
- Protect your origin server (Cloudflare Docs)
