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 做入口，自己的服务器做底座。

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