Cloudflare 免费档一天 10 万请求够不够？用临时邮箱项目省配额实战

2026-09-19 约 900 字预计阅读 4 分钟 - 次阅读 - 条评论

结论先行

我跑临时邮箱、短链、OTP、小游戏这一串站，几乎全挂在同一个 Cloudflare 账号上。先说结论，别绕：

起步和个人项目，免费档通常够用。 真要爆，先撞的往往是 账号级 Workers 每天 10 万请求，不是「邮箱业务本身」突然吃光额度。邮件进来靠 Email Routing + Worker 处理一次；列表、读信才打 API。真正烧配额的，是前端没事就轮询、静态资源也走 Worker、以及同账号里其他站一起抢。

下面以 mail.5201616.xyz 这类基于 cloudflare_temp_email 方案的自用临时邮箱为例，先给 可跟做的部署步骤，再摊开「什么吃请求、怎么省」。数字按 2026 年常见免费档口径 写，最终以 Cloudflare 官方文档为准——他们偶尔会改表。

声明：公开开放中继有滥用风险。本文只谈 自用部署与配额，不教怎么刷、怎么对外中继滥用。

免费档关键数字（2026 口径，以官方为准）

个人项目最常盯这三块：

产品	免费档常见上限（账号级 / 日）	备注
Workers	100,000 requests/day/account	整账号共享，不是「每个 Worker 各 10 万」
KV	读约 10 万/天，写仅约 1000/天	写极少，排行榜狂写很容易顶穿
D1	读约 500 万行/天，写约 10 万行/天	适合列表、日榜、结构化查询

还有 Pages、R2、Cache 等，但对「临时邮箱 + 几个小站」来说，最先报警的通常是 Workers 请求数，其次才是 KV 写入。

记住一句：10 万是账号池。 我这边同账号还有 go / otp / air / brick 等站，配额是抢的——邮箱今天省下来，游戏接口也可能把它花掉。

临时邮箱真实架构（自用视角）

mail.5201616.xyz 这类项目，常见链路大致是：

收信：Cloudflare Email Routing 把邮件转到绑定的 Worker（或 Worker 入口），入库（常见 D1 / KV 等，视部署而定）。
前端：SPA（静态资源适合挂 Pages / CDN）。
读信：只有打开列表、点开某封、刷新收件箱时，才打后端 API（Worker）。

所以：

邮件到达 → 触发一次（或少量）Worker 处理，这是「业务必要」。
人盯着页面疯狂刷新 / 短间隔轮询 → 才是配额刺客。

Email Routing 本身把「收信入口」接到 Cloudflare 生态里，省去自建 SMTP 那一摊；但 Worker 被调用一次，就算一次请求——别幻想「邮件相关都不算」。

什么吃请求，什么相对不吃

吃配额（Workers 请求）

每次打到 Worker 的 动态请求 / API（列表、读信、鉴权、删除等）。
前端定时 轮询收件箱（哪怕返回空列表，也算）。
误把 HTML/JS/CSS 也绑到 Worker 上、每次打开页面都经 Worker 吐静态文件。

相对省

Pages / 静态资源走 CDN：打开页面本身不经过 Worker（或极少经过）。
浏览器缓存：合理 Cache-Control，别每次强制拉全量前端。
减少无意义轮询：页面隐藏、用户离开标签页时暂停。
短 TTL 的 Cache API：对「短时不变」的只读响应做边缘缓存（注意邮件内容时效，别把「新信」缓存成旧信）。

一句话：静态尽量静态，动态尽量少打、打准。

实战部署：临时邮箱上 Cloudflare

前面把「吃配额」讲清楚了；很多人缺的是 怎么从零落到能收信。下面按我这边自用站 mail.5201616.xyz 的路径写——基于开源项目 dreamhunter2333/cloudflare_temp_email（替换旧的 tempik Worker），Worker 名常见为 cloudflare_temp_email，收信靠 Email Routing catch-all → 该 Worker。

配置项、变量名以 上游 README / 官方 CLI 文档 为准；版本会变，下面命令标成示例，勿照抄未核对的键名。

0. 前置条件

Cloudflare 账号，域名已接入（例：5201616.xyz）
本机有 Node.js + 包管理器（文档常用 pnpm），并安装 Wrangler：npm i -g wrangler
准备好要用来收临时信的域名；MX 最终由 Email Routing 托管（别自己乱改成第三方 MX）

1. 拉代码并登录

1
2
3
4
5
6
7
# 示例
git clone https://github.com/dreamhunter2333/cloudflare_temp_email.git
cd cloudflare_temp_email
# 可选：切到最新 tag，也可用 main
# git checkout $(git describe --tags $(git rev-list --tags --max-count=1))

wrangler login

浏览器完成 Cloudflare OAuth 后，本机 Wrangler 才能建 D1 / 部署 Worker。

2. 创建 D1（必选）与 KV（按需）

项目用 D1 存地址与邮件；KV 多用于注册验证码、Telegram 等，自用不启用可跳过。

1
2
3
4
5
6
7
# 示例：在仓库根或文档指定目录执行（以你 clone 下来的路径为准）
wrangler d1 create temp-email-db
# 初始化表结构（路径以仓库内 db/schema.sql 为准）
wrangler d1 execute temp-email-db --file=db/schema.sql --remote

# 需要注册验证 / Telegram 时再创建，例如：
# wrangler kv namespace create DEV

创建成功后控制台会给出 database_id；后面填进 wrangler.toml 的 [[d1_databases]]。绑定名必须是 DB（上游硬编码，改名会挂）。

我这边自用实例的 D1 曾命名为类似 cf-temp-email-db——名字你自定即可，关键是 ID 与 binding 配对正确。

3. 配置 Worker 并部署

1
2
3
cd worker
pnpm install
cp wrangler.toml.template wrangler.toml

编辑 wrangler.toml（示例字段，值请自己生成，不要用占位密码上线）：

name = "cloudflare_temp_email"（可与线上一致，便于对照 Dashboard）
compatibility_flags = ["nodejs_compat"]（缺了常直接起不来）
[[d1_databases]]：binding = "DB"，填入刚创建的 database_name / database_id
[vars] 里至少核对：
- DOMAINS / DEFAULT_DOMAINS：你的域名，如 ["5201616.xyz"]
- JWT_SECRET：随机串，例如本机执行 openssl rand -hex 32 后填入
- 站点访问密码：PASSWORDS（可选，私有站点建议开）
- 管理台密码：ADMIN_PASSWORDS（不配则进不了 admin）
密码用本地生成，例如：openssl rand -base64 24——文章不写真实密码；生成后只放进你的 wrangler.toml / Secrets，别提交到公开仓库

部署：

1
2
3
# 示例
pnpm run deploy
# 或：wrangler deploy

首次可能提示创建 Workers 项目；成功后 Dashboard → Workers 能看到该 Worker，打开 Worker URL 或 /health_check 若返回 OK，后端基本通了。完整变量说明见上游文档，勿凭记忆猜键名。

前端两种常见做法（二选一或按上游当前推荐）：

Worker 带 assets：先 frontend 里 pnpm build，在 wrangler.toml 配 [assets] 指向 ../frontend/dist/（见上游「带前端的 Worker」说明），再 deploy。
前后端分离：Pages 部署前端，.env 里 VITE_API_BASE 指向 Worker URL（末尾不要 /），再绑自定义域。

我这边对外入口是 https://mail.5201616.xyz——自定义域绑到 Worker 或 Pages（看你选的部署方式）。

4. Email Routing：catch-all 进 Worker

Dashboard 路径（点选，不编造截图）：

Email → Email Routing：对目标域名启用 Email Routing（按向导验证目标邮箱等）。
确保 DNS 里 Email Routing 所需的 MX / TXT 由 Cloudflare 托管生成——不要再指到其他邮件服务。
Routing rules → 添加 Catch-all（或等价「全部未匹配地址」规则）→ Action：Send to a Worker → 选中你的 cloudflare_temp_email Worker。

这样 *@你的域名（例如 *@5201616.xyz）入站都会进 Worker 解析入库，而不是丢进某个真人邮箱。

5. 自定义域 `mail.你的域名`

Worker 方案：Workers → 你的 Worker → Settings / Domains & Routes → 添加 mail.5201616.xyz（示例）为 Custom Domain，或按文档写 routes。
Pages 方案：Pages 项目 → Custom domains 绑定同名主机。

DNS 会自动出现对应记录；MX 仍交给 Email Routing，别和「网站 A/CNAME」搞混——网站记录管网页，MX 管收信。

6. 验证收信

浏览器打开 https://mail.5201616.xyz （或你的域名），用你设置的站点密码进入（若启用了 PASSWORDS）。
在界面生成/创建一个临时地址，例如 某人@5201616.xyz。
用任意外部邮箱向该地址发一封测试信。
回到页面刷新/等待列表出现；能看到主题与正文，说明 Routing → Worker → D1 → 前端 API 整条链路通了。

若一直收不到：先查 Email Routing 是否 Enabled、catch-all 是否指向正确 Worker、域名是否在 DOMAINS 列表、以及 Workers 日志有无报错。

7. 部署完立刻想到「省配额」

默认前端若 短间隔疯狂轮询，免费档 Workers 请求会被空转吃掉。部署只是上线；省配额才是长期能玩。改 poll 间隔、页面隐藏暂停、静态与 API 分离——具体清单见下一节。

部署检查清单

wrangler login 成功，本机能操作目标账号
D1 已创建且执行过 schema.sql；wrangler.toml 里 binding = "DB" 且 ID 正确
JWT_SECRET / 站点与 admin 密码已本地生成并写入配置（未提交明文到公开 Git）
DOMAINS 含你的收信域名；Worker pnpm run deploy 成功，/health_check 正常
Email Routing 已启用；catch-all → Worker cloudflare_temp_email
自定义域（如 mail.5201616.xyz）已绑定；MX 由 Email Routing 托管
向 *@你的域名 发测试信，Web UI 能看到
轮询间隔已按后文「省配额」拉长，避免一上线就空烧请求

省配额清单（可直接改）

1. 前端拉信：间隔拉长 + 可见才 poll

默认别 5 秒一轮；自用 30～60 秒 往往够。
用 Page Visibility：document.hidden 为 true 时 暂停轮询，回到前台再拉一次。
用户点「刷新」才立刻请求；自动轮询只做兜底。

2. 静态与 API 分离

前端挂 Pages（或 R2 + 自定义域），API 才走 Worker 路由。
HTML/JS/CSS 设缓存；API 路径明确不缓存或短缓存。

3. 别拿 KV 当「狂写日榜」

KV 免费档 写大约才 1000/天。排行榜、计数器、游戏日榜这类「频繁更新」：

更适合 D1（写额度量级大得多，还好做按日聚合）。
KV 适合配置、会话、低频状态；拿去做每分钟刷榜，很容易先撞写上限，而不是撞 Workers。

4. 同账号多站：监控 Workers 用量

我这边同一账号还有 go.5201616.xyz、brick.5201616.xyz 等。仪表盘里看 Workers 请求 / 天，别等 429 或配额告警才反应。哪个站突然涨，先查有没有短间隔轮询或爬虫。

5. 开放访问要克制

自用可以；若域名被扫、被当成公开中继，Worker 会被外部流量打穿配额。限流、鉴权、关公开注册——这是运维问题，也是配额问题。

粗算：1 人打开邮箱页，一天多少次？（估算）

下面是估算，不是我后台真实 analytics，别当官方数据。

场景 A：打开页面后每 30 秒轮询，挂一整天

假设活跃约 8 小时盯着标签页：8 × 60 × 2 = 960 次 API/天（仅轮询）。
再加上打开列表、读几封信、收信入库的 Worker 调用，一人一天大概 一千次量级。
相对账号 10 万：一个人这样玩，通常还宽裕——但同账号十几个站 + 多人 + 爬虫，就会挤。

场景 B：改成 60 秒间隔，且仅页面可见时轮询

同样 8 小时「可见」：约 8 × 60 = 480 次。
若实际只有 2～3 小时在看邮箱页，可见轮询大约 120～180 次，再加手动刷新与收信处理。
量级往往能砍一半甚至更多，尤其是你习惯开着标签页去干别的——隐藏即停，省的是「空转」。

多人同时用、或前端写错成 5 秒一轮，估算直接乘上去。免费档的边界感，来自这种乘法，而不是「邮箱业务神秘很贵」。

6. 收信路径别重复打

Email Routing 进 Worker 后，入库逻辑尽量一次写完。别在 Worker 里再连环 fetch 自己的另一个 Worker 做「转发」，除非必要——每次跳转都可能再计一次请求。自用场景：收信 → 解析 → 写 D1/KV → 返回，链路越短越好。

7. 读信 API 做「按需」而不是「全量」

列表接口只返回标题、发件人、时间、id；正文另开详情接口。用户刷列表时别每次把整封 MIME 拖出来。详情可以短时 Cache（注意隐私：临时邮箱内容敏感，缓存键要带邮箱地址与邮件 id，TTL 宜短）。

和「邮箱业务本身」划清边界

有人以为：临时邮箱 = 高并发收信 = 一定贵。自用体感不是这样。

收信频率：个人注册、验证码、偶尔测邮箱，一天几十封都算多；每封触发的 Worker 次数有限。
读信频率：你打开页面的次数 × 轮询频率，才是可控变量。
被扫 / 被滥用：域名暴露后，陌生流量打 API，才会突然贴近 10 万。这和「业务功能」无关，是暴露面问题。

所以排查顺序建议是：仪表盘看 Workers 曲线 → 分路由看哪条 path 多 → 是轮询、爬虫，还是静态误绑 Worker。别一上来就怪「免费档太抠」。

同账号多站时的实操习惯

我自己的习惯就三件事：

每天或每周瞟一眼 Cloudflare 仪表盘里 Workers 的 requests（免费档按天重置的节奏心里有数）。
新功能默认静态优先：能 Pages 就不进 Worker；能浏览器本地状态就不打 API。
写多的数据走 D1：日榜、计数、邮件元数据列表；KV 留给真正低频的配置。下一篇会专门写 D1 日榜怎么设计，避免把写额度花在错误模型上。

小结

够不够：个人起步通常够；爆了先看 账号级 10 万 Workers/天。
怎么上线：clone cloudflare_temp_email → D1 + Worker → Email Routing catch-all → 自定义域；清单见上文「部署检查清单」。
邮箱本身：收信 + 按需读信，合理；杀手是轮询和静态走错路径。
省钱：Pages/CDN、拉长间隔、可见才 poll、KV 慎写、多站一起盯仪表盘。
下篇预告：游戏日榜、计数这类，我会单独写一篇 D1 日榜 怎么建、怎么和免费写额度相处。

自用可玩：临时邮箱 mail.5201616.xyz · 主站 www.5201616.xyz · 短链 go.5201616.xyz · brick.5201616.xyz

有具体 Worker 路由或轮询代码想对照改的，评论区或站点留言丢我；下篇见 D1。

—— 小磊哥

赞赏