Cloudflare Workers现在可以接受入站的TCP连接。自 2017 年该平台推出以来，Worker 可以打开到数据库或服务的出站套接字，但只能作为 HTTP 服务器。新的连接（套接字）处理器移除了该限制，而gRPC支持是首个构建在其上的协议。
这项公告是在“Agents Week（智能体周）”期间发布的，该特性主要围绕语音 AI 展开，因为在这种场景下，低延迟以及客户端与模型之间保持持久的双向连接至关重要。然而，其底层支持的能力实际上比这一应用场景所暗示的要广泛得多。
此次同时发布了三项功能，它们各自有着不同的性能上限。
连接（套接字）处理程序可以接收原始的入站套接字，并通过Spectrum路由至 Worker。Spectrum 是 Cloudflare 现有的用于处理非 HTTP 流量的入口代理。Worker 可以直接读写该套接字，将其传递给另一个 Worker，或者转交给Durable Object进行处理：
export default { async connect(socket): Promise<void> { const writer = socket.writable.getWriter(); await writer.write(new TextEncoder().encode("Hello, world!\n")); await writer.close(); },} satisfies ExportedHandler;通过 Durable Object，套接字还可以借助 getTcpPort()方法进一步传递给Container，全双工通信路径也会在此处终结。Cloudflare 提供的示例包括一个 Go 语言编写的 gRPC 回显（echo）服务器和一个 Python 语言编写的 socketserver，两者均不需要任何修改即可运行。用官方的话来说，这为客户端与服务器之间的全双工通信打开了大门，支持运行任何程序、使用任何语言以及基于任何 TCP 协议。
相比之下，Workers 本身获得的能力要少一些。它们无需 Container 即可提供一元（unary）和服务器流式（server-streaming）的 gRPC 服务，也能调用外部的 gRPC 服务器，但不支持双向的流式传输。它的底层机制是协议转换而非原生支持：开发者代码使用的是gRPC-web，Cloudflare 负责将传入的 gRPC 转换为 gRPC-web，并将传出的 gRPC-web 转换回 gRPC。
文章直接解释了这一限制背后的平台约束原因：HTTP/2将请求拆分为携带流 ID（stream ID）的帧，而 gRPC 的流式传输、取消操作、流量控制和尾部元数据（trailers）都依赖于这种流级别的控制。然而，Web 平台 API（比如，fetch()）并未暴露这种控制能力。浏览器也面临同样的问题，这正是 gRPC-web 诞生的原因。自2020年以来，Cloudflare 一直在其反向代理内部将 gRPC 转换为 HTTP/1.1，以便相关博客），以便WAF规则和机器人管理（Bot Management）能够检查消息的内容。
针对这一限制，Sebastian Buzdugan 在 Cloudflare 发布公告的评论区提出了一个更务实的限制问题：Workers 是否为 gRPC 流提供了足够的回压（backpressure）控制？他指出，正是这些流处理的边缘情况决定了该实现是否真正可靠。但官方文章并未对此作出回应。
从实际效果来看，现有的客户端无需做任何更改。Worker 可以为使用grpc-swift-2或grpc-kotlin的移动应用提供服务，也可以像现在支持 REST API 一样，部署在现有的 gRPC 后端的前面。在服务端，只需使用开源的@connectrpc/connect包编写几行代码即可实现。
公告中最坦诚的部分，是 Cloudflare 解释了为什么这项功能目前处于私有测试（private beta）阶段而非全面可用（GA）：Cloudflare 内部并不使用 gRPC。
“在 Cloudflare，我们使用的是Cap'n Proto、Cap'n Web 以及内置于 Cloudflare Workers 中的 JavaScript 原生 RPC 系统，而不是 gRPC。我们在发布任何功能时，始终力求自己也在实际使用它们。”
一家供应商在发布新功能时附带这样的说明是非常罕见的，这也为外界设定了一个诚实的预期。Cloudflare 表示，他们希望先与一小部分 gRPC 开发者合作，在确保实现无误后再向所有人开放。评估该功能的团队应将其视为关于技术成熟度的信号，而非单纯的谦虚之辞。
对于平台团队而言，更关键的问题在于，除了公告中提到的应用场景，这一底层原语还能带来什么？八年来，Workers 一直受限于 HTTP 协议，这直接排除了许多类型的工作负载，如消息代理、数据库代理、自定义二进制协议，以及所有依赖套接字的应用。现在，将套接字从 Worker 传递给 Durable Object 再传递给 Container，使得边缘节点成为了任意 TCP 协议的终止点，并且在此之前可以通过 JavaScript 编写路由逻辑。
这种路由位置非常值得注意。Worker 在决定连接的去向之前，会先“看到”该连接。这与 API 网关在转发请求前进行决策的逻辑完全一致，只不过这里针对的是原始套接字而非 HTTP。Worker 处于这个位置时，能对套接字进行哪些检查或策略干预，公告中并未提及。
gRPC 的这一进展也恰逢其时。2026年7月28日发布的MCP规范在 HTTP 之外，新增了 gRPC 作为可选的传输协议。针对该版本，有开发者指出，如今的智能体基础设施在很大程度上只是在重新发现早于它的远程过程调用（RPC）规范。一个由谷歌在近十年前发布的协议，如今不断成为机器间通信的首选答案，甚至包括那些原本围绕 HTTP 设计的系统。
尽管文章中提到的所有功能目前都需要通过注册表单才能进入私有测试阶段，但是 Cloudflare 官方社交媒体上的宣传文案却称， 对 gRPC 的支持“现已可用”，并描述了在边缘原生环境提供了 gRPC 服务而无需翻译层。从该宣传渠道了解情况而来的读者会发现，实际发布的范围比宣传的要更窄。Cloudflare 表示，下一步将支持基于 UDP 的协议。
查看英文原文： Cloudflare Workers Accept Inbound TCP, with gRPC the First Protocol on Top