Cloudflare Workers开放入站TCP，gRPC支持先行

Cloudflare Workers现已能够接收入站TCP连接。自2017年推出以来，Workers虽然可以通过套接字访问数据库和其他服务，但自身只能作为HTTP服务器运行。此次新增的连接处理器打破了这一限制，gRPC也成为首个建立在该能力之上的协议。该功能在“智能体周”期间公布，重点面向需要低延迟和持久双向连接的语音AI场景。

此次发布包含三层能力。连接处理器可接收经Spectrum流量代理转发的原始TCP套接字，Worker能够直接读写、转发给其他Worker，或交由Durable Object处理。Durable Object还可通过getTcpPort()把连接继续传递给Container，并在那里完成全双工通信。官方示例中的Go语言gRPC回显服务器和Python socketserver无需修改即可运行，理论上能够承载任意语言编写的程序和任意TCP协议。

相比之下，Worker自身提供的gRPC能力较有限，支持一元调用和服务器流式服务，也能访问外部gRPC服务器，但暂不支持双向流式传输。其实现依赖协议转换：开发者使用gRPC-web，平台负责在入站gRPC与gRPC-web之间转换。原因在于HTTP/2的流式控制、取消、流量管理和尾部元数据都依赖流ID，而fetch等Web API没有暴露这些底层能力，浏览器端的gRPC-web也源于同样限制。

自2020年以来，Cloudflare还曾在反向代理内部把gRPC转换为HTTP/1.1，以便WAF规则和机器人管理功能检查消息内容。开发者Sebastian Buzdugan进一步询问Workers能否为gRPC流提供充分的回压控制，但官方公告没有回答这一可靠性问题。现有客户端无需改动，使用grpc-swift-2或grpc-kotlin的移动应用可以直接接入，Workers也能部署在现有gRPC后端前方；服务端则可借助开源的@connectrpc/connect编写少量代码完成接入。

该功能目前必须通过注册表单申请私有测试。官方解释称，内部主要使用Cap'n Proto、Cap'n Web以及Workers内置的JavaScript原生RPC系统，并未采用gRPC，因此希望先与少量gRPC开发者验证实现，再逐步扩大开放范围。评估团队应将这一私测状态视为成熟度信号，而不只是发布策略。

从更广泛的基础设施角度看，入站TCP将Workers此前仅限HTTP的边界扩展到消息代理、数据库代理、自定义二进制协议等场景。连接可以在边缘先由Worker执行路由判断，再传给Durable Object和Container，不过目前尚未披露Worker能够对原始套接字实施哪些检查或策略。2026年7月28日发布的MCP规范还把gRPC列为HTTP之外的可选传输协议，进一步凸显其在智能体和机器间通信中的地位。

目前社交媒体宣传曾将gRPC支持描述为“现已可用”，并称可在边缘原生提供服务而无需翻译层，但实际范围仍限于注册申请的私有测试，宣传口径与发布状态并不完全一致。官方下一步计划支持基于UDP的协议。