我们在 2021 年推出 Quick Tunnels，让开发者能够轻松分享他们在本地开发环境中运行的最新服务、应用程序或项目。自那以后发生了很多变化，但核心用例始终如一。
你的编码智能体刚刚完成了功能开发。开发服务器已在 localhost:5173 上运行，还没等你开口，智能体就主动提出让你在手机上试用。它运行一条命令，然后递给你一个链接：
cloudflared tunnel --url http://localhost:5173
该命令会启动一个 Quick Tunnel。cloudflared 是 Cloudflare 的轻量级连接器，它会将你的本地服务发布到一个随机的 trycloudflare.com URL 上。无需账户、无需域名、零成本。智能体现在使用 Quick Tunnels 的原因和人们一样：这是从本地端口到 URL 的最短路径。
问题始终如一：任何拿到链接的人都能打开它。
从 cloudflared 2026.9.3 开始，你可以在命令中添加 --allowed-mail，你的 Quick Tunnel 就只会允许你指定的电子邮件地址和域名访问。访问者通过 Cloudflare Access 发送的一次性 PIN 码来证明他们拥有其中一个地址。双方都不需要 Cloudflare 账户。
智能体让 Quick Tunnels 比以往更受欢迎
编写代码的智能体需要有个地方向你展示结果。运行在家中 Mac mini 上的智能体需要能从你的手机访问。笔记本电脑上的 Model Context Protocol 服务器需要一个公共端点，托管式助手才能调用它们。这些场景都需要一个 URL，而 Quick Tunnel 只需一条智能体可以自行运行的命令就能生成一个。没有需要它填写的注册表单。加上 --output json，每一行日志都会变成 JSON 对象，这样智能体无需抓取文本就能提取出 URL。
自智能体兴起以来，Cloudflare Tunnel 和 Quick Tunnels 的采用率呈指数级增长。2026 年 9 月 18 日，一个指向 Quick Tunnels 页面的链接登上了 Hacker News 榜首，获得了 800 多分和 300 条评论。该帖子读起来就像一份智能体工作流的目录。有人的 AI 自行发现了 Quick Tunnels，用来发布它刚刚构建的网站。另一位评论者称它们“在移动办公进行智能体工作时极其有用”。
还有一位评论者提出了本文要回答的问题：“还要多久，某人的智能体就会建立一个隧道，让全世界看到一个人最敏感、最私密、最令人尴尬的信息，或者尚未完成的不安全应用？”
控制谁可以访问你的服务
将电子邮件地址传给 --allowed-mail：
cloudflared tunnel --url http://localhost:8080 \ --allowed-mail alice@example.com
Alice 打开 URL，输入她的电子邮件地址，键入发送到她收件箱的验证码，然后到达你的应用。其他任何人在单个请求到达你的机器之前就会被拦截。你仍然无需创建 DNS 记录、编写配置文件或打开仪表板。
要允许更多人访问，请重复该标志或允许整个域：
cloudflared tunnel --url http://localhost:8080 \ --allowed-mail alice@example.com \ --allowed-mail bob@example.com \ --allowed-mail '*@example.com'
如果你省略 --allowed-mail，则不会有任何变化。公共 Quick Tunnels 的行为与以往完全一致。
要更改谁可以访问，请停止 cloudflared 并启动新的隧道。进程退出的那一刻，所有人的访问都会结束。
如需稳定的主机名或更丰富的规则（例如身份提供商组），请使用 Cloudflare Tunnel 配合 Cloudflare Access。如需从你自己的设备访问家中的智能体，无需任何公共 URL 并建立双向连接，请使用 Cloudflare Mesh。
将其设为你的智能体默认设置
由于保护只需一个标志，智能体可以像人一样轻松使用它。在你的编码智能体读取的指令文件中添加一行，例如 AGENTS.md：
When you start a Quick Tunnel, always add --allowed-mail me@example.com.
从那时起，你的智能体分享的预览应仅对你开放。智能体并不总是遵循指令，因此请检查它运行了什么：cloudflared 会打印隧道是否使用电子邮件认证以及它包含多少条规则，但不会打印地址。
从 Wrangler 启动受保护的隧道
如果你在 Workers 上构建，可以从最新版本的 wrangler 启动同类型的隧道：
npx wrangler tunnel quick-start http://localhost:8080 \ --allowed-mail alice@example.com
Wrangler 支持重复标志、逗号分隔值和通配符域，并且它会从调试日志中移除 --allowed-mail 值。
Cloudflare 验证电子邮件。你的机器决定谁可以访问。
当有人打开受保护的 URL 时，他们会进入 Cloudflare Access 登录页面。他们输入自己的电子邮件地址，然后输入发送到该邮箱的一次性 PIN 码。电子邮件登录是为使用浏览器的人设计的。
这一步只回答一个问题：这个人是否控制这个电子邮件地址？它并不决定他们是否受欢迎。cloudflared 在你的机器上通过将已验证的地址与你输入的规则进行比较来做出这个决定。
当没有账户时，策略存在于哪里？
将这两个问题分开是设计的核心。身份验证证明访问者是谁。授权决定该访问者是否能够进入。每个执行访问规则的 Cloudflare 产品都将授权部分放在同一个地方：你的 Cloudflare 账户。Quick Tunnel 没有账户。因此，困难的部分从来不是向某人发送验证码。而是决定访客名单应该存放在哪里。
我们从四个需求开始。设计必须：
保持 Quick Tunnels 无需账户，因为注册步骤会违背一键隧道的目的。
保持公共 Quick Tunnels 的请求路径不变。
避免在访问者登录后对每个请求进行集中式策略查找。
保护开发者输入到终端中的电子邮件地址的隐私。
我们的第一个想法是在每个 Quick Tunnel 主机名前面放置一个 Cloudflare Access 应用程序。Access 已经在流量到达 cloudflared 之前检查访问者，因此复用它看起来是最短的路径。但是数十万个 Quick Tunnels 可能同时运行，许多只运行几分钟，每个都需要自己的应用程序和策略。由于没有账户来拥有它们，我们将不得不发明一个新的命名空间并动态路由应用程序，仅仅为了存储一个只存在一下午的列表。
我们的第二个想法是构建整个流程。cloudflared 将持有规则，而 Tunnel 服务将发送和检查验证码。这个想法的授权部分很好：每个连接器检查自己的列表，这自然扩展并将规则保留在开发者的机器上。身份验证部分则不然。发送验证码是电子邮件登录中容易的部分。困难的部分是确保电子邮件送达、阻止滥用、构建安全挑战、管理会话，以及提供可访问且已翻译的登录页面，然后安全地运营所有这些多年。Cloudflare Access 已经解决了这些问题。
因此我们保留了每个想法中最好的部分。Access 验证访问者控制该电子邮件地址。一个运行在 Cloudflare Workers 上的小型身份验证代理将已验证的身份转换为短期的、签名的手递。该代理在设计上是无状态的。它不存储隧道策略、不存储访问者会话、不存储身份记录，并且它永远不会看到隧道的访客名单。cloudflared 检查手递并自行做出授权决定，在内存中，根据你输入的规则。
结果是我们最关心的特性：你的访客名单永远不会离开你的机器。Cloudflare 知道隧道需要电子邮件身份验证。它不知道你邀请了谁。
跟踪一个通过受保护 Quick Tunnel 的请求
受保护的隧道以与公共隧道相同的无账户方式创建。cloudflared 发送的唯一额外内容是身份验证模式，绝不是你的规则。如果服务不确认该模式，cloudflared 会拒绝启动，而不是错误地给你一个公共 URL。
访客首次打开该 URL 时：
cloudflared 收到一个没有会话的请求。它将浏览器重定向到 login.trycloudflare.com，并附带一个随机的、一次性 state，该 state 与该浏览器绑定，有效期为 10 分钟。
Cloudflare Access 向访客的电子邮箱地址发送一次性 PIN 并进行验证。
broker 检查 Access 身份，并返回一个短期的、签名的 assertion，该 assertion 绑定到隧道主机名和该 state。浏览器通过表单 POST 提交它，因此它永远不会出现在 URL、浏览器历史记录或日志中。
cloudflared 验证该 assertion，消耗该 state，并根据你的规则检查电子邮箱。匹配时，它会创建一个本地会话，并将访客发送到其请求的页面。否则，访客会收到一个通用响应，不会透露任何关于列表的信息。
后续请求使用该会话，最长可持续四小时（如果访客的 Access 登录更早过期，则时间更短），或直到你停止 cloudflared。没有中心化查询，也没有策略服务。
会话 cookie 包含一个随机值和一个过期时间，不包含任何关于访客身份的信息。cloudflared 在转发请求前会剥离身份验证凭据，因此你的应用永远不会看到它们，也永远不需要实现登录流程。如果任何检查失败，请求永远不会到达你的本地服务。受保护的隧道永远不会回退到公共模式。
由实习生构建
受保护的 Quick Tunnels 由两名实习生交付：产品方向的 Hugo Vicente 和工程方向的 Alessandro Frigerio。他们将其从产品需求推进到身份验证 broker，再到 cloudflared 发布。这就是 Cloudflare 实习的工作方式：实习生负责真实问题，并将解决方案交付到生产环境。
在你的下一次演示中试用
Quick Tunnels 的电子邮件保护是免费的，就像 Quick Tunnels 本身一样。安装或更新 cloudflared，启动你的本地服务器，并添加 --allowed-mail 标志：
cloudflared tunnel --url http://localhost:8080 --allowed-mail you@example.com
设置详情、匹配规则和限制见 Quick Tunnels 文档。
下次你或你的智能体分享你正在构建的内容时，该链接只会对你选择的人开放。
转载声明：本文为转载整理，原文版权归原作者及原站点所有。
原文作者：Alessandro Frigerio；如有侵权，请联系管理员删除。
