Cloudflare 实战案例分享｜一键部署

在网站建设、接口服务、静态资源分发、轻量级后端部署等场景中，Cloudflare 已经不再只是一个“免费 CDN”工具，而是逐渐演变成一套完整的云原生边缘计算平台。对于个人开发者、中小团队，甚至部分企业项目来说，Cloudflare 提供的 Workers、Pages、R2、D1、KV、Turnstile、Zero Trust、Tunnel 等服务，可以帮助我们以较低成本快速完成网站上线、接口部署、安全防护和访问加速。

本文将结合一个真实的实战思路，分享如何利用 Cloudflare 实现“一键部署”一个前端站点或轻量级服务，并在部署完成后进一步配置域名、HTTPS、缓存、安全策略和边缘函数能力。文章重点不只是介绍概念，而是尽量从实际落地角度出发，帮助你理解 Cloudflare 在项目中的使用方式。

一、为什么选择 Cloudflare？

在过去，部署一个网站通常需要准备服务器、安装 Nginx、配置 SSL 证书、绑定域名、做反向代理、设置缓存策略，还要考虑安全问题。如果项目访问量逐渐增大，还需要购买更高配置的服务器或接入 CDN。

而 Cloudflare 的优势在于，它将很多基础设施能力进行了封装：

• 全球 CDN 加速：Cloudflare 拥有覆盖全球的边缘节点，可以就近响应用户请求。
• 免费 HTTPS：只要域名接入 Cloudflare，就可以快速启用 SSL/TLS。
• DDoS 防护：基础防护能力开箱即用，适合中小型网站。
• Workers 边缘计算：可以在边缘节点运行 JavaScript/TypeScript 代码。
• Pages 静态部署：适合部署 Vue、React、Next.js、Astro、Vite 等前端项目。
• R2 对象存储：类似 S3，但对外网出口流量更友好。
• KV/D1 数据能力：适合轻量级缓存、配置、边缘数据库等场景。
• Tunnel 内网穿透：无需暴露服务器公网 IP，也可以安全访问内网服务。
• Zero Trust 访问控制：可以对管理后台、内部系统进行身份验证保护。

因此，如果你的项目规模不是特别复杂，Cloudflare 可以帮助你减少大量运维成本。

二、实战场景说明

本文以一个常见项目为例：

一个使用 Vite 构建的前端项目，需要部署到线上，并绑定自定义域名，同时通过 Cloudflare 提供 HTTPS、缓存、安全防护和后续扩展能力。

最终目标：

1. 将项目代码托管到 GitHub；
2. 使用 Cloudflare Pages 实现自动构建部署；
3. 绑定自己的域名；
4. 开启 HTTPS；
5. 配置缓存和访问规则；
6. 后续可扩展为 Workers API、R2 图床、Turnstile 人机验证等能力；
7. 实现尽可能接近“一键部署”的上线流程。

三、准备工作

在正式部署前，需要准备以下内容：

1. 一个 Cloudflare 账号

访问 Cloudflare 官网注册账号即可。注册完成后，可以进入控制台管理域名、Pages、Workers 等服务。

2. 一个 GitHub 仓库

Cloudflare Pages 支持从 GitHub 或 GitLab 自动拉取代码构建部署。因此，建议将你的项目代码上传到 GitHub。

例如，一个 Vite 项目的基础目录结构如下：

my-cloudflare-demo/
├── public/
├── src/
├── index.html
├── package.json
├── vite.config.js
└── README.md

3. 一个域名

如果你希望使用自定义域名，例如：

example.com
www.example.com
app.example.com

则需要将域名 DNS 托管到 Cloudflare，或者至少在域名解析处添加 Cloudflare 要求的 CNAME 记录。

四、项目初始化

如果你还没有前端项目，可以使用 Vite 快速创建一个。

npm create vite@latest my-cloudflare-demo

根据提示选择框架，例如：

Vue
React
Svelte
Vanilla

进入项目目录：

cd my-cloudflare-demo

安装依赖：

npm install

本地启动：

npm run dev

浏览器访问：

http://localhost:5173

确认项目正常运行后，执行构建：

npm run build

构建完成后，一般会生成：

dist/

这就是 Cloudflare Pages 后续要发布的目录。

五、配置 Cloudflare Pages

进入 Cloudflare 控制台，找到 Workers & Pages，然后选择 Create application。

选择：

Pages → Connect to Git

然后授权 GitHub，选择你的项目仓库。

构建配置

对于 Vite 项目，通常填写：

Framework preset: Vite
Build command: npm run build
Build output directory: dist

如果是 Vue CLI 项目，输出目录可能是：

dist

如果是 React CRA 项目，输出目录可能是：

build

如果是 Next.js 项目，则需要根据是否使用静态导出进行不同配置。

配置完成后，点击部署。Cloudflare 会自动拉取代码、安装依赖、执行构建并发布。

部署成功后，会得到一个默认域名，例如：

my-cloudflare-demo.pages.dev

此时，你的项目已经成功上线。

六、一键部署思路

所谓“一键部署”，通常有两种理解：

第一种是通过 Cloudflare Pages 的 Git 集成实现自动部署。只要你向 GitHub 推送代码，Cloudflare 就自动构建并发布。

第二种是通过 Cloudflare CLI 工具 Wrangler，在本地或 CI/CD 中执行命令完成部署。

方式一：GitHub 推送自动部署

这是最简单的方式。只要配置好 Pages 项目，以后每次修改代码后执行：

git add .
git commit -m "update project"
git push origin main

Cloudflare Pages 会自动检测到主分支更新，并触发构建。

这种方式非常适合：

• 个人博客；
• 产品官网；
• 文档站点；
• 前端管理页面；
• 活动页；
• 静态 Landing Page。

方式二：使用 Wrangler 一键部署

安装 Wrangler：

npm install -g wrangler

登录 Cloudflare：

wrangler login

如果你要部署 Pages，可以使用：

wrangler pages deploy dist --project-name=my-cloudflare-demo

为了更方便，可以在 package.json 中添加脚本：

{
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "deploy": "npm run build && wrangler pages deploy dist --project-name=my-cloudflare-demo"
  }
}

以后只需要执行：

npm run deploy

就能完成构建与部署。

这就是非常实用的一键部署方式。

七、绑定自定义域名

部署到 Pages 后，默认域名虽然可以访问，但正式项目一般都会使用自己的域名。

在 Cloudflare Pages 项目中找到：

Custom domains

点击添加域名，例如：

app.example.com

Cloudflare 会提示你添加 DNS 记录。如果你的域名已经托管在 Cloudflare 上，通常可以自动完成。如果域名不在 Cloudflare，需要到域名服务商处添加对应的 CNAME 记录。

例如：

app.example.com CNAME my-cloudflare-demo.pages.dev

解析生效后，访问：

https://app.example.com

即可看到部署的网站。

八、HTTPS 与 SSL/TLS 配置

Cloudflare 会自动为你的域名签发证书。建议在 SSL/TLS 中选择合适的模式。

常见模式包括：

如果使用 Cloudflare Pages，通常无需担心源站证书问题，因为 Pages 本身就是 Cloudflare 托管的服务。

如果你接入的是自己的服务器，建议使用：

Full strict

并在服务器上安装有效证书，或者使用 Cloudflare Origin Certificate。

九、缓存策略优化

Cloudflare 默认会缓存部分静态资源，但如果想进一步优化性能，可以配置 Cache Rules。

对于前端项目，常见策略如下：

1. 静态资源长期缓存

例如 Vite 构建后的资源一般带有 hash：

/assets/index-a1b2c3.js
/assets/style-d4e5f6.css

这类文件内容变化后文件名会变化，因此可以设置较长缓存时间。

建议规则：

URL contains /assets/
Cache TTL: 1 month 或 1 year

2. HTML 不强缓存

对于入口文件：

/index.html

不建议设置过长缓存，否则用户可能无法及时看到新版本。

可以设置：

Cache TTL: 0 或较短时间

3. API 请求不缓存

如果你的项目中包含接口请求，例如：

/api/user
/api/order

通常不建议缓存，除非你明确知道数据可以缓存。

规则：

URL contains /api/
Cache: Bypass

合理配置缓存后，既能提升加载速度，又能避免上线后用户访问旧版本的问题。

十、使用 Workers 增强能力

Cloudflare Pages 适合部署静态站点，但如果你还想增加后端接口，可以结合 Workers。

例如创建一个简单 API：

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

    if (url.pathname === "/api/hello") {
      return Response.json({
        message: "Hello Cloudflare Workers",
        time: new Date().toISOString()
      })
    }

    return new Response("Not Found", { status: 404 })
  }
}

部署 Workers 后，可以绑定路由：

api.example.com/*

也可以将其作为前端项目的接口服务。

Workers 的优势在于：

• 无需服务器；
• 自动扩展；
• 全球边缘节点运行；
• 冷启动较快；
• 按请求量计费，低访问量项目成本很低。

对于个人项目来说，Workers 非常适合做：

• 短链接服务；
• Webhook 转发；
• 简单 API；
• 数据代理；
• RSS 处理；
• 轻量级身份验证；
• 图片处理入口。

十一、结合 KV 存储配置数据

如果 Workers 中需要保存一些轻量级数据，可以使用 Cloudflare KV。

例如保存网站配置、白名单、短链接映射等。

伪代码示例：

export default {
  async fetch(request, env) {
    const value = await env.MY_KV.get("site_config")

    return Response.json({
      config: value ? JSON.parse(value) : {}
    })
  }
}

KV 适合读多写少的场景，例如：

• 配置中心；
• 访问令牌；
• 页面缓存；
• 短链接数据；
• 字典数据。

但需要注意，KV 是最终一致性，不适合强事务场景。如果你需要结构化查询，可以考虑 D1 数据库。

十二、使用 R2 作为静态资源存储

如果项目中有大量图片、附件、音频或视频文件，可以考虑 Cloudflare R2。

R2 的特点是：

• 类似 Amazon S3；
• 适合对象存储；
• 可以绑定自定义域名；
• 与 Cloudflare CDN 配合方便；
• 对外网出口流量成本较友好。

常见用途：

• 图床；
• 文件下载站；
• 用户上传文件；
• 静态资源存储；
• 备份文件分发。

例如，你可以将图片上传到 R2，然后通过自定义域名访问：

https://static.example.com/images/banner.png

这样前端项目中直接引用：

既能减少主项目仓库体积，也方便资源管理。

十三、使用 Turnstile 防止机器人请求

如果网站包含表单、登录、注册、评论或提交接口，可以使用 Cloudflare Turnstile。

Turnstile 是 Cloudflare 提供的人机验证服务，可以作为传统验证码的替代方案。它的体验比很多图形验证码更友好，很多情况下用户无需手动点选图片。

适合使用 Turnstile 的场景：

• 登录页面；
• 注册页面；
• 评论提交；
• 联系我们表单；
• 抽奖活动；
• 公开 API 防滥用。

基本流程是：

1. 前端集成 Turnstile 组件；
2. 用户访问页面时生成验证 token；
3. 后端将 token 提交给 Cloudflare 校验；
4. 校验通过后再处理业务请求。

这样可以有效降低垃圾请求和机器人提交。

十四、使用 Tunnel 保护源站

如果你的项目不是纯静态页面，而是部署在自己的服务器上，也可以使用 Cloudflare Tunnel。

传统方式需要开放服务器端口，例如：

80
443
8080

而 Cloudflare Tunnel 可以让服务器主动连接 Cloudflare，外部用户通过 Cloudflare 访问服务，不需要暴露服务器公网 IP。

优点包括：

• 减少源站暴露；
• 避免直接被扫描；
• 配合 Zero Trust 做访问控制；
• 对家庭服务器、内网服务非常友好；
• 适合管理后台、私有面板、测试环境。

例如你有一个本地服务：

http://localhost:3000

可以通过 Tunnel 暴露为：

https://dev.example.com

这样既方便访问，又能提升安全性。

十五、实战中的安全配置建议

Cloudflare 功能很多，但上线后不能只关注“能访问”，还要关注安全。

1. 开启 WAF 规则

可以根据业务情况开启托管规则，拦截常见攻击请求，例如 SQL 注入、XSS、恶意扫描等。

2. 配置访问频率限制

如果某些接口容易被刷，可以配置 Rate Limiting，例如：

同一 IP 1 分钟内访问超过 60 次则触发限制

3. 管理后台加 Zero Trust

如果有后台管理系统，不建议直接暴露给公网。可以使用 Cloudflare Access，让用户登录指定邮箱或身份提供商后才能访问。

4. 隐藏源站 IP

如果网站使用自己的服务器作为源站，应避免源站 IP 被直接访问。可以设置防火墙，仅允许 Cloudflare IP 段访问源站。

5. 使用 Turnstile 保护表单

对于公开提交入口，一定要考虑机器人滥用问题。

十六、部署流程总结

一个比较完整的 Cloudflare 一键部署流程如下：

本地开发
  ↓
提交代码到 GitHub
  ↓
Cloudflare Pages 自动构建
  ↓
发布到 pages.dev
  ↓
绑定自定义域名
  ↓
启用 HTTPS
  ↓
配置缓存规则
  ↓
配置安全策略
  ↓
扩展 Workers / R2 / KV / Turnstile

如果使用 Wrangler，则可以简化为：

npm run deploy

对应脚本：

{
  "scripts": {
    "deploy": "npm run build && wrangler pages deploy dist --project-name=my-cloudflare-demo"
  }
}

这样每次上线只需要执行一条命令，非常适合个人项目和快速迭代场景。

十七、常见问题与解决方案

1. 部署后页面空白怎么办？

常见原因是资源路径错误。检查 Vite 配置中的 base 是否正确。如果部署在根路径，一般保持默认即可。

2. 页面刷新后 404 怎么办？

如果是 Vue Router 或 React Router 使用 history 模式，需要配置重写规则。可以在项目根目录创建 _redirects 文件：

/* /index.html 200

这样刷新任意路由都会返回入口文件。

3. 自定义域名无法访问怎么办？

检查 DNS 是否生效，CNAME 是否正确，Cloudflare Pages 中是否成功添加该域名。

4. HTTPS 证书一直未签发怎么办？

证书签发有时需要等待几分钟到几十分钟。若长时间不生效，检查 DNS 配置和域名验证状态。

5. 更新后用户看到旧页面怎么办？

检查缓存策略，尤其是 HTML 文件是否被强缓存。建议只对带 hash 的静态资源设置长期缓存。

十八、适合 Cloudflare 一键部署的项目类型

Cloudflare 并不是适合所有项目，但以下类型非常适合：

• 个人博客；
• 技术文档；
• 产品官网；
• 作品集网站；
• 前端单页应用；
• 小型活动页面；
• 静态资源站；
• 轻量 API 服务；
• Webhook 工具；
• 短链接服务；
• 内网服务安全访问入口。

如果你的项目需要复杂后端、高并发数据库事务、大规模长连接服务，则需要结合传统云服务器、数据库或其他云平台综合设计。

十九、实战经验总结

通过 Cloudflare 实现一键部署，最大的价值不只是“省钱”，而是降低项目上线门槛。对于很多前端项目来说，过去需要运维参与的事情，现在开发者自己就可以完成。

从实际使用体验看，Cloudflare Pages 适合做前端入口，Workers 适合处理轻量逻辑，R2 适合存储文件，KV 适合保存简单配置，Turnstile 适合防止机器人提交，Tunnel 和 Zero Trust 则适合保护内部系统。

一个成熟的 Cloudflare 项目架构可以是：

用户
 ↓
Cloudflare CDN / WAF
 ↓
Pages 前端站点
 ↓
Workers API
 ↓
KV / D1 / R2

这种架构的特点是轻量、弹性、低运维成本，非常适合快速上线和持续迭代。

二十、结语

Cloudflare 的强大之处在于，它把 CDN、安全、边缘计算、对象存储、访问控制等能力整合到了一套平台中。对于个人开发者和中小团队而言，只要掌握 Pages、Workers、DNS、缓存和安全规则，就已经可以完成大量生产级项目的部署需求。

如果你希望快速上线一个项目，推荐从 Cloudflare Pages 开始；如果你需要接口能力，再逐步引入 Workers；如果你需要文件存储，可以接入 R2；如果你需要更高安全性，可以配置 WAF、Turnstile、Tunnel 和 Zero Trust。

最终，你可以将部署流程简化为一句命令：

npm run deploy

或者一次 GitHub 推送：

git push origin main

这正是 Cloudflare 一键部署最吸引人的地方：让开发者把更多时间放在产品和业务本身，而不是反复处理服务器、证书、配置和运维问题。