受保护的快速隧道：为你的下一个开发项目提供简单的无账户认证-数字安全观察

当前位置：首页 > 安全工程 > 受保护的快速隧道：为你的下一个开发项目提供简单的无账户认证正文

受保护的快速隧道：为你的下一个开发项目提供简单的无账户认证

时间：2026-10-10 02:41:35 来源：数字安全观察作者：数字安全观察阅读：112次

我们在 2021 年推出 Quick Tunnels，让开发者能轻松分享本地开发环境中运行的最新服务、应用或项目。此后发生了很多变化，但核心用例始终未变。

文章主题示意图 — 主题配图，非事件现场。摄影：Torsten Dettlaff / Pexels

你的编码代理刚刚完成功能。开发服务器已在 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 传入一个电子邮件地址：

Alice 打开 URL，输入她的电子邮件地址，键入发送到她收件箱的验证码，然后就能访问你的应用。其他任何人都会在请求到达你的机器之前被拦截。你依然无需创建 DNS 记录、编写配置文件或打开仪表板。

要允许更多人进入，可以重复该标志，或允许整个域名：

如果你省略 --allowed-mail，一切都不会改变。公共 Quick Tunnels 的行为与以往完全相同。

要更改谁可以进入，请停止 cloudflared 并启动新的隧道。进程退出的那一刻，所有人的访问权限都会终止。

如需稳定的主机名或更丰富的规则（例如身份提供商组），请使用 Cloudflare Tunnel 搭配 Cloudflare Access。若想从自己的设备访问家中的代理，且不使用任何公共 URL，并建立双向连接，请使用 Cloudflare Mesh。

将其设为你的代理默认选项

由于保护只需一个标志，代理使用起来和人一样简单。在你的编码代理读取的指令文件（例如 AGENTS.md）中添加一行：

从那时起，你的代理分享的预览应该只对你开放。代理并不总是遵循指令，所以要检查它运行了什么：cloudflared 会打印隧道是否使用电子邮件身份验证以及包含多少条规则，但不会打印具体地址。

从 Wrangler 启动受保护的隧道

如果你基于 Workers 构建，可以从最新版本的 wrangler 启动同类型的隧道：

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，有效期为 10 分钟。

Cloudflare Access 向访问者的电子邮件地址发送一次性 PIN 码并进行验证。

代理检查 Access 身份，并返回一个短期、签名的断言，绑定到隧道主机名和该 state。浏览器通过表单 POST 提交它，因此它永远不会出现在 URL、浏览器历史或日志中。

cloudflared 验证断言，用完该 state，并根据你的规则检查电子邮件。匹配时，它会创建一个本地会话，并将访问者发送到他们请求的页面。否则，访问者会收到一个通用响应，不会透露任何关于名单的信息。

后续请求使用该会话，最长可达四小时（如果访问者的 Access 登录更早过期，则更短），或直到你停止 cloudflared。没有集中式查询，也没有策略服务。

会话 cookie 只包含一个随机值和一个过期时间，不包含任何关于访问者身份的信息。cloudflared 在转发请求前会剥离身份验证凭据，因此你的应用永远看不到它们，也永远不必实现登录流程。如果任何检查失败，请求永远不会到达你的本地服务。受保护的隧道绝不会回退到公共模式。

由实习生构建

受保护的 Quick Tunnels 由两名实习生交付：产品方面的 Hugo Vicente 和工程方面的 Alessandro Frigerio。他们将其从产品需求推进到身份验证代理，再到 cloudflared 发布。这就是 Cloudflare 实习的运作方式：实习生负责真实问题，并将解决方案交付到生产环境。