Cloudflare 工具地图：除了域名解析，剩下那 130 多个东西哪个跟你有关

0030 秒速览：三句话，然后决定你从哪一节开始

先说清这篇是什么。它不是一份功能清单，是一张地图。Cloudflare 官方产品目录里躺着约 135 个条目，配了 13 个分类标签（AI、Analytics、Application security、Developer platform、Storage……），但那个页面根本不告诉你哪个产品属于哪个分类——它只是一张按字母排的扁平清单。所以「这堆东西跟我有什么关系」这个问题，官方没有回答，得你自己建地图。

如果只记三句话

如果你只有 5 分钟：跑通这一条

本篇是地图，理论上不需要你动手。但有一条命令，能让你在 5 分钟内亲眼看见「Cloudflare 在替我干活」是什么感觉——不用注册、不用有域名、不用绑卡：

# 装一个叫 cloudflared 的小程序（macOS）
brew install cloudflared

# 假设你本机 8080 端口上已经跑着个东西（随便什么都行）
cloudflared tunnel --url http://localhost:8080

# 终端会打印一行 https://随机词.trycloudflare.com
# 把这个地址发给自己手机 —— 只要能上网，就能打开你电脑上的服务

这叫快速隧道（Quick Tunnel）。它的工作原理是：你电脑上的 cloudflared 主动向 Cloudflare 架一条只出不进的加密连线，Cloudflare 再把外网的请求顺着这条线送回来。所以你的路由器一个端口都不用开，也不需要公网 IP。

本文的额度数字，你可以自己复核

这篇里出现了几十个数字（免费额度、价格、上限），而它们是会变的。我把这篇标成了时效性最强的一档，并且每个数字都附了官方出处。你想自己核，走这两步：

# 第 1 步：看 Cloudflare 官方计划对比页（已拆成三份）
open https://www.cloudflare.com/plans/

# 第 2 步：查某个产品的准确上限（把 workers 换成 r2 / d1 / kv / pages）
open https://developers.cloudflare.com/workers/platform/limits/
open https://developers.cloudflare.com/workers/platform/pricing/

规律是：「能干什么」看 /limits/，「多少钱、多少额度」看 /pricing/。这两页有时候口径不一致——本篇文末列了三处我实测到的官方自相矛盾，你可以直接去看那三处。

01一个请求的六段路：全篇的骨架

从「你知道的东西」开始：一个陌生人来你家

你已经会的那半件事，其实就是一个完整故事的开头：你租了个门牌号（域名），去物业登了记（域名解析），告诉别人「来这个门牌号找我」。但一个访客真的走过来，中间要经过的关卡远不止「找到门牌号」这一件。

Cloudflare 的位置，可以理解成在这条路上的六个地方设了岗。下表的六段，就是本篇的全部骨架：

另有一条不走网页的入口，单独成一节：信箱（Email Routing）。

这个「六段路」的比喻，到哪里就不准了

按风格要求，类比必须自己说清边界。这个比喻在两处会骗你：

• 它暗示「Cloudflare 只是个门房」，实际上它已经把仓库和车间都搬进来了。在真实架构里，很多站点的页面根本不在你家——它们就住在 Cloudflare 的机房（第 2 段和第 3 段）。你的服务器可能一次都没被碰到。所以「请求走到你家门口」这个画面，对静态站是错的。
• 「设卡」和「抄近道」不是先后关系，是同一次判断的两面。真实顺序是：请求一到 Cloudflare，它先看「这东西我这儿有现成的吗」，有就直接给（第 2 段）；没有，再看「这请求该不该放行」（第 1 段），然后才谈现算（第 3 段）。我把设卡排在前面讲，只是因为它更好懂——不是因为线上是这个顺序。

为什么非得先分层，不能直接背产品名

因为 Cloudflare 的产品名不携带它属于哪一层的信息。看这三组：

接下来的六节，一节讲一段。每节的写法都一样：这段解决什么问题 → 里面有哪些产品 → 免费层在这里能给你什么、会在哪撞墙 → 你能复制去跑的东西。

02第 0 段 · 找路：你会的那一半，以及你不知道的三件事

这一段你已经在用了。所以我不重讲「怎么加一条 A 记录」，只讲三件大多数人加了三年解析也没搞明白的事。

第一件：那个橙色小云（代理开关），到底改了什么

DNS 记录后面那个小云图标，官方叫代理状态（Proxy status）。点成橙色（Proxied）和点成灰色（DNS only），是你在这个面板上能做的最重大的一个决定，远比填对 IP 重要。

第二件：为什么你的 CNAME 查出来是个 Cloudflare 的 IP

开代理时，Cloudflare 会对 CNAME 记录做一件事叫展平（flattening）。按官方文档：被代理的 CNAME 默认会被展平，DNS 查询返回的不是「它指向的那个域名」，而是 Cloudflare 自己的任播 IP。

（「任播」是指同一个 IP 在全球很多机房同时存在，网络会自动把你送到最近的那个。这就是 Cloudflare 能「就近接入」的物理基础。）

所以你自己 dig 一下，看到返回的是 104.x 或 172.6x 开头的地址，这是对的，不是解析错了：

# 查自己的域名，看返回的是你自己的服务器 IP，还是 Cloudflare 的
dig +short example.com
# 开代理 → 返回 104.x / 172.6x 之类的 Cloudflare 地址（正常）
# 没开代理 → 返回你自己填的那个 IP

# 想看完整链路（CNAME 指向谁、经过几跳）
dig example.com +noall +answer

第三件：免费版的 DNS 记录条数，比你以为的少

流传最广的说法是「免费版能加 3,500 条记录」。这是错的，3,500 是 Pro 和 Business 的额度。官方现行规定是按你创建这个域名的时间切成两档：

200 条对个人站绰绰有余，但有两件事要注意：一是其他服务自动建的记录也计入（比如你开了 Email Routing，它自动加的 MX 和 TXT 也占额度）；二是这个数字在官方文档里出现过一次「3,500」，那是批量修改记录时的单次条数上限（Free 是 200），跟记录总量是两码事——网上很多文章就是从这里抄错的。

顺带说清：SSL 证书你不用管，但有两个边界

你域名加进来那天，Cloudflare 就送了你一张叫 Universal SSL 的证书，它免费、自动签发、自动续期，全计划都有。你不用买、不用配、不用记得续。

在往下走之前，先统一两个后面会反复出现的词：「源站」就是你自己那台服务器（你现在放在某家云上的那台也算）；「边缘」是 Cloudflare 铺在全球、离用户最近的那一圈机房。本文后面说「回源」「边缘节点」，指的都是这两头。

Universal SSL 有两个边界值得知道：

• 它只覆盖根域名和第一级子域。也就是 example.com 和 www.example.com 有证书；a.b.example.com 这种更深层级没有，要另外开 Total TLS（付费功能）。这是很多人「子域名打不开 https」的真正原因。

另一个是加密模式。这个设置决定了「访客到 Cloudflare」和「Cloudflare 到你的服务器」这两段各自的加密强度，一共五个选项：

好消息是：Cloudflare 现在默认开着 Automatic SSL/TLS，它会自己测你的源站支持到哪一档、自动选、自动灰度切换（先放 1% 流量试，没问题再逐级加到 10%…），失败会自动回滚。而且它承诺不会往更弱的模式降级。所以这个设置你大概率不用动。

03第 1 段 · 设卡：谁可以进来，谁被拦下

这一段解决的是「这个请求该不该放行」。里面的产品差别很大，因为它们拦的是不同的东西——有的拦机器，有的拦人，有的拦频率。

先把四种「拦」分清楚

WAF 那 5 条规则怎么花：先搞清楚免费版到底给你什么

关于 WAF，网上有个流传很广的说法是「托管规则集要 Pro 起」。这个说法现在只对了一半：

• 免费给你的：Cloudflare Free Managed Ruleset——一套官方维护的、针对已知漏洞的通用规则，全计划可用，你不用写。
• 要 Pro 才有：Cloudflare Managed Ruleset 和 OWASP Core Ruleset——这两个是更完整的两套。官方计划表里 Free 那一列明确写着 No。
• 你自己写的：5 条。官方计数器是「http_request_firewall_custom 阶段总量」，免费版还只能有 1 个 zone 级的自定义规则集。

5 条怎么花？一个经过验证的花法是这样分配——每条都写成界面里能填的表达式：

# 规则 1：挡住扫描常见漏洞路径的机器人（这不是真的 WordPress，它在瞎猜）
(http.request.uri.path contains "/wp-admin") or
(http.request.uri.path contains "/.env") or
(http.request.uri.path contains "/.git/")

# 规则 2：只允许你自己的国家/地区访问管理后台
(http.request.uri.path contains "/admin") and (ip.geoip.country ne "CN")

# 规则 3：挡住已知的坏 User-Agent（User-Agent 就是浏览器自报家门的名字）
(http.user_agent contains "sqlmap") or (http.user_agent contains "nikto")

# 规则 4：挡住 Referer 为空的、直接打 API 的请求
# （Referer 是浏览器告诉服务器「我是从哪个页面跳过来的」）
(http.request.uri.path contains "/api/") and not (http.referer contains "example.com")

# 规则 5：留给你的业务特例，先空着 —— 这才是最该留的那一条

限流只有 1 条，而且它比你想的笨

免费版的限流规则被砍得很厉害，值得单独说，因为很多人以为它能干很多事：

所以免费版这唯一一条，最划算的用法是守住你最贵的那个接口——比如登录接口或发短信接口，别浪费在首页上：

# 路径匹配 /api/login，同一 IP 10 秒内超过 20 次就拦
# 匹配字段：Path 等于 /api/login
# 特征：IP；阈值：20 次 / 10 秒；动作：Block

Turnstile：把「证明你是人」这件事，从用户身上挪走

你对「人机验证」的印象大概来自 reCAPTCHA——让你在九宫格里找红绿灯。Turnstile 的设计目标是让你什么都看不见：它在页面加载时在后台跑几项检查（浏览器行为、环境指纹等），大部分真人直接放行，不弹任何东西。

它的免费额度有一个反直觉的点，值得专门记住：

用法上，它需要前端和后端配合——前端拿一个令牌（token），后端把令牌送去 Cloudflare 验证真伪。只放前端等于没放，因为攻击者可以跳过你的页面直接打接口：

<!-- 前端：把组件放在表单里，它会自动往表单塞一个隐藏字段 -->
<form action="/api/comment" method="POST">
  <textarea name="body"></textarea>
  <div class="cf-turnstile" data-sitekey="你的站点密钥"></div>
  <button>提交</button>
</form>

<!-- 注意：Turnstile 的加载脚本由 Cloudflare 提供，
     它是页面上的第三方脚本，与本站「零外部脚本」的规则无关，属正常用法 -->

后端那一步在 具体场景一节里给出完整写法。

Zero Trust Access：给「自己人」开的门，不是给公众开的

这东西最容易被误解。它的作用是：在请求到达你的服务之前，先要求访问者证明自己是谁——通常是输入邮箱，收到一个 6 位验证码，填对了才放行。

关键是别对公开站点用。它的正确场景是「这个东西只有我和我同事该看」：内部后台、自建的监控面板、测试环境、NAS 的管理界面。

如果访问方是程序而不是人（比如你另一个脚本要调这个接口），邮箱验证码就走不通了，这时要用服务令牌——本质上是一对 ID + 密钥，放进请求头：

# 在 Zero Trust → Access → Service Auth 建一对令牌，然后这样调
curl https://内部工具.example.com/api/status \
  -H "CF-Access-Client-Id: 你的ID.access" \
  -H "CF-Access-Client-Secret: 你的密钥"

04第 2 段 · 抄近道：有现成的就别重做

这一段只有一个概念，但它解释了你遇到的一半「我改了，线上还是旧的」问题。

「缓存」就是「把做好的东西先放一份在离用户近的地方」

你的网站首页对每个访客都长一样。既然一样，就没必要每个人都回你服务器重新生成一遍——Cloudflare 在全球机房里存一份，谁要就直接从最近的机房给。这就是 CDN（内容分发网络）的全部意思。

中间那段「要不要用缓存」的判断，由缓存规则（Cache Rules）控制。你在面板里写的每条规则，本质上都在回答一句话：这个路径下的东西，能不能存、存多久。

免费版能写 10 条缓存规则

这个额度比 WAF 的 5 条宽松，而且缓存规则本身是全计划都有的功能，不需要额外付费——只要你的域名开着代理（小黄云）。

一条典型规则——「把 /img/ 下的图片缓存一年」——在界面里是这样填的：

# 缓存规则：给图片和字体设长期缓存
当传入请求匹配时： URI 路径 包含 /img/ 或 /fonts/

则：
  · 缓存资格 (Cache eligibility)  →  符合条件 (Eligible for cache)
  · 边缘 TTL (Edge TTL)           →  覆盖原始值 → 1 年
  · 浏览器 TTL (Browser TTL)      →  覆盖原始值 → 1 年

「我改了，线上还是旧的」——按这个顺序查

# 一条命令看到缓存状态和 TTL，比在面板里翻快得多
curl -sI https://你的域名/某个文件 | grep -iE "cf-cache-status|age|cache-control"

05第 3 段 · 现做：没有现成的，谁来现算

这是 Cloudflare 这些年变化最大的一段，也是最容易让人误解的一段——因为这里的每个东西看起来都像「一台服务器」，而它们都不是。

先破一个最贵的误解：Workers 不是 Node.js

这是新手踩得最惨的一脚。你以为「我会写 JavaScript，那我把代码放上去就行」——然后发现 fs.readFile 不存在、很多 npm 包装不上。

这个设计的直接后果是：

• 启动几乎零延迟——没有传统云函数那个「冷启动」问题（函数很久没人用，下次调用得先把运行环境启动起来，那一下会明显变慢），因为 isolate 启动的成本极低。
• CPU 时间被卡得很死。免费版每次调用只有 10 毫秒的 CPU 时间。注意是 CPU 时间不是墙上时间——你在等网络返回的 500 毫秒不算，但你真的在算的那 10 毫秒算。所以视频转码、图片压缩、大循环，这些都不该放这儿。
• 它不能装 Docker 镜像。想要真正的容器，得用 Containers，那是另一个产品，且没有免费额度。

这一段有五个东西，用一句话分开它们

Workers 与 Pages 的关系，比你以为的近

它们看起来是两个产品，实际上Pages 的函数部分就是跑在 Workers 上的。真正的分界只有一句话：

上手：三条命令跑通第一个 Worker

# 1. 建项目（它会问你几个问题，选最简单的模板即可）
npm create cloudflare@latest my-worker

# 2. 进去看这个文件 —— 这就是一个完整的 Worker
#    src/index.js 内容如下：
export default {
  async fetch(request) {
    return new Response("你好，这是从 Cloudflare 边缘返回的");
  },
};

# 3. 本地预览 → 部署上线
npx wrangler dev          # 打开 http://localhost:8787 看效果
npx wrangler deploy       # 部署，会给你一个 xxx.workers.dev 地址

那个 async fetch(request) 是整个模型的全部：每个进来的请求，都会调用一次这个函数，你返回什么，访客就收到什么。没有路由注册、没有端口监听、没有启动流程。

# wrangler.toml
name = "my-worker"
main = "src/index.js"
compatibility_date = "2026-09-16"

routes = [
  { pattern = "api.example.com/*", custom_domain = true }
]

Pages：连上仓库，然后你就再也不用管部署了

# 方式一：连 GitHub 仓库（推荐，以后 push 就自动部署）
# 面板 → Workers & Pages → Create → Pages → Connect to Git
# 填：构建命令 npm run build / 输出目录 dist

# 方式二：命令行直接传（适合本地一次性发布）
npm run build
npx wrangler pages deploy dist

Pages 免费版有一个不显眼但会咬人的限制：每个账号 100 个项目，而且官方明确写了这个上限「不会例行提高」。另外官方营销页写的是「无限站点」——这两处是矛盾的，见文末。

Workers AI：免费额度怎么算，以及第一批该用哪几个模型

它的免费额度单位叫 Neuron（神经元），每天 10,000 个。这个单位反直觉的地方在于：它不是「次数」——不同模型每次调用消耗的 Neuron 数不一样，大模型贵、小模型便宜。所以「每天能做多少次」没有统一答案。

绑定和调用长这样：

# wrangler.toml 里加一个绑定
[ai]
binding = "AI"

# 然后在 Worker 里直接调
export default {
  async fetch(request, env) {
    const answer = await env.AI.run(
      "@cf/meta/llama-3.1-8b-instruct",
      { prompt: "用一句话解释什么是 CDN" }
    );
    return Response.json(answer);
  },
};

06第 4 段 · 取料：算出来的东西存哪

这一段有四个产品，全都长得像「数据库」，但它们的差别是形状的差别，不是档次的差别。选错形状，你会拧巴很久。

用一个类比分开它们：柜子、账本、仓库、传送带

这个类比的边界：它给不了你「性能」这一维。真实世界里 KV 是最终一致的（改完要过一会儿别处才看得到，下面细说），D1 是强一致的（改完立刻所有人都看得到），它们的取舍一半在形状、一半在一致性，而类比只讲了形状。

KV 最容易被误用，因为它叫「数据库」

KV 的官方定位写得很直白：它靠「最终一致」来换取高性能。这句话翻译成人话是：

• 你在某个地方改了一个值，那个改动所在位置的 Cloudflare 机房通常立刻能看到；
• 但世界上其他机房可能要等最多 60 秒甚至更久才能看到新值。官方原文还特意补了一句：前一句那种「通常立刻可见」不保证，不建议依赖；
• 还有一条更隐蔽的：「这个键不存在」这个结论也会被缓存。你新建了一个键，别的地方可能还在拿着「它不存在」的旧结论。

# 建一个命名空间，拿到 ID 填进 wrangler.toml
npx wrangler kv namespace create MY_KV

[[kv_namespaces]]
binding = "MY_KV"
id = "刚才拿到的ID"

# 在 Worker 里读写（注意：put 是异步生效的）
await env.MY_KV.put("site:banner", "双十一活动", { expirationTtl: 86400 });
const banner = await env.MY_KV.get("site:banner");  // 读不到就是 null

D1：那个「按扫描行数计费」的坑，是本篇最值钱的一条

D1 免费版每天给 500 万行读。看到这个数字，你大概会想「够我用十年」。但它的计数方式决定了这个数字可能一夜之间用完：

# 建库（会返回一个 database_id，填进 wrangler.toml）
npx wrangler d1 create my-db

# 建表 + 建索引 —— 索引这一步千万别省
npx wrangler d1 execute my-db --remote --command \
  "CREATE TABLE users (id INTEGER PRIMARY KEY, email TEXT, created_at TEXT);"
npx wrangler d1 execute my-db --remote --command \
  "CREATE INDEX idx_users_email ON users(email);"

# 查一下你某条 SQL 到底扫了多少行（这是自查额度的手段）
npx wrangler d1 execute my-db --remote --command \
  "EXPLAIN QUERY PLAN SELECT * FROM users WHERE email = 'a@b.com';"

# 在 Worker 里用（绑定名是 DB）
const { results } = await env.DB
  .prepare("SELECT * FROM users WHERE email = ?")
  .bind(email)
  .all();

D1 还有两个硬边界要知道：单个数据库最大 500 MB，官方写明「不可再提高」；每个账号最多 10 个库。所以它适合「配置、用户、订单」这种小表，不适合把日志一股脑灌进去。

R2：它最值钱的一条，是「出站不要钱」

所有云存储都收两种钱：存（按 GB 每月）和取（把数据传出去，专业叫「出站流量」）。传统对象存储里，取的钱常常比存的钱多好几倍——你把 10 GB 图片存一年可能花几块钱，但被下载 1 万次可能花几百块。

R2 最关键的差异就在这：出站流量完全不收费。官方原文说得很彻底——不管你是用 Workers API、S3 API 还是那个测试用的 r2.dev 域名取数据，都不产生流量费。

# 建桶 + 上传一个文件 + 确认它能被公开读到
npx wrangler r2 bucket create my-images
npx wrangler r2 object put my-images/logo.png --file=./logo.png
npx wrangler r2 bucket list

要在网页里直接引用这些文件，有两条路：开一个公开域名（简单，但谁拿到链接都能下），或者用 Worker 当门卫（在返回文件前先检查权限，然后签一个几分钟后过期的临时链接）。第二种是图床和付费资源的常见做法。

Queues：只在一种情况下你需要它

场景是这样的：用户提交了一个请求，你的 Worker 要干一件慢事（比如调一次大模型、发一封邮件）。用户不想等 10 秒，而 Workers 的 CPU 时间也等不起。这时你把这件事丢进 Queues，立刻返回「收到了」，另一个 Worker 在后台慢慢处理。

它的免费额度有一个容易踩的点：一条消息正常走完（写入 + 读出 + 删除）算 3 次操作，所以每天 10,000 次的额度实际约等于 3,300 条消息。另外免费版消息只保留 24 小时且不可配置。

07第 5 段 · 回连：你自己的机器怎么接上来

前四段的前提都是「你的东西已经在 Cloudflare 上了」。但现实里你总有些东西在你自己家、你公司、你那台常年开着的机器上——想让外面访问它，这就是这一段。

传统做法要你做四件事，Tunnel 让你做零件

在没有这类工具的世界里，「让别人访问我家的服务」意味着：搞一个公网 IP（或者做动态域名解析，因为你家 IP 老变）→ 在路由器上做端口转发 → 配一个 Nginx 做反向代理（反向代理就是站在你的服务前面、替它接客人的那一层：访客连的是它，它再把请求转给你真正在跑的服务）→ 申请并记得续期 HTTPS 证书。四件事，每件都有坑。

Cloudflare Tunnel 把这四件事全砍掉了，靠的是一个反直觉的设计：不是让外面连进来，是让你的机器连出去。

因为是「只出不进」，你路由器上一个端口都不用开，也不需要公网 IP，更不需要 DDNS。证书、HTTPS、DDoS 防护全都自动继承前面几段的能力。

费用：隧道本身免费

这一点值得单独确认，因为早年的 Argo Tunnel 是按带宽计费的。官方现在的说法是「任何组织都可以免费使用这个产品只出不进的连接能力」。额度上：每个账号 1,000 条隧道、1,000 条路由（路由额度与 Cloudflare Mesh 共享），每条隧道最多 25 个活跃副本（副本就是同一条隧道同时跑在几台机器上、互为备份）。带宽方面官方没有给出数字上限。

上手：从快速隧道到正式隧道

快速隧道（速览那节里试过的）够你体验，但正式用要建具名隧道。区别在于：它是常驻的、绑定你自己的域名、不会每次重启换地址。

# 1. 登录（会打开浏览器让你授权，证书存到 ~/.cloudflared/）
cloudflared tunnel login

# 2. 建一条具名隧道（会生成隧道 ID 和凭证文件，凭证等同密码，别提交进 Git）
cloudflared tunnel create my-server

# 3. 让 Cloudflare 自动为它建一条 DNS 记录（CNAME 指向 <隧道ID>.cfargotunnel.com）
cloudflared tunnel route dns my-server app.example.com

# 4. 先在前台跑一遍，确认没报错（排错阶段一定要前台跑）
cloudflared tunnel run my-server

配置文件放在 /etc/cloudflared/config.yml（或 ~/.cloudflared/ 下）：

tunnel: 你的隧道ID
credentials-file: /root/.cloudflared/你的隧道ID.json

ingress:
  - hostname: app.example.com
    service: http://localhost:8080
  - hostname: nas.example.com
    service: http://192.168.1.50:5000
  # 最后这条兜底规则是必需的，漏了隧道起不来
  - service: http_status:404

校验配置、装成开机自启的服务：

cloudflared tunnel ingress validate          # 先校验，改错了会直接告诉你哪行
sudo cloudflared service install            # 装成系统服务
sudo systemctl enable --now cloudflared    # 开机自启 + 立刻启动
sudo systemctl status cloudflared          # 确认是 active (running)

用 Docker 的话更省事（注意用 expose 而不是 ports——服务端口不要发布到主机，只有 cloudflared 能从内部访问它）：

services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    restart: unless-stopped
    command: tunnel --no-autoupdate run --token ${TUNNEL_TOKEN}
    networks: [tunnel]
  app:
    image: 你的应用镜像
    expose: ["8080"]        # 是 expose，不是 ports
    networks: [tunnel]

networks:
  tunnel:
    name: tunnel

Docker 里填服务地址有个对照关系，填错了就会「隧道是健康的，但访问一直 502」：

防火墙只开一个端口就够：7844

如果你在防火墙很严的环境里（公司内网、只允许白名单出口），这里有个常见的搞错点。官方文档写得很清楚：

需要放行的目标主机是 region1.v2.argotunnel.com 和 region2.v2.argotunnel.com。顺带纠正一个流传很广的说法：官方文档里没有 80 端口的要求。

本能的下一步：加一道登录墙

默认情况下，你刚建好的隧道对所有人开放——只要知道域名就能访问。这是最危险的一步，很多人就停在这里了。加 Access 的流程是：

Tunnel 不是 VPN，这一点必须说清

最后一行值得加粗：所有流量都经过 Cloudflare，它在边缘做 HTTPS 解密。处理高度敏感数据时，这是必须纳入考虑的一条——那种情况下应该用直连方案。

08另一条入口 · 信箱：不走网页的那一半

前面七段讲的都是 HTTP 请求。但你的域名还接着另一个入口：邮件。这一节只讲一个产品，因为对个人用户来说，它是整篇里投入产出比最高的一个。

Email Routing：给每一家网站发一个不同的邮箱

核心用法只有一句：你在网站上注册时填的邮箱，每家都不一样，但全都会转到你真正的邮箱里。

比如你有个域名 example.com，那么 taobao@example.com、github@example.com、某个小网站@example.com 全都能建，全部转到你的 Gmail。哪天 某个小网站@example.com 开始收垃圾邮件，你就知道是谁把你的邮箱卖了——然后一条规则把它删掉，其他全不受影响。

额度与几个反直觉的点

开通过程中会动到你的 DNS

这一步值得单独提，因为它和第 0 段那条配额规则直接相关：开启 Email Routing 时，Cloudflare 会自动往你的 DNS 里加 MX 和 TXT 记录，这些记录也计入你那个 200 条的额度。而且按第 0 段的规则，MX 记录永远不能开小黄云。

# 开启后你的 DNS 会长这样（数值以面板实际给的为准）
# MX 记录 — 告诉全世界「寄给这个域名的邮件送到哪」
MX   @    route1.mx.cloudflare.net    (优先级 21)
MX   @    route2.mx.cloudflare.net    (优先级 44)
MX   @    route3.mx.cloudflare.net    (优先级 87)

# TXT 记录 — 防伪造，声明「只有这些服务器能代表我发信」
TXT  @    "v=spf1 include:_spf.mx.cloudflare.net ~all"

# 验证一下（生效可能要几分钟）
dig MX example.com +short

（MX 记录是「邮件该送到哪台服务器」的说明；SPF 是一条写在 TXT 里的声明，用来防止别人假冒你的域名发信。这两个都属于「配好就别动」的东西。）

09一个具体场景：给静态站加一个「留言表单」

前面八节把六段路拆开讲了。现在用一个真实需求把它们串起来——这个需求小到看起来不该动用五个产品，但它恰好每一段都要碰到。

需求：你的站是 Pages 托管的静态站，现在想加一个留言框。要求是：要防机器人、留言要能存下来、你自己要能看。

为什么这件事不简单

静态站的意思是没有后端——一堆 HTML 文件，谁都能改，但没人能处理「提交」这个动作。所以你必须给它补一个后端。按六段路走一遍，就是完整方案：

五个产品里用到三个。这就是分层的好处：需求一来，你不需要记住 135 个产品，只需要问「这个活儿落在哪几段上」。

第一步：前端页面

<!-- comments.html 或你站点里的某个页面 -->
<form id="comment-form">
  <textarea name="body" required placeholder="说点什么"></textarea>

  <!-- Turnstile 组件：渲染后会自动往表单里塞一个隐藏字段 -->
  <div class="cf-turnstile"
       data-sitekey="你的站点密钥"></div>

  <button type="submit">提交</button>
</form>

<div id="comments"></div>

第二步：建数据库（第 4 段）

# 建库，把返回的 database_id 填进 wrangler.toml
npx wrangler d1 create blog-comments

# 建表
npx wrangler d1 execute blog-comments --remote --command \
  "CREATE TABLE comments (
     id INTEGER PRIMARY KEY AUTOINCREMENT,
     body TEXT NOT NULL,
     created_at TEXT DEFAULT (datetime('now'))
   );"

# 建索引 —— 因为列表页要按时间倒序查，没索引就会全表扫描，直接吃你的行读额度
npx wrangler d1 execute blog-comments --remote --command \
  "CREATE INDEX idx_comments_created ON comments(created_at DESC);"

wrangler.toml 里要声明这个绑定，Pages Functions 才知道去哪儿找它：

name = "my-blog"
pages_build_output_dir = "dist"

[[d1_databases]]
binding = "DB"                      # 代码里就用 env.DB 访问
database_name = "blog-comments"
database_id = "刚才返回的ID"

第三步：写后端（第 3 段 + 第 1 段）

在 Pages 项目里建一个 functions/api/comment.js，它就会自动变成 /api/comment 这个接口。这个文件就是所谓「Pages Functions」，它跑的其实就是 Workers。

// functions/api/comment.js
export async function onRequestPost({ request, env }) {
  const form = await request.formData();
  const body = (form.get("body") || "").trim();
  const token = form.get("cf-turnstile-response");

  if (!body || body.length > 500) {
    return new Response("内容为空或过长", { status: 400 });
  }

  // 关键一步：把令牌交给 Cloudflare 验证真伪。只放前端等于没放。
  const verify = await fetch(
    "https://challenges.cloudflare.com/turnstile/v0/siteverify",
    {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        secret: env.TURNSTILE_SECRET,   // 用环境变量存，别写进代码
        response: token,
      }),
    }
  ).then(r => r.json());

  if (!verify.success) {
    return new Response("人机验证没通过", { status: 403 });
  }

  await env.DB
    .prepare("INSERT INTO comments (body) VALUES (?)")
    .bind(body)
    .run();

  return Response.json({ ok: true });
}

那个 env.TURNSTILE_SECRET 要在面板里设成环境变量（Settings → Environment variables）——环境变量就是一批存在代码之外、运行时才喂给代码的配置项。不能写进代码本身，因为代码迟早会进 Git、会被人看到，写进去就等于把钥匙公开了。

第四步：把留言读出来

// functions/api/comments.js
export async function onRequestGet({ env }) {
  // 有了 idx_comments_created 索引，这条查询只扫它要的那几十行
  const { results } = await env.DB
    .prepare("SELECT id, body, created_at FROM comments ORDER BY created_at DESC LIMIT 50")
    .all();

  return Response.json(results);
}

这个方案里，哪些地方是你会踩的坑

• Turnstile 的密钥分两半。「站点密钥」是公开的、放前端；「密钥」是私密的、只放后端环境变量。搞反了等于把门钥匙贴在门上。
• 别忘索引。没有 idx_comments_created 的话，每次打开留言列表都会全表扫描一遍——留言越多，每次消耗的行读额度越大。这是 D1 那个坑的现场版。
• 不要给 /api/ 加缓存规则。留言是动态的，被缓存了你会看到「我提交了但它不显示」。
• 免费额度够用吗？算一下：每天 10 万次 Worker 请求、D1 每天 500 万行读。一个有几十条留言的小站，离撞墙非常远。

1012 组最容易混为一谈的名词

这一节是可以直接查的。每组给「一句话分界」和「什么时候你会混」。

11免费额度速查 + 三类硬墙

这一节也是拿来查的。数字全部核对于 2026-09-16，来源见文末。

三类墙的性质完全不同，先分清

主力产品速查

最后一行值得单独想一下它的含义：用免费版，等于接受「它挂了不赔」。这不是说它容易挂——而是说你在做架构决定时，不能把「Cloudflare 一定在线」当成前提写进去。

12场景索引：你现在的处境 → 用哪个

如果你不想读全文，直接从这一节找自己的处境。

13遇到陌生名词的三步归位法

这是本篇最想留给你的一样东西。以后你在任何教程、任何 AI 的回答里看到「用 R2 配 Vectorize，前面套一层 AI Gateway」这种句子，按这三步走就不会慌。

第一步：问它是在「搬东西」「做东西」还是「看门」

Cloudflare 的所有产品都能塞进这三个大桶之一，而且塞不进去的很少：

先归到大桶，你至少知道该去面板的哪一区找，也知道它大概要花你多少精力（看门类的通常配一次就不管了，做东西类的才需要你写代码）。

第二步：看名字里有没有线索

Cloudflare 的命名其实比它看起来有规律，只是没人告诉过你：

• 能「干活」的：Workers（工人）、Pages（页面）、Workflows（流程）、Agents（代理）——都是有动作含义的词。
• 存东西的：名字都是很短的字母数字代号，像仓库编号——R2、D1、KV。看到这种短代号，基本可以直接判断它是存储。
• 看门的：WAF、Access、Turnstile、Shield、Gateway——都是「关口」类词汇。
• 管道类的：带 Network、Tunnel、Mesh、Interconnect 的，都是在解决「怎么连上」。

第三步：去官方目录确认它到底是「产品」还是「功能」

这一步能省掉大量困惑。因为 Cloudflare 把产品和功能混在同一个导航里，而两者的问题性质完全不同：

判断方法很简单：去产品目录搜一下，搜不到就是功能。「CNAME flattening 怎么收费」这种问题之所以没人回答，是因为它压根不是一个产品。

求助 AI 的时候，直接把这三步写进问题里

新手问 AI 时最容易犯的错，是问「R2 是什么」——你会得到一段和官网 README 差不多的介绍，看完还是不知道要不要用。换成这个模板，答案质量会完全不同：

# 可直接粘贴的提问模板
我想做的是：【用一句话说你的目标，比如"给博客加图片上传"】

我的现状：【比如"静态站托管在 Pages，没有后端，每月预算 0 元"】

请按这个结构回答：
1. 这个需求会落在「请求的哪一段路」上（找路 / 设卡 / 抄近道 / 现做 / 取料 / 回连）
2. 为此我需要的产品是哪几个，哪些是免费额度内够用的
3. 免费层在这个方案里会在哪里撞墙（条数上限 / 每日配额 / 要绑卡）
4. 给我最小的可运行示例，包括要敲的命令

如果我提到的某个词其实是「某个产品的功能」而不是独立产品，请指出来。

最后一句是关键——它逼着回答者区分产品和功能，而不是笼统地把名词堆给你。

14六个常见误解

15名词速查表（按段分）

按六段路排列。第三列回答的是「你什么时候会需要它、别把它当成什么」——这才是有用的那一列。

16来源与证据边界

本文的每个数字，来自哪里

本篇的额度与价格全部核对自 Cloudflare 官方一手源。规律是：「能干什么」看 /limits/，「多少额度、多少钱」看 /pricing/。

三处官方源自相矛盾的地方（我按原样呈现，不替你选）

这三处是只有真去逐页对过才发现的。我把两边都留着，并标明各自出处——你可以自己去看，也可以拿这个去问官方。

第三行我特意留着，因为它是本篇唯一一条我明确标为「推断而非直引」的结论。其余数字都是官方原文。

关于中国大陆访问：原因是结构性的，不是你配错了

如果你在大陆访问 pages.dev 或 workers.dev 觉得慢或者不稳，那不是你的配置问题。官方对这件事有一句很清楚的说明：

由此可以推出一条：免费版和普通付费版的流量，不走中国大陆境内的机房。大陆用户会被就近调度到香港、日本、新加坡等境外节点，延迟和稳定性因此受限。这解释了你为什么会觉得「明明有 CDN 怎么还慢」——问题不在 CDN，在于机房位置。

这也是为什么本篇反复强调「正式上线一定要绑自己的域名」：用自己的域名至少不会额外叠加 *.workers.dev 这类共享域名本身的解析问题。但绑域名不能解决机房位置问题——那只有 China Network 能解决，而它需要企业套餐。

本文的证据边界

• 所有额度数字核对于 2026-09-16。这类信息变动频繁，本篇被标为时效性最强的一档。你读到时的实际数字请按上面那张来源表复核。
• 「六段路」这个分层是我建的，不是官方的。Cloudflare 官方产品目录是一张按字母排的扁平清单，并不提供「产品 → 分类」的映射（页面上的 13 个分类标签只是筛选按钮，正文里返回的是无分组的链接列表）。所以本文的分层是按「一个请求的路径」重新组织的，读起来顺，但不要把它当作官方架构。
• 有几处数字只有一个来源。比如 Zero Trust 免费版的「50 用户」来自 Cloudflare 产品页，开发者文档站里没有这个数字；Workers AI 的「10,000 Neurons/天」只在定价页出现，限流页完全不提免费额度。遇到这类数字，建议以产品页为准，或直接在面板里看自己的实际额度。
• 本篇刻意没有展开的：Cloudflare 还有一整个面向企业和大规模场景的产品群（Load Balancing、Magic Transit、Cloudflare One、AI Gateway、Hyperdrive、Vectorize、R2 SQL 等）。它们要么需要企业套餐，要么属于「你已经上手之后自然会碰到」的进阶件。本文只在速查表里点了名、标了段位，没有展开讲——这是刻意的取舍，不是遗漏。

99一句话总结

最后一件事留给你自己验——这也是本篇唯一无法替你验证的一条：拿你自己的一个真实需求，走一遍六段路。

比如「我想给站点加个搜索框」或者「我想让同事能看我的本地报表」。先别查任何文档，就在纸上把六段写下来，标出这个需求落在哪几段、哪几段用不上。然后再去对照 场景索引那一节，看你标的和我建议的差在哪。

如果你能不看本文就把那六段默出来、并且说清哪几段在这个需求里是空的——这篇地图就长在你脑子里了。