Cloudflare速率限制配置指南：5分钟防御CC攻击，免费版也能用

凌晨3点,手机突然疯狂震动。睁开眼一看,全是服务器监控告警。赶紧爬起来打开电脑,CPU使用率飙到100%,网站已经完全打不开了。查了一圈日志才发现,有几十个IP在疯狂刷接口,每秒几百个请求往上怼。这就是传说中的CC攻击。说实话,那天晚上我真的挺崩溃的。一边手忙脚乱地封IP,一边想着该怎么办。临时封了几个IP,马上又有新的IP顶上来,根本封不过来。后来折腾了两个多小时,才想起来Cloudflare应该有防护功能。打开后台一看,果然有个Rate Limiting(速率限制)功能。当时我以为这玩意儿肯定要付费,犹豫了半天要不要开。结果点进去一看,免费版居然就能用!配置了一条规则,限制单IP每分钟最多20个请求,超过就封10分钟。5分钟搞定,立竿见影,攻击流量直接被拦在外面了。那次以后我才明白,其实防御CC攻击没那么复杂,关键是要提前配置好速率限制规则。今天就来聊聊怎么用Cloudflare的速率限制功能,包括免费版怎么用、阈值该设多少、不同场景怎么配置,还有一些容易踩的坑。如果你也担心网站被攻击,或者想提前做好防护,这篇文章应该能帮到你。

什么是CC攻击?速率限制为什么能防住它

先说说CC攻击到底是啥。CC的全称是Challenge Collapsar,说白了就是模拟一堆正常用户疯狂访问你的网站,把服务器资源耗尽。你可能会问,这不就是DDoS吗?其实还真不太一样。传统的DDoS攻击比较粗暴,直接发送大量垃圾数据包,特征很明显,Cloudflare的自动DDoS防护基本能拦住。但CC攻击更狡猾,它发的是正常的HTTP请求,就像真人在访问一样,所以传统的DDoS防护可能识别不出来。举个例子,正常用户访问你的网站,可能1分钟就点几个页面,发起5-10个请求就差不多了。但CC攻击呢?单个IP可能30秒内就发起1000多个请求,这明显就不正常了。而且攻击者往往会用很多台机器(或者代理IP)一起发起攻击,流量特别分散,更难防。 速率限制就是针对这个特点设计的。它的原理很简单:监控每个IP(或者会话、API密钥等)的请求频率,如果超过你设定的阈值,就采取行动——可以是弹个验证码让对方证明自己是真人,也可以直接封禁一段时间。拿我之前遇到的那次攻击来说,攻击者的IP每秒能发200-300个请求,而我设置的阈值是每分钟20个。这样一来,攻击流量在第1-2秒就会触发限制,后面的请求就被拦在外面了。正常用户呢?根本不会触发这个限制,所以体验不受影响。有个数据你可能感兴趣:阿里云WAF的最佳实践文档里提到,典型CC攻击中,单台傀儡机在30秒内能发起1000次以上请求,而正常用户通常每分钟不超过10次。这个差距还是很明显的。说到这,你可能会担心:万一有正常用户操作比较快呢?比如在API接口快速刷新数据?这个问题确实存在,所以阈值的设置很关键,后面我会详细讲不同场景该设多少。

免费版也能用!Cloudflare速率限制功能全解析

这个必须重点说一下,很多人(包括以前的我)都以为速率限制是付费功能。其实从2022年10月开始,Cloudflare把速率限制免费开放给所有用户了,包括Free、Pro、Business计划。之前是什么情况呢?在2022年之前,如果你想用速率限制功能,得按流量付费,每百万请求收5美元。对于流量大的网站来说,这笔费用其实挺可观的。我当时就因为这个,一直没舍得开。但现在完全不用担心了。Cloudflare在官方博客里明确宣布,速率限制规则已经包含在所有计划里,不再额外收费。免费版用户可以创建1条速率限制规则,Pro和Business用户能创建更多条。你可能会想,才1条规则够用吗?说实话,对于中小网站来说,1条规则真的够了。关键是要把这条规则用在最容易被攻击的地方——通常是登录接口、注册接口或者核心API接口。我自己的几个小项目,都是只配了1条规则,专门保护登录接口。运行了快一年,基本没遇到过问题。偶尔有些小规模的扫描攻击,也都被拦下来了。当然,如果你的业务比较复杂,有多个需要保护的接口,那可能需要升级到Pro或Business计划。Pro计划每月20美元,可以创建10条规则;Business计划每月200美元,可以创建15条规则。不过对于个人站点和中小企业来说,免费版的1条规则通常就能解决大部分问题。还有一点要提醒:虽然免费版只有1条速率限制规则,但Cloudflare的基础DDoS防护是所有计划都包含的,而且不限流量。所以对于明显的DDoS攻击,会被自动拦截。速率限制主要是针对那些更隐蔽的CC攻击和接口滥用。 免费版 vs 付费版的主要区别:

规则数量: Free 1条,Pro 10条,Business 15条
高级特征: 付费版可以用更复杂的匹配条件,比如Bot Score、JA3指纹等
响应时间: 付费版在高流量场景下响应更快对于刚开始接触速率限制的朋友,我建议先用免费版试试水。配置一条规则保护你最重要的接口,跑一段时间看看效果。如果确实需要更多规则,再考虑升级也不迟。

阈值怎么设?不同场景的配置建议

这个问题我当时也很头疼。第一次配置的时候,盯着那个”Requests per period”输入框发愁:设10还是100?设太低怕把正常用户拦了,设太高又担心防不住攻击。后来查了Cloudflare官方文档和一些大厂的最佳实践,再结合自己的实际测试,总结了一些不同场景的推荐阈值。注意这些都是参考值,你需要根据自己网站的实际流量特征来调整。

登录/注册接口(最容易被攻击)

登录接口是重灾区,经常被用来做暴力破解和撞库攻击。这种接口的特点是:正常用户访问频率很低,但一旦被攻击,流量会很大。 推荐配置(三层递进式): Cloudflare官方推荐用三层规则,这样既能防住攻击,又不会误伤正常用户:

第1层: 4次请求/分钟 → 触发JavaScript挑战
第2层: 10次请求/10分钟 → 触发验证码(CAPTCHA)
第3层: 20次请求/小时 → 直接封禁1天不过免费版只有1条规则,所以我们得简化一下。我自己用的配置是:
单层配置: 20次请求/60秒 → 封禁10分钟这个阈值是怎么定的?我翻了一下自己网站的日志,发现正常用户登录时,就算输错密码重试,通常一分钟内也不会超过5次。而攻击脚本呢?基本上一分钟能打几百上千次。所以20次/分钟这个阈值,既能拦住绝大多数攻击,也不会误伤正常用户。如果你的网站对安全要求特别高,可以设得更严格:
严格模式: 10次请求/60秒 → 封禁1小时

API接口(按业务特性调整)

API接口的情况比较复杂,不同类型的API访问频率差别很大。 普通查询类API:

推荐配置: 30次请求/10秒 → JavaScript挑战这个阈值对应的是每秒3个请求,对于大多数正常的前端应用来说够用了。如果有用户快速刷新,也不至于立刻被封。 计算密集型API(比如图片处理、数据分析):
推荐配置: 10次请求/60秒 → 限速这类API消耗服务器资源比较大,所以阈值要设低一些。每分钟10次,对于正常使用来说完全够了,但能有效防止有人恶意调用耗尽资源。 公开API(对外提供的服务):
推荐配置: 根据你的API计费模式和资源承受能力来定如果你提供免费API,可以设成100次/小时;如果是付费API,可以根据套餐等级设置不同的限制。 Google Cloud Armor有个参考案例:他们建议对API设置2000次请求/20分钟,超出后限制20%的流量。这种渐进式限速的方式也值得借鉴。

普通网页(防内容爬取)

普通网页的访问频率比API低,但也要防止有人恶意爬取内容。 推荐配置:

常规页面: 100次请求/30秒 → JavaScript挑战
特殊页面(搜索、下载等): 50次请求/60秒 → 验证码为什么普通页面的阈值设这么高?主要是考虑到正常用户浏览网页时,可能会快速点击多个链接,加上页面里的CSS、JS、图片等资源,一个页面可能产生十几个请求。所以30秒100次,对正常浏览来说不会触发。但对于爬虫来说,30秒100次请求的速度还是太快了,很容易被拦下来。 特别注意:不要在首页设置太严格的限制!我之前遇到过一个坑:给首页设了很严格的速率限制,结果把Google和Bing的爬虫都拦了,SEO排名直接掉下去。后来赶紧把首页的规则删了,才恢复过来。

实际案例参考

阿里云WAF的最佳实践文档里给了个中小站点的预防性配置:

当单个IP在30秒内访问超过1000次 → 封禁10小时这个配置比较宽松,适合用来做兜底防护。如果你不确定该设多少,可以先用这个作为起点,然后根据实际日志调整。还有个技巧:配置规则之后,先不要直接用”Block”(封禁)动作,可以先用”Managed Challenge”(托管挑战)。这样即使阈值设得有点低,真人用户也能通过验证码继续访问,不会被完全拦住。等跑一段时间,确认没有误伤,再改成”Block”。

5分钟配置教程(手把手教你)

说了这么多理论,现在来点实战的。我会一步步教你怎么配置速率限制规则,真的很简单,5分钟就能搞定。

步骤1:进入Rate Limiting规则页面

登录Cloudflare后台,选择你要配置的域名,然后按这个路径走: Security → WAF → Rate limiting rules 点进去之后,如果你之前没配置过,应该能看到一个”Create rule”按钮。免费版用户这里会显示”0/1 rules”,意思是你还可以创建1条规则。

步骤2:填写基本信息

点”Create rule”之后,会看到一个配置页面。先填最上面的基本信息: Rule name(规则名称): 建议起个有意义的名字,比如”Login-Rate-Limit”或”API-Protection”。以后如果有多条规则,好找一些。

步骤3:配置匹配条件(Expression)

这一步是告诉Cloudflare,什么样的请求要被这条规则监控。 如果你要保护登录接口,可以这样配置:

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

这表示只监控访问/api/login这个路径的请求。 如果你要保护整个API,可以用包含匹配:

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

这样所有访问/api/开头的路径都会被监控。还可以加更多条件。比如你想排除某些User-Agent(比如你自己的监控脚本),可以点”And”添加额外条件:

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

步骤4:设置速率限制参数(核心)

这是最关键的部分,决定了什么时候触发限制。 Characteristics(计数特征): 选择用什么来识别和计数请求。最常用的选项:

IP Address: 根据访问者的IP地址计数(推荐,防CC攻击首选)
Session: 根据Cookie中的会话ID计数(适合已登录用户)
Headers: 根据HTTP头部计数(比如API Key,适合API保护) 对于登录接口防护,选IP Address就行。 Period(时间窗口): 从下拉菜单选择时间窗口,比如10秒、30秒、60秒等。我一般选60秒,也就是1分钟。时间太短(比如10秒)可能容易误伤,时间太长(比如10分钟)可能防护效果打折扣。 Requests per period(请求阈值): 这就是前面说的阈值,在这个时间窗口内允许多少个请求。根据前面的建议,登录接口可以设20,API接口可以设30。 Duration(封禁时长): 触发限制后,要封多久。选项从1分钟到24小时不等。我一般选10分钟。时间太短可能攻击者马上又来,时间太长可能误伤正常用户。举个完整例子,保护登录接口的配置:
Characteristics: IP Address
Period: 60 seconds
Requests: 20
Duration: 10 minutes 意思是:根据IP地址统计,如果1分钟内同一个IP访问登录接口超过20次,就封这个IP 10分钟。

步骤5:选择响应动作(Action)

触发限制后,要怎么处理这些请求?有几个选项: Managed Challenge(托管挑战) - 推荐首选: Cloudflare会自动判断是真人还是机器人。真人可能会看到一个验证页面(有时候甚至直接通过),机器人会被拦住。这个选项体验最好,误伤后影响最小。 Block(直接拦截): 直接返回403错误,拒绝访问。防护效果最好,但如果误伤就比较麻烦。建议在确认规则没问题之后再用。 Legacy CAPTCHA(传统验证码): 弹出验证码,用户输入正确才能继续。体验一般,但能有效区分真人和机器人。 JS Challenge(JavaScript挑战): 发送一段JavaScript代码给客户端执行,验证是否是真实浏览器。对爬虫有效,但对正常用户几乎无感知。我建议刚开始用Managed Challenge,跑一段时间确认没问题,再改成Block提高防护强度。

步骤6:保存并启用

配置完之后,拉到页面底部,点”Deploy”按钮。规则会立即生效,不需要等待。

步骤7:验证规则是否生效

配置完后,可以简单测试一下。用curl或者浏览器快速访问多次看看:

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

如果配置正确,前20次应该正常,第21次起应该会收到429状态码或者看到挑战页面。你也可以去Cloudflare后台的Security → Events查看拦截日志,确认规则在工作。

完整配置示例

假设我要保护一个登录接口/api/auth/login,这是我的完整配置: 基本信息:

Rule name: Login-Rate-Limit 匹配条件:
URI Path equals /api/auth/login 速率限制参数:
Characteristics: IP Address
Period: 60 seconds
Requests: 20
Duration: 10 minutes 响应动作:
Action: Managed Challenge 点Deploy,搞定!整个过程真的就5分钟。

高级技巧和常见坑

配置速率限制规则看起来简单,但实际用起来还是有些坑的。这里分享几个我踩过的坑和一些高级技巧。

坑1: 误伤SEO爬虫

这个坑我前面提过,但真的很重要,再强调一次。 千万不要在首页或者全站配置过严的速率限制! 我之前有个项目,为了省事,直接给整个网站配了一条规则:30秒超过50次请求就封。结果运行了一周,发现Google Search Console里抓取错误暴增。仔细一查,原来是Google的爬虫访问网站时,会同时抓取CSS、JS、图片等很多资源,很容易触发限制。后来我改成只保护登录和API接口,普通页面不设限制,问题就解决了。建议:

登录、注册、API等敏感接口:严格限制
普通内容页面:宽松限制或不限制
首页:尽量不设限制如果你确实需要防止内容被爬取,可以用Cloudflare的Bot Management功能(付费),它能识别善意爬虫(如Google)和恶意爬虫,区别对待。

坑2: 攻击者绕过速率限制

有个朋友配置了速率限制,结果还是被CC攻击打穿了。后来发现,攻击者直接绕过Cloudflare,用服务器真实IP发起攻击。 为什么会这样? Cloudflare只是一个反向代理,它在你的服务器前面挡着。但如果攻击者知道你服务器的真实IP,直接访问源服务器,就绕过Cloudflare了。 解决办法:

在服务器防火墙只允许Cloudflare的IP访问 Cloudflare官方提供了IP列表(IPv4和IPv6),你可以配置防火墙,只允许这些IP访问80和443端口。对于Linux服务器,可以用这个脚本:

# 只允许Cloudflare IP访问
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

定期更换源服务器IP 如果源IP已经泄露,考虑更换。同时注意不要在DNS里直接暴露源IP。
使用Cloudflare的Authenticated Origin Pulls 这是一个更高级的方案,要求客户端提供Cloudflare的证书,确保请求确实来自Cloudflare。

坑3: 忘记监控调整

配置规则不是一劳永逸的,需要定期检查调整。我见过有人设了规则之后就不管了,结果:

阈值设太低,经常误伤正常用户,用户投诉客服也不知道
业务增长了,访问量上去了,原来的阈值不合适了
攻击模式变了,规则没更新,防护效果下降建议: 定期(比如每月)检查Cloudflare的Security Analytics:
看看拦截了多少请求
是否有明显的误伤(正常用户触发了限制)
429错误率是否异常根据数据调整阈值:
如果429错误很少,可以考虑降低阈值提高防护
如果429错误很多,可能需要提高阈值或调整规则

技巧1: 分布式攻击的应对

现在的CC攻击越来越智能,攻击者会用大量代理IP发起攻击,每个IP的请求频率都不高,很难被简单的IP限速拦住。 对付分布式攻击的几个方法:

使用Session/Cookie计数(而不是IP) 如果你的网站有会话机制,可以用Session ID来计数。攻击者即使换IP,Session ID不变,照样会被拦。配置时Characteristics选Cookie,然后指定你的Session Cookie名称。
结合User-Agent过滤 很多攻击脚本的User-Agent都很异常,比如包含”Python”、“curl”等工具特征。可以在匹配条件里加上User-Agent过滤。
使用Bot Management(付费功能) 这是最强的方案,Cloudflare会给每个请求打分(1-100),分数越低越可能是机器人。你可以设置规则:只对Bot Score < 30的请求应用速率限制。不过这个功能需要Business或Enterprise计划,不是所有人都用得起。

技巧2: 渐进式响应策略(付费版)

前面提到过Cloudflare官方推荐的三层防护,虽然免费版只有1条规则,但付费版用户可以试试这个策略: 第1层(宽松):

阈值: 较高(如30次/分钟)
动作: JS Challenge(几乎无感知) 第2层(中等):
阈值: 中等(如50次/10分钟)
动作: Managed Challenge(可能需要验证) 第3层(严格):
阈值: 较低(如100次/小时)
动作: Block 24小时(封禁) 这样可以给真人用户更多机会,同时对顽固攻击者加大惩罚力度。

技巧3: 针对特定地区的防护

如果你的业务主要在中国,可以考虑对海外流量设置更严格的限制。在Expression里加上地理位置条件:

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

这样只对非中国的IP应用严格限制,国内用户不受影响。不过要注意,有些正常用户可能用VPN,也会被当成海外流量。所以还是建议用Challenge而不是直接Block。

最后说几句

说了这么多,其实核心就一句话:配置速率限制真的不难,关键是要提前做,别等到被攻击了才想起来。我见过太多朋友,都是半夜被告警吵醒才开始研究怎么防护。那种手忙脚乱的感觉,真的很糟糕。而如果你提前花5分钟配好规则,就能安心很多。给你的行动建议:

现在就去配置一条规则,哪怕你的网站从来没被攻击过。防患于未然总比临时抱佛脚强。
从登录接口开始。如果你只有1条免费规则的额度,就用在登录或注册接口上。这是最容易被攻击的地方,也是最需要保护的地方。
配置后测试一下。用curl或者浏览器快速刷新几次,确认规则会触发。然后去Security Events里看看拦截日志,确保一切正常。
定期检查调整。设个提醒,每个月看一次Security Analytics,根据实际情况调整阈值。最后再提醒一下:千万记得在服务器防火墙只允许Cloudflare IP访问,不然攻击者绕过Cloudflare直接打你源站,配再多规则也没用。如果你在配置过程中遇到问题,可以参考Cloudflare的官方文档,或者去社区论坛问问。大部分问题都有人遇到过,能找到解决方案。希望这篇文章能帮你顺利配置好速率限制,让网站远离CC攻击的困扰。

发布于: 2025年12月1日 · 修改于: 2025年12月4日

Easton

技术开发

Cloudflare速率限制配置指南：5分钟防御CC攻击，免费版也能用

什么是CC攻击?速率限制为什么能防住它

免费版也能用!Cloudflare速率限制功能全解析

阈值怎么设?不同场景的配置建议

登录/注册接口(最容易被攻击)

API接口(按业务特性调整)

普通网页(防内容爬取)

实际案例参考

5分钟配置教程(手把手教你)

步骤1:进入Rate Limiting规则页面

步骤2:填写基本信息

步骤3:配置匹配条件(Expression)

步骤4:设置速率限制参数(核心)

步骤5:选择响应动作(Action)

步骤6:保存并启用

步骤7:验证规则是否生效

完整配置示例

高级技巧和常见坑

坑1: 误伤SEO爬虫

坑2: 攻击者绕过速率限制

坑3: 忘记监控调整

技巧1: 分布式攻击的应对

技巧2: 渐进式响应策略(付费版)

技巧3: 针对特定地区的防护

最后说几句

Astro Cloudflare部署完全指南：SSR配置+国内访问3倍提速

从零搭建Astro博客：1小时完成首页到部署的完整指南

Astro是什么？3分钟看懂零JS、孤岛架构和内容优先的真正含义

什么是CC攻击?速率限制为什么能防住它

免费版也能用!Cloudflare速率限制功能全解析

阈值怎么设?不同场景的配置建议

登录/注册接口(最容易被攻击)

API接口(按业务特性调整)

普通网页(防内容爬取)

实际案例参考

5分钟配置教程(手把手教你)

步骤1:进入Rate Limiting规则页面

步骤2:填写基本信息

步骤3:配置匹配条件(Expression)

步骤4:设置速率限制参数(核心)

步骤5:选择响应动作(Action)

步骤6:保存并启用

步骤7:验证规则是否生效

完整配置示例

高级技巧和常见坑

坑1: 误伤SEO爬虫

坑2: 攻击者绕过速率限制

坑3: 忘记监控调整

技巧1: 分布式攻击的应对

技巧2: 渐进式响应策略(付费版)

技巧3: 针对特定地区的防护

最后说几句

相关文章

Astro Cloudflare部署完全指南：SSR配置+国内访问3倍提速

从零搭建Astro博客：1小时完成首页到部署的完整指南

Astro是什么？3分钟看懂零JS、孤岛架构和内容优先的真正含义