**原文标题：** Protected Quick Tunnels: simple accountless authentication for your next dev project **作者：** Nikita Cano、Hugo Vicente、Alessandro Frigerio **来源：** Cloudflare Blog，2026 年 10 月 2 日 **原文：** https://blog.cloudflare.com/protected-quick-tunnels/
临时隧道方便分享，也会把服务公开
Cloudflare Quick Tunnels 的用途，是把本机开发环境里运行的服务临时变成一个可访问的网址。通常只需运行一条命令：
cloudflared tunnel --url http://localhost:5173
cloudflared 会通过随机的 trycloudflare.com 地址转发到本地端口。无需注册 Cloudflare 账号、准备域名或付费，适合把尚在开发中的页面发给同事查看，也适合让手机访问家中电脑上的开发服务。对代码代理而言，它同样提供了一个从本地端口快速获得 URL 的方式。
但传统 Quick Tunnel 的链接本身就是访问入口：拿到链接的人都能打开服务。若本地应用包含私人资料、调试接口或尚未完善的功能，单纯“链接不公开”并不是访问控制。
从 cloudflared 2026.9.3 开始，可以使用 --allowed-mail 给 Quick Tunnel 加上邮箱允许名单。访问者通过 Cloudflare Access 收到一次性 PIN 并证明自己控制相应邮箱；访问者和隧道发起者都不需要 Cloudflare 账号。
只允许指定邮箱或域名访问
指定一个邮箱的示例：
cloudflared tunnel --url http://localhost:8080 \
--allowed-mail alice@example.com
Alice 打开隧道网址，输入邮箱，再输入发到收件箱的一次性验证码，通过后才会到达本地应用。其他访问者会在请求到达开发者机器之前被拦截。整个过程不需要创建 DNS 记录、编写配置文件或打开控制台。
可重复传入参数，允许多个邮箱；也可以用通配域名规则：
cloudflared tunnel --url http://localhost:8080 \
--allowed-mail alice@example.com \
--allowed-mail bob@example.com \
--allowed-mail '*@example.com'
未设置 --allowed-mail 时，Quick Tunnel 的原有公开行为不变。要调整允许名单，停止当前 cloudflared 进程并启动一个新隧道；进程一旦退出，当前隧道的所有访问会话也随之结束。
若需要固定主机名或身份提供方群组等更丰富的规则，应使用 Cloudflare Tunnel 搭配 Cloudflare Access。若要从个人设备访问家中的代理，同时避免公开 URL 并建立双向连接，文章建议使用 Cloudflare Mesh。
也可以从 Wrangler 启动
使用 Workers 的开发者可以从最新版 Wrangler 启动受保护的 Quick Tunnel：
npx wrangler tunnel quick-start http://localhost:8080 \
--allowed-mail alice@example.com
Wrangler 支持重复传入参数、逗号分隔的值和通配域名；它也会从调试日志中移除 --allowed-mail 的值。
对于代码代理，可以把默认规则写进它读取的指令文件，例如 AGENTS.md：
When you start a Quick Tunnel, always add --allowed-mail me@example.com.
之后代理创建预览隧道时就能按这条规则添加邮箱限制。不过，代理可能没有遵循指令，因此仍应查看实际启动命令。cloudflared 会说明隧道是否启用邮箱验证以及包含多少条规则，但不会打印具体邮箱地址。
邮箱认证与访问授权分别在哪里完成
受保护网址的访问过程分成“确认来访者是谁”和“判断此人是否在允许名单中”两步。Cloudflare Access 负责验证邮箱：访问者输入邮箱并使用发送到该邮箱的一次性 PIN 登录。这个步骤只证明访问者控制这个邮箱，不决定该邮箱是否获准访问。
允许名单保存在运行 cloudflared 的开发者机器上，由本地连接器作出授权判断。这样既复用了 Access 处理邮件送达、滥用防护、安全挑战、会话管理、可访问的登录页和多语言体验等认证能力，也避免了为每条短暂运行的 Quick Tunnel 单独创建 Cloudflare Access 应用和策略。原文指出，Quick Tunnel 数量很大，许多只运行几分钟；为它们逐一建立账号归属和策略空间并不合适。
设计还满足几个约束：Quick Tunnel 仍然免账号；未启用保护的公开隧道请求路径保持原样；用户登录后不必在每次请求时访问中央策略服务；开发者在终端输入的邮箱地址也应受到保护。
为此，Cloudflare Access 验证邮箱后，一个运行在 Cloudflare Workers 上的小型认证代理会把已验证身份转换成短时、带签名的交接凭证。代理按无状态方式运行，不保存隧道策略、访客会话或身份记录，也看不到隧道的允许名单。随后 cloudflared 在内存中校验凭证，并依照开发者输入的规则自行授权。Cloudflare 知道这个隧道要求邮箱认证，但不会知道开发者邀请了哪些人。
首次访问时的请求流程
受保护隧道仍以免账号方式创建；cloudflared 额外发送的只有认证模式，不发送邮箱规则。如果服务端未确认该模式，cloudflared 会拒绝启动，避免意外创建一个实际公开的 URL。
访客首次打开链接时，流程如下：
cloudflared发现请求没有会话，将浏览器重定向至login.trycloudflare.com。重定向携带与该浏览器绑定的随机一次性状态值，有效期为 10 分钟。- Cloudflare Access 向访客邮箱发送一次性 PIN 并验证邮箱。
- 认证代理检查 Access 身份，返回一个短时签名断言，并将其绑定到隧道主机名和上述状态值。浏览器通过表单 POST 提交断言，所以断言不会进入 URL、浏览历史或日志。
cloudflared校验断言、消耗该状态值，再将邮箱与本地规则匹配。匹配时创建本地会话并把访客送回原请求页面；不匹配时返回通用响应，不泄露允许名单内容。- 后续请求可复用会话，最长四小时；如果访客的 Access 登录更早过期，会话也会提前结束。停止
cloudflared同样会结束会话。
会话 Cookie 只含随机值和到期时间，不包含访客身份。cloudflared 会在把请求转发到本地应用前移除认证凭证，所以应用无需接收这些凭证，也不必自行实现登录流程。任何校验失败都会使请求止步于隧道入口；受保护的隧道不会退回公开模式。
快速开始
文章给出的最短示例是安装或更新 cloudflared、启动本地服务，再执行：
cloudflared tunnel --url http://localhost:8080 --allowed-mail you@example.com
邮箱保护与 Quick Tunnels 本身一样免费。--allowed-mail 的配置细节、匹配规则和限制应以原文关联的 Quick Tunnels 文档为准；本文不展开未在原文中列出的规则。
**版本提示：** 邮箱保护从 cloudflared 2026.9.3 开始提供。以上命令、产品能力和收费说明均来自原文所述版本与时间点。
暂无评论内容