一台机器多个服务，每个都有自己的 ts.net 名字
原生 tailscale serve 一台机器只有一个 MagicDNS 名字。本页对比 Tailscale Services、TSLink 每个应用一个节点、Docker sidecar 和 TSDproxy 四种做法。
最后更新于
普通的 tailscale serve（不带 --service）一台机器只有一个 MagicDNS 名字，第二个服务只能换端口或挂在路径下。TSLink 把每个应用作为独立的 tsnet 节点运行，每个应用得到根路径、443 端口上的 HTTPS 地址 <name>.<tailnet>.ts.net。 假设两个应用已经分别监听 3000 和 8080，可以这样试：
tslink add web --proxy localhost:3000 --allow you@example.com
tslink add api --proxy localhost:8080 --allow you@example.com
tslink url web --wait
tslink url api --wait把登录名换成你自己的 Tailscale 账号。每条 url 命令会打印准确地址，请使用这个地址，因为运行时主机名可能与请求的名字不同。对已存在的名字再执行 add 会替换原有服务。节点第一次启动时，tslink 可能返回一个 auth_url（状态 needs_login），在浏览器里完成一次入网后，再重新执行 url。清理时执行 tslink remove web 和 tslink remove api，没有 unshare 命令。TSLink 是独立项目，并非由 Tailscale 出品。
原生 Serve 为什么停在一个名字
Tailscale 的 MagicDNS 文档写明，MagicDNS 用设备的机器名作为 DNS 记录的一部分，所以一台设备只有一个名字。tailscale serve 参考提供了两种在这个名字上区分应用的办法：--https=<port>（或 --http=<port>）指定监听端口，--set-path 把服务挂在某个 URL 路径下。两种办法都会改变你发给别人的地址。
Tailscale 自己的 tsnet 文档说明了背后的限制：tailnet 里的每个 IP 地址都要与单个设备强关联，因此在一台设备上运行多个服务会很麻烦。文档接着说，tsnet 允许同一台设备上的多个服务拥有不同的 IP 地址、访问控制规则，甚至不同的用户身份。TSLink 正是这样使用 tsnet：每个注册的应用对应一个嵌入式节点，全部运行在同一个 daemon 里。各节点暴露什么，参见分享一个应用。
路径方案还有自己的问题。许多前端默认运行在 / 下，所以路径挂载会让静态资源和重定向失效。
Services、每个应用一个节点、Docker
四种做法都能让每个应用拥有自己的名字，区别在于需要先准备什么。下表只列出有官方文档或项目文档可查的要求。
| Tailscale Services | TSLink 每个应用一个节点 | Docker sidecar | TSDproxy 自动代理 | |
|---|---|---|---|---|
| 每个应用得到什么 | 自己的 MagicDNS 名字和 TailVIP，以 Service 的形式定义（配置文件参考） | 自己的 tsnet 节点和名字：<name>.<tailnet>.ts.net | 应用容器旁边放一个 Tailscale 容器，每个服务得到唯一的名字（Tailscale 的 Docker 指南） | 一个代理进程为每个带标签的容器创建一个 tsnet 节点，拥有自己的名字和 HTTPS，不需要每个服务一个 Tailscale 容器（README） |
| 对宿主的要求 | 设备必须使用基于 tag 的身份，官方文档明确说用户账号登录的设备不能当 Service host | 普通节点。全新的免凭据节点是用户自有节点，保存了凭据时节点带 tag（配置的默认 tag，初始为 tag:tsmain） | 需要运行 Docker 的机器 | 运行该代理，并能连到它所配置的 Docker 服务端的机器 |
| 权限与审批 | Owner、Admin 或 Network admin 权限；在 admin console 或通过 API 定义 Service；除非有自动审批策略，否则要批准 advertise | 每个新节点入网一次（浏览器登录或已保存凭据），外加你的 tailnet 要求的设备审批 | 因部署而异 | 因部署而异 |
| 客户端版本 | Tailscale v1.86.0 或更高，或不稳定版 v1.87.x | 主机不需要另装 Tailscale；访问的手机和电脑照常需要 Tailscale | 因部署而异 | 因部署而异 |
| 跨主机 | 一个 Service 可以由多台获批主机 advertise | 一次注册对应一台主机，不自动跨主机聚合 | 容器在运行它们的主机上 | 一个代理可连接多个已配置的 Docker 服务端，包括远程主机（服务端配置） |
Services 的要求引自 Tailscale Services 文档，我们读到的页面标注的最后验证日期是 2026 年 10 月 7 日。如果你需要一个跨主机、换主机后依然稳定的服务名，Services 是合适的选择，不过它需要带 tag 的主机和管理员权限。TSLink 的应用今天就能在一台普通机器上运行。已经跑在容器里、愿意给每个应用配一个 Tailscale 容器的，适合 Docker sidecar。想用一个代理进程按标签发布容器的，适合 TSDproxy，它与 tsnsrv 的对比见工具对比页。
各方案在 Tailscale 计费上算什么
TSLink 节点就是 Tailscale 节点，会计入你的套餐。下面的事实来自 Tailscale 的定价页与 FAQ以及 tags 文档，读取日期是 2026-10-22。节点是否带 tag 取决于有没有凭据，与注册是否持久无关：tslink add 注册的是非临时节点，除非加 --ephemeral；tslink share 默认注册临时节点。
- 默认是免凭据入网。 全新节点是用户自有节点，不带 tag。FAQ 写明 user devices 免费且不限量，这一类临时节点也在此列。每个节点都要单独在浏览器里授权，不要假设基于 tag 的访问规则对它生效，它也不能当 Services host。密钥按默认 180 天的周期过期。
- 保存了凭据时（这是可选的），每个应用节点带上配置的默认 tag，初始为
tag:tsmain，可用--tags覆盖。这样它就是一个 tagged resource，FAQ 把它定义为由 tag 而非用户身份拥有的设备。Personal 套餐起步包含 50 个 tagged resources，超出部分每个每月 1 美元，FAQ 同时写明 Tailscale 目前没有强制执行这些上限。 - 带 tag 的临时节点（保存了凭据，再加
--ephemeral，tslink share默认就带这个参数）先消耗临时节点的分钟额度。按 FAQ 的说法，设备在线超过四小时后，会按标准 tagged resource 计算。 - Services host 同样是 tagged 设备。 一台带 tag 的主机可以 advertise 多个 Service，所以 Services 占用的 tagged resources 可能比每个应用一个带 tag 的 TSLink 节点更少。
何时不该用 TSLink
- 一个应用就够了。 如果设备名下的一个端口或路径已经满足需求，直接用
tailscale serve 3000，不必多加一层。参见何时使用 TSLink。 - 需要跨主机的统一名字，或主机故障切换。 选 Services。TSLink 管理的是一台主机上的应用，不做跨主机聚合。
- 想用自己的域名。 TSLink 只提供
*.ts.net名字。 - 应用已经在 Docker 里，并且喜欢按标签自动发布。 TSDproxy 更贴合这种工作流。
- 想少占用 tagged resources。 一台带 tag 的 Services 主机可以承载多个 Service，而保存了凭据时，每个应用一个 TSLink 节点会各占一个 tagged resource。
- 需要主机级进程隔离。 TSLink 的各节点有独立的网络身份，但运行在同一个共用 daemon 里，不隔离应用本身。
相关页面
- 分享一个应用，而非整台机器：每个 TSLink 节点暴露什么，以及如何设置每个应用的访问规则。
- tailscale serve 子路径导致 JS/CSS 404 怎么办：路径挂载为什么会让静态资源和登录失效。
- 在手机上使用编程 agent 的 Web UI：开发服务器沿用同样的每个应用一个节点的做法。
- 工具对比与何时使用 TSLink：更完整的决策表。
以上 Tailscale 官方来源访问日期：2026-10-22。TSLink 行为以 v0.2.0 为准。TSLink 是 anydoor7 的独立项目，并非由 Tailscale 制作或背书。