Cloudflare 免费节点方案阅读记录（FreeDidi）

Blog 版：在 F-SJ Blog 阅读

出处：FreeDidi / 零度博客原文《2026 最强 Cloudflare 免费节点！永久可用+免费域名｜10分钟搭建｜解锁 ChatGPT / Gemini！》

原文发布时间：2026-04-02

为什么会记录这篇文章

最开始看到这篇文章，是因为它把几个平时经常听到、但容易分散理解的东西串到了一起：免费域名、Cloudflare DNS、Cloudflare Pages、Worker KV、环境变量、自定义域名和一个可视化管理面板。

单独看这些名词，每个都不复杂；放在一起之后，就变成了一个完整的“个人云端小服务”样板。它不一定适合照抄到正式环境里，但很适合用来理解：没有服务器、没有固定公网 IP、预算很低时，Cloudflare 这类边缘平台到底能做到什么程度。

这篇记录不会复刻真实节点、token、UUID、私钥、订阅地址，也不会记录具体绕过用途。更值得留下的是它背后的组合思路，以及做这类实验时应该注意的边界。

我看到的核心思路

这套流程的核心不是某一个“免费节点”，而是把多个免费或低成本组件组合起来：

域名负责入口。
Cloudflare DNS 负责解析和 HTTPS。
Cloudflare Pages 负责部署。
Worker KV 负责轻量存储。
环境变量负责保存后台口令。
管理面板负责生成和维护配置。

这和搭建个人 Blog、私人 Email 的思路很像：先把服务跑起来，再回头理解每一层为什么存在、负责什么、风险在哪里。

流程拆解

1. 先准备一个域名

原文先从免费域名开始。这里的重点不是域名本身有多特殊，而是“先拥有一个可以被 Cloudflare 托管的入口”。

如果还没有域名，可以先看我整理过的免费域名获取：DigitalPlat 与 Cloudflare 集成记录。那篇笔记更聚焦“如何拿到免费域名，并把它交给 Cloudflare 管理”。

有了域名，后面才可以继续做 DNS 托管、自定义子域名、Pages 绑定和 HTTPS 访问。没有域名，也可以用 Pages 默认域名测试，但长期使用和迁移都会不方便。

2. 把域名接入 Cloudflare

域名拿到后，下一步就是交给 Cloudflare 管理。

这个动作本质上是在确认几件事：

域名 NS 是否已经切到 Cloudflare。
Cloudflare 是否能管理 DNS 记录。
HTTPS / SSL 状态是否正常。
后续子域名是否能直接绑定到 Pages 项目。

很多 Cloudflare 项目的第一道门槛都在这里。只要域名托管和 SSL 状态正常，后面 Pages、Workers、Email、R2 这些能力才更容易串起来。

3. 创建 Worker KV

原文里还需要创建 Worker KV。

我理解它的角色更像一个轻量级配置仓库：不用单独准备数据库，也不用维护服务器，只需要给 Pages / Worker 项目绑定一个 KV 空间，就可以保存一些运行配置或状态。

当然，KV 不是关系型数据库，也不适合复杂查询。但对这种小型工具面板来说，它的门槛足够低，和 Cloudflare Pages 放在一起也比较自然。

4. 创建 Cloudflare Pages 项目

部署部分使用 Cloudflare Pages。原文提到使用 CMliu 的开源程序，可以通过 GitHub 源码或 Pages 专用安装包完成部署。

这里最值得注意的是：Pages 不只是“静态网页托管”。结合 Functions、KV、环境变量之后，它可以承载一些轻量后台能力。对个人项目来说，这种模式比直接买服务器更省心，也更适合快速试错。

5. 配置管理员环境变量

原文中管理员口令通过环境变量配置，变量名是：

ADMIN

这类信息应该只放在 Cloudflare 后台，不应该写进公开笔记，也不应该提交到 GitHub。配置完成后，还需要重新部署一次，让生产环境真正读取到新变量。

这个步骤也提醒我：只要项目涉及后台、口令、token、密钥，就应该优先使用平台环境变量，而不是把配置写死在代码里。

6. 绑定 KV 命名空间

KV 绑定使用的变量名是：

KV

它把前面创建的 KV 空间交给 Pages 项目使用。绑定完成后再次部署，后台才有地方保存配置和状态。

这一点和 Blog 项目里的 D1 / KV 绑定很像：代码只是调用接口，真正的数据能力来自 Cloudflare 后台绑定的资源。

7. 绑定自定义域名

原文建议使用子域名，不建议直接使用根域名。

这个建议比较实际。根域名通常还要留给主页、Blog 或其它长期入口；实验项目更适合放到独立子域名下。这样后续即使删除项目、替换 Pages、调整 DNS，也不容易影响主站。

大致流程是：

在 Pages 控制台添加自定义域名。
选择一个独立子域名。
根据提示添加 CNAME 或让 Cloudflare 自动配置。
等待域名激活和 HTTPS 生效。

8. 访问后台并生成订阅

自定义域名生效后，原文通过 /admin 进入后台，用管理员口令登录，然后生成节点链接或订阅地址。

这里我更关注“后台面板”这种设计方式：复杂配置不要都写在文件里，而是通过一个受保护的管理页面来维护。这个思路也可以迁移到 Blog 项目，比如评论审核、友链审核、订阅用户管理等，都更适合放在 Admin 页面里处理。

9. 高级选项先只理解概念

原文后半部分还有优选订阅地址、ProxyIP、自定义 ProxyIP 等内容。

这类配置已经偏向具体网络环境调优，公开记录不适合展开具体地址和参数。对我来说，保留概念就够了：

优选入口：尝试选择更合适的访问路径。
ProxyIP：在特定网络环境下改善可用性。
自定义订阅：适配不同客户端和不同网络条件。

这篇文章对个人项目的启发

这篇文章最有价值的地方，是展示了 Cloudflare 免费生态的组合能力。

它和单纯“买一台服务器然后部署服务”的思路不一样。Cloudflare 的模式更像是把很多小积木拼起来：DNS、Pages、Workers、KV、环境变量、自定义域名，每个积木只解决一小段问题，但组合后就能跑出一个完整服务。

这种方式特别适合个人学习：

成本低，适合试错。
部署快，容易看到结果。
不需要长期维护服务器。
每个组件都能单独学习和替换。
做坏了也容易删掉重来。

这也是为什么我会把它和 Blog、Email 项目放在同一类思路里看：它们本质上都在回答一个问题——一个普通个人用户，能不能用低成本云服务搭出属于自己的工具体系？

风险和边界

这类方案适合学习、验证和个人低频测试，不适合作为高负载、强稳定性或敏感业务的长期基础设施。

需要注意：

Cloudflare 免费额度和服务策略可能变化。
第三方开源项目需要自行审查源码和许可证。
后台密码、订阅地址、UUID、私钥等不能公开。
实验项目不建议和正式 Blog / Email 混用同一个子域名。
使用前应确认当地法律法规和平台服务条款。