我没有把任何一台设备交给 Tailscale，却运行着它的魔法网络

Tailscale 是大家最常推荐的私有外部访问服务之一。它这么受欢迎，不光因为免费，还因为让组网简单得有点犯规。你把设备加入 tailnet，转眼间它们就能互相通信，不需要任何多余的额外开销。

但有一点一直让我很在意。我 tailnet 的协同靠的是别人家的基础设施——Tailscale 的托管控制平面。我想弄清楚，如果把控制平面搬到自己拥有、自己掌控的环境里，这种 Tailscale 魔法还能剩下多少。

其实我并不需要 Tailscale

魔法并不在我原先以为的地方

Tailscale 是我刚开始折腾 homelab 时选的服务之一，到现在也还在用。配置起来简单到让人很难不心动。你只要在 Tailscale 上注册个账号，它会为该账号分配一个 tailnet，然后就搞定了。接下来，在你的设备上安装 Tailscale 客户端，并用同一个账号登录。你的设备一下子就能互相访问，完全不用在路由器上打洞。

从用户角度看，这像是单个产品在扛下所有繁重工作。但实际上它是两个部分：WireGuard 在底层负责加密网络，而 Tailscale 管理的控制平面负责身份、密钥、协调和路由。Tailscale 只是把两者打包成一个打磨得很精致的产品。你可能会想：“我们真的需要控制平面吗？”答案是：需要，不是因为它是唯一的方式，而是因为它更可靠。我甚至试过用原生 WireGuard 替代 Tailscale，但当时 CGNAT 让我打消了这个念头。

然后就轮到 Headscale 了。它是一个自托管的控制平面，用来替代 Tailscale 的协调服务器。对我来说，好处是我不用把它部署在自己的 homelab 里。它能舒舒服服地跑在一台用完就能扔的 VPS 上。你可能会想：“既然反正都得用 VPS，干嘛不干脆再装个 WireGuard 用呢？”你这么问没错，但 Headscale 最棒的地方是，你不用操心客户端 App。你还能继续用同一个 Tailscale 客户端，只换个协调服务器就行。

说到底，无非就是把协调层从 Tailscale 的基础设施搬到我自己的基础设施上。Headscale 让我能自己掌控协调层，又不用牺牲 Tailscale 客户端的体验。

Headscale 这部分可并不轻松

它可不是装上就能用

我手头已经有一台 Hetzner 的小型 VPS，配置是 2 个共享 vCPU、4GB 内存和 40GB NVMe 磁盘空间。我当时用它通过 Pangolin 托管自己的 ingress。对中小型 homelab 来说，这点资源绰绰有余。建议用双栈，也就是同时有公网 IPv4 和公网 IPv6；不过只有 IPv4 也照样能跑。Headscale 还建议为实际部署单独建一个用户，但我懒得折腾多个用户。

我翻出 Docker Compose 文件，像部署别的 Docker 容器那样把它部署起来。几分钟就启动跑起来了。默认情况下，Headscale 不自带 UI，所以只能靠命令行操作。一开始用着倒没遇到什么问题。根据文档，只需要三条命令——一条创建用户，另一条生成认证密钥，最后一条注册节点。可我一直没走到能创建任何东西那一步。API 就是连不上。

services: headscale: image: headscale/headscale:latest container_name: headscale restart: unless-stopped command: serve volumes: - ./config:/etc/headscale - ./data:/var/lib/headscale networks: - pangolinnetworks: pangolin: external: true

这台 VPS 已经装有 Pangolin，而 Pangolin 靠 Traefik 做反向代理。所以我以为加个 Docker 标签就能通过 Traefik 把 Headscale 暴露出去——结果一点动静都没有。原来 Traefik 根本没启用 Docker provider，所以它压根看不到这个容器。最后我没靠自动路由，而是在 dynamic_config.yml 里加了一段 router/service 配置，才把它修好。

headscale-router: rule: "Host(`headscale.example.com`)" service: headscale-service entryPoints: - websecure tls: certResolver: letsencryptheadscale-service: loadBalancer: servers: - url: "http://headscale:8080"

又处理了几个零碎的小毛病后，Headscale 终于跑起来了。我建了个用户，生成了认证密钥，又注册了几个节点，一切顺利。我跑了几次 ping 测试，延迟从 2ms 跳到了 100ms，但 0% 丢包才是我想要的结果。

docker exec headscale headscale users createdocker exec headscale headscale preauthkeys create --user --expiration 24htailscale up --login-server --authkey

这些操作全都是在命令行（CLI）里完成的。操作步骤其实挺简单，可对于本来就要管一堆其他服务的人来说，要记住每条命令还挺烦的。所以我就从 Headscale 的推荐列表里，部署了一个第三方管理后台。那这个后台给我的第一印象呢？感觉我压根没离开 Tailscale，几乎没差别。

但我还是舍弃了一些东西

便利是有代价的

我碰到的配置问题，全都是为了把控制平面跑起来，而不是重建它底下那层加密网络。除了一次性的控制平面搭建不算，后面用起来几乎跟 Tailscale 一样。

大多数设备，我要么用一条终端命令加进 Headscale 网络，要么把认证密钥填进手机 App。它们用起来都像是在 Tailscale 托管的控制平面下一样。Tailscale 主要是一个点对点网络，所以即使更换了协调服务器，客户端也根本察觉不到什么。

正如我在上一篇文章里多次提到的，自托管唯一简单的部分就是运行服务本身；可管起来比你想的麻烦多了。Tailscale 的托管控制平面帮你省掉了不少平时根本看不见的活儿。等你在自己的基础设施上托管控制平面时，数据还在你手里，但责任也就落到你头上了。

先不说持续要交的订阅费，服务在线、更新、备份、配置、恢复这些事，都得你一直盯着。而且 Headscale 并不能直接替代 Tailscale 的所有功能。有些功能没有，比如 Tailscale Funnel 和 Tailscale Serve；而像 MagicDNS 这类功能，还得额外配置。

对于像我这样不光管着几个容器，还管着好几套基础设施的人来说，再多加一个服务，跟从零开始的人比起来，负担没那么大。归根结底，不是说自托管就一定好、Tailscale 就一定差，而是在省事和掌控之间做取舍。

基础设施，你更信任谁家的？

Tailscale 的免费版挺大方，我们刚才体验的这些完全够用。用 Tailscale 唯一要付出的代价，就是得把所有设备托管到它的协调服务器上。如果你不介意这一点，在私有外部访问这块，Tailscale 是最好用的产品之一。但如果你的数据都放在别人家的基础设施上，这让你心里不踏实，Headscale 恰恰证明，这套“魔法”从来就不是 Tailscale 专属的。