Cloudflare为Quick Tunnels加入邮件访问控制：临时预览链接也能限定受众
2026年10月2日，Cloudflare介绍了Protected Quick Tunnels：从cloudflared 2026.9.3开始，开发者可以给临时本地预览链接加上邮件访问控制。官方文档在9月30日已经更新相关说明，因此此次新闻按10月2日介绍理解，不把它写成当天才首次出现的能力。
分享本地页面时，访问名单可以直接随命令设置
Quick Tunnels把本地HTTP服务发布到随机的trycloudflare.com地址，原本知道链接的人即可访问。现在启动时加入allowed-mail参数，就能指定允许的邮箱；访客通过邮件一次性PIN证明对该地址的控制权，开发者和访客均无需Cloudflare账号。该保护与Quick Tunnels一样免费。
名单可以包含多个地址，也可以允许某个邮箱域名。两种选择的受众差别很大：指定一位同事适合小范围验收，允许整个公司域名则可能包括更多人员。这里验证的是邮箱访问权，并没有额外判断收件人的项目角色或是否应看到页面里的某一条记录。
AI模型生成的概念插图：临时预览入口先检查受邀邮箱，再通往本地应用；不是Cloudflare实际登录页或安全架构图。
保护开关与链接生命周期都要看清
新参数是主动选择项，省略它仍会创建公开Quick Tunnel。Cloudflare明确提醒，即使给编码助手写了默认加保护的指令，也应查看实际执行结果；终端会显示是否启用邮件认证及规则数量，而不会打印允许的地址。
要修改名单，需要停止进程并创建新的隧道。进程退出后，所有人的访问都会结束；新隧道的主机名也会变化。这种生命周期适合“现在给同事看一下”，却不适合把地址长期写进第三方回调或客户手册。
例如一次手机验收，真正应检查的是两条路径：受邀邮箱能否打开目标页面，未在名单内的邮箱能否被阻止。随后停止本地进程，再确认旧链接不可访问。这样才能把“设置了参数”与“完成了访问验证”分开记录。
开发隧道的限制仍然存在
官方文档将Quick Tunnels定位为测试与开发工具，没有可用性保证；每个隧道最多支持200个同时在途请求，超过后返回429。它不支持Server-Sent Events，邮件认证也要求交互式浏览器会话，不能当作无人值守脚本的认证机制。
这些限制对AI应用预览尤其具体：若界面依赖SSE持续接收生成内容，普通页面能打开也不等于完整交互可用。需要稳定域名、更丰富身份策略或生产流量时，官方建议使用正式Cloudflare Tunnel与Access方案，而不是延长一个临时进程的寿命。
邮件门禁为短期分享增加一道身份检查，减少了临时链接被随意访问的风险，但应用自己的权限和数据暴露仍需单独控制。演示环境若连接真实后台，获准打开页面的人可能仍拥有页面本身赋予的操作能力，不能把隧道入口名单当成应用内的细粒度授权。
来源与核对时间
资料核对：2026年10月3日（北京时间）。本文未创建隧道；验收场景为原创分析。
