Ubuntu 上 Tailscale 安装失败怎么修复

为什么 Ubuntu 上的 Tailscale 安装错误属于 apt 错误

Ubuntu 上的 Tailscale 安装错误几乎总是发生在任何 Tailscale 代码运行之前。它们属于 apt 错误。Ubuntu 没有自带 tailscale 软件包：截至 August 2026，在 Ubuntu 软件包存档中检查到的匹配项只有 Go 辅助库和 python3-tailscale，因此守护进程必须从 Tailscale 自己的 apt 软件源 pkgs.tailscale.com 获取。

添加该软件源会写入两个文件。一个文件告诉 apt 软件包存放在哪里。另一个文件保存公钥，apt 使用它检查软件源索引的签名。下面几乎所有故障都源于这两个文件之一有误，或者 apt 与软件源之间的设备拒绝了请求。

以下是 Tailscale 为 Ubuntu 24.04 发布的命令：

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt-get update && sudo apt-get install tailscale

noble 是 Ubuntu 24.04 的代号，并且会出现在两个 URL 中。第二条命令会将一行注释和一行 deb 写入 /etc/apt/sources.list.d/tailscale.list，而 cat 会准确显示写入其中的内容。

cat /etc/apt/sources.list.d/tailscale.list

将 deb 行看作由四个字段组成的地址：方括号中的选项 [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg]，然后是软件源基址，即通过 https 访问的 pkgs.tailscale.com/stable/ubuntu，接着是套件 noble，最后是组件 main。apt 会将基址和套件拼接成一个 URL 并获取该 URL：https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease。如果您可以手动获取该 URL，apt 也可以获取。诊断过程就是这些。

先查看 apt 错误，再进行任何更改

单独运行更新命令，避免其他输出将错误滚过屏幕。

sudo apt update

第三方软件源失败时，输出通常如下所示。您机器上的发行版代号和 IP 地址会不同。

E: Failed to fetch https://pkgs.tailscale.com/stable/ubuntu/dists/wilma/InRelease  404  Not Found [IP: 203.0.113.9 443]
E: Some index files failed to download. They have been ignored, or old ones used instead.

输出中的两项内容决定下一步操作：状态码，以及 E: Failed to fetch 行中的完整 URL。不要根据底部的摘要行猜测原因。复制该 URL，并直接向服务器发起请求。

curl -sS -o /dev/null -w '%{http_code}\n' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease

对于 Tailscale 发布软件包的发行版代号，该命令会输出 200。截至 August 2026 的检查结果显示，noble 会返回一个包含 Origin: Tailscale 和 Codename: noble 的签名索引。将 noble 替换为您自己的错误信息中的发行版代号，然后再次运行该命令。如果 curl 获取到 200，而 apt 获取到错误，则软件源正常，问题出在 apt 自身的配置中。

状态代码的含义

• 404 Not Found 表示仓库在该路径下没有文件。在 pkgs.tailscale.com 中，这几乎总是 URL 中的代号。
• 403 Forbidden 表示有服务返回了响应，但拒绝了请求。截至 2026 年 8 月，该仓库对不存在的路径返回 404，因此 403 通常指向服务器与 Tailscale 之间的代理、过滤设备或防火墙。
• 401 Unauthorized 或 407 Proxy Authentication Required 表示代理要求提供凭据，但 apt 未发送这些凭据。
• 连接错误或名称解析错误表示根本没有进行 HTTP 通信。请跳转到 IPv6 部分。

URL 中的代号并不是 Tailscale 发布的代号

Tailscale 会为每个 Ubuntu 代号创建一个单独的目录。请求不存在的代号时会返回 404，因为服务器上没有可提供的 dists/<codename>。供应商在 pkgs.tailscale.com/stable 中的列表会显示当前存在的代号。2026 年 8 月，该列表从 16.04 延伸到 resolute，也就是 Ubuntu 26.04。

错误代号通常来自在基于 Ubuntu 但并非 Ubuntu 的发行版上运行 lsb_release -cs。在 Linux Mint 22 上，该命令会输出 wilma，这是 Mint 自己的代号，而 Tailscale 没有为此代号发布软件包。应改为读取 Ubuntu 基础版本。

. /etc/os-release
echo "$VERSION_CODENAME $UBUNTU_CODENAME"

在 Ubuntu 上，这两个值相同。在衍生发行版上，VERSION_CODENAME 是衍生发行版的名称，UBUNTU_CODENAME 是其所基于的 Ubuntu 版本。在两个 URL 中都使用 UBUNTU_CODENAME。

第二种情况是发行版升级。Ubuntu 升级工具运行时会禁用第三方软件源。因此，在将 Ubuntu 24.04 升级到 26.04后，您会发现 /etc/apt/sources.list.d/tailscale.list 已被注释掉，或者仍然指定 noble，但当前系统已经是 resolute。重新运行两个 curl 命令，并使用新的代号即可修复；这两个命令会覆盖这两个文件。

第三种情况是发布时间差异。新的 Ubuntu 版本发布后的几周内，Canonical 可能已经提供该代号，但 Tailscale 尚未提供。将文件指向上一个 LTS 代号通常也能完成安装，因为这些软件包的依赖项很少，但此时运行的是为旧版本构建的软件包。使用 apt policy tailscale 检查实际安装的版本，并在正式代号出现后将文件改回正确代号。

密钥环为空，而写入它的命令没有输出任何内容

这个问题通常不会显示明显错误，也是这类问题最常见的原因。重新查看密钥环命令：

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null

shell 会在任一程序运行前先构建整个管道，因此 sudo tee 会立即打开密钥环路径，并将其截断为 0 字节。如果 curl 随后失败，而 -f 会让它在出现任何 HTTP 错误时失败，那么 curl 不会写入任何内容，并以非零状态退出。文件会保持为 0 字节。管道的退出状态取决于最后一个命令，也就是 tee，而该命令执行成功。终端不会输出任何内容，于是您继续执行下一个命令，并误以为密钥已安装。

检查文件，不要只检查生成该文件的命令。

ls -l /usr/share/keyrings/tailscale-archive-keyring.gpg
gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg

正常的密钥环会输出一行 pub 和一行 uid，其中包含 Tailscale 的名称。0 字节文件只会输出 gpg: no valid OpenPGP data found.，不会有其他内容。若文件中写入的是 HTML 错误页面，输出结果也相同；对该文件执行 head -c 80 后，会看到网页开头，而不是二进制密钥数据。

如果密钥环中没有可用密钥，sudo apt update 会下载索引，然后拒绝该索引。您会看到一行 W: GPG error，其中包含 Tailscale 软件源及其套件名称；随后是文本 The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 和一个 16 字符的密钥 ID；下方还会显示软件源未签名的错误。请注意 apt 的含义：它已成功下载索引，但无法验证签名。这是密钥问题，不是网络问题。如果密钥环文件完全不存在，错误消息又会不同，并通过 Could not open file /usr/share/keyrings/tailscale-archive-keyring.gpg 直接指出文件路径。

分两步写入密钥，这样下载失败时不会破坏现有的密钥环。

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg -o /tmp/tailscale.gpg
gpg --show-keys /tmp/tailscale.gpg
sudo install -m 0644 -o root -g root /tmp/tailscale.gpg /usr/share/keyrings/tailscale-archive-keyring.gpg

中间那一行是检查条件：如果没有输出 Tailscale uid，请停止，不要复制该文件。0644 权限模式很重要，因为 apt 会降权为无特权的 _apt 用户来获取并验证文件；因此，只有 root 能读取的密钥环，apt 也无法使用。

.list 文件和 .sources 文件描述了同一个软件仓库

Ubuntu 在 Ubuntu 24.10 中将自有软件源迁移到了 deb822 格式，其中 /etc/apt/sources.list 变为 /etc/apt/sources.list.d/ubuntu.sources。Tailscale 仍发布单行格式的软件源文件。截至 2026 年 8 月，pkgs.tailscale.com 上没有可下载的 .sources 文件：该 URL 返回 404。因此，如果您的计算机上有 tailscale.sources，说明这是您或某份指南手动创建的；如果 tailscale.list 也仍然存在，apt 现在就会将同一个软件仓库描述两次。

较轻的情况是在每次更新时显示警告：

W: Target Packages (main/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list.d/tailscale.list:1 and /etc/apt/sources.list.d/tailscale.sources:1

严重的情况发生在两个文件指定了不同的密钥环路径时，因为 apt 无法确定哪个密钥控制该软件仓库。它会先显示 E: Conflicting values set for option Signed-By regarding source，然后显示软件仓库及其 suite，接着显示由 != 分隔的两个密钥环路径，最后拒绝继续：

E: The list of sources could not be read.

在其中一个文件被移除前，这种问题会阻止所有 apt 命令，而不仅是更新命令。Ubuntu 自有软件仓库也会出现相同问题；deb822 迁移后重复 apt 软件源错误介绍了通用情况。

删除任何文件前，请找出所有提及 Tailscale 的文件。

grep -RIn tailscale /etc/apt/sources.list /etc/apt/sources.list.d/

保留其中一个文件。如果不想丢失另一个文件，可以将其重命名以禁用它：apt 只读取以 .list 或 .sources 结尾的文件，因此会跳过 tailscale.list.bak，但该文件仍会保留在磁盘上供参考。

正确编写 deb822 源文件

如果您更喜欢新格式，请转换现有文件，不要重新输入仓库地址，因为地址中的拼写错误正是上述错误的常见起点。新版 apt 提供了转换器，可将 .list 文件重写为 deb822 stanza，并将 signed-by 选项转移为 Signed-By。

apt modernize-sources --help
sudo apt modernize-sources

Ubuntu 24.04 自带的 apt 版本早于该子命令，因此查看帮助信息即可立即确认当前版本是否支持它。如果不支持，请根据磁盘上已有的源配置行构建 stanza。这样基础地址来自供应商提供的文件，而不是依赖手动输入。

. /etc/os-release
{
  echo 'Types: deb'
  echo "URIs: $(awk '/^deb /{print $3}' /etc/apt/sources.list.d/tailscale.list)"
  echo "Suites: $UBUNTU_CODENAME"
  echo 'Components: main'
  echo 'Signed-By: /usr/share/keyrings/tailscale-archive-keyring.gpg'
} | sudo tee /etc/apt/sources.list.d/tailscale.sources
sudo rm /etc/apt/sources.list.d/tailscale.list

该命令会输出写入的 stanza，因此您可以在执行下一个 apt update 前检查各字段。以下 4 个字段需要详细了解，因为它们的错误表现各不相同：

• URIs 只能写到仓库的基础地址。将 dists/noble 部分粘贴到其中会导致 404，因为 apt 会自行追加 dists/<suite>，并请求 dists/noble/dists/noble。
• Suites 是代号，必须与单行格式中间的值完全一致。
• Signed-By 接受 keyring 文件的绝对路径。它也接受直接内嵌在该字段下方的 ASCII armor 格式密钥；密钥的每一行必须缩进 1 个空格，密钥内部的每个空行必须写成单独的点号。
• Enabled: no 可在不删除源的情况下停用它。相比重命名文件，这种方式更容易撤销，也更便于向后续维护人员说明。

第三方仓库应每个文件只保留一个 stanza。如果确实要在同一文件中保留多个 stanza，请在 stanza 之间加入空行。仓库索引已将 amd64 和 arm64 列为支持的架构，因此 ARM VPS 不需要额外的 Architectures 字段。

中间代理返回 403

由于该路径在此仓库中不存在时会返回 404，因此 403 表示有其他设备代替它返回了响应。先检查 apt 自身的配置，因为其中设置的代理只适用于 apt，不适用于交互式 curl。

grep -RIn -i proxy /etc/apt/apt.conf.d/ /etc/apt/apt.conf
sudo apt-config dump | grep -i 'acquire::http'

然后监控 apt 实际发送的内容。

sudo apt -o Debug::Acquire::http=1 update

该命令会输出请求行、apt 发送的请求头，以及 apt 连接所经过的代理（如果有）。将其与对同一 URL 执行的普通 curl 进行比较。如果 curl 返回 200，而 apt 返回 403，说明两者的请求存在某些中间设备关注的差异，通常是用户代理：

curl -sS -o /dev/null -w '%{http_code}\n' -A 'Debian APT-HTTP/1.3' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease

如果该命令返回 403，而默认的 curl 返回 200，说明过滤设备正在根据名称拒绝 apt。应在该设备上修复，而不是修改服务器。会检查 TLS 的企业代理会产生另一种结果：apt 报告证书验证失败，而不是返回状态码，因为它收到的证书由代理签发，而不是由 Tailscale 的证书颁发机构签发。另一种常见原因是云出口防火墙只允许访问 Ubuntu 镜像；此时应在防火墙上允许 pkgs.tailscale.com。

仅 IPv6 出站，以及不是状态码的错误

如果 apt 从未收到 HTTP 响应，请分别测试每种协议。

curl -4 -sS -o /dev/null -w 'v4 %{http_code}\n' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease
curl -6 -sS -o /dev/null -w 'v6 %{http_code}\n' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease

如果 IPv4 可以响应，而 IPv6 一直挂起或报告 Network is unreachable，说明 apt 失败是因为解析器库优先使用 IPv6，但服务器没有可用的 IPv6 路径。强制本次运行使用 IPv4，以确认这一判断：

sudo apt -o Acquire::ForceIPv4=true update

如果更新成功，请将此设置永久化。

echo 'Acquire::ForceIPv4 "true";' | sudo tee /etc/apt/apt.conf.d/99force-ipv4

也要考虑相反的情况。如果 VPS 完全没有 IPv4 地址，强制使用 IPv4 不会解决问题，因为没有 IPv4 路由可供流量使用。此时需要供应商提供的带 DNS64 的 NAT64，或使用持有 IPv4 地址的代理。其表现是连接错误中出现 IPv6 地址，因此 curl -6 行才是能说明实际原因的信息。

回退方案及其代价

供应商安装脚本。 curl -fsSL https://tailscale.com/install.sh | sh 是 Tailscale 公布的命令。阅读该脚本可以发现，它会通过 /etc/os-release 检测发行版，然后从相同的 URL 写入本指南一直在修复的同两个路径：/usr/share/keyrings/tailscale-archive-keyring.gpg 和 /etc/apt/sources.list.d/tailscale.list。这会影响您的预期：它不会绕过被代理阻止的软件仓库。它只会在输出更少的情况下以相同方式失败。将下载的脚本通过管道传给 shell 并以 root 身份执行是一种取舍，不是解决方案，因为您信任服务器在该时刻返回的内容，并且不会保留实际执行过的脚本副本。如果您接受这种取舍，请明确了解其风险：

curl -fsSL https://tailscale.com/install.sh -o install.sh
less install.sh
sh install.sh

静态二进制文件。 同一服务器会在 pkgs.tailscale.com/stable 的静态二进制文件部分发布普通 tar 包。截至 2026 年 8 月，稳定版本为 1.102.2，64 位 x86 文件为 tailscale_1.102.2_amd64.tgz。您需要自行放置 tailscale 客户端和 tailscaled daemon，并自行管理 daemon，因此不会有 apt upgrade 路径；此后每次更新都需要您记得手动下载。对于隔离网络主机，或必须固定使用某个确切版本的场景，这种方式适用。

Ubuntu 自带的软件包。 Ubuntu 没有提供该软件包。未配置供应商软件仓库时运行 sudo apt install tailscale，最终会得到 E: Unable to locate package tailscale；无论 apt update 如何修改，都无法改变这一点。如果您实际需要的是由自己控制的协调服务器，而不是 Tailscale 托管的服务器，那是另一项决策：运行 Headscale 作为您自己的控制服务器对此进行了介绍，Tailscale 与普通 WireGuard 的比较则说明了您是否需要整套机制。

软件包已安装，但 tailscaled 无法启动

apt 不再报告问题后，故障会转移到守护进程。

systemctl status tailscaled
sudo journalctl -u tailscaled -n 50

如果 VPS 使用与主机共享内核的容器虚拟化技术，例如 LXC 或 OpenVZ，日志中会出现一行提示 /dev/net/tun 不存在。该守护进程需要 TUN 设备来创建 tailscale0 接口，但容器未获得该设备。请要求服务提供商为容器启用 TUN，或改用 KVM 方案，这样您可以使用自己的内核。在 KVM 上无需额外配置即可正常工作。

完成后，sudo tailscale up 会输出登录 URL，tailscale status 应列出您的计算机，并显示 100.64.0.0/10 范围内的地址。列出的计算机即可作为后续配置的基础，例如从 VPS 发布私有子网，或将 VPS 用作出口节点。

FAQ

为什么 apt 提示 Tailscale 软件源未签名？

因为 apt 下载了软件源索引，但无法使用 /usr/share/keyrings/tailscale-archive-keyring.gpg 验证其签名。通常原因是密钥环文件大小为 0 字节：sudo tee 在 curl 未下载任何内容前截断了文件，而管道因 tee 成功而报告成功。运行 gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg。正常的密钥环会输出一行 pub 和一行包含 Tailscale 名称的 uid；为空或损坏的密钥环会输出 gpg: no valid OpenPGP data found.。请先将密钥下载到临时文件并在那里检查，然后以模式 0644 将其复制到目标位置，这样 _apt 用户才能读取。

Tailscale URL 中应填写哪个 Ubuntu 代号？

使用 /etc/os-release 中 UBUNTU_CODENAME 的值。Ubuntu 24.04 中该值为 noble，Ubuntu 26.04 中为 resolute。不要在基于 Ubuntu 的发行版中使用 lsb_release -cs：在 Linux Mint 22 中，它会输出 wilma，而 Tailscale 没有发布该名称下的软件包，因此 apt 会在 dists/wilma/InRelease 上报告 404。编辑任何内容前，先使用 curl -sS -o /dev/null -w '%{http_code}\n' 针对 https://pkgs.tailscale.com/stable/ubuntu/dists/<codename>/InRelease 手动获取索引，确认选择正确。

将 Tailscale 安装脚本通过管道传给 shell 执行是否安全？

这是一个需要您慎重决定的取舍。脚本来自 Tailscale，执行的操作与手动步骤相同：读取 /etc/os-release，写入相同的密钥环和相同的 /etc/apt/sources.list.d/tailscale.list，然后安装软件包。代价是您会以 root 身份执行服务器当时返回的全部内容，并且不会保留脚本记录。可以使用 -o install.sh 下载脚本，阅读后再执行。这样既能获得便利，也不会忽略脚本内容。对于软件源被阻断的情况，它也无法提供帮助，因为它使用的仍是已经失败的相同 URL。

如何在不使用 apt 软件源的情况下在 Ubuntu 上安装 Tailscale？

使用发布在 pkgs.tailscale.com 上的静态 tarball。截至 2026 年 8 月，当前版本为 1.102.2，其中 amd64 文件名为 tailscale_1.102.2_amd64.tgz。您需要自行安装 tailscale 和 tailscaled 程序，并自行通过 systemd 运行守护进程。代价是升级不便：没有 apt 软件包自动获取新版本，因此每次更新都必须手动进行。Ubuntu 的软件包归档中没有自带的 tailscale 软件包，因此在未配置厂商软件源的计算机上，sudo apt install tailscale 会停在 E: Unable to locate package tailscale。