面向所有人的安全私有网络:用户、节点、agent 与 Workers — 介绍 Cloudflare Mesh
原文:Secure private networking for everyone: users, nodes, agents, Workers — introducing Cloudflare Mesh Source: https://blog.cloudflare.com/mesh/
2026-04-14
AI agent 改变了团队对私有网络访问的思考方式。你的编码 agent 需要查询暂存数据库,生产 agent 需要调用内部 API,个人 AI 助手需要访问家庭网络上运行的服务。客户端不再只是人类或服务,它们是 agent,自主运行,发起未经你显式批准的请求,作用于你需要保护的基础设施。
每一种工作流背后都有同一个问题:agent 需要访问私有资源,但用于此的工具是为人类、而不是为自主软件设计的。VPN 需要交互式登录;SSH 隧道需要手动设置;把服务公开暴露则有安全风险。而且这些方式都无法让你看到 agent 在连接之后到底在做什么。
今天,我们推出 Cloudflare Mesh,把你的私有网络互连起来,并为你的 agent 提供安全访问。我们还把 Mesh 集成到 Cloudflare Developer Platform,让 Workers、Durable Objects 以及用 Agents SDK 构建的 agent 能直接访问你的私有基础设施。
如果你已经在使用 Cloudflare One 的 SASE 与 Zero Trust 套件,那么你已经可以使用 Mesh。要保护 agentic 工作负载,你不需要全新的技术范式,你需要一个为 agentic 时代而生的 SASE,那就是 Cloudflare One。Cloudflare Mesh 是一种全新体验,设置更简单,并复用了你已经熟悉的接入方式:WARP Connector(现称为 Cloudflare Mesh node)和 WARP Client(现称为 Cloudflare One Client)。两者结合,为人类、开发者和 agent 流量构建一张私有网络。Mesh 直接集成到你现有的 Cloudflare One 部署中,你已有的 Gateway 策略、Access 规则与设备态势检查会自动应用到 Mesh 流量上。
如果你只是一名想为 agent、服务和团队提供私有网络的开发者,Mesh 就是起点。几分钟内即可完成设置,连接你的网络,保护你的流量。由于 Mesh 运行在 Cloudflare One 平台之上,你可以随时间扩展到更高级的能力:用 Gateway 实现网络、DNS 和 HTTP 策略以做精细流量控制;用 Access for Infrastructure 管理 SSH 与 RDP 会话;用 Browser Isolation 实现安全 Web 访问;用 DLP 防止敏感数据外泄;用 CASB 保护 SaaS 安全。第一天你不必规划这一切,需要时也无须迁移。
全新的 agentic 工作流
私有网络始终是把客户端连接到资源 — 通过 SSH 登录服务器、查询数据库、访问内部 API。变化的是客户端的身份。一年前,答案是你的开发者和服务;今天,越来越多的是你的 agent。
这并非空谈。看看整个生态:MCP(Model Context Protocol)服务器 大量涌现来提供工具访问,编码 agent 需要读取私有仓库与数据库,个人助手运行在家庭硬件上。每种模式都假定 agent 能访问到所需资源。当这些资源被隔离在私有网络中时,agent 就被卡住了。
这造成了三种今天难以保护的工作流:
-
从移动设备访问个人 agent。你在家里的 Mac mini 上运行 OpenClaw,想从手机、咖啡店里的笔记本或工作机上访问它。但把它暴露到公网(即使加上密码)也可能留下安全缺口。你的 agent 拥有 shell 访问、文件系统访问以及对家庭网络的网络访问权限,一处配置错误就可能让任何人入侵。
-
让编码 agent 访问你的暂存环境。你在笔记本上使用 Claude Code、Cursor 或 Codex,让它检查部署状态、查询暂存数据库的分析数据,或读取内部对象存储。但这些服务位于私有云 VPC 中,你的 agent 无法访问,除非把它们暴露到公网,或把整台笔记本接入 VPC。
-
把已部署的 agent 连接到私有服务。你正在用 Agents SDK 在 Cloudflare Workers 上为产品构建 agent。这些 agent 需要调用内部 API、查询数据库、访问不在公网上的服务。它们需要私有访问,但要有作用域权限、审计轨迹,并且不会泄露凭证。
Cloudflare Mesh:一张面向用户、节点和 agent 的私有网络
Cloudflare Mesh 是面向开发者的私有网络。一个轻量连接器、一个二进制,就能连接一切:个人设备、远程服务器、用户终端。你不需要为每种模式安装独立工具,网络上一个连接器,所有访问模式都能工作。
连接之后,私有网络中的设备可以使用私有 IP 互相通信,通过 Cloudflare 遍布 330 多个城市的全球网络路由,带来更好的可靠性以及对网络的控制。
如今,通过 Mesh,一个解决方案就能搞定上文提到的所有 agent 场景:
-
在手机上运行 Cloudflare One Client for iOS,你可以通过 Mesh 私有网络把移动设备安全地连接到本地运行 OpenClaw 的 Mac mini。
-
在笔记本上运行 Cloudflare One Client for macOS,你可以把笔记本接入私有网络,让编码 agent 访问并查询暂存数据库或 API。
-
在 Linux 服务器上运行 Mesh nodes,你可以把外部云中的 VPC 串联起来,让 agent 访问外部私有网络中的资源与 MCP。
由于 Mesh 由 Cloudflare One Client 驱动,每条连接都继承了 Cloudflare One 平台的安全控制。Gateway 策略适用于 Mesh 流量,设备态势检查会校验接入设备,DNS 过滤拦截可疑查询。这些都无需额外配置:保护人类流量的策略同样保护 agent 流量。
在 Mesh 与 Tunnel 之间选择
Mesh 推出后,你可能会问:什么时候用 Mesh、什么时候用 Tunnel?二者都把外部网络私有连接到 Cloudflare,但用途不同。Cloudflare Tunnel 是单向流量的理想方案,Cloudflare 把流量从边缘代理到特定的私有服务(比如一个 Web 服务器或一个数据库)。
Cloudflare Mesh 则提供完整的双向、多对多网络。Mesh 上的每台设备和节点都能通过私有 IP 互访。在你的网络中运行的应用或 agent 可以发现并访问 Mesh 上的任意其他资源,无需为每个资源单独建立 Tunnel。
借助 Cloudflare 网络的力量
Cloudflare Mesh 既具有 mesh 网络的优点(韧性、高可扩展性、低延迟、高性能),又通过 Cloudflare 路由解决了 mesh 网络的关键挑战:NAT 穿透。
互联网的大部分都在 NAT(Network Address Translation)之后。它通过映射公网头与内部私有地址,让一整个本地网络的设备共享单个公网 IP。当两台设备都位于 NAT 后面,直连可能失败,流量不得不退回到中继服务器。如果你的中继基础设施接入点有限,大量流量都会落到这些中继上,带来延迟并降低可靠性。虽然你可以自建中继服务器作为补偿,但这意味着要承担额外基础设施的运维负担,只为连接你已有的网络。
Cloudflare Mesh 采用了不同思路。所有 Mesh 流量都经由 Cloudflare 全球网络路由,这与服务互联网上一些最大网站的基础设施是同一套。对于跨区域或多云流量,这一路径稳定优于公网路由。不存在降级回退路径,因为 Cloudflare 边缘就是路径本身。
通过 Cloudflare 路由也意味着每个数据包都经过 Cloudflare 的安全栈。这正是把 Mesh 构建在 Cloudflare One 平台上的关键优势:安全不是事后再附加的另一个产品。借助同一条全球骨干,我们可以为每个团队从第一天起就提供这些核心支柱:
50 个节点、50 个用户免费。 整个团队加整个暂存环境共用一张私有网络,每个 Cloudflare 账户都包含。
全球边缘路由。 330 多个城市,优化的骨干路由。没有接入点有限的中继服务器,也没有降级的回退路径。
第一天就有的安全控制。 Mesh 运行在 Cloudflare One 上。Gateway 策略、DNS 过滤、DLP、流量审查与设备态势检查都在同一平台上可用。先从简单的私有连接开始,需要时打开 Gateway 策略来过滤流量,需要会话级 SSH 与 RDP 控制时启用 Access for Infrastructure,需要防止敏感数据离开网络时加上 DLP。每项能力都只是一键之差。
高可用。 创建一个启用高可用的 Mesh node,并使用同一令牌以主备模式启动多个连接器。它们通告相同的 IP 路由,一个挂掉时,流量会自动故障切换。
通过 Workers VPC 与开发者平台集成
Mesh 跨外部云连接你的 agent 与资源,但你也需要从 Workers 上用 Agents SDK 构建的 agent 发起连接。为此,我们扩展了 Workers VPC,让整个 Mesh 网络对 Workers 与 Durable Objects 可见。
也就是说,你可以从 Workers 连接 Cloudflare Mesh 网络,让整个网络通过单个绑定的 fetch() 调用即可访问。这与 Workers VPC 既有的 Cloudflare Tunnel 支持互补,让你在保护网络方式上有更多选择。如今,你可以在 wrangler.jsonc 中指定要连接的整个网络。要绑定到你的 Mesh 网络,使用保留关键字 cf1:network,绑定到你账户的 Mesh 网络:
"vpc_networks": [
{ "binding": "MESH", "network_id": "cf1:network", "remote": true },
{ "binding": "AWS_VPC", "tunnel_id": "350fd307-...", "remote": true }
]
然后你可以在 Worker 或 agent 代码中使用它:
export default {
async fetch(request: Request, env: Env, ctx: ExecutionContext) {
// Reach any internal host on your Mesh, no pre-registration required
const apiResponse = await env.MESH.fetch("http://10.0.1.50/api/data");
// Internal hostname resolved via tunnel's private DNS resolver
const dbResponse = await env.AWS_VPC.fetch("http://internal-db.corp.local:5432");
return new Response(await apiResponse.text());
},
};
把开发者平台与 Mesh 网络连通,你可以构建安全访问私有数据库、内部 API 与 MCP 的 Workers,从而构建跨云 agent 与 MCP,为应用提供 agentic 能力。同时也开启了一个全新世界:agent 可以自主端到端观测你的整个技术栈,交叉引用日志,并实时给出优化建议。
整体如何拼合
Cloudflare Mesh、Workers VPC 与 Agents SDK 共同为 agent 提供一张统一的私有网络,横跨 Cloudflare 与你的外部云。我们把连接性与计算合并,让 agent 安全访问全球任何地方所需的资源。
Mesh nodes 是你的服务器、虚拟机和容器。它们运行无界面版本的 Cloudflare One Client,获得一个 Mesh IP。服务之间通过私有 IP 双向通信,经由 Cloudflare 边缘路由。
Devices 是你的笔记本和手机。它们运行 Cloudflare One Client 直接访问 Mesh nodes:SSH、数据库查询、API 调用,全部走私有 IP。本地编码 agent 利用这条连接访问私有资源。
Agents on Workers 通过 Workers VPC Network 绑定访问私有服务。它们获得对整个网络的作用域访问权限,由 MCP 居中调度。网络强制 agent 能访问到什么,MCP 服务器强制 agent 能做什么。
接下来
Mesh 的当前版本提供了安全统一连接的基础。但随着 agentic 工作流愈加复杂,我们要超越简单的连接,走向一张更直观可管、且能更细粒度感知“谁或什么“在与你的服务通信的网络。下面是我们今年余下时间正在构建的内容。
主机名路由
我们将在今年夏天把 Cloudflare Tunnel 的 hostname routing 扩展到 Mesh。你的 Mesh nodes 将能吸引私有主机名(如 wiki.local 或 api.staging.internal)的流量,而无需管理 IP 列表,也不必担心这些主机名如何在 Cloudflare 边缘解析。按名字而非 IP 路由。如果你的基础设施使用动态 IP、自动伸缩组或临时容器,这能消除一整类路由难题。
Mesh DNS
今天你通过 Mesh IP 访问 Mesh nodes:ssh 100.64.0.5。这能用,但不是你思考基础设施的方式。你想的是名字:postgres-staging、api-prod、nikitas-openclaw。
今年晚些时候我们将构建 Mesh DNS,让加入你 Mesh 的每个节点和设备自动获得一个可路由的内部主机名。无需 DNS 配置或手动记录。添加一个名为 postgres-staging 的节点,Mesh 上任意设备都能把 postgres-staging.mesh 解析到正确的 Mesh IP。
结合主机名路由,你将能 ssh postgres-staging.mesh 或 curl http://api-prod.mesh:3000/health,无需知道或管理任何 IP 地址。
身份感知路由
今天,Mesh nodes 向 Cloudflare 边缘做认证,但在网络层共享一个身份。设备通过 Cloudflare One Client 用用户身份认证,但节点尚未携带 Gateway 策略可区分的、可路由的独立身份。
我们要改变这一点。目标是让 Mesh 实现身份感知路由,每个节点、每台设备,最终每个 agent 都获得一个策略可评估的独立身份。规则不再基于 IP 段编写,而是基于谁或什么在连接来编写。
这对 agent 最重要。今天,当 Workers 上运行的 agent 通过 VPC 绑定调用工具时,目标服务只看到是 Worker 在请求,并不知道是哪个 agent 发起、谁授权、获得了哪些作用域。在 Mesh 这一侧,当笔记本上的本地编码 agent 访问暂存服务时,Gateway 看到的是你的设备身份,而不是 agent 的身份。
我们正在构建这样的模型,让 agent 在网络中携带自己的身份:
-
Principal / Sponsor:授权该动作的人(平台团队的 Nikita)
-
Agent:执行该动作的 AI 系统(部署助手,会话 #abc123)
-
Scope:该 agent 被允许做什么(读取部署、触发回滚,其他什么都不做)
这样你就能写出这种策略:Nikita 的 agent 的读操作允许,而写操作需要 Nikita 本人。Agent 流量可以与人类流量独立过滤;agent 的网络访问可以被吊销,而不影响 Nikita 自己。
实现这一点的基础设施已就位。Mesh nodes 用每节点令牌注册,设备用每用户身份认证,Workers VPC 绑定按服务作用域访问。缺失的一块是把这些身份暴露给策略层,让 Gateway 可以基于它们做路由与访问决策。这就是我们正在构建的。
容器中的 Mesh
今天,Mesh nodes 运行在 VM 与裸金属 Linux 服务器上。但现代基础设施越来越多地运行在容器中:Kubernetes Pod、Docker Compose 栈、临时 CI/CD runner。我们正在构建一个 Mesh Docker 镜像,让你能向任何容器化环境添加 Mesh node。
这意味着你将能在 Docker Compose 栈中包含一个 Mesh sidecar,让该栈中的每个服务都获得私有网络访问。运行在暂存集群容器中的微服务可以通过 Mesh 访问生产 VPC 中的数据库,任何一方都不需要公网端点。
它对 CI/CD 流水线也很有用,可以在构建和测试期间访问私有基础设施:你的 GitHub Actions runner 拉取 Mesh 容器镜像,加入网络,对暂存环境运行集成测试,然后销毁。整个过程无需管理 VPN 凭证或维持持久隧道:容器退出时节点也随之消失。
我们预计 Mesh Docker 镜像将于今年晚些时候推出。
开始使用
在我们继续演进这些身份与路由能力的同时,安全统一连接的基础今天已可用。你可以在几分钟内开始打通你的云,并保护你的 agent。
开始使用 Cloudflare Mesh:在 Cloudflare 仪表盘 中前往 Networking > Mesh。最多 50 个节点和 50 个用户免费。
用 Agents SDK 与 Workers VPC 构建 agent: 安装 Agents SDK(npm i agents),按 Workers VPC 快速入门 操作,并构建一个具备私有后端访问的远程 MCP server。
已经在用 Cloudflare One? Mesh 与你现有设置兼容。你的 Gateway 策略、设备态势检查与 Access 规则会自动应用到 Mesh 流量上。参见 Mesh 文档 添加你的第一个节点。