Cloudflare Quick Tunnels 现在支持邮箱认证。开发者只需在启动 cloudflared 时加入 --allowed-mail，就能把本地应用暴露给指定邮箱地址或域名，而隧道创建者和访问者都不需要 Cloudflare 账号。
这项能力特别适合临时预览、远程调试和小范围验收：它保留了 Quick Tunnel 即开即用的特点，同时避免“拿到随机链接的人都能访问”这一明显风险。
一条命令，把公开链接变成受限入口
假设本地应用已经监听 http://localhost:3000，并且机器上安装了 cloudflared，可以这样启动受保护的 Quick Tunnel：
cloudflared tunnel \
--url http://localhost:3000 \
--allowed-mail alice@example.com
命令运行后，cloudflared 会输出一个临时公网地址。与普通 Quick Tunnel 不同，访问者需要使用被允许的邮箱完成认证，才能进入本地应用。
如果希望按组织域名放行，可以把允许项改成目标域名。具体的域名格式以及一个命令中配置多个值的方式，建议以当前安装版本的帮助信息为准：
cloudflared tunnel --help | grep -A 3 -B 3 allowed-mail
例如，在当前版本确认域名参数格式后，可以按下面的思路调整：
cloudflared tunnel \
--url http://localhost:3000 \
--allowed-mail example.com
这里的 example.com 需要替换为团队实际使用的邮箱域名。若只需邀请一两位测试人员，优先填写完整邮箱地址，权限边界通常更清晰。
它解决的是“临时共享”的身份边界
过去使用 Quick Tunnel 分享开发服务时，随机生成的 URL 本身往往承担了“秘密”的角色。只要链接被转发、记录到聊天截图，或者出现在浏览器历史中，其他拿到链接的人就可能尝试访问。
--allowed-mail 把访问条件从“知道 URL”提升为“知道 URL，并能通过指定邮箱身份认证”。这对以下场景很实用：
- 把尚未部署的前端页面发给产品经理验收；
- 让外部合作方临时查看一个回调处理页面；
- 在两台不便直接联网的设备之间调试 Web 服务；
- 分享本地文档站、Storybook 或管理界面原型；
- 在短期演示中限制访问者范围。
它的关键优势不是替代完整的身份平台，而是减少临时项目的配置成本。无需先创建 Cloudflare 账号、配置正式 Tunnel 或搭建单独的登录系统，就可以获得基础的邮箱访问控制。
可以这样做一个可复制的本地演示
下面用 Python 自带的 HTTP 服务器创建一个最小示例。先准备页面：
mkdir -p quick-tunnel-demo
cd quick-tunnel-demo
cat > index.html <<'EOF'
<!doctype html>
<html lang="zh-CN">
<head>
<meta charset="utf-8">
<title>受保护的开发预览</title>
</head>
<body>
<h1>Quick Tunnel 已连接</h1>
<p>如果你能看到这里，说明邮箱认证已经通过。</p>
</body>
</html>
EOF
启动本地服务：
python3 -m http.server 8000 --bind 127.0.0.1
保持这个终端运行，再打开另一个终端启动隧道：
cloudflared tunnel \
--url http://127.0.0.1:8000 \
--allowed-mail reviewer@example.com
将 reviewer@example.com 替换为实际测试者的邮箱，然后把命令输出的临时地址发给对方。测试结束后，在运行 cloudflared 的终端按 Ctrl+C 即可关闭入口。
绑定到 127.0.0.1 还能避免示例服务器直接监听局域网的所有网卡。对于只打算经由隧道访问的本地服务，这是一个更稳妥的默认设置。
邮箱认证不等于完整的应用安全
受保护的 Quick Tunnel 很方便，但仍需要明确它的边界。
不要把它当成应用自身的授权系统。 邮箱认证控制的是谁能通过隧道入口，无法替代应用内部的角色、租户和数据权限检查。即使只有团队成员能够访问，后台接口仍应验证用户是否有权执行删除、导出或修改操作。
避免暴露真实生产数据。 开发服务器可能包含调试端点、详细错误信息、未脱敏数据库副本或默认管理员功能。临时认证降低了误访问概率，但不会自动修复应用漏洞。
限制隧道的存活时间。 Quick Tunnel 更适合临时任务。验收或调试完成后应立即停止进程，不要把它当作无人值守的长期部署方案。
域名放行要谨慎。 允许整个邮箱域名比允许单个地址更省事，但访问范围也更大。对于供应商、学校或成员数量较多的组织，优先维护明确的邮箱名单。
检查终端与协作工具中的信息。 临时 URL 仍不应随意发布到公开工单、公开仓库或可搜索的聊天频道。邮箱认证是一层保护，不是泄露链接的理由。
采用前的简短清单
在团队中使用这项能力时，可以逐项确认：
- 本地服务只监听必要的地址和端口；
--allowed-mail使用最小范围的邮箱地址或域名；- 测试数据已脱敏，不包含生产密钥和真实用户信息；
- 应用内部的敏感操作仍有独立鉴权；
- 临时任务结束后立即关闭
cloudflared； - 如果需要固定域名、长期运行或更复杂的访问策略，改用正式隧道与完整身份访问方案。
对于“把本地页面安全地给几个人看一下”这类需求，受邮箱保护的 Quick Tunnel 补上了恰到好处的一环：部署步骤仍然只有一条命令，但访问权不再只由一个可转发的 URL 决定。