Cloudflare Pages免费额度一夜透支？被恶意刷量的排查与自救指南
最近几天后台收到一封让人心惊肉跳的账单提醒，打开 Cloudflare 仪表盘一看，好家伙，原本够用一个月的 Pages 免费构建请求额度，居然在一夜之间被刷到了红线。更离谱的是，流量来源高度集中，清一色的法国 IP。这到底发生了什么？是针对我个人的攻击，还是误伤了？今天就来复盘一下这次“被薅羊毛”的经历，顺便给各位站长提个醒，顺便分享如果不幸中招该如何自救。
一、 现象：一夜回到解放前
事情发生得很突然。前一天晚上我还看到额度剩余充裕，结果第二天早上起来，系统提示 10K 的免费额度已经见底。作为个人开发者，我在 Pages 上部署的项目非常简单，主要就是给自己和朋友用的一个临时邮箱服务和几个静态展示页。按理说，这点私域流量根本不可能触发 Cloudflare 的限额红线。
Cloudflare 后台流量分析图表，显示后半夜出现异常的流量垂直拉升，且主要集中在法国IP。
打开分析面板一看，数据图出现了一根诡异的“垂直拉升”线，时间主要集中在后半夜。更可疑的是，访问来源极其单一，绝大多数请求都指向那个临时邮箱的接口，而且 IP 归属地全都指向法国。这显然不是正常的用户访问，更像是一场有组织、有预谋的扫描和调用。
二、 分析：为什么是我？
经过一番排查和代码审计，我基本锁定了问题所在：那个简易的临时邮箱成了众矢之的。
更详细的请求来源分布，进一步佐证了攻击源的高度集中和异常性。
很多做灰产或垃圾注册的团伙，都会编写脚本在全网扫描“在线 tempmail”、“临时邮箱”等关键词。一旦发现开放接口且没有强验证的服务，他们就会像蝗虫一样扑过来，利用你的接口去接收各大网站（如社交媒体、电商、游戏等）的注册验证码。
在这个案例中，我的服务可能被某个法国的自动化脚本库收录了。他们通过高并发请求，利用我的邮箱接口完成成千上万次账号注册。每一次验证码的接收和展示，背后都是服务器的一次动态请求或页面构建，最终导致我的 Cloudflare Pages 额度被瞬间榨干。简单来说，我成了免费的水军基站。
三、 自救：如何堵住漏洞？
既然找到了原因，那就得赶紧止损和防护。如果是你遇到了类似情况，或者正打算开发类似的工具，建议务必检查以下几点配置（不涉及复杂代码，主要是 CF 面板操作）。
1. 地域封锁
既然攻击源集中在特定地区，最暴力的手段就是直接封禁。虽然这有点“一刀切”，但在紧急情况下非常有效。
- 操作路径：Security > WAF > Custom Rules > Create Rule。
- 规则逻辑：选择
Incoming Request，字段选Country，运算符Not in，值填写你想保留的国家代码（如CN,US,JP），或者反过来，直接inFR然后选择Block动作。对于博主来说，既然业务主要面向国内，直接放行 CN，其他全封锁是最快方案。
2. 部署 WAF 速率限制
单纯封禁 IP 可能不够，因为攻击者通常会更换代理 IP。我们需要限制单位时间内的请求频率。
- 操作路径：Security > WAF > Rate Limiting Rules > Create rule。
- 配置建议：针对你的 Tempmail 接口路径（例如
/api/mail），设置每分钟不超过 10-20 次请求。超过这个阈值，直接触发 Challenge（验证码）或 Block。由于邮箱接收通常不需要高频刷新，这个限制不会影响正常用户体验，但能让脚本直接卡死。
3. 接口加上简单的动态验证（如果有代码能力）
对于 Pages Functions 或者 Worker，可以在入口处加一道简单的“墙”。比如检查 Header 中的 User-Agent，拦截空 UA 或者包含特定关键词（如 python, curl, bot）的请求。虽然高级爬虫会伪装 UA，但这能筛掉大部分低级的扫描脚本。
4. 升级架构，隐藏接口
如果你的服务太容易通过 Google 搜索到，建议更改 API 路径，不要使用默认的 /api 等常见路径，甚至可以使用随机哈希字符串作为接口地址。虽然这是“被动”防御，但在没人知晓的情况下，安全系数最高。
四、 总结与反思
这次被“刷爆”的经历给我上了一课：免费的确实是最贵的，但也最容易被滥用。 Cloudflare Pages 尽管免费额度大方，但针对恶意流量并没有自动防御机制，完全靠用户自己配置 WAF。
如果你也在搭建类似对外开放的工具类应用，不管是 Tempmail、图床还是短链服务，务必在上线第一天就开启防火墙策略。不要等到额度被刷光、服务被迫停摆了才想起来要去查日志。安全这一课，早晚都得补，早补早省心。
希望这篇排查笔记能帮到同样遇到“异常流量”的朋友，有问题欢迎在评论区交流！
评论已关闭