Headscale：把 Tailscale 的控制面搬回自己机器

它替代的是什么

Tailscale 的组网分两层：控制面负责设备注册、密钥分发、ACL 下发；数据面是 WireGuard 直连或 DERP 中继。Headscale 只重写控制面——客户端仍然是官方的 Tailscale，账号体系换成你自己的。

项目 44,911 star，BSD-3-Clause，当前版本 0.29.5。对「不想把设备清单交给第三方」的人来说，这是最省事的路径：客户端不改，服务端自建。

部署：一个容器加一份配置

services:
  headscale:
    image: headscale/headscale:0.29.5
    container_name: headscale
    restart: unless-stopped
    volumes:
      - ./config:/etc/headscale
      - ./data:/var/lib/headscale
    ports:
      - "127.0.0.1:8080:8080"
    command: serve

配置里最关键的是 server_url，必须写成客户端实际访问的 HTTPS 地址；写错会表现为「登录链接打不开」或「节点一直离线」。数据库默认 SQLite，小规模够用，规模上来再换 Postgres。

控制面必须走 TLS。可以自己签发，也可以放在反向代理后面；但不要让 8080 直接暴露到公网。

加节点的流程

# 服务端生成预授权密钥
docker exec headscale headscale preauthkeys create --user 1 --expiration 24h

# 客户端登录
tailscale up --login-server https://hs.example.com --authkey <key>

不用预授权密钥的话，客户端会打印一个注册链接，你在服务端执行 headscale nodes register 确认。两种方式都行，前者适合批量，后者适合临时。

ACL 是它真正的价值

默认策略是「全部互通」，这在多设备场景下并不安全。用策略文件按标签划分：

{
  "acls": [
    { "action": "accept", "src": ["tag:laptop"], "dst": ["tag:nas:443,22"] }
  ]
}

配合 --advertise-tags 给节点打标签，就能做到「笔记本只能访问 NAS 的 443 和 22，访问不了其他设备」。这套模型比防火墙规则更贴近「人」和「设备」的关系。

子网路由与出口节点

家里有一网段设备（打印机、摄像头）不能装客户端，就让一台常开机器做子网路由：--advertise-routes=192.168.1.0/24，服务端批准后，其他节点就能直接访问该网段。

出口节点（exit node）则把所有流量经某台机器转发，适合在外连公共 Wi-Fi 时使用。两者都要求服务端显式批准，不会自动生效。

几个需要提前知道的限制

• 版本匹配：客户端与控制面的协议有兼容窗口，升级前看 release notes；
• 非官方支持：出问题只能看文档和 issue，别指望官方客服；
• DERP 中继：NAT 打洞失败时会走中继，自建 DERP 才能保证中继也在自己手里；
• 备份：db.sqlite3 和 private.key 一起备，丢了等于所有节点要重新注册。

我的判断

Headscale 适合「设备不多、但不想被第三方托管」的场景：家庭、小团队、几台 VPS。它的复杂度集中在前期的 TLS 和 ACL，配好之后几乎不用管。

如果只是三五台设备互相访问，官方 Tailscale 的免费额度足够，自建的收益主要是「控制权」而不是「功能」。这一点想清楚，再决定要不要动手。

延伸阅读

• Authelia 与 Authentik 怎么选
• 反向代理的三个原生参数