【VPS 进阶玩法精选 032】用 Headscale 在 VPS 上自建 Tailscale 控制端：零信任组网实战

延伸阅读

更多相关攻略推荐：低配 VPS 也能秒开网站：Cloudflare 优化、Redis 、用几台便宜 VPS 组 k3s / Docker Swarm 容器集、2026 用 VPS 组异地私网：Tailscale / ZeroT、教你看懂 %st 乱飙！深入揭秘 VPS 厂商的 CPU 偷窃（St、【发行版选型 10】如何选择合适的 Linux 发行版。

什么是 Headscale？和 Tailscale 到底什么关系

先把这个最容易搞混的点说清楚：Tailscale 本质是一套基于 WireGuard 的零配置 Mesh VPN。它真正的隧道（数据面）走的是 WireGuard，设备之间点对点直连，速度很快；但决定「谁能连谁、密钥怎么发、节点清单在哪」的那个协调服务器，是 Tailscale 公司闭源托管在自己云上的。换句话说，你的设备拓扑、连接记录、ACL 策略，其实都保存在 Tailscale 的服务器里。

Headscale 干的事，就是把这个闭源的控制平面用开源方式重新实现了一遍（MIT 许可证，项目名 juanfont/headscale）。它只替换「协调层」，你的手机、电脑、路由器上装的还是官方 Tailscale 客户端。流量依然是设备间 WireGuard 直连，不经过 Headscale 服务器。Headscale 只负责密钥交换、节点注册、下发网络地图和 ACL。所以一句话总结：Headscale = 用官方 Tailscale 客户端 + 你自己的协调服务器。

这套项目到 2026 年中已经相当成熟，GitHub 星标约 41,000+，稳定线在 v0.28.0（2026-02-04 发布），年中已进入 v0.29.x 阶段。对个人的 homelab 和小团队来说，完全算生产可用了。

为什么要自建控制端

第一个理由最实在：隐私和数据主权。设备拓扑、连接日志、ACL 全部留在你自己的基础设施里，不去第三方 SaaS。做 GDPR 或合规场景的朋友，这一点几乎是无法绕开的。

第二个理由：设备数量没有上限。Tailscale 免费档在 2024 年后放宽到 100 台设备、3 个用户，但终究有天花板；Headscale 对设备和用户数完全没有限制，你想接多少接多少。

第三个理由：没有订阅费。Headscale 本身免费，你只要承担一台 VPS 的成本，通常每月 3 到 10 美元就够常年跑。对比 Tailscale 高级套餐动辄按人/按设备收费，长期下来省得不是一点半点。

第四个理由：可控、可审计。密钥、注册流程、策略文件全捏在自己手里，适合把基础设施当核心资产的开发者和小企业。当然要诚实地说一句：代价是你失去了官方那套图形管理后台，以及一部分最新 SaaS 特性（后面会列）。如果你就想要最省心、不想自己运维，直接用 Tailscale 官方 SaaS 也完全没问题。

一台 VPS 就够了：配置与成本

很多人被「自建服务器」吓到，其实 Headscale 对配置要求极低。官方和多篇 2026 年教程（itprotutorials、serverspace、rdp.sh 等）一致给出的最低配置是：1 个 vCPU + 512 MB 内存。原因很简单，控制平面只做协调，不承载任何数据流量，资源占用小到可以忽略。

磁盘方面，它用 SQLite 数据库，数据量从几 MB 到几十 MB 不等，给 10 GB 起步就绰绰有余。带宽更不用操心，只有客户端注册和心跳会经过控制端，日常几乎是零。你需要的一个硬性条件是：这台 VPS 必须有一个公网 IP，并且你手里要有一个能指向它的域名。因为 Tailscale 客户端强制要求通过 HTTPS 连接控制平面，证书签发需要真实域名。所以家里 NAT 后没公网 IP 的机器不太适合直接做控制端（除非你做端口转发加动态 DNS）。

正因为如此，Headscale 跟我们常推荐的廉价 VPS 完美契合。RackNerd、CloudCone、Vultr 这类每月 2 到 10 美元的 KVM 机器，跑它常年在线毫无压力。再加上 Docker + Docker Compose、Caddy 或 Nginx 反代（处理 TLS）、Let's Encrypt 自动证书，一套标准组合就齐了。

实战部署：Docker + 域名 + 反向代理

下面走一遍标准流程。先建目录 /opt/headscale/{config,data}，把官方的 config-example.yaml 下载下来。这里有几个关键配置项要改对：server_url 设成你的域名（例如 https://hs.yourdomain.com）；listen_addr 设为 0.0.0.0:8080；ip_prefixes 用 100.64.0.0/10（这是 Tailscale 的 CGNAT 网段，别改）；dns.magic_dns 设 true；base_domain 设成另一个子域（例如 tailnet.yourdomain.com），注意它必须和 server_url 的主机名不同，且都是你控制的域；database 用 sqlite3。

docker-compose.yml 里用 headscale/headscale 镜像。这里有个强烈建议：固定具体版本 tag，比如 0.28.0，而不是用 latest。社区里有一半「升级后起不来」的惨案，都是因为 latest 在 minor 版本升级时悄悄改了 schema。把 config 和 data 两个卷挂上去，暴露 8080 端口即可。

反向代理用 Caddy 最简单，一行 Caddyfile：hs.yourdomain.com { reverse_proxy headscale:8080 }，Caddy 会自动申请和续期 Let's Encrypt 证书。用 Nginx 的话需要自己配 Certbot。防火墙记得放行 80 和 443（TLS），如果自建 DERP 的 STUN 要开 UDP 3478，而最常被忽略的是：客户端之间 WireGuard 直连还需要放行 UDP 41641。

服务起好后，建用户和预授权密钥：先 headscale users create myuser，再 headscale preauthkeys create --user myuser --reusable --expiration 24h。拿到密钥后，节点接入就很简单了。

把设备拉进 Mesh：节点接入与组网

在任意设备安装官方 Tailscale 客户端，执行：tailscale up --login-server https://hs.yourdomain.com --authkey 你的密钥。移动端（iOS/Android）在 App 里填自定义协调服务器 URL 就行。整套体验跟用官方 Tailscale SaaS 几乎没区别，只是登录时跳到你自己的服务器。

接入之后，最常用的几个能力要会用。Subnet Router（子网路由）能直接把家里整段局域网（比如 192.168.1.0/24）暴露给 mesh 里的其他设备，这样你在公司也能访问家里的 NAS、路由器、摄像头。Exit Node（出口节点）可以把某台家庭或办公室设备当成出网网关。MagicDNS 让你直接用主机名互访，不用记 IP。ACL 用 HuJSON 语法（和 Tailscale 完全一致），可以基于用户、标签、端口做细粒度访问控制，建议用标签（如 tag:server）而不是用户来写规则，长期更干净。

校验也很简单：客户端跑 tailscale status 或 tailscale ping，服务端跑 headscale nodes list，看节点是不是都上线了。

Headscale vs 手动 WireGuard：该怎么选

很多人会问：我都装了 WireGuard，为什么不直接手写配置？这里给个对比。手动 WireGuard 每对端要手配密钥和配置，大概 10 到 15 分钟一对；Tailscale/Headscale 每设备约 2 分钟，服务端首次部署 30 到 60 分钟。密钥管理手动的要自己生成、分发、轮换，Headscale 全自动。NAT 穿透上，手动方案至少需要一端有公网 IP 或做端口转发，Headscale 内置 DERP 中继加 STUN，自动打洞。节点发现手动要逐节点配，Headscale 自动 Mesh。ACL 手动靠 iptables/nftables，Headscale 用服务端策略文件。

延迟方面，手动 WireGuard 是内核级，最小；Headscale 直连时同样最小，但走 DERP 中继会多 20 到 50 毫秒。一句话取舍：节点少、要极致性能或零依赖、甚至是气隙/合规禁第三方环境，选手动 WireGuard；3 台以上设备、想免去端口转发的麻烦、要策略化 ACL 和远程访问家里设备，选 Headscale（或直接用 Tailscale SaaS）。Headscale 比纯 Tailscale 多出的代价是：你要自己运维控制端，而且没有图形管理界面。

常见坑与运维要点

第一，必须 HTTPS。Tailscale 客户端强制控制端走安全连接，裸 HTTP 或自签证书会直接注册失败，所以反代加有效证书是硬性要求。

第二，端口别漏。除了 8080/443，客户端间直连还要 UDP 41641，自建 DERP 要 UDP 3478。只开 80/443 会导致部分节点连不上。

第三，版本错配。Headscale 需要追 Tailscale 客户端的协议版本（capver），服务端旧、客户端新会连接失败，两端都要及时更新。

第四，跳版本升级是社区头号雷区。0.x 阶段每个 minor 都可能改配置字段或做数据库迁移，必须逐版本升（0.25 到 0.26 到 0.27 到 0.28），且升级前务必备份 SQLite。

第五，控制端要「永远在线」。现有隧道有约 5 分钟心跳宽限，但新建隧道和 ACL 变更在 Headscale 宕机期间无法生效。把它当关键基础设施，定时备份数据库，做恢复演练。

第六，没有官方 GUI。一切靠 headscale CLI。社区有 headscale-ui、headplane 这类第三方前端，但多一个部件多一份维护。超过 3 名运维建议上 headplane。另外控制端公网暴露有攻击面，建议加 fail2ban 或 CrowdSec，管理操作尽量 SSH 进服务器执行。

还有两点要诚实交代：维护者官方其实不鼓励用 Docker/反代跑 Headscale（README 明确写了 do not support nor encourage），但社区普遍部署成功，你照本文做没问题；默认用的还是 Tailscale 公共 DERP，走中继的流量元数据仍经过 Tailscale 服务器（加密但可见），想彻底自托管需要额外一台机器自建 derper。

适合谁 & 不适合谁

Headscale 最适合：重视隐私、想要数据主权的个人和小团队；设备多、要免 NAT 配置远程访问家里设备的 homelab 玩家；想摆脱 Tailscale 订阅费、又不想回到手写 WireGuard 麻烦的人；小团队想自建零信任组网替代付费档。

不太适合：想要官方图形后台和一键支持的人；需要 Funnel、Serve、Tailnet Lock（签名节点）、网络流量日志、App Connectors、Services 服务发现、Mullvad 出口节点这些最新 SaaS 特性的人（这些 Headscale 暂时做不到，继续用 Tailscale 官方更合适）；50 人以上的大团队，因为 CLI/OIDC 运维成本会明显上升，那时可以评估 NetBird 这类全开源方案。

典型场景清单给你参考：异地多地点设备互访、远程访问家里 NAS/路由器/摄像头、移动端安全访问内网、把家里设备当出网出口、小团队替代 Tailscale 付费档、甚至设备间 P2P 打游戏（延迟低）。综合来看，一台每月几美元的廉价 VPS，就能换来一套完全属于自己的零信任组网，性价比相当高。

💡 延伸阅读：关于架构与基础设施的更多深潜指南，请前往 VPS 主题导读中心 (Hub) 获取全盘策略。