Cloudflare Rate Limiting Guide: Defend Against CC Attacks in 5 Minutes, Even on the Free Plan

3 AM. My phone vibrating like crazy. I opened my eyes to a flood of server monitoring alerts. Rushed to my computer - CPU usage at 100%, website completely down. After digging through the logs, I found dozens of IPs hammering my endpoints with hundreds of requests per second. That’s when I learned what a CC attack really feels like.

Honestly, I was pretty overwhelmed that night. I was frantically banning IPs left and right, trying to figure out what to do. But as soon as I blocked a few, new ones would pop up. After struggling for over two hours, I finally remembered that Cloudflare should have some kind of protection feature. Logged into the dashboard and sure enough, there it was - Rate Limiting.

I thought for sure it would cost money, so I hesitated. But when I checked the settings, I was surprised to find the free tier includes it! I configured a simple rule - limit any single IP to 20 requests per minute, ban for 10 minutes if exceeded. Took 5 minutes to set up, worked like a charm - the attack traffic was instantly blocked.

That experience taught me that defending against CC attacks isn’t that complicated - the key is setting up rate limiting rules before you get hit. Today I’ll walk through how to use Cloudflare’s rate limiting feature, including how to use the free tier, what thresholds to set, how to configure different scenarios, and some common pitfalls to avoid. If you’re worried about your site getting attacked, or want to set up protection in advance, this guide should help.

What is a CC Attack? Why Does Rate Limiting Work?

Let me explain what a CC attack actually is. CC stands for Challenge Collapsar - basically, it simulates a bunch of normal users flooding your website to exhaust server resources.

You might ask, isn’t that just a DDoS? Not quite. Traditional DDoS attacks are more brute-force - they send massive amounts of garbage packets with obvious signatures that Cloudflare’s automatic DDoS protection can usually handle. But CC attacks are sneakier - they send normal HTTP requests that look like real users, so traditional DDoS protection might not catch them.

For example, a normal user visiting your site might click a few pages per minute, sending 5-10 requests tops. But a CC attack? A single IP could fire off 1000+ requests in 30 seconds. That’s clearly abnormal. And attackers often use many machines (or proxy IPs) together, making the traffic even more distributed and harder to block.

Rate limiting is designed specifically for this pattern. The principle is simple: monitor the request frequency for each IP (or session, API key, etc), and if it exceeds your threshold, take action - could be showing a CAPTCHA to prove they’re human, or directly blocking them for a period.

In the attack I experienced, the attacker’s IP was sending 200-300 requests per second, while I had set my threshold at 20 per minute. That means the attack traffic triggered the limit within the first 1-2 seconds, and subsequent requests were blocked. Normal users? They never even hit the limit, so their experience wasn’t affected.

Here’s an interesting data point: Alibaba Cloud’s WAF best practices doc mentions that in typical CC attacks, a single bot machine can launch 1000+ requests in 30 seconds, while normal users usually stay under 10 per minute. The difference is pretty obvious.

At this point, you might worry: what if a legitimate user is just operating quickly? Like rapidly refreshing data on an API? That’s a valid concern, which is why threshold configuration is critical - I’ll explain in detail later what values to use for different scenarios.

Free Tier Works Too! Complete Cloudflare Rate Limiting Breakdown

This is really important to emphasize - many people (including past me) thought rate limiting was a paid feature. Actually, since October 2022, Cloudflare has made rate limiting free for all users, including Free, Pro, and Business plans.

What was it like before? Prior to 2022, if you wanted to use rate limiting, you had to pay by traffic - $5 per million requests. For high-traffic sites, that could add up. That’s why I never enabled it back then.

But now you don’t need to worry. Cloudflare officially announced in their blog that rate limiting rules are included in all plans at no extra charge. Free tier users can create 1 rate limiting rule, while Pro and Business users can create more.

You might think, is just 1 rule enough? Honestly, for small to medium sites, 1 rule really is sufficient. The key is using that rule on the most attack-prone endpoints - typically login, registration, or core API endpoints.

For my own small projects, I only configured 1 rule specifically protecting the login endpoint. It’s been running for almost a year with basically no issues. The occasional small-scale scanning attack has all been blocked.

Of course, if your business is more complex with multiple endpoints needing protection, you might need to upgrade to Pro or Business. Pro is $20/month for 10 rules; Business is $200/month for 15 rules. But for personal sites and small businesses, the free tier’s 1 rule typically solves most problems.

One more thing to note: while the free tier only has 1 rate limiting rule, Cloudflare’s basic DDoS protection is included in all plans with unlimited traffic. So obvious DDoS attacks will be automatically blocked. Rate limiting is mainly for those more subtle CC attacks and API abuse.

Free vs Paid Tier Main Differences:

• Rule count: Free 1 rule, Pro 10 rules, Business 15 rules
• Advanced features: Paid tiers can use more complex match conditions like Bot Score, JA3 fingerprinting
• Response time: Paid tiers respond faster under high traffic

For beginners with rate limiting, I suggest starting with the free tier. Configure one rule to protect your most important endpoint, run it for a while and see how it performs. If you really need more rules, you can always upgrade later.

How to Set Thresholds? Configuration Recommendations for Different Scenarios

This question really gave me a headache at first. When I first configured it, I stared at that “Requests per period” input box wondering: set it to 10 or 100? Too low might block legitimate users, too high might not stop attacks.

After researching Cloudflare’s official docs and some big tech best practices, plus my own testing, I’ve summarized some recommended thresholds for different scenarios. Note these are reference values - you need to adjust based on your site’s actual traffic patterns.

Login/Registration Endpoints (Most Attack-Prone)

Login endpoints are ground zero, frequently targeted for brute force and credential stuffing attacks. These endpoints have a characteristic pattern: normal users access them infrequently, but once attacked, traffic spikes dramatically.

Recommended Config (Three-Tier Progressive):

Cloudflare officially recommends using three tiers so you can block attacks without harming legitimate users:

• Tier 1: 4 requests/minute → JavaScript Challenge
• Tier 2: 10 requests/10 minutes → CAPTCHA Challenge
• Tier 3: 20 requests/hour → Ban for 1 day

But the free tier only allows 1 rule, so we need to simplify. My personal config:

• Single Tier Config: 20 requests/60 seconds → Ban for 10 minutes

How did I arrive at this threshold? I checked my site’s logs and found that normal users logging in, even with password retry errors, rarely exceed 5 attempts in a minute. Attack scripts? They can easily hit hundreds or thousands per minute. So 20/minute blocks the vast majority of attacks without impacting real users.

If your site has especially high security requirements, you can be more strict:

• Strict Mode: 10 requests/60 seconds → Ban for 1 hour

API Endpoints (Adjust by Business Type)

API endpoints are more complex - different API types have vastly different access patterns.

Regular Query APIs:

• Recommended Config: 30 requests/10 seconds → JavaScript Challenge

This threshold corresponds to 3 requests per second, which works fine for most normal frontend apps. Even if users refresh quickly, they won’t immediately hit the limit.

Compute-Intensive APIs (like image processing, data analysis):

• Recommended Config: 10 requests/60 seconds → Rate limit

These APIs consume more server resources, so the threshold should be lower. 10 per minute is plenty for normal use but effectively prevents malicious resource exhaustion.

Public APIs (services you provide externally):

• Recommended Config: Based on your API billing model and resource capacity

If you offer a free API, you could set 100 requests/hour; for paid APIs, you can set different limits based on tier.

Google Cloud Armor has a reference case: they recommend setting APIs at 2000 requests/20 minutes, then throttling 20% of traffic once exceeded. This progressive throttling approach is worth considering.

Regular Web Pages (Prevent Content Scraping)

Regular pages have lower access frequency than APIs, but you still want to prevent malicious scraping.

Recommended Config:

• Regular pages: 100 requests/30 seconds → JavaScript Challenge
• Special pages (search, downloads, etc): 50 requests/60 seconds → CAPTCHA

Why set the threshold so high for regular pages? Mainly because normal users browsing might quickly click multiple links, plus CSS, JS, images and other resources - a single page might generate dozens of requests. So 100 in 30 seconds won’t trigger during normal browsing.

But for scrapers, 100 requests in 30 seconds is still too fast - they’ll easily get caught.

Special Note: Don’t set overly strict limits on your homepage! I learned this the hard way: I configured a strict rate limit on my homepage and ended up blocking Google and Bing crawlers, and my SEO rankings tanked. Had to quickly remove the homepage rule to recover.

Real-World Case Reference

Alibaba Cloud WAF’s best practices doc provides a preventive config for small-medium sites:

• When a single IP exceeds 1000 accesses in 30 seconds → Ban for 10 hours

This config is pretty loose, suitable as a baseline defense. If you’re unsure what to set, you can start here and adjust based on your actual logs.

Here’s another tip: after configuring rules, don’t immediately use the “Block” action - try “Managed Challenge” first. That way even if your threshold is a bit low, real users can still continue after solving a CAPTCHA, instead of being completely blocked. Run it for a while, confirm there’s no false positives, then switch to “Block”.

5-Minute Configuration Tutorial (Step by Step)

Enough theory - let’s get practical. I’ll walk you through configuring rate limiting rules step by step. It really is simple - 5 minutes to complete.

Step 1: Navigate to Rate Limiting Rules Page

Log into your Cloudflare dashboard, select the domain you want to configure, then follow this path:

Security → WAF → Rate limiting rules

Once there, if you haven’t configured any rules yet, you should see a “Create rule” button. Free tier users will see “0/1 rules”, meaning you can create 1 more rule.

Step 2: Fill in Basic Information

After clicking “Create rule”, you’ll see a configuration page. Start with the basic info at the top:

Rule name: Choose a meaningful name like “Login-Rate-Limit” or “API-Protection”. Makes it easier to find if you have multiple rules later.

Step 3: Configure Match Conditions (Expression)

This step tells Cloudflare what requests this rule should monitor.

If you want to protect a login endpoint, you can configure like this:

Field: URI Path
Operator: equals
Value: /api/login

This means only monitor requests to /api/login.

If you want to protect all APIs, use a contains match:

Field: URI Path
Operator: contains
Value: /api/

This monitors all paths starting with /api/.

You can add more conditions. For example, to exclude certain User-Agents (like your own monitoring scripts), click “And” to add extra conditions:

Field: User Agent
Operator: does not equal
Value: MyMonitorBot

Step 4: Set Rate Limiting Parameters (Core)

This is the most critical part, determining when the limit triggers.

Characteristics: Choose what to use for identifying and counting requests. Most common options:

• IP Address: Count by visitor IP (recommended for CC attack defense)
• Session: Count by session ID in cookies (good for logged-in users)
• Headers: Count by HTTP headers (like API Key, good for API protection)

For login endpoint protection, choose IP Address.

Period (Time Window): Select from dropdown options like 10 seconds, 30 seconds, 60 seconds, etc.

I usually choose 60 seconds (1 minute). Too short (like 10 seconds) might cause false positives, too long (like 10 minutes) might reduce protection effectiveness.

Requests per period (Request Threshold): This is the threshold we discussed earlier - how many requests are allowed in the time window.

Based on earlier recommendations, set 20 for login endpoints, 30 for API endpoints.

Duration (Ban Duration): How long to ban once triggered. Options range from 1 minute to 24 hours.

I usually choose 10 minutes. Too short and attackers might return immediately; too long might harm legitimate users.

Complete example for protecting a login endpoint:

• Characteristics: IP Address
• Period: 60 seconds
• Requests: 20
• Duration: 10 minutes

Meaning: Track by IP address, if the same IP accesses the login endpoint more than 20 times in 1 minute, ban that IP for 10 minutes.

Step 5: Choose Response Action

Once triggered, how should these requests be handled? Several options:

Managed Challenge - Recommended first choice: Cloudflare automatically determines if it’s human or bot. Real people might see a verification page (sometimes they even pass through directly), bots get blocked. Best experience, minimal impact if false positive occurs.

Block: Directly returns 403 error, denies access. Best protection but problematic if false positives occur. Best to use after confirming the rule works properly.

Legacy CAPTCHA: Shows a CAPTCHA, user must enter correctly to continue. Average experience but effectively distinguishes humans from bots.

JS Challenge: Sends JavaScript code to the client to execute, verifying it’s a real browser. Effective against scrapers but almost imperceptible to normal users.

I recommend starting with Managed Challenge, run it for a while to confirm no issues, then switch to Block for stronger protection.

Step 6: Save and Deploy

After configuration, scroll to the bottom and click the “Deploy” button. The rule takes effect immediately - no waiting required.

Step 7: Verify the Rule Works

After configuring, you can do a simple test. Use curl or a browser to access rapidly multiple times:

for i in {1..30}; do curl https://yourdomain.com/api/login; done

If configured correctly, the first 20 should be normal, then starting from #21 you should get a 429 status code or see a challenge page.

You can also check Security → Events in the Cloudflare dashboard to view blocking logs and confirm the rule is working.

Complete Configuration Example

Say I want to protect a login endpoint /api/auth/login, here’s my complete config:

Basic Info:

• Rule name: Login-Rate-Limit

Match Conditions:

• URI Path equals /api/auth/login

Rate Limiting Parameters:

• Characteristics: IP Address
• Period: 60 seconds
• Requests: 20
• Duration: 10 minutes

Response Action:

• Action: Managed Challenge

Click Deploy - done! Really takes just 5 minutes.

Advanced Tips and Common Pitfalls

Configuring rate limiting rules seems simple, but there are still some pitfalls in actual use. Here are some traps I’ve fallen into and some advanced techniques.

Pitfall 1: Blocking SEO Crawlers

I mentioned this earlier but it’s so important I’ll emphasize again.

Never configure overly strict rate limiting on your homepage or site-wide!

I had a project where, to save effort, I configured a single site-wide rule: ban after 50 requests in 30 seconds. After a week, I saw crawl errors exploding in Google Search Console. Turns out Google’s crawler simultaneously fetches CSS, JS, images and many other resources when visiting, easily triggering the limit.

I fixed it by protecting only login and API endpoints, leaving regular pages unrestricted.

Recommendations:

• Login, registration, API and other sensitive endpoints: strict limits
• Regular content pages: loose limits or no limits
• Homepage: avoid limits if possible

If you really need to prevent content scraping, use Cloudflare’s Bot Management feature (paid), which can distinguish between good crawlers (like Google) and bad ones, treating them differently.

Pitfall 2: Attackers Bypass Rate Limiting

A friend configured rate limiting but still got hit by a CC attack. Turns out the attacker bypassed Cloudflare entirely and hit the real server IP directly.

Why does this happen?

Cloudflare is just a reverse proxy sitting in front of your server. If attackers know your server’s real IP, they can access it directly and bypass Cloudflare.

Solutions:

1. Only allow Cloudflare IPs through your server firewall

Cloudflare provides official IP lists (IPv4 and IPv6), you can configure your firewall to only allow these IPs to access ports 80 and 443.

For Linux servers, you can use this script:

# Only allow Cloudflare IPs
for i in `curl https://www.cloudflare.com/ips-v4`; do
  ufw allow from $i to any port 443 proto tcp
  ufw allow from $i to any port 80 proto tcp
done

2. Regularly rotate origin server IP

If your origin IP has leaked, consider changing it. Also be careful not to expose the origin IP in DNS.

3. Use Cloudflare’s Authenticated Origin Pulls

A more advanced solution requiring clients to provide Cloudflare’s certificate, ensuring requests actually come from Cloudflare.

Pitfall 3: Forgetting to Monitor and Adjust

Configuration isn’t set-it-and-forget-it - you need regular checks and adjustments.

I’ve seen people set rules and never look back, resulting in:

• Threshold too low, frequently blocking legitimate users, even when users complain to support they don’t know why
• Business grew, traffic increased, old threshold no longer appropriate
• Attack patterns changed, rules not updated, protection effectiveness declined

Recommendations:

Regularly (like monthly) check Cloudflare’s Security Analytics:

• See how many requests were blocked
• Check for obvious false positives (legitimate users triggering limits)
• Monitor if 429 error rate is abnormal

Adjust thresholds based on data:

• If 429 errors are rare, consider lowering threshold for better protection
• If 429 errors are frequent, might need to raise threshold or adjust rules

Tip 1: Handling Distributed Attacks

Modern CC attacks are getting smarter - attackers use many proxy IPs to launch attacks, each IP’s request frequency staying low, hard to catch with simple IP rate limiting.

Ways to counter distributed attacks:

1. Use Session/Cookie counting (instead of IP)

If your site has a session mechanism, you can count by Session ID. Attackers changing IPs won’t help if the Session ID stays the same - they’ll still get caught.

When configuring, select Cookie for Characteristics and specify your Session Cookie name.

2. Combine with User-Agent filtering

Many attack scripts have abnormal User-Agents, like containing tool signatures such as “Python”, “curl”. You can add User-Agent filtering to match conditions.

3. Use Bot Management (paid feature)

The strongest solution - Cloudflare scores each request (1-100), lower scores more likely bot. You can set rules: only apply rate limiting to requests with Bot Score < 30.

However, this feature requires Business or Enterprise plans - not everyone can afford it.

Tip 2: Progressive Response Strategy (Paid Tier)

I mentioned Cloudflare’s officially recommended three-tier protection earlier. While the free tier only allows 1 rule, paid tier users can try this strategy:

Tier 1 (Loose):

• Threshold: Higher (like 30/minute)
• Action: JS Challenge (almost imperceptible)

Tier 2 (Medium):

• Threshold: Medium (like 50/10 minutes)
• Action: Managed Challenge (might need verification)

Tier 3 (Strict):

• Threshold: Lower (like 100/hour)
• Action: Block 24 hours

This gives real users more chances while ramping up punishment for persistent attackers.

Tip 3: Region-Specific Protection

If your business is mainly in China, you could set stricter limits for overseas traffic.

Add geo-location condition in Expression:

(ip.geoip.country ne "CN") and (http.request.uri.path eq "/api/login")

This only applies strict limits to non-China IPs, domestic users unaffected.

Note that some legitimate users might use VPNs and get treated as overseas traffic. So still recommend using Challenge instead of direct Block.

Final Thoughts

After all this, the core message is simple: Configuring rate limiting really isn’t hard - the key is doing it in advance, not waiting until you get attacked.

I’ve seen too many friends who only start researching protection after getting woken up at night by alerts. That panicked scrambling feeling is awful. But if you spend 5 minutes setting up rules in advance, you can sleep much better.

My action recommendations for you:

1. Go configure a rule right now, even if your site has never been attacked. Prevention is better than scrambling at the last minute.

2. Start with the login endpoint. If you only have 1 free rule quota, use it on your login or registration endpoint. That’s the most attack-prone and most protection-worthy place.

3. Test after configuring. Use curl or rapid browser refreshing to confirm the rule triggers. Then check Security Events to see blocking logs and ensure everything’s working.

4. Regular check-ins. Set a reminder to review Security Analytics monthly and adjust thresholds based on actual conditions.

One last reminder: Remember to configure your server firewall to only allow Cloudflare IPs, otherwise attackers can bypass Cloudflare and hit your origin directly, rendering all your rules useless.

If you run into issues during configuration, check Cloudflare’s official documentation or ask in their community forums. Most problems have been encountered before and have solutions.

Hope this article helps you successfully configure rate limiting and keep your site safe from CC attacks.

Published on: Dec 1, 2025 · Modified on: Dec 4, 2025

Easton

Technology