摘要：# 当CC攻击来敲门，我用Cloudflare这个“限流阀”把它挡在门外 说实话，干网络安全这行久了，最烦的就是那种“PPT防护”——方案写得天花乱坠，真遇到CC攻击（Challenge Collapsar，说白了就是模拟大量真人请求搞垮你网站的攻击）的…

当CC攻击来敲门，我用Cloudflare这个“限流阀”把它挡在门外

说实话，干网络安全这行久了，最烦的就是那种“PPT防护”——方案写得天花乱坠，真遇到CC攻击（Challenge Collapsar，说白了就是模拟大量真人请求搞垮你网站的攻击）的时候，该崩还是崩。我自己就看过不少中小型站点，问题往往不是没上防护，而是防护策略配得稀里糊涂，钱花了，效果没见着。

今天不聊那些虚头巴脑的大方案，就聚焦一个具体、实用、甚至有点“小众”但极其有效的实操点：如何用Cloudflare自带的Rate Limiting（速率限制）规则，实实在在地防住CC攻击。 这玩意儿用好了，很多时候比你去买一堆昂贵的高防服务都管用。

一、先泼盆冷水：Cloudflare的免费防护不是万能的

很多朋友一听Cloudflare，第一反应就是“免费的CDN，能防攻击”。这话对，也不对。

Cloudflare的默认防护（比如它的WAF规则集）确实能拦住大部分自动化脚本和明显的恶意流量。但CC攻击恶心就恶心在，它经常模仿正常用户的行为——用真实的浏览器，间隔几秒访问几个页面，IP地址还可能经常换（比如从代理池来）。这种流量，在Cloudflare看来，跟普通用户没太大区别，它默认的“盾牌”可能就放行了。

结果就是：你的源站服务器（比如一台小小的VPS）CPU和内存直接被这些“假用户”占满，真用户反而打不开网站。说白了，攻击成本可能就几十块钱，但你的业务停摆损失可就大了去了。

所以，核心思路不是指望Cloudflare全自动搞定，而是我们要学会给它划一条明确的“红线”：告诉它，超过某个频率的请求，不管你看上去多正常，都给我拦下来。这就是Rate Limiting的活儿。

二、Rate Limiting实战：别上来就乱设规则

在Cloudflare控制台的“安全性” -> “WAF” -> “速率限制规则”里，你可以创建规则。但很多新手容易犯两个错误：

1. 限得太死：比如，设置“每分钟每个IP只能请求5次”。得，你网站正常用户稍微多刷几下页面，或者有个爬虫来抓数据，连人带爬虫一起被拦了，误伤惨重。
2. 限得太宽：比如，“每分钟每个IP允许请求120次”。对于真正的CC攻击来说，这额度太充裕了，根本形同虚设。

那怎么设？我的经验是，分场景、分路径、动态调整。别想着一刀切。

场景一：针对登录口的“暴力破解”式CC攻击

攻击者最喜欢用大量密码组合撞你的登录接口（比如 /wp-login.php 或 /api/login）。这种请求特征很明显：高频、短时间、针对单一敏感路径。

实战规则可以这么配：

• 规则名称：保护登录接口 - 严格模式 （自己看得懂就行）
• 路径：*你的域名.com/wp-login.php* （使用通配符*确保覆盖所有变体）
• 请求频率：每分钟 10 次。这个数很关键。一个正常用户，一分钟内登录失败10次？要么是忘了密码，要么就是有问题。就算真忘了，等一分钟也不是大事。
• 防护动作：“阻止”。对于这种明确的高危路径，不用客气。
• 持续时间：1小时。一旦触发，这个IP就被关一小时“禁闭”，清净。

（这里插句私货：我见过有站长把这个值设成“5分钟”，结果自己测试时输错两次密码就被锁了，气得直拍桌子。所以，一定要给自己留点容错空间。）

场景二：针对全站的“慢速”CC攻击

这种更隐蔽。攻击者用成千上万个IP，每个IP每分钟只请求你的首页或文章页5-6次，看上去完全“人畜无害”。但一万个IP加起来，就是每分钟五六万请求，服务器照样扛不住。

对付这种，就不能只靠限制单个IP了，得用上 “全局速率限制” 的思路。但Cloudflare的免费版和Pro版对全局限制有请求数门槛，不过我们可以变通一下。

实战策略：

1. 找到消耗最大的路径：先去服务器日志或Cloudflare Analytics里看看，攻击期间哪个页面或API被请求得最多。假设是首页 /。
2. 设置一个稍宽松但合理的单IP限制：比如，每分钟请求首页不超过30次。一个真实用户，疯狂刷新首页，一分钟30次也顶天了。
3. 启用“缓解期”：在规则的高级设置里，有个 “缓解期” 。比如设为 1分钟。意思是，如果一个IP在1分钟内触发了规则，那么接下来的1分钟内，它对这个路径的所有请求都会被直接阻止，而不仅仅是超过阈值的那部分。这相当于一个“冷静期”，能有效打断攻击节奏。
4. 组合使用：针对 /wp-admin/（后台）、/xmlrpc.php（WordPress的另一个攻击重灾区）等特定路径，设置更严格的、独立的Rate Limiting规则。这叫 重点部位，重点布防。

三、几个容易被忽略但巨实用的细节

1. 别忘了“响应代码”筛选：高级规则里可以设置“当响应代码为XXX时计数”。比如，你可以单独为 429（太多请求） 或 404（找不到页面） 设置限制。攻击者经常扫描不存在的路径（/admin.php, /test.cgi），产生大量404，用这个功能能精准过滤垃圾流量。
2. “速率限制”和“防火墙规则”打组合拳：在WAF的防火墙规则里，你可以根据IP的地理位置、ASN（自治系统号，比如某个已知的IDC或代理服务商）、甚至JA3指纹（一种客户端TLS指纹）来先过滤掉一波高风险的流量源，然后再让Rate Limiting规则处理剩下的。先圈定嫌疑范围，再精确打击。
3. 监控与调整：规则不是设完就一劳永逸的。头几天一定要看Cloudflare的“速率限制分析”报告，看看有多少请求被拦了，触发规则的IP主要来自哪里。如果误拦太多，就把阈值调高一点；如果攻击还在继续，就调低一点或缩短缓解期。这是个动态博弈的过程。

四、最后说点大实话

Cloudflare的Rate Limiting，尤其是免费版，是有局限的。比如它对全局总请求数的限制能力有限，对于海量分布式IP的CC攻击（DDoS级别的CC），最终还是得靠Cloudflare自身的Anycast网络和更高级的付费服务（如Pro版的更高额度、Business版的Advanced Rate Limiting）来扛。

但是，对于绝大多数中小网站遇到的、那种“让你业务卡顿、服务器报警、但又没完全打死”的日常性、中等规模的CC攻击，把Rate Limiting规则精心配置好，能解决你80%以上的烦恼。它就像在你家水管上装了个智能水阀，平时用水不受影响，但一旦检测到水管爆裂（异常高频请求），立马掐断，保护你家里的“装潢”（源站服务器）。

安全防护，很多时候不是堆砌最贵的技术，而是在关键环节上，把基础且有效的工具用到极致。Cloudflare的Rate Limiting，就是这么一件被很多人低估的“基础神器”。

行了，方法都告诉你了，赶紧去你后台看看，你的Rate Limiting规则是不是还空着，或者配得跟没配一样？是时候给它动动手术了。