一条命令把 localhost 上的本地服务变成公网可访问地址：Cloudflare 发布 Quick Tunnels
不用账号、域名和入站端口，Quick Tunnel 就能给本地服务生成一个 HTTPS 公网入口。真正值得弄清的是请求怎么回来、Agent 怎样读取地址，以及为什么它只能用于测试。
在本地跑通一个 Web 服务、测试移动端页面，或者给外部平台配置 Webhook 回调时，开发者经常遇到同一个门槛：代码跑在自己的电脑上，公网访问不到。
传统将本地服务接入公网的方式，往往需要在路由器后台进行端口配置，或者注册第三方内网穿透服务。Cloudflare 推出的 Quick Tunnels（快速隧道）提供了一种几乎没有摩擦的替代方案：无需注册 Cloudflare 账号，无需购买或托管域名，也无需在路由器上开放任何入站端口，只要本地安装命令行工具并执行一行命令，就能立即为本地服务生成一个具备全球 HTTPS 加密访问能力的公网网址。
本地服务连入公网的传统痛点
在很多开发协作场景下，本地运行的服务必须接受外部访问：
分享预览：向远程同事展示正在开发中的原型，或在移动端等外部设备上预览本地前端界面的呈现效果。
接收 Webhook：接入外部平台的 Webhook 时，对方向你的服务推送事件通知，必须填写一个可直接访问的公开网址。
浏览器测试：在自动化测试或跨环境流程中运行浏览器测试，需要外部测试环境能稳定调用本地服务。
给 Coding Agent 一个公网端点：本地运行的 AI 编程代理或脚本在生成服务后，需要一个真实的公网入口供进一步调试或外部调用。
在缺少轻量穿透工具前，解决这些需求往往要把本地环境暴露在公网，或者在前置准备中花费大量时间注册账号、管理认证凭据以及维护配置文件。
只出不进：反向隧道如何绕开入站端口
Quick Tunnels 的底层依托于 Cloudflare 的轻量级守护进程 cloudflared。它能绕开路由器配置的核心原因，在于其采用了只出不进（Outbound-only）的反向隧道架构。
日常访问网站时，外部请求主动打向你的路由器 IP，这属于“入站流量”，路由器必须开放对应端口才能放行。但在 Quick Tunnels 架构中，数据流向完全倒了过来：
建立连接阶段：本地终端执行命令后，cloudflared 会主动向离当前网络最近的 Cloudflare 位置发起一条加密出站连接。这种出站通信无需在路由器上开放任何入站端口；不过在严格受限的网络环境中，仍需允许相应的出站流量（官方文档对正式 Tunnel 特别提示服务器需能访问 Cloudflare 的 7844 端口）。
请求转发阶段：外部用户访问分配给你的公开 URL 时，请求首先到达 Cloudflare 全球边缘网络，完成 TLS 握手、DDoS 防护和路由解析；随后，请求经由 Cloudflare 返回，通过该连接到达本地的 cloudflared，再由其转发至相应的 localhost 端口。
生命周期随进程终止：页面说明隧道随进程结束（Ends with the process）。当你在终端中断命令或终止 cloudflared 进程时，隧道即告结束，公网链接随之失效。
https://…trycloudflare.com
cloudflared → localhost:8000
主动建立加密出站连接
响应沿同一路径返回；终止 cloudflared 进程，临时隧道随之结束。
三步上手：从本地端口到公网链接
使用 Quick Tunnels 不需要登录或准备配置文件，完整过程只有三个步骤。
第一步是安装官方客户端 cloudflared。macOS 用户可以通过 Homebrew 直接安装：
brew install cloudflared
Windows 和 Linux 用户可以参考官方页面对应系统标签下的安装说明进行操作。整个安装过程不需要关联 Cloudflare 账户。
第二步是启动本地开发服务。以常见的前端工程或后端 API 为例，在日常开发使用的端口上启动本地服务：
npm run dev
假设本地服务已在 http://localhost:8000 正常运行。
第三步是开启隧道。新开一个终端窗口，执行如下命令：
cloudflared tunnel --url http://localhost:8000
终端建立连接后，会返回一个随机的 trycloudflare.com 子域名，例如官方示例中的 https://quiet-marble-otter.trycloudflare.com。直接复制这个网址发送给同事，或者填入第三方服务的 Webhook 配置项，外部请求就会自动流转到你的本地开发环境。
面向 Coding Agent 与脚本的机器可读输出
除了人类开发者手动复制链接，Quick Tunnels 还针对现代自动化工作流与 AI 编程代理（Coding Agent）进行了适配。
当编程代理或自动化脚本在本地启动服务后，如果需要把页面交由外部浏览器运行测试或提供公网端点，程序需要能够自动提取生成的公网 URL。
只要在启动命令后增加 --output json 参数，即可让脚本或 Agent 取得机器可读的运行结果：
cloudflared tunnel --url http://localhost:8000 --output json
官方页面在此处展示的可视化示例字段如下：
Tunnel ready https://quiet-marble-otter.trycloudflare.com
location: lhr01 · protocol: quic
页面上展示的 Tunnel ready、公网 URL、位置代码（如 lhr01）和连接协议（如 quic）是可视化示意字段，不是可以照抄的 JSON 样例。自动化脚本应直接解析 --output json 返回的结构化数据，不要依赖给人看的日志文本。这个隧道只在进程运行时生效，任务结束后停止进程即可，无需另行清理。
核心边界：为什么不能用于正式生产
Quick Tunnels 带来了极高的启动速度，但官方文档对其定位非常清晰：仅用于开发测试（For local development / testing only）。在将其引入日常工具链时，必须清楚它的技术限制与安全边界。
不支持 SSE（Server-Sent Events）：官方文档明确标注 Quick Tunnels 不支持 SSE。所谓 SSE，是指服务器保持连接、持续向浏览器推送一串事件的方式，常见于逐步返回内容的场景。如果本地服务依赖这一方式向外推送数据，则不应选用 Quick Tunnels。
同时处理的请求数限制为 200：官方文档明确说明 Quick Tunnels 有 200 concurrent request limit，即同时处理的请求数限制为 200，而非连接数。一旦需求可能接近该量级，或者需要进行压力测试与承接公开访问流量，就不应选择 Quick Tunnels。
随机子域名与访问控制配置边界：Quick Tunnels 会生成随机的 trycloudflare.com 子域名，页面没有提供自定义域名或访问控制的配置步骤。若需要稳定、长期、可管理的公开主机名，官方要求改为正式 Tunnel。
如果需要将内网服务稳定、长效地对外发布，必须转向正式的 Cloudflare Tunnel：
前置条件：正式 Tunnel 需要注册 Cloudflare 账号，拥有托管在 Cloudflare 上的域名，并在能访问互联网的服务器或虚拟机上安装 cloudflared。
路由配置：正式 Tunnel 通过控制台或 API 创建，并配置公开主机名（hostname）到本地服务的路由映射。
防火墙端口要求：在处于严格企业防火墙后的服务器上部署正式 Tunnel 时，需要确保服务器能向外访问 Cloudflare 的 7844 端口。
工具选型判断清单
判断是否应该使用 Quick Tunnels，可以依据以下信号进行快速决策：
适合选用的场景：
- 分享预览：向远程协作者或在外部移动设备上临时展示本地前端界面，无需复杂配置即可通过公网链接预览。
- 接收 Webhook：联调外部平台的 Webhook 事件推送，需要一个临时公网端点进行接收。
- 运行浏览器测试：自动化测试工具需要跨网络访问本地运行的服务以完成端到端测试。
- 给 Coding Agent 提供端点：本地运行的自动化脚本或编程代理需要自动获取并读取一个真实的公网访问入口。
不应选用的场景：
- 依赖 SSE 的服务：服务需要保持长连接持续向浏览器推送事件（官方明确不支持 SSE，无法正常建立该通信）。
- 并发请求接近 200、压测或承接公开流量：官方限制同时处理的请求数为 200（200 concurrent request limit），若需求接近该上限，或用于接口压测与公开流量，容易触发限制。
- 生产环境与需固定域名的长期服务：需要长期稳定运行、固定域名与可管理路由的场景（官方要求生产环境创建正式 Tunnel）。
- 包含未隔离敏感数据或无应用层鉴权的服务：公开 URL 会让外部请求直接穿透至本地服务；基于网络路径安全操作判断，只应暴露本来就愿意被该测试对象访问、且应用自身已做必要鉴权与数据隔离的内容（此项为开发者安全操作建议，并非 Cloudflare 产品的额外安全承诺）。