Quick Tunnels 简介与演进

Cloudflare 于 2021 年推出 Quick Tunnels，旨在通过 cloudflared 连接器将本地运行的服务（如 localhost:5173）快速发布到随机的 trycloudflare.com 域名下。该方式无需注册账号、绑定域名或付费，成为开发者及自动化编码代理（coding agent）将本地端口暴露为公网 URL 的最短路径。

随着 AI 代理的普及，Quick Tunnels 被用于代理自托管服务、移动设备访问家庭 Mac mini 上的代理，或为模型上下文协议（MCP）服务器提供公网端点。代理可通过 --output json 参数让日志输出结构化，便于自动提取 URL。

新增邮箱鉴权保护

此前的 Quick Tunnels 任何获得链接者均可直接访问，存在敏感信息泄露风险。从 cloudflared 2026.9.3 版本起，用户可在启动命令中加入 --allowed-mail 参数指定允许访问的邮箱地址或整个域名。访客需在 Cloudflare Access 页面输入邮箱并填写一次性 PIN 完成验证，而通信双方均无需 Cloudflare 账号。

配置示例

cloudflared quick-tunnel --allowed-mail alice@example.com --allowed-mail @corp.com

若省略该参数，隧道行为与传统公开方式一致；停止 cloudflared 进程后所有访问立即终止。对于需要稳定主机名或复杂身份规则的场景，建议使用 Cloudflare Tunnel 配合 Access；若需无公网 URL 的双向连接，可参考 Cloudflare Mesh。

认证与授权分离设计

该特性核心在于将“身份认证”与“访问控制”解耦：

  • 认证：由 Cloudflare Access 负责，向访客邮箱发送一次性 PIN，证明其控制该地址。
  • 授权：由本地 cloudflared 进程执行，比对验证后的邮箱与用户键入的规则。

为此，Cloudflare 设计了一个运行在 Workers 上的无状态代理（broker），它仅将 Access 验证过的身份转换为短期签名凭证，不存储任何隧道策略、会话或游客列表。因此，开发者的 guest list 始终保留在本地机器内存中，云侧仅知晓该隧道启用了邮箱认证，无从获知具体邀请对象。

请求流程

  1. 创建隧道时，cloudflared 仅上报认证模式，若服务端未确认则拒绝启动，避免误开公开隧道。
  2. 访客首次打开 URL，浏览器被重定向至登录页，携带 10 分钟有效的单次状态值。
  3. Access 发送 PIN 至邮箱并校验，broker 返回绑定隧道主机名与状态的短期签名断言。
  4. cloudflared 校验断言，并在内存中执行本地规则决策，放行或拒绝。

对读者的意义与技术解读

对于运维、SRE 与网络工程师，临时将内网服务映射至公网进行调试、演示或对接外部助手是常见需求。传统方案如 SSH 反向隧道或自建 VPN 配置繁琐，而完全公开的隧道又易引发数据暴露。Cloudflare 此方案在“零账号摩擦”与“基本访问控制”间取得平衡：

  • 轻量安全：邮件 PIN 验证成本低，且策略留守本地，符合隐私最小化。
  • 自动化友好：代理可在 AGENTS.md 中写入一行指令默认启用保护，适合 AI 工作流。
  • 边界清晰：云厂商仅处理认证挑战，授权决策在边缘客户端，降低中心化策略泄露风险。
  • 适用场景：快速分享开发预览、家庭实验室远程触达、Webhook 临时接收等，但不替代企业级零信任网络访问。

从网络诊断视角，此类隧道不影响 ICMP 或 TCP 端口探测，但改变了应用层可达性；工程师在排查连通性时，需区分是隧道认证阻断还是实际服务故障。平台用户可结合本站 tcping / http 测速工具，对隧道端点进行握手与首包分析，验证链路质量。