Cloudflare 从入门到进阶：构建更快、更安全的互联网应用

更新日期：2026年7月7日

2026年7月7日

如果你维护过任何一个面向公网的网站，你大概率遇到过这三个问题：访问速度慢（用户在地球另一端加载你的页面要等好几秒），被攻击（某天突然涌入大量异常流量，服务器直接挂掉），以及配置繁琐（HTTPS 证书、缓存策略、防火墙规则，每一项都要折腾半天）。

Cloudflare 就是为了解决这三个问题而设计的。它像一个架在全球 330 多个城市的智能网关，把你的网站保护在身后，同时让它跑得更快。

本教程专为开发者、运维人员和站长编写。读完并跟着操作之后，你将能够：

理解 Cloudflare 的核心工作原理
独立把你的域名接入 Cloudflare 并完成基础配置
判断什么场景该用（不该用）Cloudflare
了解 Workers 边缘计算、R2/D1/KV 存储和 Zero Trust 安全体系的基本用法

我们从最基础的概念开始，不需要你事先了解 Cloudflare，但需要你对域名、DNS 和 HTTP 有基本认知。

第1章 Cloudflare 是什么

1.1 一个没有 Cloudflare 的网站会遇到什么

假设你买了一台 VPS，部署了一个博客。域名 example.com 直接解析到 VPS 的公网 IP。一切正常——直到问题出现。

问题一：慢。 你的服务器在洛杉矶，一个东京的用户打开你的网站需要经过十几个网络节点，每次页面加载都要横跨太平洋。如果你的页面有几张没压缩的高清图片，加载时间可能超过 5 秒。

问题二：脆弱。 某天，有人对你的服务器发起 DDoS 攻击——几万台被控制的设备同时向你的 IP 发送请求。你的 1 核 2G VPS 在几秒内就耗尽资源，网站彻底不可访问。你不知道攻击来自哪里，也不知道怎么防御。

问题三：麻烦。 配置 HTTPS 证书需要安装 Certbot、写 cron 定时续期。做缓存需要配 Nginx、调参数。想屏蔽恶意 IP 要写 iptables 规则。每件事都不难，但加起来就是很大的心智负担。

这些问题不是你的技术不够好，而是单体服务器的物理限制——一台机器只能在一个地方，只能处理有限的流量。

1.2 Cloudflare 的三重身份

Cloudflare 可以理解为一个全球分布的反向代理网络，它提供三类核心能力：

内容加速（CDN）：Cloudflare 把你的静态资源（HTML、CSS、JS、图片）缓存到全球 330+ 个数据中心。当东京的用户访问你的网站时，Cloudflare 直接从东京的节点返回缓存内容，不需要每次都回源到洛杉矶。

安全防护：所有流量先到达 Cloudflare，经过 DDoS 防护、Web 应用防火墙（WAF）和 Bot 检测的过滤，只有正常的请求才会转发到你的源站。你的真实服务器 IP 被隐藏起来，攻击者根本找不到。

运维简化：免费 SSL 证书自动签发和续期、一键缓存配置、DNS 管理面板、流量分析仪表板——这些原本需要多个工具才能完成的事，在 Cloudflare 控制台里点几下就行。

用一句话概括：Cloudflare 是架在你的网站和互联网之间的一层智能保护网。

图 1.1：Cloudflare 作为反向代理，同时提供内容加速、安全防护和运维简化三类服务。

1.3 全球网络意味着什么

Cloudflare 在全球 330+ 个城市部署了数据中心。这个数字意味着：

无论用户在哪里，数据往返时间（RTT）都能控制在几十毫秒以内
DDoS 攻击流量被分散到全球数百个节点，每个节点只承担一小部分
所有的产品功能（缓存、WAF、Workers）在每一个节点上都能运行

你不需要选择部署区域，不需要配置多地域同步——流量自动被路由到离用户最近的节点。

1.4 有和没有 Cloudflare 的对比

对比维度	没有 Cloudflare	有 Cloudflare
全球访问速度	取决于服务器位置，跨洲访问慢	就近节点响应，首字节时间大幅降低
DDoS 防护	需要自建或购买专业设备	免费提供 L3/L4 和 L7 DDoS 防护
HTTPS 证书	手动申请、配置、续期	自动签发，自动续期
缓存	需要手动配置 Nginx/Varnish	控制台一键配置，支持自定义规则
服务器 IP	暴露在公网	隐藏，攻击者看不到真实 IP
成本	带宽、计算资源全部自担	免费计划可覆盖个人和小型项目

1.5 练习与检查：识别和解释

识别练习：打开一个你常用的网站，用浏览器开发者工具查看它的 Network 面板。观察响应头里有没有 cf-cache-status、cf-ray、server: cloudflare 这样的字段——这些说明该网站正在使用 Cloudflare。

检查点：不看上文，用你自己的话解释这三个问题： 1. 为什么用了 Cloudflare 后访问速度会变快？ 2. 为什么 Cloudflare 能防止别人直接攻击你的服务器？ 3. CDN 缓存和反向代理分别是什么意思？

第2章工作原理：反向代理与 Anycast DNS

2.1 域名是怎么变成 IP 地址的

当你把域名接入 Cloudflare 时，首先要做的一件事是修改域名的权威 DNS 服务器（Nameserver）。在修改之前，你的域名 DNS 由域名注册商（如阿里云、GoDaddy）管理。修改后，Cloudflare 成为这个域名的权威 DNS——所有对这个域名的 DNS 查询都由 Cloudflare 来回答。

DNS 的日常工作是：用户输入 example.com → 浏览器向 DNS 服务器查询 → DNS 返回 IP 地址 → 浏览器向这个 IP 发 HTTP 请求。

但 Cloudflare 接管 DNS 之后，事情变了一点点：当 DNS 记录的代理状态（Proxy Status）设为”已代理”时，Cloudflare 返回的不是你服务器的真实 IP，而是 Cloudflare 自己的 Anycast IP 地址。用户的请求于是先到达 Cloudflare，而不是直接打到你的服务器上。

2.2 反向代理：站在服务器前面

反向代理（Reverse Proxy）和正向代理（Forward Proxy）的区别很简单：

正向代理：代理客户端。比如公司内网的员工通过一台代理服务器访问外网，外网服务器不知道真实客户端是谁。
反向代理：代理服务端。用户请求先到反向代理，反向代理再转发给后端服务器。用户不知道真实服务器是谁。

Cloudflare 就是典型的反向代理。在”已代理”模式下，所有 HTTP/HTTPS 请求的路径变成：

用户浏览器 → Cloudflare 边缘节点 → 你的源站服务器 → Cloudflare 边缘节点 → 用户浏览器

Cloudflare 在这个路径上可以做很多事：检查请求是否恶意、返回缓存内容、压缩图片、修改请求头、注入安全脚本等。

2.3 Anycast：同一个 IP，最近的节点响应

Cloudflare 在全球数百个数据中心广告同一个 IP 地址。这依靠一种叫 Anycast 的网络路由技术。

简单理解：当用户的 DNS 查询到达互联网的路由系统时，BGP 协议会自动计算从用户到各个 Cloudflare 数据中心的路径距离，然后把请求路由到最近的那个节点。从用户的角度看，它访问的是同一个 IP，但实际上每次请求都可能被路由到不同的物理位置。

这种设计的三个好处：

低延迟：用户总是连接到最近的数据中心
高可用：如果一个数据中心故障，流量自动被路由到其他节点
抗 DDoS：攻击流量被分散到数百个节点，而不是集中打击一个 IP

2.4 一次完整请求的全旅程

来追踪一个完整的用户请求：

用户在浏览器输入 https://example.com
浏览器向 DNS 查询 example.com 的 IP 地址
Cloudflare 的 DNS 服务返回一个 Anycast IP（如 104.21.x.x）
浏览器通过 BGP 路由连接到最近的 Cloudflare 数据中心
Cloudflare 检查：这个请求是不是攻击？（DDoS 防护）
Cloudflare 检查：这个请求有没有匹配缓存？（CDN 缓存查找）
如果缓存命中，直接返回内容给用户（结束）
如果缓存未命中，Cloudflare 向源站服务器发起请求
Cloudflare 检查：响应内容是否安全？（WAF 出站检查）
Cloudflare 缓存响应内容（根据缓存规则），然后返回给用户

整个过程通常在几十到几百毫秒内完成，对用户完全透明。

图 2.1：DNS 查询 → Anycast 路由 → 安全检查 → 缓存查找 → 源站回源 → 内容返回的完整请求链路。

2.5 练习与检查：追踪一次请求

场景分析：你的源站在新加坡，一个来自巴西圣保罗的用户第一次访问你的网站首页。描述这个请求经过了哪些步骤。第二次访问同一页面时，又有什么不同？

检查点： 1. 什么是”代理状态”，“已代理”和”仅 DNS”的区别是什么？ 2. Anycast 为什么能抗 DDoS？ 3. CDN 缓存命中时，请求有没有到达你的源站？

第3章核心能力全景

3.1 四层能力栈

Cloudflare 的产品看似很多，但可以清晰地按功能栈分为四层：

┌─────────────────────────────────────┐
│           计算层                     │
│   Workers · Pages · Durable Objects │
├─────────────────────────────────────┤
│           存储层                     │
│   R2 · D1 · KV · Queues · Stream   │
├─────────────────────────────────────┤
│           安全层                     │
│   DDoS · WAF · Bot · SSL/TLS       │
│   Zero Trust · Access · Gateway    │
├─────────────────────────────────────┤
│           网络层                     │
│   CDN · DNS · 负载均衡              │
│   Argo · Spectrum · Magic Transit  │
└─────────────────────────────────────┘

底层为上层提供基础。网络层是所有流量的入口，安全层对流量进行过滤和加密，计算层和存储层让你可以在边缘构建完整的应用。

3.2 网络层

CDN（内容分发网络）：Cloudflare 最基础的能力。静态资源被缓存到全球边缘节点，用户就近访问。支持自定义缓存规则、Cache Reserve（大规模持久缓存）和 Tiered Cache（分层缓存）等高级选项。

DNS：Cloudflare 是全球最大的权威 DNS 提供商之一，也是最快的公共 DNS 解析器（1.1.1.1）。作为权威 DNS，你管理域名的所有 DNS 记录；作为公共解析器，它帮助全球用户更快地解析域名。

负载均衡：将流量分发到多个源站服务器，支持地理位置路由（把欧洲用户路由到欧洲的源站）和健康检查（自动摘除故障服务器）。

3.3 安全层

DDoS 防护：在免费计划下，Cloudflare 就提供”不计量缓解”（Unmetered Mitigation）——意思是无论攻击流量多大，Cloudflare 都不会因为带宽消耗向你收费。L3/L4（网络层/传输层）和 L7（应用层）攻击都能防护。

WAF（Web 应用防火墙）：通过规则集检测和拦截常见的 Web 攻击——SQL 注入、跨站脚本（XSS）、文件包含、命令注入等。Cloudflare 提供托管规则集（由安全团队维护）和自定义规则（你自己写匹配条件）。

Bot 管理：区分好 bot（搜索引擎爬虫）和坏 bot（撞库、刷票、爬数据）。通过行为分析和机器学习来判断流量是真实用户还是自动化脚本。

3.4 计算层

Workers：在 Cloudflare 的边缘节点上运行 JavaScript（或通过 WebAssembly 运行其他语言）。你写的代码被部署到全球 330+ 个数据中心，在离用户最近的地方执行。可以用来做 API 网关、A/B 测试、请求改写、鉴权等。

Pages：面向前端开发者的网站托管平台。连接 GitHub 仓库后自动构建和部署。和 Workers 深度集成，可以在页面旁边跑无服务器函数（Functions）。

3.5 存储层

Cloudflare 提供了四种主要的存储产品，每种场景不同：

产品	类型	一致性	适用场景
KV	键值存储	最终一致（最多60秒）	配置数据、少量频繁读取的数据
R2	对象存储（S3 兼容）	强一致	图片、视频、静态文件、备份
D1	关系型数据库（SQLite）	强一致	用户数据、订单、结构化业务数据
Durable Objects	有状态计算 + 存储	强一致	协作编辑、实时计数、会话管理

关键区别：KV 是最终一致性——写入后立即读取可能拿到旧值。如果需要写入后立刻读到新值，应该用 D1 或 Durable Objects。R2 最大的卖点是零出口费——从 R2 向外传输数据不收取流量费，这对视频、图片等带宽密集型场景非常友好。

图 3.1：Cloudflare 产品按网络→安全→计算→存储四层组织，下层为上层提供基础设施。

3.6 练习与检查：产品分类

识别练习：访问 Cloudflare 产品页面，对照本章的四层分类，确认每个产品属于哪一层。

检查点： 1. KV 和 R2 分别适合什么场景？为什么 KV 不适合做计数器？ 2. Workers 和你熟悉的传统后端（如 Express、Django）有什么区别？ 3. DDoS 防护在免费计划下有多少限制？

第4章适用场景：什么时候该用 Cloudflare

4.1 个人博客和小型网站

这是 Cloudflare 最典型的使用场景。大多数个人博客和展示型网站完全可以用免费计划覆盖：

全球 CDN 加速页面加载
免费 SSL 证书（自动签发和续期）
基础 DDoS 防护
3 条页面规则（做 URL 重定向等）

典型配置：域名接入 → DNS 代理 → SSL 设为 Full(Strict) → 缓存静态资源 → 完成。

4.2 电商和 SaaS 产品

如果你的网站涉及用户登录、在线支付或企业数据，安全性要求更高。建议至少使用 Pro 计划（$20/月）：

WAF 托管规则集（防御 OWASP Top 10 攻击）
更精细的 Bot 检测
图片优化（自动压缩、WebP 转换）
更多页面规则和缓存 API

对于支付页面和用户数据接口，确保 SSL 模式设为 Full(Strict)，避免中间人攻击。

4.3 API 服务和后端应用

Workers 非常适合做 API 层：

API 网关：用 Worker 做请求鉴权、限流、路由转发
数据转换：在边缘层修改请求/响应格式
A/B 测试：根据请求特征动态分流到不同后端
Webhook 处理：接收第三方回调，处理后转发

配合 R2 或 D1 存储，可以在完全不管理服务器的情况下运行完整的后端逻辑。

4.4 企业内部网络

Cloudflare 的 Zero Trust 方案正在替代传统的 VPN：

Cloudflare Tunnel：服务器上运行 cloudflared，创建出站隧道。外部流量通过 Cloudflare 网络进入内网，不需要在防火墙上开放任何入站端口。
Access：在应用前面加一层身份认证（SSO），员工必须先通过身份验证才能访问内部工具。
Gateway：DNS 过滤和安全 Web 网关，防止员工访问恶意网站。

图 4.1：不同使用场景匹配不同的 Cloudflare 产品组合。✅ 为强烈推荐。

4.5 不适合的场景

诚实地讲，Cloudflare 不是银弹。以下情况需要谨慎评估：

纯静态文件分发且流量极大：Cloudflare 的服务条款对非 HTML 内容（图片、视频、软件下载）的免费缓存比例有限制。如果你的网站 90% 以上流量是图片/视频，免费计划可能不适用。
需要特定区域合规：某些行业（金融、医疗）要求数据必须留在特定国家。Cloudflare 的数据处理涉及全球节点，需要确认合规性。
极低延迟的实时应用（如 FPS 游戏服务器）：CDN 和反向代理增加了额外一跳（hop），对延迟极端敏感的场景可能需要直接连接。
不想把 DNS 管理权交给第三方：这是使用 Cloudflare 的必要前提，不接受的话无法使用。

4.6 练习与检查：场景分析

场景分析：你是一家小型电商的运维，网站目前部署在国内云服务器上，正在考虑拓展海外市场。列出使用 Cloudflare 后可以获得的三项改善，以及可能遇到的一个问题。

检查点： 1. 一个小型博客，日均 1000 PV，需要付费吗？ 2. 什么场景下必须用 Full(Strict) SSL 模式？ 3. Cloudflare Tunnel 和传统 VPN 的本质区别是什么？

第5章入门实践：域名接入

5.1 注册和计划选择

访问 cloudflare.com 点击”注册”
用邮箱注册，验证邮箱后进入控制台
在计划选择页面，从 Free 开始。先不用付费——等你确认需要 WAF、图片优化等高级功能时再升级

各计划核心差异速览：

功能	Free	Pro	Business	Enterprise
CDN / DNS	✅	✅	✅	✅
DDoS 防护	✅（不计量）	✅	✅	✅
免费 SSL	✅	✅	✅	✅
WAF 托管规则	❌	✅	✅	✅
图片优化	❌	✅	✅	✅
自定义 SSL 上传	❌	❌	✅	✅
Workers（免费额度）	10万请求/天	10万请求/天	✅	✅
价格	$0/月	$20/月	$200/月	定制

5.2 添加站点

进入控制台后：

点击”添加站点”
输入你的域名（如 example.com），选择 Free 计划
Cloudflare 会自动扫描你域名当前的所有 DNS 记录（A、CNAME、MX、TXT 等）
检查扫描结果：确保所有重要的记录都被识别。如果有遗漏，手动添加
确认每条记录的代理状态：
- 网站/应用的 A 记录和 CNAME → 开启代理（橙色云朵图标）
- 邮件相关的 MX 记录 → 关闭代理（灰色云朵图标，邮件不能走 CDN）
- FTP/SSH 的子域名 → 通常关闭代理

5.3 修改域名服务器

这是最关键的一步。Cloudflare 会给你分配两个域名服务器地址，类似于：

alice.ns.cloudflare.com
bob.ns.cloudflare.com

你需要去你的域名注册商（如 Namecheap、阿里云、GoDaddy、Cloudflare Registrar 等）的管理后台，把域名的 Nameserver 从注册商默认值修改为 Cloudflare 提供的这两个地址。

这个过程叫做”更换域名服务器”。修改后，DNS 的传播需要时间：

通常在 5-30 分钟内开始生效
全球完全生效可能需要 24-48 小时（TTL 缓存导致）
大部分用户会在一小时内看到效果

Cloudflare 控制台会显示状态：待处理的域名服务器更新 → 有效。

5.4 验证接入

域名服务器修改生效后，验证以下几个标志：

Cloudflare 控制台域名状态显示”有效”（Active）
浏览器访问你的域名，打开开发者工具 → Network 面板
查看响应头中是否有 server: cloudflare 和 cf-ray: 字段
用 dig 或 nslookup 查询你的域名 A 记录，返回的 IP 应该属于 Cloudflare 的 IP 段（如 104.21.x.x、172.67.x.x）

5.5 常见踩坑

NS 修改被忽略：某些注册商的界面比较隐蔽。确保你修改的是”域名服务器”（Nameserver），而不是”DNS 记录”（DNS Records）——这是两个完全不同的东西。

DNS 记录遗漏：Cloudflare 扫描可能漏掉一些不太常见的记录类型（SRV、CAA）。接入前先在自己当前的 DNS 管理面板导出所有记录，方便对照。

邮件服务中断：MX 记录必须关闭代理（灰云）。如果 MX 记录被代理，入站邮件会经过 Cloudflare，大概率会丢失。

SSL 证书等待：刚接入时，Cloudflare 需要为你的域名签发边缘证书。这个过程可能需要几分钟到几小时。在这期间 HTTPS 可能会报错——等证书生效就好了。

图 5.1：从注册到验证的完整接入流程——注册 → 添加站点 → 扫描 DNS → 修改 NS → 等待生效 → 验证。

5.6 练习与检查：接入验证

实操练习：如果你有一个闲置域名，尝试完成完整的接入流程。如果没有，在 Cloudflare 控制台至少完成”添加站点”和查看 DNS 扫描结果的前两步（不需要真的修改 NS）。

检查点： 1. 修改 Nameserver 和修改 DNS 记录有什么区别？ 2. 为什么 MX 记录不能开启代理？ 3. 接入后如何确认 Cloudflare 已经在生效？

第6章基础配置实战

6.1 DNS 记录管理

接入 Cloudflare 后，所有的 DNS 记录都在 Cloudflare 控制台管理。不需要再回注册商那边操作。

记录类型速查：

类型	用途	是否可代理
A	指向 IPv4 地址	✅
AAAA	指向 IPv6 地址	✅
CNAME	指向另一个域名	✅
MX	邮件服务器	❌
TXT	文本记录（SPF、DKIM）	❌
NS	子域名授权	❌

代理开关的判断原则：需要 Cloudflare 保护和加速的 HTTP/HTTPS 流量 → 代理；其他协议（邮件、SSH、FTP）和不需要保护的服务 → 不代理。

6.2 SSL/TLS 模式选择

这条值得单独强调，因为选错 SSL 模式可能导致安全问题。Cloudflare 提供四种模式：

关闭（Off）：不加密。不要用。

Flexible（灵活）：用户到 Cloudflare 是 HTTPS，Cloudflare 到源站是 HTTP。 - 浏览器地址栏会显示小锁图标 - 但源站连接没有加密——是个”假 HTTPS” - 不推荐，仅用于测试或源站完全不支持 HTTPS 的过渡期

Full：全程 HTTPS。Cloudflare 到源站也加密，但不验证源站的证书是否有效（自签名证书也能通过）。 - 比 Flexible 安全，但不防中间人攻击

Full(Strict)：全程 HTTPS，且严格验证源站证书——必须是受信任的 CA 签发的有效证书，且在有效期内。 - 这是生产环境的推荐配置

安全等级：Off < Flexible << Full < Full(Strict)
                                       ↑
                                   选这个

如果你不确定自己的源站配置是否支持 Full(Strict)，可以先选 Full 过渡，但上线前务必升级到 Full(Strict)。

6.3 缓存规则配置

Cloudflare 默认只缓存静态文件（CSS、JS、图片、字体等），不缓存 HTML 页面。这个默认策略对大多数网站已经够用。

需要自定义缓存时，进入”缓存 → 缓存规则”：

按路径缓存：/images/* 设置长缓存时间
按文件类型缓存：.pdf、.mp4 等大文件单独配置
绕过缓存：/admin/* 和 /api/* 不缓存（动态内容）
按 Cookie 区分：已登录用户和未登录用户看不同的缓存版本

通用建议：静态资源（CSS/JS/图片）缓存 30 天以上，但记得文件名使用版本哈希（如 app.a1b2c3d.js），这样更新内容时能自动绕过旧缓存。

6.4 页面规则和防火墙规则

页面规则让你对特定 URL 路径做精细控制。免费计划有 3 条。常见用法：

/admin/* → 安全级别设为”高”、缓存级别设为”绕过”
/uploads/* → 缓存级别设为”标准”
*example.com/* → 开启”自动 HTTPS 重写”

防火墙规则（WAF 自定义规则）让你根据请求特征做判断：

某个 IP 段频繁报错 → 质询（Challenge）或阻止
特定 User-Agent → 阻止
特定国家/地区的流量 → 质询
请求路径包含 wp-admin → 仅允许指定 IP

6.5 免费 SSL 证书

Cloudflare 提供免费的边缘证书（Edge Certificate），自动签发、自动续期。你不需要在源站配置 Let’s Encrypt 或购买证书（当然，源站本身仍然需要一个证书用于 Full 模式）。

选项说明：

Universal SSL：免费、自动、通配符（*.example.com），但你的访客的浏览器需要支持 SNI
Advanced Certificate Manager（付费）：支持更多自定义选项

对于绝大多数网站，Universal SSL 完全够用。确保开启了”始终使用 HTTPS”和”自动 HTTPS 重写”选项。

图 6.1：从源站是否有证书开始，通过决策树选择最合适的 SSL/TLS 模式。

6.6 练习与检查：配置审计

配置清单：打开你的 Cloudflare 控制台，逐一检查以下配置： - [ ] DNS 关键记录已确认（代理状态正确） - [ ] SSL/TLS 模式至少为 Full - [ ] “始终使用 HTTPS”已开启 - [ ] 静态资源路径已配置缓存规则 - [ ] /api 和 /admin 路径已设为不缓存

检查点： 1. Flexible 模式下浏览器显示小锁，但为什么不安全？ 2. 为什么缓存静态资源时要用版本哈希文件名？ 3. 页面规则和防火墙规则的区别是什么？

第7章进阶：边缘计算与存储

7.1 Workers：在离用户最近的地方运行代码

传统后端部署在少数几个数据中心。如果你的服务器在美东，亚洲用户的每个 API 请求都要跨太平洋。Workers 改变了这个模型：你的代码被部署到 Cloudflare 的每一个边缘节点，在离请求者最近的地方执行。

一个 Worker 是一个 JavaScript（或 TypeScript）函数，监听 HTTP 请求并返回响应。最简单的 Worker 长这样：

export default {
  async fetch(request, env, ctx) {
    return new Response("Hello from the edge!");
  },
};

这段代码运行在 Cloudflare 全球 330+ 个节点上。任何一个节点收到请求，就在本地执行并返回结果。请求不需要回源。

典型用途： - API 代理和网关（修改请求/响应头、做鉴权） - A/B 测试（根据 cookie 动态路由到不同版本） - 地理位置相关逻辑（返回用户附近的门店信息） - 图片处理（用 WebAssembly 做实时裁剪/压缩） - Webhook 接收和处理

7.2 第一个 Worker

用 Wrangler CLI 创建和部署一个 Worker：

安装 Wrangler（需要 Node.js 16.17.0+）：

npm install -g wrangler

登录并创建项目：

wrangler login
npm create cloudflare@latest my-worker -- --type simple
cd my-worker

部署：

npx wrangler deploy

部署完成后，你的 Worker 就运行在 https://my-worker.<你的子域名>.workers.dev 上了。

一个小例子：天气 API 代理

假设你的前端直接调用第三方天气 API，但不想在前端暴露 API Key。写一个 Worker 作为代理：

export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);
    const city = url.searchParams.get("city") || "Beijing";

    // 调用第三方 API，API Key 在 Worker 配置中，不暴露给前端
    const apiUrl = `https://api.weatherapi.com/v1/current.json?key=${env.WEATHER_API_KEY}&q=${city}`;
    const response = await fetch(apiUrl);
    const data = await response.json();

    // 可以在这里做数据处理、过滤、格式化
    return Response.json({
      city: data.location.name,
      temp: data.current.temp_c,
      condition: data.current.condition.text,
    });
  },
};

在 wrangler.toml 中配置密钥：

[vars]
WEATHER_API_KEY = "你的密钥"

7.3 存储产品选择

四个存储产品，怎么选？

KV（Key-Value）：最简单的键值存储。读很快（全球分布），写最终一致。适合存储不经常变化、读多写少的数据，如网站配置、功能开关、翻译文本。不适合做计数器、实时状态——写入后可能 60 秒才能在全球读到新值。

R2（对象存储）：S3 兼容的 API，零出口费。适合图片、视频、用户上传文件、构建产物、备份。如果你用过 AWS S3，R2 的 API 几乎一样，迁移成本很低。

D1（关系型数据库）：基于 SQLite 的无服务器数据库。支持 SQL 查询，强一致性。适合用户数据、订单系统、CMS 内容、任何需要关系和事务的结构化数据。

Durable Objects（持久对象）：全球唯一的单实例计算+存储。适合协作编辑（多个用户同时操作同一文档）、实时计数器（不怕并发）、会话管理和 WebSocket 连接状态。

选择决策：
需要 SQL 查询？          → D1
需要存文件/图片/视频？   → R2
简单读多写少配置？       → KV
多人实时协作或并发计数？ → Durable Objects

7.4 实战组合：图片托管服务

用 Workers + R2 构建一个简单的图片托管服务，二十几行代码：

export default {
  async fetch(request, env) {
    const url = new URL(request.url);

    // 上传图片
    if (request.method === "POST" && url.pathname === "/upload") {
      const key = `${Date.now()}-${Math.random().toString(36).slice(2)}`;
      await env.BUCKET.put(key, request.body, {
        httpMetadata: { contentType: request.headers.get("content-type") },
      });
      return Response.json({ url: `${url.origin}/${key}` });
    }

    // 访问图片
    const key = url.pathname.slice(1);
    const object = await env.BUCKET.get(key);
    if (!object) return new Response("Not Found", { status: 404 });

    return new Response(object.body, {
      headers: {
        "content-type": object.httpMetadata.contentType,
        "cache-control": "public, max-age=31536000",
      },
    });
  },
};

在 wrangler.toml 中绑定 R2 桶：

[[r2_buckets]]
binding = "BUCKET"
bucket_name = "my-images"

部署后，你可以用 curl -X POST --data-binary @photo.jpg https://your-worker.workers.dev/upload 上传图片，然后直接通过 URL 访问。所有图片存储在 R2 中，没有出口流量费。

图 7.1：从数据类型、读写模式和一致性需求出发，选择适合的存储产品。

7.5 练习与检查：Worker 实操

实操练习：创建你的第一个 Worker——一个简单的 Hello World 即可。用 wrangler dev 在本地测试，然后用 wrangler deploy 发布到 Cloudflare。确认它可以通过 .workers.dev 域名访问。

检查点： 1. Worker 和传统的后端服务器有什么区别？ 2. 为什么 KV 不适合做计数器？应该用什么替代？ 3. R2 的”零出口费”指的是什么？在什么场景下这个优势特别重要？

第8章进阶：安全防护与 Zero Trust

8.1 WAF：精准拦截攻击请求

WAF（Web Application Firewall）通过一组规则来检测和拦截恶意请求。Cloudflare 的 WAF 分为两层：

托管规则集（Managed Rulesets）：由 Cloudflare 安全团队维护，覆盖 OWASP Top 10（SQL 注入、XSS、命令注入、路径遍历等）和常见 CMS 漏洞（WordPress、Drupal）。你只要开启，不需要自己写规则。Pro 及以上计划可用。

自定义规则（Custom Rules）：你自己写的匹配条件。例如：

字段：URI 路径
运算符：包含
值：/wp-admin
操作：阻止

或者更复杂的条件：

(ip.src in {1.2.3.0/24} and http.request.uri.path contains "/login")
or (cf.threat_score gt 50)
→ 操作：JS 质询

WAF 规则在请求到达源站之前执行，所以可以阻止恶意请求而不会消耗源站资源。

8.2 DDoS 防护的内部机制

Cloudflare 的 DDoS 防护不需要你配置——它始终在线。

L3/L4（网络层/传输层）防护：SYN flood、UDP flood、ICMP flood 等攻击在边缘网络被自动检测和过滤。Cloudflare 利用 Anycast 网络将攻击流量分散到全球数百个节点，每个节点只面对总量的一小部分。

L7（应用层）防护：HTTP flood 攻击（大量看似合法的 HTTP 请求）通过速率限制、行为分析和挑战页面来缓解。当检测到异常流量模式时，Cloudflare 会自动向可疑客户端发送 JS 挑战或 CAPTCHA。

免费计划的 L3/L4 DDoS 防护是”不计量”的——即使遭受 Tbps 级别的攻击，你也不会收到账单。L7 防护在免费计划下有速率限制。

8.3 Cloudflare Tunnel：不开放任何端口

传统做法：服务器上运行一个 Web 应用 → 防火墙开放 80/443 端口 → 配置端口转发 → 公网 IP 暴露。这每一步都增加了攻击面。

Cloudflare Tunnel 的做法完全不同：

在你的服务器上安装 cloudflared
cloudflared 创建一条出站隧道连到 Cloudflare 的边缘网络
外部用户通过 Cloudflare 网络访问你的应用
你的防火墙不需要开放任何入站端口——连 443 都不需要
服务器甚至不需要有公网 IP

这从根本上消除了端口扫描、暴力破解和网络层攻击的风险——攻击者根本看不到你的服务器。

快速上手：

安装 cloudflared：

macOS：

brew install cloudflared

Linux：

curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -o cloudflared
chmod +x cloudflared
sudo mv cloudflared /usr/local/bin/

cloudflared tunnel login
cloudflared tunnel create my-tunnel
cloudflared tunnel route dns my-tunnel app.example.com
cloudflared tunnel run --url http://localhost:3000 my-tunnel

8.4 Zero Trust 体系

Cloudflare Zero Trust 是一套替代传统”信任内网”模型的安全体系：

Access：在应用前面加身份认证。用户访问 admin.example.com 时，先被重定向到 Cloudflare 的登录页面。只有通过你配置的身份提供者（Google Workspace、Azure AD、GitHub 等）认证的用户才能看到应用。

Gateway：DNS 过滤和安全 Web 网关。阻止员工设备访问已知恶意域名和钓鱼网站。支持按策略分组（全部员工、市场部、外聘人员等）。

WARP：安装在终端设备上的客户端。将设备流量通过加密隧道发到 Cloudflare 网络，在那里执行 Gateway 策略。相当于一个不依赖内网 VPN 的安全上网方案。

这套体系的核心思想：不信任任何网络，不信任任何设备，每次访问都要验证。

8.5 安全配置检查清单

上线前逐项确认：

图 8.1：Tunnel 替代 VPN、Access 做身份认证、Gateway 做 DNS 过滤——三层防护构成 Zero Trust 体系。

8.6 练习与检查：安全审计

安全检查：检查一个你维护的或你熟悉的网站，对照上面的清单逐项核对，记录哪些已做到、哪些需要改进。

检查点： 1. WAF 托管规则集和自定义规则分别解决什么问题？ 2. Cloudflare Tunnel 和反向代理 + 防火墙有什么本质区别？ 3. “零信任”（Zero Trust）的核心原则是什么？

综合练习

学完这八章内容，你应该能够独立完成以下任务。把它当成一个自检列表：

任务：为一个新网站完整配置 Cloudflare

你有一个域名 myproject.com，一台运行着 Node.js 应用的 VPS（端口 3000）。

接入：将域名接入 Cloudflare，修改 Nameserver
DNS：配置 A 记录指向 VPS IP，开启代理
SSL：设置 Full(Strict) 模式，确认 HTTPS 正常
缓存：配置静态资源（CSS/JS/图片）长缓存，API 路径不缓存
WAF：开启托管规则集（如果有 Pro），写一条自定义规则限制 /admin 路径
Worker：创建一个 Worker 作为 API 代理，隐藏源站实际路径
Tunnel：用 cloudflared 创建一个隧道，通过临时 URL 测试你的应用
安全检查清单：逐项核对第八章的检查清单

自检评估

完成后对照以下标准：

评估维度	达标标准
接入正确性	域名状态”有效”，curl 响应头含 `cf-ray`
SSL 安全性	`curl -v https://myproject.com` 显示 TLS 握手成功，无证书警告
缓存效果	同一静态资源第二次请求在 50ms 以内，响应头含 `cf-cache-status: HIT`
安全防护	`/admin` 路径从未授权 IP 访问时被拦截或质询
Worker 运行	通过 `.workers.dev` 域名成功返回自定义响应