Cloudflare Workers 支持入站 TCP 与 gRPC

Cloudflare Workers 支持入站 TCP 与 gRPC，实时应用更简单

AI 正在改变人与计算机的交互方式，语音越来越重要：实时助手、AI 听写等语音界面需要客户端、模型与支撑服务之间的低延迟通信，很多开发者用 gRPC——一个构建在 HTTP/2 与 TCP 之上的远程过程调用（RPC）框架。

作为 Agents Week 的一部分，Cloudflare 在 2026 年 8 月把 Workers 的能力向另一个方向扩展：支持入站 TCP 连接，并新增多种运行 gRPC 应用的方式。

connect(socket)：Worker 直接接收入站 TCP

Workers 运行时新增 connect(socket) 处理器，让 Worker 直接接受由 Spectrum（Cloudflare 面向非 HTTP 流量的入口代理）提供的入站 TCP Socket，并可在 Worker、Durable Objects 之间传递，精确控制入站连接的路由。例如 Worker 可以把 Socket 转发到 Durable Object，再连接到运行在容器里的服务，实现从客户端到容器服务器的全路径控制，开启任意语言、任意 TCP 协议的全双工通信。

容器的双向 gRPC

gRPC 是一个成熟流行的 RPC 框架，广泛用于移动应用、分布式系统，以及最近的语音 AI 应用。实时语音 AI 要求低延迟，且客户端与服务器能在一条持久连接上双向发消息。利用上述 API，现在可以把任意语言的 gRPC 服务器部署到 Cloudflare，完整支持客户端与服务器之间的双向流式传输，借助 Cloudflare 全球 330+ 节点在离客户端更近的位置处理请求——对低延迟语音与就近推理尤其有价值。

Worker 作为 gRPC 服务器与客户端

更简单的场景不需要容器：Worker 可以直接以 gRPC 服务器或客户端的形式工作，并自动做 gRPC 与 gRPC-web 转换。浏览器没有 gRPC 所需的底层 HTTP/2 特性，也没有原生 TCP Socket API；Cloudflare 会把入站 gRPC 翻译成 gRPC-web，把出站 gRPC-web 翻译成 gRPC。基于 protobuf 定义，用 @connectrpc/connect 开源包，几行代码就能在 Worker 里实现一个一元 gRPC 服务器；外出调用外部 gRPC 服务器也一样简单。

典型用法：

为说 gRPC 的移动应用提供 gRPC 后端——移动应用常为减少网络载荷、高效序列化而使用 gRPC，现在可以直接用 grpc-swift-2、grpc-kotlin 等原生库在 Workers 上构建后端。
在现有 gRPC 后端前放置一个 Worker——像过去在 REST API 前放 Worker 那样，把性能关键的工作移到离用户更近的地方。

用 ConnectRPC 写一个最小 Worker 服务

一个最小的"一元"gRPC 服务在 Worker 里只需要几十行。基于 protobuf 生成的类型，配合 @connectrpc/connect：

// say.proto: service Say { rpc Hello(HelloRequest) returns (HelloReply); }
import { createConnectRouter } from '@connectrpc/connect';
import { Say } from './gen/say_pb';

export default {
  async fetch(req: Request): Promise<Response> {
    const router = createConnectRouter();
    router.service(Say, {
      async hello(req) {
        return { message: `Hello, ${req.name}` };
      },
    });
    return router.handler(req);
  },
};

浏览器端无需改动：Cloudflare 自动把浏览器发来的 gRPC-web 请求翻译给这个 Worker。需要强调的一点是，gRPC 用 protobuf 做二进制序列化，载荷通常比 JSON 小 3-10 倍，对移动端流量与电量都更友好，这也是语音 AI 与移动应用偏爱它的原因。

gRPC 与 REST 的取舍

维度	REST/JSON	gRPC
序列化	JSON 文本，可读性好	protobuf 二进制，更小更快
传输	HTTP/1.1 或 HTTP/2	基于 HTTP/2
双向流	需 WebSocket 等额外方案	原生支持
强类型	需 OpenAPI 等补充	通过 .proto 生成
适用	浏览器、公开 API	服务间、移动端、低延迟实时

如果客户端只有浏览器、接口又是公开的，REST 往往更简单；当你有移动端 App、服务间调用密集或需要低延迟双向流时，gRPC 的优势更明显。介于两者之间的 gRPC-web 正好让浏览器也能享受同一套接口定义。

前置条件与准备工作

目前这批能力处于私有测试阶段，想试用需要做三件事：

注册 Cloudflare 账号并开通 Workers（免费版即可体验基础能力）；
在官方渠道申请加入 gRPC/TCP 私有测试（Private Beta）；
准备好一个 protobuf 定义与本地开发环境，方便用 wrangler dev 本地调试。

参考：Cloudflare 官方博客原文 https://blog.cloudflare.com/grpc-workers/、gRPC 官方文档 https://grpc.io/docs/、ConnectRPC 文档 https://connectrpc.com/docs/

适合哪些场景

综合来看，这几项能力覆盖了三类典型需求：

实时语音与 AI 助手：低延迟、双向流是刚需，gRPC 已在语音 AI 生态中被广泛使用，现在可以在更靠近用户的边缘节点处理，而不是把流量拉回某个中心机房。
移动应用后端：移动团队无需为了上边缘改写协议，直接复用 grpc-swift-2、grpc-kotlin 等成熟原生库，减少网络载荷并生成强类型客户端。
存量 gRPC 服务的加固与加速：在现有 gRPC 后端前加一层 Worker，即可获得 Cloudflare 的 WAF、Bot 管理等安全能力与就近处理，而客户端与服务端都无需改动。

下一步

这批能力目前处于私有测试阶段。Cloudflare 内部使用 Cap'n Proto 与内建的 JavaScript 原生 RPC 系统，因此希望先与一小批使用 gRPC 的开发者密切合作，确保完善后再向所有人开放。更长远的目标是继续拓展 Workers 平台可承载的流量类型，超越 TCP 走向基于 UDP 的协议。

16IDC 观察

对做实时应用、语音工具或移动端后端的开发者，这批能力意味着"边缘"不再只是 HTTP 请求的分发层，而能承载真正的长连接与双向流。想打好基础，可先读本站的网站 API 对接基础与 REST 与 GraphQL 对比；需要实时推送时，可参考 WebSocket 实时通信指南。更多内容请查看后端对接分类。

原文来源：https://blog.cloudflare.com/grpc-workers/

Cloudflare Workers 支持入站 TCP 与 gRPC，实时应用更简单