Cloudflare Workers 进化：私有网络直连Redis，服务器不用暴露公网了

Cloudflare Workers 又进化了：以后你的服务器，可能不用再暴露公网了

Cloudflare 最近偷偷搞了个大动作，一个很关键的能力：Workers VPC 现在支持通过 connect() 连接私有网络里的 TCP 服务。

这句话听着挺技术，但翻译成人话就是——

Cloudflare Worker 不再只是个能发 HTTP 请求的小函数了，它开始可以直接访问你自己服务器里的 Redis、MQTT、Memcached，甚至一些自定义 TCP 服务。

再直白点说：

以前你有一台 VPS，里面跑着数据库、Redis、后端服务。Worker 想访问它，通常得把服务包装成一个公网 API。是不是挺麻烦的？

现在多了一种可能：你的服务可以藏在私有网络里，不直接暴露公网，Worker 通过 Cloudflare 的私有通道去访问它。

说实话，这件事对做独立站、工具站、SaaS、爬虫后台、AI 应用的人，意义还挺大的。

以前的问题：Worker 很强，但后端连接有点别扭

Cloudflare Workers 这几年越来越像一个“边缘后端”了，对吧？

它能做的活挺多——接口、鉴权、缓存、限流、A/B 测试、页面渲染……而且部署在全球边缘节点，响应那叫一个快。

不过说实话，它以前有个明显的短板：

它最擅长的，还是 HTTP。

什么意思呢？就是说，你的 Worker 要是想连接自己的服务器，流程基本是这样的：

用户访问网站
↓
Cloudflare Worker
↓
公网 API
↓
你的服务器
↓
数据库 / Redis / 内部服务

你看，最大的问题来了——你的后端 API 不得不暴露到公网。

就算你加了鉴权、防火墙、白名单……它本质上还是个公网入口，对吧？

我觉得这对小团队和个人开发者来说挺头疼的。你一边想享受 Cloudflare 的边缘能力，一边又得费劲维护一个传统后端入口……这真的不别扭吗？

这次更新到底解决了啥？

说实话，这次更新的核心就一句话：Workers VPC 终于支持 raw TCP 连接了。

TCP 嘛，别想得太玄乎。

你看，很多基础设施压根儿就不是跑 HTTP 的，对吧？比如：

• Redis
• Memcached
• MQTT
• 还有那些消息队列
• 一些内部服务，你懂的
• 甚至各种自定义协议的服务

过去啊，Worker 对这些服务真的不太友好……你猜怎么着？现在不一样了。

现在 Worker 可以通过 VPC 网络绑定，直接连到 Cloudflare Tunnel、Cloudflare Mesh 或者 Cloudflare WAN 背后的私有服务。这真的有用吗？我觉得挺香的。

也就是说，你可以把 Worker 摆在最前面，真正的服务藏在后面。

架构大概长这样：

用户
↓
Cloudflare Worker
↓
Cloudflare 私有网络
↓
你的 VPS / 内网服务 / Redis / 后端程序

老实讲，这就很像给个人开发者和小团队搞了一套“轻量版私有云入口”。为什么这么说？因为门槛低了不少啊。

举个最容易理解的例子

假设你有一个 AI 工具站，对吧？

你需要做免费额度限制，比如：

• 每个 IP 每天只能用 20 次——不多不少，够用就行
• 登录用户呢？每天可以用 100 次
• 付费用户嘛，1000 次，随便造
• 滥用用户？立刻封禁，没商量

说实话，这类场景最适合用 Redis。

以前你的架构可能是这样的：

Worker 收到请求
↓
请求你的公网 API
↓
API 查询 Redis
↓
返回是否放行

现在可以变成：

Worker 收到请求
↓
直接通过私有通道访问 Redis
↓
判断是否放行

少了一层公网 API，也少了一层暴露风险。你猜怎么着？这效果还挺明显的。

我觉得这对高频请求、限流、计数、任务状态、缓存这类场景很有用……

它真正的价值不是“能连数据库”

很多人看到这个更新，第一反应可能是：是不是 Cloudflare Worker 终于可以直接连我的数据库了？

说实话，答案得实事求是——

理论上，TCP 能力让 Worker 连接更多私有服务成为可能；不过，不代表所有数据库都适合直接连。

尤其是 PostgreSQL、MySQL 这类数据库，我倒是觉得，简单粗暴地让全球 Worker 节点直接裸连，风险挺大的。

原因很简单：数据库怕连接数爆炸。

你看，Worker 是边缘计算，节点可能来自好多地区，请求一多……它没有连接池、复用和控制，很容易就把数据库打爆了，对吧？

所以对于数据库，更稳妥的方式仍然是：

Worker → Hyperdrive → PostgreSQL

或者：

Worker → 私有后端 API → 数据库

话说回来，这次更新真正最适合的，其实是 Redis、Memcached、MQTT、自定义 TCP 服务、内部协议服务这些轻量、高频、连接逻辑相对简单的基础设施。

对个人开发者有什么用？

说实话，这个能力大公司肯定用得上，不过我觉得对个人开发者、小团队、还有那些独立站长来说，想象空间更大一些。

因为它让一种架构变得更自然了：

Cloudflare 负责前台入口，你自己的服务器负责后台能力。

举个例子，你可以这样设计——

Cloudflare Worker 主要负责这些：

• 接收用户请求
• 登录鉴权
• 限流
• 缓存
• 路由
• 风控
• 轻量业务逻辑

然后你的服务器那边呢，就负责：

• 数据库存储
• Redis 缓存
• 爬虫任务
• AI 任务队列
• 后台管理
• 长时间运行任务
• 复杂业务处理

这样一来，Worker 就不用扛所有后端逻辑了，你也不用把内部服务全暴露到公网上……对吧？

我觉得，这才是这次更新真正值得关注的地方。

它不是万能药

也别把这个更新给神化了，对吧？

我觉得它不是说，Cloudflare Workers 已经能完全替代传统服务器，没那么夸张。

也不是说，以后所有数据库都得直接挂在 Worker 后面，你猜怎么着？那可能会出事。

更不是说，你的后端架构就可以不用设计了，老实讲，这真的有用吗？。

目前更合理的判断是：Cloudflare Workers 正在从“边缘函数”变成“边缘网关 + 轻量后端”。

说实话，它越来越适合放在业务入口层，处理用户请求的第一道逻辑。

不过真正重的活，比如复杂数据库事务、后台任务、长时间计算、大规模爬虫、AI 批处理……这些还是得放在传统服务器、容器或专门的后端系统里。

为什么这件事值得关注？

说实话，Cloudflare 的路线越来越清楚了。

以前你可能觉得：Cloudflare 就是 CDN 啊。后来你发现它能做 Pages。再后来 Workers 也来了。然后呢？R2、KV、D1、Queues、AI Gateway、Vectorize、Containers……一口气冒出来一堆。现在 Workers 还能更自然地连接私有网络服务了，你猜怎么着？

我觉得这意味着 Cloudflare 正在从“网站加速服务”慢慢变成一套完整的开发平台。

尤其是对独立开发者来说，未来一种很常见的架构可能是这样的：

前端部署在 Cloudflare
API 跑在 Workers
对象存储用 R2
缓存和状态用 KV 或者 Redis
数据库用 D1 或者 PostgreSQL
重任务放自己的 VPS 或容器
Worker 通过私有网络访问后端服务

这套组合的优势……快、便宜、全球化、安全边界更清晰。你说是不是？

最后说一句

这次更新最重要的点，说实话，不是“Worker 多了一个 API”。

而是 Cloudflare 给开发者打开了一条新路：

你可以把自己的服务器、数据库、Redis、内部服务，变成 Cloudflare Workers 背后的私有基础设施。

前面用 Cloudflare 扛流量、做安全、做边缘逻辑。后面用自己的服务器处理数据、任务和复杂业务。

这比单纯讨论“Serverless 能不能替代服务器”更现实，对吧？

未来的架构可能不是二选一。不是只用 Cloudflare，也不是只用 VPS。

而是：Cloudflare 做入口，自己的服务器做底座。

我觉得，这对个人开发者来说，反而是最实用、最省钱、也最灵活的一种路线。

FAQ：Cloudflare Workers VPC 连接私有网络常见问题

Q: Workers VPC 的 connect() 功能什么时候正式可用？
A: 截至2025年，这个功能已经进入公开测试阶段了。所有 Cloudflare Workers 用户，只要启用 VPC 网络功能就能体验。

Q: 使用 Workers VPC 连接 Redis 需要额外付费吗？
A: 不需要。你猜怎么着？只要你的 Workers 计划包含 VPC 网络功能（比如 Workers Paid 计划），连接私有网络内的 Redis 等 TCP 服务就不产生额外费用。不过要注意 Workers 请求次数和带宽限制。

Q: 这个功能适合连接 MySQL 数据库吗？
A: 技术上可行，但官方不建议直接裸连。为什么这么说？因为 MySQL 这类关系型数据库对连接数特别敏感。建议通过 Hyperdrive 或私有后端 API 做连接池管理，不然 Worker 边缘节点并发起来，数据库可能直接崩掉……