INDEX / NO.046 — 2026.08.24 — 工具实操

Tailscale：AI 开发者的异地组网神器与 Headscale 自建账号服务

把家里的 GPU 主机、云服务器和随身电脑连成一个虚拟局域网：从 Tailscale 上手、远程开发与屏幕共享，到 Headscale 自建控制面和安全边界。

微信公众号原文 ↗ ← 返回索引

做 AI 开发的，多半有这么个网络问题：家里的 GPU 机器、云上的服务器、随身的 MacBook 和手机，散在三个网络里。想 SSH 回家跑训练，想在外面访问只监听本机的 Jupyter 或 ComfyUI，想临时把 demo 发给别人看，都得各想办法。要么租公网 IP，要么用 frp 这类端口转发工具。配置繁琐，还留一堆暴露面。

Tailscale 解决的就是这件事：把散落各地的设备组成一个加密的虚拟局域网，设备之间优先点对点直连，不需要公网 IP，不需要在路由器上做端口映射。

先说结论：个人开发者，官方免费版就够用，额度对个人相当宽裕。Headscale 自建是给另一类人的：非要自己握着账号体系和控制面不可的。

tailscale

四步上手

以两台设备为例，一台 Linux 服务器，一台 MacBook。

第一步，装。macOS 和 Windows 从应用商店或官网装图形客户端；Linux 一行脚本：

curl -fsSL https://tailscale.com/install.sh | sh

第二步，登录。执行 tailscale up，会给出一个链接，浏览器打开后用 Google、GitHub 或微软账号授权。这个账号就是你的用户体系，管理端在 Tailscale 控制台（login.tailscale.com）。

Tailscale 登录页，支持 Google、Microsoft、GitHub 账号

第三步，每台设备重复一遍。所有设备登录同一账号后就在同一个 tailnet 里了。

第四步，验证：

tailscale status   # 列出所有节点和连接方式
tailscale ping 设备名称 # 测试到某台设备走直连还是中继

status 输出里，direct <ip:port> 是打洞成功，走了直连。relay "tok" 是在走东京的 DERP 中继，能通，但延迟高。tailscale ping 还可能看到 peer-relay：由网内设备做中继，通常比 DERP 快。它不是自动的，要管理员提前在一台常开设备上开中继端口、在策略里授权，网内设备打洞失败时才会优先用它。

到这里，从 MacBook 直接 ssh user@100.x.y.z 就能连上那台 Linux 服务器了，跟在一个局域网里没有区别。

macOS 客户端菜单栏界面：Connected 状态与设备 Tailscale IP

五个高频场景

场景一：远程 SSH 回家开发

最基础的用法。家里机器装上客户端，人在外面直接 ssh 它的 Tailscale IP 或 MagicDNS 名字；VS Code 的 Remote-SSH 也走这条路，远程连 GPU 主机写代码和在本地几乎一个手感。家里是宽带 NAT 没有公网 IP 也没关系，两边的 NAT 由协调服务器帮忙打洞穿透。这是它替代 frp 的核心场景：不用租 VPS 做中转、不用改路由器配置。

场景二：Subnet Router，访问整个家庭局域网

家里有些设备装不了客户端（打印机、NAS、路由器管理页）。挑一台常开的机器开子网路由，Linux 上要先开内核 IP 转发：

# Linux：开启 IP 转发
echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

# 通告家里整个网段
sudo tailscale set --advertise-routes=192.168.1.0/24

macOS 做子网路由不用手动开转发，通告时系统自动处理。路由通告同样要在控制台批准，之后你在外面就能直接访问家里 192.168.1.x 的所有设备，不用每台都装 Tailscale。

场景三：Exit Node，自建 VPN

把家里机器设为出口节点：

# 家里常开的机器（Linux/macOS）
sudo tailscale set --advertise-exit-node

控制台批准后，在外的手机打开 Tailscale App，在 Exit Node 菜单里选中家里那台机器；电脑端对应命令是 tailscale set --exit-node=<家里机器的IP>。

之后手机的所有流量都从家里出，等于自建了一个 VPN，在公共 Wi-Fi 场景下也多一层加密。

场景四：Serve 和 Funnel，分享本地服务

本地起的 Jupyter、Gradio、ComfyUI 或 Ollama 服务想给别人看，不用买域名配证书：

tailscale serve 3000   # 暴露给 tailnet 内部，自动配 HTTPS
tailscale funnel 3000  # 暴露到公网，自动分配 https://机器名.你的tailnet.ts.net

Funnel 自带域名和证书，做临时 demo 分享很好用。但注意：Funnel 地址对全公网开放，tailnet 的 ACL 管不到它。ComfyUI、Ollama 这类服务默认连登录都没有，Jupyter 虽然默认带 token 认证，分享场景里也常被人顺手关掉。直接 Funnel 出去之前，先确认服务自身有认证；只是分享给 tailnet 内部的话，用 Serve 就够。

场景五：远程桌面，替代 ToDesk、向日葵、TeamViewer

远程控制另一台 Mac，不用装第三方工具。macOS 自带的屏幕共享（系统设置 → 通用 → 共享 → 屏幕共享），本质是个监听 5900 端口的 VNC 服务。Tailscale 工作在网络层，两台 Mac 进了同一个 tailnet，5900 端口自然就是通的。控制端打开自带的”屏幕共享”App，填对方的 Tailscale IP 或 MagicDNS 名字就能连。Finder 侧边栏的自动发现靠 Bonjour，跨不过 tailnet，第一次得手动输地址。

要把它用顺手，三个前提：

  • 目标 Mac 要有一个带密码的本地账户，屏幕共享权限选”所有用户”或指定账户；
  • 能源设置里关掉睡眠（或 sudo pmset -a sleep 0），Mac 睡着就连不上了；
  • 认证用 macOS 账户，别开”VNC 显示程序可用密码控制”那个兼容选项，VNC 密码认证强度弱。

跟 ToDesk、向日葵、TeamViewer 比，这套组合的好处：打洞成功时设备直连、WireGuard 加密，不经过远控厂商的服务器；不用再注册一个远控软件账号（官方版本身也要用 Google 或 GitHub 登录，只是少一层）。代价也有：iPhone 和 iPad 没有自带 VNC 客户端，得买 Screens、Jump Desktop 这类 App。被控端如果是 Windows，同一个思路换成微软远程桌面 App（RDP，3389 端口），体验比 VNC 还好，注意 Windows 家庭版不能当被控端，要 Pro 或更高版本。

体验好坏也要看条件：两台都是 Apple Silicon、系统都在 macOS Sonoma 14 以上，连接时会弹出屏幕共享类型选择窗口，手动选 High Performance 才进高性能模式，走 UDP 5900-5902，有 30/60fps、立体声、HDR。官方建议一块 4K 屏预留 75 Mbps 带宽。这套方案对网络的要求和 Tailscale 的连接质量直接相关：直连时延迟通常更低，中高分辨率的远控体验更好；打洞失败走中继，高分辨率远控就可能受影响，具体取决于两端网络。硬件不满足，只能用 Standard 模式，能用，但就是标准 VNC 那个水平。

不是无条件免费

免费额度（2026 年 8 月定价页）：Personal 计划免费，6 个用户，用户设备数量不限。服务器、子网路由这类按标签注册的基础设施资源，免费给 50 个。个人用，基本花不完。

它是怎么工作的

Tailscale 底层是 WireGuard，整个系统分三层。搞清这三层，“流量到底走不走他的服务器”就有答案了：

控制面：Tailscale 官方的协调服务器。只负责设备认证、分发公钥和网络拓扑信息，不经手任何业务流量。

Tailscale 协调服务器分发公钥

数据面：设备之间直接建立 WireGuard 加密隧道。通过 STUN、ICE 这些标准技术做 NAT 穿透，大部分家用网络都能打洞成功，流量直连，不经过任何第三方。

Tailscale 点对点 mesh 网络，设备直连不经中心节点

DERP 中继：打洞失败的兜底（硬 NAT、企业防火墙场景），流量经由 Tailscale 的加密中继服务器转发。中继转发的是端到端加密后的流量，Tailscale 知道你在传数据，但看不到内容。

Tailscale 通过 DERP 中继转发加密流量

几个核心术语：

  • tailnet：由用户、设备和资源组成的私有网络；
  • 节点：加入 tailnet 的每台设备，各分到一个 100.x.y.z 段的固定 IP；
  • MagicDNS：自动给节点配主机名，ssh user@macbook 直接用名字，不用记 IP。

所以直连成功时，你的业务流量不经过 Tailscale 的服务器；打洞失败，会走 Peer Relay 或 DERP 中继，中继看到的也是加密后的流量。官方掌握的不只有在线状态、设备列表和 IP 变动。日志文档还写明，客户端会发送运行与连接日志，其中包括设备间 TCP/UDP 连接的打开和关闭事件。介意这些信息继续交给官方，看后面 Headscale 那一节。

不想用他的账号和节点：Headscale 自建

Tailscale 的控制面是闭源云服务，DERP 中继也默认用官方的。不想把设备元数据交给第三方、想自己管账号的，看 Headscale：它是控制服务器的开源实现，客户端仍用 Tailscale，控制面改由自己维护。

搭建

需要一台有公网 IP 的 VPS。部署方式上，官方支持的是二进制包和 DEB 包；项目也提供容器镜像，但明确声明 Docker 部署不在官方支持范围，出问题靠社区帮助。装好后建用户和预授权密钥：

headscale users create myheadscale
headscale preauthkeys create --user myheadscale

客户端登录时把服务器指向自己的实例：

tailscale up --login-server https://hs.example.com --authkey <KEY>

用户体系不再走 Google 或 GitHub SSO，用户在 Headscale 里自己管理，也可以接自己的 OIDC。

DERP 中继同样可以收回来。Headscale 内嵌了一个 DERP 服务器，配置里把官方默认列表清空：

derp:
  server:
    enabled: true   # 启用 Headscale 内嵌 DERP
  urls: []          # 清空默认的 Tailscale DERP 列表

这样打洞失败时的兜底中继，也跑在你自己的 VPS 上。日志的事比想象的好一点：Headscale 默认就会指示客户端关闭向 Tailscale 日志服务器的上报，客户端连上后生效。想把连接前的启动日志也断掉，才需要给 tailscaled 加 --no-logs-no-support 参数或设 TS_NO_LOGS_NO_SUPPORT 环境变量。平台差异不小：Windows 只能用环境变量；macOS 只有开源命令行版支持，App Store 版和 Standalone 版关不掉。关掉后官方也不再为这台设备提供技术支持。

功能兼容性

Exit Node、Subnet Router、MagicDNS、ACL、Tailscale SSH、Taildrop 这些核心功能都能用。Serve 的 HTTP 转发可以工作，但缺少官方 Tailscale 那套原生自动 HTTPS 和证书能力，相关工作由 #1921 和 #2527 跟踪；Funnel 目前不支持（#1040）。

客户端差异，自建前先看这里

这是自建方案最大的实际成本：

  • Linux：官方客户端，--login-server 直接用，最顺畅；
  • Android：官方 App，设置里填自建服务器地址；
  • iOS：App Store 官方客户端内置自定义协调服务器选项；
  • macOS：图形客户端直接支持，在设置的账户管理里添加账户时填自建服务器地址即可，命令行 --login-server 也可用；
  • Windows：官方客户端即可，CMD 或 PowerShell 里执行 tailscale login --login-server <地址> 完成登录。

安全风险，自建前先想清楚

自建改变的不只是成本，还有安全模型。核心问题：那台 Headscale 服务器被攻破会怎样？

WireGuard 加密保护的是流量，不保护成员资格。谁能进网络、ACL 是什么，协调服务器说了算，不管是官方的还是你的。Headscale 被攻破，攻击者就能往你网里塞自己的节点、改 ACL 给自己开权限，等于整个 tailnet 的门被配了把新钥匙。节点之间的流量仍是端到端加密，他解不开已有节点之间的通信。但进了网能碰到什么，就看你 ACL 写得多严了。

官方和自建在这里有个真实差距：官方有 Tailnet Lock，主动启用后，新节点加入要指定签名密钥的加密签名，协调服务器被攻破也塞不进恶意节点（这个功能默认不开，要自己动手启用）。Headscale 不支持，功能请求（GitHub issue #1307）到发稿时还是 open。这不是少个功能的事，是防线缺了一块。

周边生态也要留心。常见的第三方 Web UI Headplane，今年刚修掉一个路径穿越加越权漏洞（CVE-2026-46484）。核心没洞、周边先把口子开了，自建常常这么翻车。Headscale 自己也说得很直白：两名维护者都有全职工作，项目定位是 homelab 和自托管爱好者，不是企业软件。官方 Tailscale 有安全公告页和响应流程，这层差距摆在那。

对应的运维纪律：

  • preauth key 用一次性、短过期的，长期可复用的 key 是高危品；
  • metrics 和 gRPC 端口只绑 127.0.0.1，不暴露在公网；
  • 不建议把 Headscale 跑在自己 tailnet 的节点上。官方明确说这种部署不受支持，可能影响子网路由、中继节点和 MagicDNS；
  • 跟着 release 更新，修复滞后的窗口期没有别人给你兜底。

我的看法：自建是把”信任 Tailscale 公司”换成”信任自己的运维水平”。tailnet 里只跑个人开发流量，做好上面几条，风险可控。要在里面过生产凭据和公司资源，Tailnet Lock 的缺失就是硬伤，这种建议留在官方版。

自建的代价

一台公网 VPS 是前提，控制面和中继都跑在上面。这台机器挂掉，缓存里已有的连接可能还能继续，但节点建立新连接、密钥刷新、策略更新、新设备加入和路由批准都会受影响；如果内嵌 DERP 也在这台机器上，需要中继的连接也会断。运维责任全在你自己。另外，官方控制台的一些便利没有了，比如 *.ts.net 域名的自动 HTTPS。换来的是控制面和兜底中继完全可审计。

如果连 Headscale 都不想跑，还有两条路：纯 WireGuard，零第三方依赖但密钥和端点全手工维护，适合两三台固定设备；Netbird，开源 mesh 组网，控制面和 relay 都可自托管，覆盖主流桌面和移动平台，但它不能用 Tailscale 的客户端，两边不通用。

怎么选

我的判断分三档：

  1. 轻度使用，设备分散在两三个网络：直接用官方免费版，配置成本很低，免费额度对个人几乎无上限，省下的折腾时间远大于元数据暴露的顾虑。
  2. 介意元数据交给第三方：Headscale 自建。有合规要求的读者注意：自建只是把数据收回到自己手里，不自动等于满足合规，该走的审计还是要走。主要设备是 Linux、Android 和 macOS 的话迁移成本低。但 tailnet 里要过生产凭据和公司资源的话，先看安全那一节：没有 Tailnet Lock，控制面被攻破，攻击者能进网络，实际能碰多大面还受你的 ACL 和服务自身认证约束。
  3. 极端信任要求，或只有两三台固定机器：纯 WireGuard 手工配置，零第三方依赖，代价是密钥和端点全靠自己维护。

介于官方和自建之间的务实路径：先用官方版跑起来，确认组网确实解决你的问题，再迁到 Headscale。

参考链接：

扫码关注公众号
扫码关注公众号
扫码加群交流
扫码加群交流