Cloudflare Pages 部署 EdgeTunnel 与 CFNew：KV、环境变量、自定义域名完整教程

这篇文章记录一套尽量不依赖本地开发环境的 Cloudflare Pages 部署方法，目标是通过 Cloudflare Dashboard 的 Direct Upload（直接上传） 完成两个项目的部署：

1. cmliu/edgetunnel
2. byJoey/cfnew

两者都运行在 Cloudflare 的边缘运行时上，都可以通过 Pages 的 _worker.js Advanced Mode 执行动态逻辑，但它们的环境变量、KV Binding 名称和管理入口完全不同，最容易出错的地方就是把两套配置混在一起。

本文按 2026 年 8 月的仓库与 Cloudflare Pages 文档整理。Cloudflare Dashboard 的菜单名称以后可能变化，但配置逻辑不会因为界面换皮而改变。

本文仅用于学习 Cloudflare Pages、Workers Runtime、KV Binding 和边缘网络应用的部署流程。请遵守所在地法律法规、Cloudflare 服务条款以及相关开源项目的许可和免责声明。

---

一、先理解 Pages、_worker.js 和 KV

Cloudflare Pages 最初主要用于静态站点，但 Pages Functions 可以执行服务端逻辑。对于已经写成 Worker 的项目，Cloudflare 还提供 Advanced Mode：

Pages 项目
   │
   ├── 静态资源
   │
   └── _worker.js
          │
          ▼
   Cloudflare Workers Runtime

只要部署目录中存在符合 Module Worker 语法的 _worker.js，Pages 就可以让它接管请求。

因此像 EdgeTunnel、CFNew 这种项目，即使最终入口看起来是一个 pages.dev 网站，真正的动态请求处理仍然发生在 Cloudflare Workers Runtime 中。

Cloudflare 官方 Direct Upload 当前支持：

Dashboard 拖拽：
- 文件夹
- ZIP

Wrangler：
- 文件夹
- 不直接接受 ZIP

而 _worker.js 同时支持 Dashboard 拖拽和 Wrangler 部署。

1. 环境变量是什么

环境变量可以理解为“不写死在代码中的配置”。

例如：

ADMIN = 后台管理密码
u     = UUID

代码部署不变，但运行时可以从 Cloudflare 环境中读取这些配置。

2. KV 是什么

Workers KV 是 Cloudflare 的分布式键值存储。

可以简单理解为：

Key             Value
--------------  --------------------
config          {...}
preferred_ips   [...]
settings        {...}

KV Namespace 的数据库名字可以自己取，但代码访问它时使用的 Binding 名必须和项目代码一致。

例如：

真实 KV Namespace 名称：
edgetunnel-prod-kv

代码中的 Binding：
KV

这两个名字不是一回事。

---

二、本文统一使用的命名方案

为了以后不混乱，建议两个项目完全分开。

项目	Pages 项目名	KV Namespace	KV Binding
EdgeTunnel	edgetunnel-pages	edgetunnel-prod-kv	KV
CFNew	cfnew-pages	cfnew-prod-kv	C

这里：

edgetunnel-pages
edgetunnel-prod-kv
cfnew-pages
cfnew-prod-kv

只是推荐名称，可以修改。

但是下面两个 Binding 名是代码要求，不要自己改：

EdgeTunnel：KV
CFNew：     C

---

三、方案一：部署 cmliu/edgetunnel 2.1

1. 获取官方部署包

项目：

https://github.com/cmliu/edgetunnel

当前项目为 EdgeTunnel 2.1。

对于 Pages Direct Upload，作者当前 README 直接推荐下载：

main.zip

也就是说，不需要自己从仓库里拼接 Pages 文件。

在 GitHub README 的：

Pages 上传 部署方法

下面找到 main.zip 下载链接即可。

建议保留原始 ZIP，例如：

main.zip

或者另存一份：

edgetunnel-main.zip

文件名本身不影响部署。

---

四、创建 EdgeTunnel Pages 项目

登录 Cloudflare Dashboard，进入：

Workers & Pages
→ Create application
→ Pages
→ Upload assets / Direct Upload

如果中文界面名称略有不同，只要找到：

Pages
上传资产

即可。

1. 项目名称

建议填写：

edgetunnel-pages

如果已经存在，可以使用：

edgetunnel-pages-01

Cloudflare 会给项目分配类似：

https://edgetunnel-pages.pages.dev

的默认地址。

2. 第一次上传

上传：

main.zip

然后：

Deploy site

第一次部署只负责把代码放上去。

此时网页能打开，并不代表所有后台功能已经配置完成，因为 ADMIN 和 KV 还没有准备好。

---

五、配置 EdgeTunnel 的 ADMIN

进入：

Workers & Pages
→ edgetunnel-pages
→ Settings
→ Variables and Secrets

添加生产环境变量。

变量名：

ADMIN

值：

自己生成的强密码

例如密码应该是随机长密码，而不是：

123456
admin
password

如果 Dashboard 提供 Secret / Encrypt 类型，建议把 ADMIN 保存为 Secret，而不是普通明文变量。

配置目标：

Production

ADMIN = <你的强密码>

ADMIN 是 EdgeTunnel 当前唯一明确的必填环境变量，用于：

/admin

后台登录。

---

六、建议固定 EdgeTunnel UUID

EdgeTunnel 的 UUID 不是必填项，但是长期使用时建议主动固定。

如果不主动设置，项目可以根据其他配置派生相关身份信息；当以后修改 ADMIN 或 KEY 时，可能造成订阅 TOKEN 或 UUID 变化。

因此建议生成一个 UUIDv4。

Windows PowerShell：

[guid]::NewGuid().ToString()

Python：

python -c "import uuid; print(uuid.uuid4())"

然后增加：

UUID = <生成的 UUIDv4>

例如格式：

xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx

不要复制网上教程中的示例 UUID。

建议把 UUID 和 ADMIN 一样妥善保存。

---

七、是否建议设置 OFF_LOG

EdgeTunnel 默认支持 KV 日志记录。

如果只是个人使用，不需要后台长期记录访问日志，可以增加：

OFF_LOG = 1

这样可以关闭项目自身的 KV 日志记录逻辑。

最终比较简洁的生产环境变量可以是：

ADMIN   = <强密码>
UUID    = <随机 UUIDv4>
OFF_LOG = 1

其他变量先保持为空。

---

八、创建 EdgeTunnel KV Namespace

现在创建独立 KV。

Cloudflare Dashboard 中找到：

Storage & Databases
→ KV

不同版本界面也可能显示：

Workers KV

点击：

Create instance

或者：

Create namespace

名称建议填写：

edgetunnel-prod-kv

然后创建。

注意：

KV Namespace 名：
edgetunnel-prod-kv

只是 Cloudflare 后台给人看的名字。

代码真正关心的是下一步的 Binding 名。

---

九、把 KV 绑定到 EdgeTunnel

回到：

Workers & Pages
→ edgetunnel-pages
→ Settings
→ Bindings
→ Add
→ KV namespace

这里按下面填写。

Variable name

KV

必须大写。

不要填写：

kv
edgetunnel-kv
edgetunnel-prod-kv

KV Namespace

下拉选择：

edgetunnel-prod-kv

最终应当是：

Binding type:
KV Namespace

Variable name:
KV

Namespace:
edgetunnel-prod-kv

保存。

---

十、为什么配置完以后必须重新部署

Cloudflare Pages 的 KV Binding 在创建后不会自动注入到已经存在的旧 Deployment 中。

因此：

添加 ADMIN
添加 UUID
添加 OFF_LOG
绑定 KV

之后，建议创建一个新的 Production Deployment。

对于 Direct Upload 项目，Cloudflare Dashboard 当前没有一个单纯的“原文件原地重新执行”按钮，因此最直接的方法就是：

Deployments
→ Create new deployment
→ Production
→ 再上传一次原来的 main.zip
→ Save and Deploy

代码不需要改。

第二次上传的意义不是“更新代码”，而是让新 Deployment 带上最新变量和 Binding。

---

十一、验证 EdgeTunnel 是否部署成功

部署完成后访问：

https://edgetunnel-pages.pages.dev/admin

或者你的实际 pages.dev 地址。

输入：

ADMIN

密码。

至少完成下面三个检查：

1. /admin 能打开
2. ADMIN 可以正常登录
3. 后台修改一个配置并保存后，刷新仍然存在

第三项最重要。

如果修改后刷新仍然保存，说明：

Pages                 正常
_worker.js            正常
ADMIN                 正常
KV Binding            正常
KV 持久化             正常

---

十二、EdgeTunnel 其他环境变量怎么处理

EdgeTunnel 当前还支持很多可选环境变量。

变量	是否建议初次配置	作用
ADMIN	必须	管理后台密码
UUID	推荐	固定 UUID
OFF_LOG	推荐按需	关闭 KV 日志
KEY	暂不需要	快速订阅路径密钥
PROXYIP	暂不需要	自定义 ProxyIP
URL	暂不需要	默认主页/伪装 URL
GO2SOCKS5	暂不需要	指定目标强制走 SOCKS5
DEBUG	不建议	调试日志
BEST_SUB	暂不需要	优选订阅生成器
PRELOAD_RACE_DIAL	暂不需要	预加载竞速拨号
TCP_CONCURRENT_DIAL	默认即可	TCP 并发拨号
PROXY_CONCURRENT_DIAL	默认即可	Proxy 并发拨号

第一次部署不要为了“看起来配置完整”而把所有变量填满。

建议：

ADMIN   = 已设置
UUID    = 已设置
OFF_LOG = 1

其他保持默认

等基础连接完全正常以后，再调整 ProxyIP、优选、SOCKS5 等高级项。

---

十三、给 EdgeTunnel 绑定自定义域名

确认 pages.dev 地址正常后，再配置自己的域名。

进入：

edgetunnel-pages
→ Custom domains
→ Set up a custom domain

假设自己的主域名是：

example.com

建议分一个独立子域：

edt.example.com

不要为了这个项目直接占用根域名。

如果域名 DNS 已经托管在同一个 Cloudflare 账户，一般按 Dashboard 引导即可完成。

如果 DNS 在第三方服务商，Cloudflare Pages 会提示创建对应 CNAME。

最终后台：

https://edt.example.com/admin

---

十四、以后怎么更新 EdgeTunnel

Direct Upload 的更新非常简单。

当上游项目发布新版后：

1. 打开官方 GitHub
2. 阅读 README / CHANGELOG
3. 下载新的 main.zip
4. Pages → Deployments
5. Create new deployment
6. 上传新版 ZIP
7. 部署
8. 验证 /admin 和已有配置

正常情况下：

ADMIN
UUID
KV Binding
自定义域名

都是项目级配置，不需要每次重建。

不过如果新版 README 新增或修改了 Binding、变量或兼容性要求，就必须跟着调整。

---

十五、方案二：部署 byJoey/CFNew v2.9.9

项目：

https://github.com/byJoey/cfnew

截至本文整理时，仓库 README 标识版本：

CFnew v2.9.9

相比 EdgeTunnel，CFNew 更强调：

VLESS / Trojan / xhttp
图形化 KV 管理
内置延迟测试
优选 IP 管理
地区筛选
ECH
HTTP / HTTPS / SOCKS5 出站代理
多客户端订阅生成

最重要的区别是：

EdgeTunnel：
ADMIN + KV Binding "KV"

CFNew：
u + KV Binding "C"

千万不要混用。

---

十六、选择 CFNew 明文版还是混淆版

仓库当前主要提供两个代码文件：

明文源吗
少年你相信光吗

作者说明两者逻辑一致，其中：

明文源吗

便于阅读、审查和排错；

少年你相信光吗

属于混淆版本。

对于自己长期维护的部署，我更推荐：

明文源吗

原因很简单：

出问题时更容易审查
升级时更容易比较 diff
更容易确认第三方依赖与行为

---

十七、准备 CFNew Pages 上传文件

打开仓库中的：

明文源吗

获取完整原始代码。

在本地建立：

cfnew-pages/

把文件保存/重命名成：

_worker.js

最终：

cfnew-pages/
└── _worker.js

注意 Windows 默认可能隐藏扩展名。

一定确认不是：

_worker.js.txt

如果希望通过网页上传 ZIP，可以将该目录压缩成：

cfnew-pages.zip

部署包的根目录中应直接存在 _worker.js。

Cloudflare Pages Direct Upload 官方支持 _worker.js Advanced Mode，因此不需要建立 /functions 文件夹。

---

十八、为 CFNew 单独生成 UUID

CFNew 的基础配置中：

u

是必填变量。

先生成一个新的 UUIDv4，不要和 EdgeTunnel 共用。

PowerShell：

[guid]::NewGuid().ToString()

Python：

python -c "import uuid; print(uuid.uuid4())"

记下：

<CFNew UUID>

CFNew 默认使用：

/{UUID}

作为订阅/配置入口，因此不要随意公开这个 UUID。

---

十九、创建 CFNew Pages 项目

Cloudflare：

Workers & Pages
→ Create application
→ Pages
→ Upload assets

项目名建议：

cfnew-pages

如果冲突：

cfnew-pages-01

上传：

cfnew-pages.zip

或直接上传对应文件夹。

第一次部署。

得到类似：

https://cfnew-pages.pages.dev

---

二十、配置 CFNew 必填变量 u

进入：

cfnew-pages
→ Settings
→ Variables and Secrets

生产环境添加：

Variable name:
u

值：

<CFNew UUID>

注意：

u

是小写。

不是：

U
UUID
uuid

当前 CFNew README 中，基础配置明确将 u 标记为必需。

---

二十一、创建 CFNew KV Namespace

Cloudflare：

Storage & Databases
→ KV
→ Create instance

名称建议：

cfnew-prod-kv

不要与 EdgeTunnel 共用：

edgetunnel-prod-kv

虽然技术上可以让多个 Worker 绑定同一个 Namespace，但没有必要把两个完全不同项目的配置混在同一个 KV 中。

独立 KV 更利于：

排错
备份
删除
迁移
权限隔离

---

二十二、把 CFNew KV 绑定为 C

回到：

Workers & Pages
→ cfnew-pages
→ Settings
→ Bindings
→ Add
→ KV namespace

填写：

Variable name:
C

KV Namespace：

cfnew-prod-kv

最终：

C → cfnew-prod-kv

这里最容易填错。

CFNew 不是：

KV

而是：

C

当前官方 README 的图形化配置与 KV 存储说明都明确要求绑定变量名 C。

---

二十三、CFNew Compatibility Date

CFNew v2.9.5 的更新记录明确提到：

compatibility_date = 2026-01-20

如果当前 Pages Dashboard 提供：

Settings
→ Functions
→ Compatibility

之类的 Compatibility Date 设置，可以按照项目当前基线使用：

2026-01-20

不要为了“越新越好”随手改成当天日期。

Compatibility Date 不是软件版本号，它决定 Worker Runtime 的兼容行为。

如果当前 Dashboard 没有单独暴露这个项目级设置，不要为了这一项额外乱加未知 Compatibility Flag。

---

二十四、重新部署 CFNew

和 EdgeTunnel 一样：

u
C → cfnew-prod-kv

是在第一次部署后配置的。

因此需要创建新的 Production Deployment。

进入：

Deployments
→ Create new deployment
→ Production

重新上传：

cfnew-pages.zip

然后：

Save and Deploy

代码不需要修改。

---

二十五、CFNew 的后台入口不是 /admin

这一点一定要注意。

EdgeTunnel：

/admin

CFNew：

/{UUID}

假设：

Pages:
https://cfnew-pages.pages.dev

UUID:
12345678-1234-4abc-8def-123456789abc

那么入口形式：

https://cfnew-pages.pages.dev/12345678-1234-4abc-8def-123456789abc

不要照搬：

/admin

---

二十六、第一次进入 CFNew 后台怎么配置

第一次目标不是“打开所有高级功能”，而是先让最基础链路正常。

建议初始状态：

VLESS      开
Trojan     关
xhttp      关
ECH        关

ProxyIP p  空
出站代理 s 空
wk         空 / 自动

API 管理   关

这样出现故障时变量最少，排错最容易。

---

二十七、验证 CFNew KV 是否正常

进入：

https://你的域名/{UUID}

修改一个普通设置。

点击：

保存全部

然后刷新页面。

如果配置仍然存在，则说明：

Pages              正常
_worker.js          正常
u                   正常
Binding C           正常
cfnew-prod-kv       正常
KV 写入与读取        正常

CFNew 的优势也在这里：

KV 正常以后，大多数配置都可以通过图形页面修改并立即生效，不需要每改一个参数就重新部署 Pages。

---

二十八、CFNew 常用变量说明

基础配置

变量	作用	建议
u	UUID，访问订阅和配置界面	必填
p	ProxyIP	初次留空
s	SOCKS5 / HTTP / HTTPS 出站代理	初次留空
d	自定义路径	初次留空
wk	Worker/ProxyIP 地区	初次留空

注意：

p
wk

互斥。

如果设置了 p，就会直接使用指定 ProxyIP，wk 地区匹配失效。

协议相关

变量	作用	默认/建议
ev	VLESS	默认启用
et	Trojan	默认禁用
ex	xhttp	默认禁用
tp	Trojan 自定义密码	不填则使用 UUID
ech	ECH	初次关闭
alpn	TLS ALPN	初次留空

高级控制

变量	作用
yx	自定义优选 IP / 域名
yxURL	优选地址来源 URL
scu	自定义订阅转换地址
epd	优选域名开关
epi	优选 IP 开关
egi	GitHub 默认优选开关
qj	出站方式
dkby	只生成 TLS 节点
yxby	关闭所有优选
rm	地区智能匹配控制
ae	API 管理

初次部署依旧建议：

只设置 u
其余先通过默认值运行

KV 图形化后台工作正常以后，再逐项调整。

---

二十九、CFNew v2.9.9 的出站方式 qj

v2.9.9 对出站代理逻辑进行了重新整理。

当前语义：

qj 留空
→ 优先走代理

qj = no
→ 优先直连，失败再走代理

qj = only
→ 只走代理，失败直接断开，不回退

如果没有配置：

s

出站代理，那么第一次完全不需要碰 qj。

不要从旧版教程直接复制旧配置，因为 v2.9.9 已经调整了这个字段的语义说明。

---

三十、CFNew 的 ECH 要不要开

CFNew 当前支持 ECH，并且开启 ECH 后会自动进入仅 TLS 模式。

对于第一次部署：

ECH = OFF

更容易排错。

推荐顺序：

基础 VLESS 先正常
↓
订阅导入客户端
↓
确认连接
↓
再测试 ECH

不要在第一次部署时同时：

改 ProxyIP
开 ECH
开 Trojan
开 xhttp
改 ALPN
改 DNS

否则连接失败以后很难知道是哪一项造成的。

---

三十一、CFNew 内置优选测速怎么用

CFNew 当前提供内置延迟测试功能，可以从：

手工 IP
Cloudflare 随机 IP
远程 URL

获取候选。

建议第一次不要一下保存几百个地址。

更合理的流程：

获取候选
→ 测试
→ 按地区筛选
→ 只看最快若干个
→ 保存少量稳定结果

网络质量会随运营商、地区和时间变化，因此“别人测试最快的 IP”不一定对自己的网络最快。

优选结果应该根据自己的真实网络环境测试。

---

三十二、给 CFNew 绑定自定义域名

确认：

https://cfnew-pages.pages.dev/{UUID}

正常后再添加域名。

进入：

cfnew-pages
→ Custom domains
→ Set up a custom domain

例如：

cfnew.example.com

最终配置入口：

https://cfnew.example.com/{UUID}

建议 EdgeTunnel 与 CFNew 分两个子域：

edt.example.com
cfnew.example.com

不要让两个项目抢同一个 hostname。

---

三十三、以后怎么更新 CFNew

CFNew 使用 KV 保存图形化配置，因此以后更新代码通常很简单。

流程：

1. 打开 byJoey/cfnew
2. 阅读 README 最新版本号和更新记录
3. 获取新的“明文源吗”
4. 替换本地 _worker.js
5. 重新生成/更新上传目录
6. Pages → Create new deployment
7. 上传新版
8. 部署
9. 检查 /{UUID}
10. 检查 KV 中原配置是否仍然存在

正常代码更新不会要求你重新创建：

u
C Binding
cfnew-prod-kv
自定义域名

但每次大版本升级仍应先读 README，尤其关注：

变量语义
Binding 名
Compatibility Date
路径格式
KV 数据结构

---

三十四、EdgeTunnel 和 CFNew 到底有什么区别

项目	EdgeTunnel	CFNew
当前本文版本	2.1	2.9.9
Pages 支持	是	可使用 _worker.js Advanced Mode
必填变量	ADMIN	u
推荐固定 UUID	UUID	u 本身就是 UUID
KV Binding	KV	C
推荐 KV 名	edgetunnel-prod-kv	cfnew-prod-kv
管理入口	/admin	/{UUID}
KV 图形化配置	有后台	是，重点功能
VLESS	是	是
Trojan	是	是
Shadowsocks	是	不是当前主打
xhttp	-	是
ECH	- / 视版本功能	是
内置延迟筛选	侧重订阅/优选功能	是
适合人群	想要成熟一站式 EDT 面板	喜欢新功能和更强图形化调节

我的建议不是“只能留一个”。

完全可以：

edgetunnel-pages
作为稳定备用

cfnew-pages
作为新功能测试和日常使用候选

两者使用独立 KV 和独立子域即可。

---

三十五、最容易犯错的地方

错误 1：把两个 KV Binding 写反

正确：

EdgeTunnel：
KV → edgetunnel-prod-kv

CFNew：
C → cfnew-prod-kv

错误 2：把 CFNew 的 u 写成 UUID

正确：

u

小写。

错误 3：添加 KV 后不重新部署

Pages Binding 新增以后：

必须创建新 Deployment

旧部署不会自动拥有新 Binding。

错误 4：Direct Upload 创建新部署时不知道上传什么

重新上传：

和第一次相同的 ZIP / 文件夹

即可。

如果只是为了让新环境变量和 Binding 生效，代码不需要变化。

错误 5：CFNew 去访问 /admin

CFNew 入口：

/{UUID}

EdgeTunnel 才是：

/admin

错误 6：KV Namespace 名和 Binding 名混为一谈

例如：

Namespace:
cfnew-prod-kv

Binding:
C

不能因为数据库叫：

cfnew-prod-kv

就把 Variable name 也填写成 cfnew-prod-kv。

错误 7：Windows 把 _worker.js 保存成 _worker.js.txt

在资源管理器中开启：

查看
→ 文件扩展名

确认真正后缀是：

.js

错误 8：一上来把所有高级功能打开

最稳定的排错策略永远是：

最少变量
→ 基础跑通
→ 一次只改一项
→ 每次修改后验证

---

三十六、1101 和配置不生效怎么排查

如果 Pages 报错：

Error 1101
Worker threw exception

先不要立刻改 ProxyIP。

按这个顺序检查。

EdgeTunnel

1. main.zip 是否正确
2. ADMIN 是否存在
3. Binding 是否叫 KV
4. KV Namespace 是否选对
5. 配置后是否重新部署

CFNew

1. _worker.js 是否处在上传目录根部
2. u 是否为小写
3. UUID 是否有效
4. Binding 是否叫大写 C
5. 是否选中了 cfnew-prod-kv
6. 配置后是否重新部署

如果：

页面能打开
但后台配置保存后消失

第一怀疑对象应该是 KV Binding，而不是代码。

---

三十七、Direct Upload 的一个重要限制

Cloudflare 当前明确规定：

一个以 Direct Upload 创建的 Pages 项目，之后不能直接切换为 Git Integration。

如果以后想要：

GitHub push
→ 自动构建
→ 自动部署

需要创建新的 Git Integration Pages 项目。

但 Direct Upload 项目内部仍然可以在后续部署时选择：

Dashboard 拖拽
或
Wrangler pages deploy

所以以后并不是永远只能手工拖 ZIP。

---

三十八、以后想用 Wrangler 怎么部署

Direct Upload 项目后续可以使用 Wrangler 创建新的 Deployment。

基本形式：

npx wrangler login

然后：

npx wrangler pages deploy <目录> --project-name=<Pages项目名>

例如：

npx wrangler pages deploy ./cfnew-pages --project-name=cfnew-pages

这只是部署方式变化。

现有：

Pages 项目
环境变量
KV
自定义域名

仍然可以继续使用。

对于偶尔更新的项目，没有必要一开始就引入 Wrangler；等需要 Git、本地开发、自动化或 Codex/MCP 管理时再使用更合理。

---

三十九、安全与维护建议

1. 永远从官方仓库获取代码

EdgeTunnel：

https://github.com/cmliu/edgetunnel

CFNew：

https://github.com/byJoey/cfnew

不要从不明网盘、短链、Telegram 转存文件直接覆盖生产代码。

2. 更新前看 diff 或 CHANGELOG

尤其关注：

新增第三方域名
新增日志
新增远程 API
新增外部订阅转换
Binding 变化
变量默认值变化

3. 两个项目不要共用 KV

推荐：

edgetunnel-prod-kv
cfnew-prod-kv

分开。

4. 不把高权限 Cloudflare 密钥交给第三方网页

手动 Pages 部署根本不需要：

Global API Key

如果某个第三方部署器要求整个 Cloudflare Global API Key，应先理解它为什么需要这么高权限。

能用 Cloudflare OAuth、Scoped API Token、Wrangler 登录完成的事情，不要主动扩大权限范围。

5. UUID 和后台路径不要公开

特别是 CFNew：

/{UUID}

既是配置入口的一部分，也参与订阅身份。

不要直接把完整管理地址发在公开帖子、截图和 Issue 中。

---

四十、推荐的最终结构

如果两个都保留：

Cloudflare Account
│
├── Pages: edgetunnel-pages
│   ├── Domain: edt.example.com
│   ├── ADMIN
│   ├── UUID
│   ├── OFF_LOG=1
│   └── KV
│       └── KV → edgetunnel-prod-kv
│
└── Pages: cfnew-pages
    ├── Domain: cfnew.example.com
    ├── u
    └── KV
        └── C → cfnew-prod-kv

后台分别：

EdgeTunnel:
https://edt.example.com/admin

CFNew:
https://cfnew.example.com/{UUID}

这样以后更新、排错和删除都非常清晰。

---

四十一、部署完成后的验收清单

EdgeTunnel

• Pages Production Deployment 成功
• ADMIN 已配置
• UUID 已固定
• OFF_LOG 按需求配置
• edgetunnel-prod-kv 已创建
• Binding 名为大写 KV
• 配置后已经重新部署
• /admin 可以登录
• 后台配置保存后刷新仍存在
• 自定义域名正常

CFNew

• 使用当前最新版代码
• _worker.js 文件名正确
• Pages Production Deployment 成功
• u 已配置且为有效 UUIDv4
• cfnew-prod-kv 已创建
• Binding 名为大写 C
• 配置后已经重新部署
• /{UUID} 可以打开
• 图形化配置保存后刷新仍存在
• 基础 VLESS 先正常
• 高级功能逐项开启
• 自定义域名正常

---

四十二、参考资料

本文写作时主要对照以下官方/上游资料，建议更新项目时优先查看这些来源。

Cloudflare Pages Direct Upload
https://developers.cloudflare.com/pages/get-started/direct-upload/

Cloudflare Pages Functions Advanced Mode
https://developers.cloudflare.com/pages/functions/advanced-mode/

Cloudflare Pages Bindings
https://developers.cloudflare.com/pages/functions/bindings/

cmliu/edgetunnel
https://github.com/cmliu/edgetunnel

byJoey/cfnew
https://github.com/byJoey/cfnew

---

总结

如果只记四组配置，记住下面这些就够了。

EdgeTunnel：

Pages:
edgetunnel-pages

KV Namespace:
edgetunnel-prod-kv

KV Binding:
KV

后台：
/admin

CFNew：

Pages:
cfnew-pages

KV Namespace:
cfnew-prod-kv

KV Binding:
C

必填变量：
u

后台：
/{UUID}

两者第一次部署后的关键动作都是：

先上传代码
→ 配环境变量
→ 创建并绑定 KV
→ 再创建一次 Production Deployment
→ 验证后台配置持久化
→ 最后再绑自定义域名

把基础链路跑通以后，再去折腾 ProxyIP、优选、ECH、SOCKS5、HTTP/HTTPS 出站代理和其他高级功能，会比一开始把所有参数一起打开稳定得多。