cloudflare/cloudflared

如果你已经把这个域名交给 Cloudflare 管理，又想把家里或内网机器上的服务对外开放，cloudflared 值得一试。它是连接 Cloudflare 网络的外连隧道守护进程，不是可以完全自建的反向代理。

解决什么问题

假设一台机器上跑着 Web 应用、SSH 或 RDP，你不想把它直接暴露在公网。传统做法是在防火墙上开端口、准备公网 IP，然后持续防守这个入口。使用 Cloudflare Tunnel 时，守护进程主动向外连接 Cloudflare，客户端请求先到 Cloudflare，再由它经隧道转发回你的源站。变化发生在入口这一步：客户端不再直连你的机器，公网入口变成 Cloudflare 网络，防火墙可以保持关闭。

有什么不同

这是一个由托管服务配合的连接器，而不是自带完整路由的隧道服务器。你需要先把域名加入 Cloudflare 账户并把域名服务器指向 Cloudflare，创建 Tunnel 后，可以通过 DNS 记录、Cloudflare 负载均衡或 WARP 私有流量把流量路由过去。认证和配置都围绕 Cloudflare 账户进行，控制面在你的机器之外。这就是核心取舍：公网暴露面更小、路由器配置更少，代价是依赖 Cloudflare 的账户、DNS 和网络。README 说源站可以保持“尽可能关闭”，这是产品表述，不是对源站安全性的独立验证。

客户端还支持通过 cloudflared access 处理 SSH、RDP 等第 4 层 TCP 访问。另一种方式是使用 WARP 客户端，让连接到隧道后方私有源站的用户不必在本机运行 cloudflared access。这会影响运维方式：一种要在每个访问者的机器上装命令行工具，另一种把访问管理放进 WARP 部署。无论选哪种，开始之前都有一些前置条件，下文会说明。

谁值得试

适合已经在 Cloudflare 管理域名的人，例如想把家庭实验室、内部管理后台或 SSH 主机通过公开域名访问，同时让源站防火墙保持关闭。托管控制面减少了需要自己维护的环节。不太适合想要完全不依赖 Cloudflare 账户或 DNS 托管的人，也不适合要求入口层完全跑在自己基础设施上的场景。如果只是想先验证隧道是否可用，文档提供了 TryCloudflare，可以先不添加网站就做测试，这让快速试用成为可能，而不必马上迁移整个域名。

使用条件与边界

README 明确说，使用前仍然需要先把网站添加到 Cloudflare并把域名服务器改为 Cloudflare。虽然现在做私有路由时可以不挂公开网站，但这条历史遗留要求仍然存在，是采用时最大的门槛：它不能当作任意域名上即插即用的本地代理。Tunnel 和路由主要在 Cloudflare 控制台与文档中配置，客户端只是连接器，不负责提供路由服务。

支持范围限定在最近一次发布一年内的版本，与功能可用性无关的破坏性变更也可能影响更旧的版本。这意味着升级节奏是日常维护的一部分，而不是装完就不管。项目提供独立二进制、Docker 镜像、Debian、RPM 与 Homebrew 包，也支持用 Go 和 Cap'n Proto 从源码构建。要注意这个仓库只是客户端，网络侧由 Cloudflare 提供，本地测试无法复现完整链路。请参考下载与升级说明，不要假设旧安装会一直受支持。

HotRepo 点评

HotRepo 只有一条带日期的观察：2026-10-27 进入过一次日榜，当时仓库有 16,292 颗星，当天增加 45 颗；只有一个记录日期，无法判断关注度是否持续。项目本身创建于 2017 年，客户端并不新。采用前建议先对照文档确认你的域名与 DNS 配置满足 Cloudflare Tunnel 的要求，因为是否已有可托管的域名，往往直接决定这类私有网络用户能否使用。