--- title: "一台机器多个服务，每个都有自己的 ts.net 名字" description: "原生 tailscale serve 一台机器只有一个 MagicDNS 名字。本页对比 Tailscale Services、TSLink 每个应用一个节点、Docker sidecar 和 TSDproxy 四种做法。" url: "https://tslink.md/zh/docs/several-apps-one-machine" locale: "zh" product_version: "0.2.0" source: "https://github.com/anydoor7/tslink/blob/v0.2.0/docs/architecture.md" --- > Documentation index: https://tslink.md/zh/llms.txt · Installed binary is authoritative: `tslink manifest`. **普通的 `tailscale serve`（不带 `--service`）一台机器只有一个 MagicDNS 名字，第二个服务只能换端口或挂在路径下。TSLink 把每个应用作为独立的 tsnet 节点运行，每个应用得到根路径、443 端口上的 HTTPS 地址 `..ts.net`。** 假设两个应用已经分别监听 3000 和 8080，可以这样试： ```bash 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 文档](https://tailscale.com/docs/features/magicdns)写明，MagicDNS 用设备的机器名作为 DNS 记录的一部分，所以一台设备只有一个名字。[`tailscale serve` 参考](https://tailscale.com/docs/reference/tailscale-cli/serve)提供了两种在这个名字上区分应用的办法：`--https=`（或 `--http=`）指定监听端口，`--set-path` 把服务挂在某个 URL 路径下。两种办法都会改变你发给别人的地址。 Tailscale 自己的 [tsnet 文档](https://tailscale.com/docs/features/tsnet)说明了背后的限制：tailnet 里的每个 IP 地址都要与单个设备强关联，因此在一台设备上运行多个服务会很麻烦。文档接着说，tsnet 允许同一台设备上的多个服务拥有不同的 IP 地址、访问控制规则，甚至不同的用户身份。TSLink 正是这样使用 tsnet：每个注册的应用对应一个嵌入式节点，全部运行在同一个 daemon 里。各节点暴露什么，参见[分享一个应用](https://tslink.md/zh/docs/share-one-app.md)。 路径方案还有自己的问题。许多前端默认运行在 `/` 下，所以[路径挂载会让静态资源和重定向失效](https://tslink.md/zh/docs/serve-set-path-breaks-app.md)。 ## Services、每个应用一个节点、Docker 四种做法都能让每个应用拥有自己的名字，区别在于需要先准备什么。下表只列出有官方文档或项目文档可查的要求。 | | Tailscale Services | TSLink 每个应用一个节点 | Docker sidecar | TSDproxy 自动代理 | | -------- | ------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 每个应用得到什么 | 自己的 MagicDNS 名字和 TailVIP，以 Service 的形式定义（[配置文件参考](https://tailscale.com/docs/reference/tailscale-services-configuration-file)） | 自己的 tsnet 节点和名字：`..ts.net` | 应用容器旁边放一个 Tailscale 容器，每个服务得到唯一的名字（[Tailscale 的 Docker 指南](https://tailscale.com/blog/docker-tailscale-guide)） | 一个代理进程为每个带标签的容器创建一个 tsnet 节点，拥有自己的名字和 HTTPS，不需要每个服务一个 Tailscale 容器（[README](https://github.com/almeidapaulopt/tsdproxy/blob/cc0c124946d2a76b172fb9cd97cea1458f7a93a8/README.md)） | | 对宿主的要求 | 设备必须使用基于 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 服务端，包括远程主机（[服务端配置](https://github.com/almeidapaulopt/tsdproxy/blob/cc0c124946d2a76b172fb9cd97cea1458f7a93a8/docs/content/docs/serverconfig.md)） | Services 的要求引自 [Tailscale Services 文档](https://tailscale.com/docs/features/tailscale-services)，我们读到的页面标注的最后验证日期是 2026 年 10 月 7 日。如果你需要一个跨主机、换主机后依然稳定的服务名，Services 是合适的选择，不过它需要带 tag 的主机和管理员权限。TSLink 的应用今天就能在一台普通机器上运行。已经跑在容器里、愿意给每个应用配一个 Tailscale 容器的，适合 Docker sidecar。想用一个代理进程按标签发布容器的，适合 TSDproxy，它与 tsnsrv 的对比见[工具对比页](https://tslink.md/zh/docs/comparisons.md)。 ## 各方案在 Tailscale 计费上算什么 TSLink 节点就是 Tailscale 节点，会计入你的套餐。下面的事实来自 Tailscale 的[定价页与 FAQ](https://tailscale.com/pricing)以及 [tags 文档](https://tailscale.com/docs/features/tags)，读取日期是 2026-10-22。节点是否带 tag 取决于有没有凭据，与注册是否持久无关：`tslink add` 注册的是非临时节点，除非加 `--ephemeral`；`tslink share` 默认注册临时节点。 * **默认是免凭据入网。** 全新节点是用户自有节点，不带 tag。FAQ 写明 user devices 免费且不限量，这一类临时节点也在此列。每个节点都要单独在浏览器里授权，不要假设基于 tag 的访问规则对它生效，它也不能当 Services host。密钥按[默认 180 天的周期](https://tailscale.com/docs/features/access-control/key-expiry)过期。 * **保存了凭据时**（这是可选的），每个应用节点带上配置的默认 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](https://tslink.md/zh/docs/when-to-use-tslink.md)。 * **需要跨主机的统一名字，或主机故障切换。** 选 Services。TSLink 管理的是一台主机上的应用，不做跨主机聚合。 * **想用自己的域名。** TSLink 只提供 `*.ts.net` 名字。 * **应用已经在 Docker 里，并且喜欢按标签自动发布。** TSDproxy 更贴合这种工作流。 * **想少占用 tagged resources。** 一台带 tag 的 Services 主机可以承载多个 Service，而保存了凭据时，每个应用一个 TSLink 节点会各占一个 tagged resource。 * **需要主机级进程隔离。** TSLink 的各节点有独立的网络身份，但运行在同一个共用 daemon 里，不隔离应用本身。 ## 相关页面 * [分享一个应用，而非整台机器](https://tslink.md/zh/docs/share-one-app.md)：每个 TSLink 节点暴露什么，以及如何设置每个应用的访问规则。 * [tailscale serve 子路径导致 JS/CSS 404 怎么办](https://tslink.md/zh/docs/serve-set-path-breaks-app.md)：路径挂载为什么会让静态资源和登录失效。 * [在手机上使用编程 agent 的 Web UI](https://tslink.md/zh/docs/agent-ui-phone.md)：开发服务器沿用同样的每个应用一个节点的做法。 * [工具对比](https://tslink.md/zh/docs/comparisons.md)与[何时使用 TSLink](https://tslink.md/zh/docs/when-to-use-tslink.md)：更完整的决策表。 以上 Tailscale 官方来源访问日期：**2026-10-22**。TSLink 行为以 v0.2.0 为准。TSLink 是 [anydoor7](https://github.com/anydoor7/tslink) 的独立项目，**并非由 Tailscale 制作或背书**。