2026年11月12日

Cloudflare DDoS Protection for WordPress: Defaults, Rules, Origin

Networking & Connectivity

This article is a localized edition of the Japanese original. Read the Japanese original

Cloudflare provides DDoS protection at layers 3 and 4 (the network layer) and layer 7 (HTTP) on every plan, including the Free plan, with no limit on attack volume. Attacks are detected and mitigated automatically, so there is no special switch to "turn on DDoS protection".

However, this protection only applies to traffic that goes through Cloudflare. It doesn't help if your DNS setup is incomplete, or if your server's (the origin's) IP address is known and attacked directly. Also, "low-volume but persistent" traffic, such as brute-force attempts on the WordPress login page, may not be stopped by automatic DDoS protection. Using a WordPress site as the example, this article walks through the settings to make in Cloudflare and on the origin side, in order.

Dashboard labels are written as they appear in Cloudflare's new security dashboard as of October 2026. Cloudflare sometimes changes its layout, so if you can't find something, check the current location in the official documentation (developers.cloudflare.com).

Step 1: Add your site to Cloudflare and proxy the DNS records

Add the domain in the Cloudflare dashboard, then, in the control panel of the company where the domain is registered, change the name servers to the ones Cloudflare shows.
Under "DNS" → "Records", confirm that the "Proxy status" of your website's A / AAAA / CNAME records is "Proxied" (orange cloud).

Records set to "DNS only" (gray cloud) don't go through Cloudflare, so neither DDoS protection nor the WAF applies to them. DNS-only records also expose the origin's IP address as-is. Check these points too.

Whether a subdomain such as mail points to the same IP address as the web server as DNS only
Whether TXT records such as SPF contain the web server's IP address
Whether you send email from the same server as the web server (the IP address can be found in email headers and bounce messages)

Because DNS records from before onboarding remain on record externally, Cloudflare recommends changing the origin's IP address after onboarding. If your IP address is already being targeted, ask your server provider whether the IP address can be changed.

Also set the "SSL/TLS" encryption mode to "Full (strict)" and install a valid certificate on the origin, so the connection between Cloudflare and the origin is verified HTTPS as well.

Step 2: Check the HTTP DDoS protection sensitivity

HTTP DDoS protection runs by default as a Cloudflare-managed ruleset (HTTP DDoS attack protection). The defaults are usually fine, but if legitimate traffic is being blocked, or you want attacks stopped sooner, you can create an override to change the sensitivity and action.

Open "Security" → "Security rules" and select the "DDoS protection" tab.
Under "HTTP DDoS attack protection", select "Create override".
Give it a name in "Override name", choose "Ruleset action" and "Ruleset sensitivity", and click "Save".

The available values are as follows (according to the official documentation as of October 2026).

Setting	Options
Ruleset sensitivity	High (default), Medium, Low, Essentially Off
Ruleset action	Block, Managed Challenge, Interactive Challenge (Log only with Enterprise Advanced DDoS Protection)

High is the most sensitive. Lowering the sensitivity reduces false positives but also raises the threshold before an attack is mitigated. Plans without Advanced DDoS Protection can create only one override, and it applies to all requests.

Step 3: Add a custom rule for the login page and XML-RPC

On WordPress, brute-force attempts against /wp-login.php and /xmlrpc.php are common. Putting a challenge (a browser check) on these requests makes it harder for bulk bot traffic to reach the origin. Set this up with a custom rule (the feature that replaced the former "Firewall Rules").

In "Security" → "Security rules", select "Create rule" → "Custom rules".
Enter a name in "Rule name".
Under "When incoming requests match", open "Edit expression" and enter the expression below (building it by selecting fields gives the same result).
Under "Then take action", choose "Managed Challenge" and click "Deploy".

This is the expression to enter in step 3.

(http.request.uri.path eq "/wp-login.php") or (http.request.uri.path eq "/xmlrpc.php")

If you don't use XML-RPC (no posting from Jetpack or external apps), you can set /xmlrpc.php to "Block". If you do use it, a challenge will stop the apps from connecting, so leave it out of this rule.

If administrators have a fixed IP address, adding a condition that excludes it saves you from being challenged yourself.

((http.request.uri.path eq "/wp-login.php") or (http.request.uri.path eq "/xmlrpc.php")) and not ip.src in {203.0.113.10}

203.0.113.10 is an example; replace it with your own IP address. The official documentation recommends starting with "Managed Challenge" rather than "Block", checking the matched requests under "Security" → "Analytics" → "Events", and only then switching to "Block". You can create 5 custom rules on Free, 20 on Pro, and 100 on Business (as of October 2026).

Step 4: Limit login attempts with a rate limiting rule

When the same IP address sends many requests in a short time, stop it with a rate limiting rule. In "Security" → "Security rules", select "Create rule" → "Rate limiting rules" and configure it as follows.

Condition: URI Path equals /wp-login.php
Counted by: IP address
Threshold: for example, 10 requests per 10 seconds
Action: Block ("Duration" is how long the block lasts)

On the Free plan you get one rate limiting rule, the only fields you can use in the condition are Path and Verified Bot, counting is by IP only, and both the period and the block duration are fixed at 10 seconds (as of October 2026). Displaying the login page and submitting the login each generate requests, so setting the threshold too low will block people who are logging in normally. After setting it up, log in yourself to check.

Step 5: Use Under Attack mode while you’re under attack

When a layer 7 attack is slowing your site down, turn on "Under Attack mode" temporarily. When you turn on "Under Attack Mode" in "Quick Actions" on the domain's "Overview" page, every visitor sees a browser check screen, and only those who pass can view the site.

Use it as a last resort and turn it off once the attack subsides. It isn't meant to stay on all the time.
Visitors whose browsers don't run JavaScript, and traffic from external services (APIs, feeds, payment notifications, and so on), may no longer get through.
To apply it only to the admin area, you can also create a rule under "Rules" → "Configuration Rules" that matches the path and turn on "I'm Under Attack".

If the problem is just a lot of bot traffic, you can also go to "Security" → "Settings", filter by "Bot traffic", and turn on "Bot fight mode" (available on the Free plan). However, Bot fight mode can't be bypassed with custom rules and may challenge API or app traffic, so on sites that use external integrations, test it before relying on it.

Step 6: Keep the origin server from being attacked directly

If the origin's IP address is known, attackers can bypass Cloudflare and reach the server directly. On a VPS or dedicated server, configure the firewall so the web ports (80 and 443) accept connections only from Cloudflare's IP addresses. Cloudflare publishes its IP ranges at https://www.cloudflare.com/ips/.

Here is an example using ufw on Ubuntu. If you don't allow the SSH port first, you'll lock yourself out, so be careful.

# Allow SSH first (adjust if you changed the port)
sudo ufw allow OpenSSH

# Allow 80/443 only from Cloudflare's IP ranges
for ip in $(curl -s https://www.cloudflare.com/ips-v4) $(curl -s https://www.cloudflare.com/ips-v6); do
  sudo ufw allow proto tcp from "$ip" to any port 80,443
done

# Delete any rule that allowed 80/443 from anyone (example)
sudo ufw delete allow 'Apache Full'

sudo ufw status numbered

Cloudflare's IP ranges can change, so check the list periodically. On shared hosting you usually can't configure the firewall yourself, so use the WAF or IP restriction features your hosting provider offers.

For stronger protection, there is also Authenticated Origin Pulls, which uses a certificate to verify that connections come from Cloudflare (available when the encryption mode is Full or Full (strict)), and Cloudflare Tunnel, which connects the origin to Cloudflare without a public IP address (you install cloudflared on the server).

Step 7: Record visitors’ real IP addresses on the origin

When traffic goes through Cloudflare, the client address seen in server logs and by WordPress is a Cloudflare IP address. As a result, log investigation and IP restrictions in security plugins don't work correctly. On Apache, use mod_remoteip to restore the real IP address from the CF-Connecting-IP header that Cloudflare adds.

sudo a2enmod remoteip

Create /etc/apache2/conf-available/remoteip.conf with the following content. For RemoteIPTrustedProxy, list every Cloudflare IP range, one per line.

RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 103.21.244.0/22
# List all the ranges from https://www.cloudflare.com/ips/ below

To record the real IP address in the access log, change %h to %a in the LogFormat in /etc/apache2/apache2.conf.

sudo a2enconf remoteip
sudo apache2ctl configtest
sudo systemctl restart apache2

If you put ranges other than Cloudflare's in RemoteIPTrustedProxy, Apache will trust client IP addresses forged in the header, so use only the official list.

Things to keep in mind

Cloudflare's DDoS protection doesn't reduce the load from uncached dynamic pages (WordPress login, search, cart, and so on). Throttle heavy requests with the rules from Steps 3 and 4.
After adding rules, check that admin login, posting, contact forms, payments and external integrations still work. If something stops working, check "Security" → "Analytics" → "Events" to see which rule blocked it.
Features and limits per plan can change. Check the current details in the official documentation before configuring.

Summary

Cloudflare's DDoS protection works automatically on all plans. First check that your website's DNS records are "Proxied" and that the origin's IP address hasn't leaked.
You can override HTTP DDoS sensitivity and action on the "DDoS protection" tab of "Security rules", but the defaults are usually fine.
On WordPress, put custom rules and rate limiting on /wp-login.php and /xmlrpc.php.
Use Under Attack mode only while you're under attack.
Have the origin accept connections only from Cloudflare's IP addresses, and record the real client IP with mod_remoteip.

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)