Hacker News 中文摘要

RSS订阅

Cloudflare 推出 Quick Tunnels -- Cloudflare Quick Tunnels

原文链接 | HN讨论 | 2026-09-19 01:32:07

Cloudflare 的快速隧道（Quick Tunnels）可免费、安全地把正在构建的一切发布到公网。无需创建账户、配置文件或等待，一条命令即可让本地应用上线。它会自动启用 HTTPS，提供 DDoS 防护，不在本机暴露端口，并把流量经由 Cloudflare 全球边缘网络转发。安装 cloudflared 后，在任意端口运行本地 Web 服务或 API，执行 cloudflared tunnel --url http://localhost:8000，再把生成的 trycloudflare.com 预览链接分享给团队。

正文

为你构建的一切提供免费安全隧道

通过 Quick Tunnels，几秒内即可在全球预览和发布创意。单条命令就能将本地应用部署到互联网。

即时设置

一条命令上线。无需注册账户、配置文件或等待。

默认安全

自动 HTTPS、DDoS 防护，本机无暴露端口。

全球网络

流量经 Cloudflare 边缘网络路由，实现快速可靠的全球连接。

安装 cloudflared

从 Cloudflare 面板、包管理器或 GitHub 下载命令行工具。Quick Tunnels 无需登录。

运行本地应用

在任何端口（如 localhost:8000）启动 Web 服务器或 API，兼容你已有的工具。

创建隧道

一条命令启动安全入口，Cloudflare 负责证书、路由与 DDoS 防护。

cloudflared tunnel --url http://localhost:8000

分享链接

将生成的 trycloudflare.com 预览 URL 发给团队，从设计评审到自动化 QA 加速每次反馈。

评论

社区整体认可「不注册、不部署就能把本机服务暴露出去」的便利，但批评集中在两处：落地页质量糟糕到像随手生成的，以及免认证隧道难免被滥用、隐私风险高。分歧主轴是——这究竟是个顺手的小工具，还是又一个把流量进一步推向 Cloudflare 的集中化隐患。

认为官网质量拉胯，像随手 vibe code 出来的

  • 多处细节被点名：首行副标题的字体颜色几乎与背景同色、暗色模式在 Firefox 下显示异常、文案被指充满 AI 味，还有人质疑「难道没人打开自己生成的产品页看一眼吗」（较多人） > 难道我们已经到了没人愿意打开自己生成的产品页面看一眼的年代？还是更糟——有人看过，然后说「行，就这样吧」。（@rplnt）
  • 顺带一条代表社区情绪的玩笑：有人说 Claude 在这页面上加班了。

认为它本质就是 Cloudflare 版 ngrok，做演示和临时环境很省事

  • 有人把它直接等同于 ngrok，也有人提到此前得自己手搓隧道；还有人关心配额是否比 ngrok 宽松，因为文档里没写限制（较多人） > 很喜欢，这很酷。我以前用 ngrok 做这种事，现在 Cloudflare 也提供就方便多了。（@nullbyte）
  • 有用户称自己的 AI 几天前就发现了它，用来跑一个临时记分小网站，体验不错（少数人）。

认为免费隧道必被滥用，至少该要求登录

  • 指出这类服务历史上长期被骗子等滥用，最终进黑名单而变得没用；有人见过节点拿已知 Cloudflare 站点伪装 hostname 指向临时隧道，因此主张至少要登录（较多人） > 这功能存在很久了，也被不少人滥用过。我认为至少应该强制登录。（@himata4113）
  • 另有担忧指向 agent：自动开隧道可能把最敏感、最私密或半成品应用直接暴露给全世界，除非跑在沙箱里（少数人）。

认为只适合短期演示，进生产要谨慎

  • 有经验称其隧道延迟方差向来很大，原本 30–50ms 到 EC2 的链路会变成 115–750ms；也有人担心它会蚕食自家付费服务，还有人希望有持久 URL 和桌面应用 SDK（较多人） > 对我们来说，他们的隧道延迟波动一直很大。比如本来到 EC2 是 30–50 毫秒，现在变成 115 到 750 毫秒。（@dangoodmanUT）
  • 服务条款也是障碍：官方不允许用隧道跑视频流，有人因此不能把它架在 Jellyfin 前面给父母看（少数人）。

担心流量进一步集中到 Cloudflare 手里

  • 随着 Cloudflare 体量变大，信任度在下降；这些好用的功能代价是大量流量都要穿过他们的系统（少数人） > 我用过 Cloudflare Tunnels，但最近对他们越来越大的体量信任度很低。（@aliasxneo）

认为 Tailscale、洋葱服务或纯 SSH 隧道更合适

  • 有人推荐洋葱服务：能力相同且由全球志愿者网络支撑，延迟虽高但对测试反而理想，能暴露非最优网络下的真实表现；也有人用 Tailscale 在手机上私密共享小应用，称 Cloudflare 的 Zero Trust 面板和 Warp 组合配置起来近乎不可能（较多人） > 如果你只是业余爱好者或测试服务的开发者，用洋葱服务更合理。它做的是同一件事，背后是全球志愿者网络。（@smalltorch）
  • 另有更轻的方案被提及：pinggy 只需一条 SSH 命令、无需安装，免费会话每小时一轮；no-ip 提供免费动态 DNS；开源隧道清单 awesome-tunneling 也被推荐（少数人）。

有价值的补充

  • Cloudflare 会泄露 DNS 记录，机器人能立刻扫到这些临时 URL，目前看不出是否或如何修复。
  • 免费隧道服务进黑名单的机制值得提前评估：滥用规模一旦上来，URL 的可达性会先于配额成为瓶颈。
  • 除了 HTTPS，隧道似乎已能承载部分非 HTTPS 流量，但文档说明含糊。
  • 官方 TOS 对视频流的限制更像「保留追究权利」条款，实际风险取决于用量，但它确实挡住了 Jellyfin 这类正当用法。
  • 想自建或换方案的话，awesome-tunneling 汇总了 frp、bore、ngrok 等开源/半开源选项，适合先做对比。