Article
“我刚用 AI 做了一个超棒的网站，大家快来看看：http://localhost:3000”
这个是一个经常能看到的烂梗，但是也很简短的说明了一个痛点需求，如何把本地的网站让别人也能访问。
我之前的话，会写一篇具体的部署流程，教你怎么部署到 cloudflare、vercel、netlify… 但是今天我想教一个又快又好的方法，先看下面的流程：
一条命令把 localhost 变成公网地址
Quick Tunnel 是 Cloudflare 官方的临时隧道工具，命令行里的一个小功能，免费，不需要注册账号。
它做的事情只有一件：把跑在你电脑上的 localhost 服务，变成一个公网可以直接访问的 HTTPS 地址。 不用注册 Cloudflare 账号，不用有自己的域名，不用在路由器上开端口，运行一条命令，几秒钟后终端里会打印出一个随机的 *.trycloudflare.com 地址，发给任何人都能打开。
和以往解决这类问题的办法对比一下，差别更明显。老办法无非几条路：在路由器上做端口映射，暴露整台机器还受运营商限制；先部署一个临时预览环境，为了看一眼走一遍完整发布流程；用团队 VPN 或者传统内网穿透工具，注册账号、配置 token、处理确认页，一套下来兴致先没了一半。Quick Tunnel 把这整套流程压缩成了一条命令，用完即走，什么都不留下。
怎么用：三步，一分钟
第一步，安装 cloudflared，就是 Quick Tunnel 的客户端。macOS 用 Homebrew：
brew install cloudflaredWindows 用 winget：
winget install --id Cloudflare.cloudflaredLinux 各发行版的包管理器基本都有，也可以直接去 GitHub Releases 下载二进制文件。安装不需要登录任何账号。
第二步，把你的项目在本地跑起来，任何框架任何端口都行。比如一个 Vite 项目：
npm run dev
# 此时服务在 http://localhost:3000第三步，开隧道：
cloudflared tunnel --url http://localhost:3000几秒钟后，终端会打印出这次分配的随机公网地址，长这样：
https://xxx-xxx-xxx.trycloudflare.com把这个地址发给同事、发到手机上、贴给 AI Agent，对方打开的就是你本机 localhost:3000 上的页面，自带 HTTPS 证书，锁是绿的。
关掉终端进程，隧道就消失了，下次再跑会分配一个新的随机地址。它天生就是给临时预览用的，不是给正式部署用的。
它是怎么做到的
原理值得花一段讲清楚，因为这是它和传统端口映射的本质区别。
cloudflared 启动后，从你的电脑向最近的 Cloudflare 边缘节点发起一条出站连接。注意方向，连接是由你的机器主动发起的，外面的请求从来没有直接碰过你的端口。所有访问 *.trycloudflare.com 地址的请求，会先打到 Cloudflare 全球 335 多个城市的边缘节点，经过 TLS 加密和 DDoS 过滤，再沿着这条出站连接回到你本机的服务。
也就是说，你的电脑全程没有开放任何入站端口，防火墙一个规则都不用改，家里、公司、咖啡馆的网络环境通通无所谓。官网给的数字是大约 3 秒出地址，实际体验确实就是敲下回车看两行日志的功夫。
给 AI Agent 用的新定位
- 官网：try.cloudflare.com
- 客户端开源地址：cloudflare/cloudflared
- 官方文档：Quick Tunnels 文档（最近一次更新是 2026 年 4 月）
- Quick Tunnel 本身 2021 年就有了，最近官网首页翻新，定位明显转向了开发者和 AI Agent 场景。
这次翻新的首页最值得注意的是一句话：Now with JSON output for coding agents，配合一整块 Built for the agent era 的版面。Cloudflare 明确把 Quick Tunnel 往 Agent 工作流里推了，官网原话是 Your agent needs a URL, not a laptop。
具体给了三个能力：
一是结构化输出。隧道的地址、边缘节点、健康状态可以直接以 JSON 格式打到 stdout，Agent 拿到就能解析，不用再去写正则从人读的日志里扒 URL。写脚本做过这件事的人都知道这一步省了多少脆弱代码。
二是 Webhook 就绪。Stripe、GitHub 这类平台的回调需要一个真实可访问的 URL，本地开发时通常只能用 mock。现在把回调地址指到 Quick Tunnel 的公网地址，测试的就是真实的回调链路。
三是随进程销毁。隧道跟着 cloudflared 进程走，进程结束隧道就没了，不存在忘记回收的暴露面。对自动化脚本和 Agent 来说，这比手工管理一个长期隧道省心得多。
对玩 Vibe Coding 的人来说这三个能力正好都用得上。让 Agent 自己起个本地服务、拿到公网地址、跑截图和验收，这一整套现在一条命令就串起来了，中间不需要人去注册任何账号。
用之前要知道的限制
官方文档上写明 Quick Tunnel 只用于测试和开发，别拿来跑生产。具体限制有这么几条，都来自官方文档：
- 并发请求有硬上限，目前在途请求超过 200 个会直接返回 429 状态码
- 不支持 Server-Sent Events，做流式输出的项目要注意
- 每次运行分配的地址都是随机的，进程一关就失效，没法固定
- 没有 SLA 保证，Cloudflare 会在这些免费隧道上试验新特性
- 如果
.cloudflared目录里存在config.yaml配置文件，Quick Tunnel 会跑不起来，需要先把那个文件改名挪走
如果需要固定域名和更高额度，注册一个 Cloudflare 账号，用正式版的 Cloudflare Tunnel，个人用也是免费的，这是官方给出的升级路径。
和其他预览方案比一下
先把两类东西分开：Quick Tunnel、ngrok 解决的是“把此刻正在本机运行的服务暴露出去”；Vercel、Netlify 解决的是“把代码构建并部署成一个可持续访问的预览环境”。它们都能发出链接，但不是同一条流程。
| 方案 | 从本地到链接的流程 | 适合什么情况 | 需要先准备什么 |
|---|---|---|---|
| Cloudflare Quick Tunnel | 本地启动项目 → 跑一条 cloudflared 命令 → 复制链接 | 现在就想让别人看你电脑上正在跑的页面；联调 Webhook | 安装 cloudflared；不用账号、域名或 Git 仓库 |
| Vercel Preview Deployment | 提交代码或用 CLI 部署 → 云端构建 → 分享预览链接 | 已接入 Git 的前端项目；需要按提交、PR 反复评审 | Vercel 账号；项目配置和一次构建部署 |
| Netlify Deploy Preview | 提交 PR/MR → 云端构建 → 分享预览链接 | 团队在 PR/MR 里看改动、留反馈 | Netlify 账号、关联 Git 仓库和部署配置 |
| ngrok | 本地启动项目 → 运行 ngrok → 分享链接 | 需要更完整的隧道能力和长期工作流 | 账号和认证配置 |
| localtunnel、serveo 等 | 本地启动项目 → 运行客户端 → 分享链接 | 偶尔临时试一下，能接受社区服务的不确定性 | 通常不需账号，但可用性取决于服务本身 |
所以不是“Quick Tunnel 能不能替代 Vercel、Netlify”。如果页面已经能构建、希望每个 PR 都有可回溯的预览链接，Vercel 和 Netlify 更合适；它们会在云端重新构建，链接不依赖你的电脑继续开着。Vercel 的每次部署都会生成独立 URL，Netlify 也会为 PR/MR 自动生成 Deploy Preview。 Vercel 官方文档 Netlify 官方文档
反过来，如果你还没推代码、项目依赖本地环境，或者只是想把眼前这个 localhost:3000 给同事、手机或 Agent 看一眼，先开 Quick Tunnel 最省事。它不是部署，也不替你保存构建产物；终端一关，链接就失效。
我的建议很简单：把 Quick Tunnel 放在“本地验证和临时分享”这一步，把 Vercel、Netlify 放在“代码提交后的持续预览”这一步。两者接起来，才是一条完整流程。
最后
本地开发和公网之间的浏览和测试本来就是一个麻烦的环节，你改完想给别人看看，至少先得部署一遍。
Quick Tunnel 把这一步压缩成了一条命令。工具本身不新，五年前就有了，但这次翻新把 JSON 输出、Webhook、随进程销毁这些能力补齐之后，它从一个开发者的临时小技巧，变成了 Agent 工作流里顺手的一块积木。
这类工具可能用不上，但是需要的时候就体现其价值所在了，所以建议现在就装上 cloudflared，等下次需要的时候，一分钟就能解决这个问题。
我是 Rico，感谢阅读！
