Ubuntu 安裝 Tailscale 失敗？apt 錯誤排除指南

為什麼 Ubuntu 上的 Tailscale 安裝錯誤屬於 apt 錯誤

在 Ubuntu 上發生的 Tailscale 安裝錯誤，幾乎總是在任何 Tailscale 程式碼執行之前就出現了。這些都是 apt 錯誤。Ubuntu 本身並未提供 tailscale 套件：經 2026 年 8 月查閱 Ubuntu 套件庫，僅有 Go 輔助函式庫與 python3-tailscale 符合條件，因此 daemon 必須來自 Tailscale 位於 pkgs.tailscale.com 的專屬 apt 套件庫。

新增該套件庫會寫入兩個檔案。其中一個檔案告知 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 並進行擷取：https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease。如果您能手動擷取該 URL，apt 也同樣能擷取。這就是完整的診斷方式。

在進行任何變更前，請先閱讀 apt 的錯誤訊息

請單獨執行更新指令，以免錯誤訊息被其他輸出洗掉。

sudo apt update

第三方儲存庫失敗時會顯示如下訊息。您機器上的代號（codename）與 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。經 2026 年 8 月驗證，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 代號建立獨立的目錄。若請求的代號不存在，伺服器會因找不到 dists/<codename> 而回傳 404 錯誤。請參考供應商於 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 會在程式執行前先建立整個管線（pipeline），因此 sudo tee 會開啟金鑰環路徑並立即將其截斷為零位元組。若隨後 -f 導致 curl 因 HTTP 錯誤而失敗，curl 將不會寫入任何內容並以非零狀態退出。該檔案將維持零位元組。管線的退出狀態取決於最後一個指令，即 tee，該指令執行成功。系統不會輸出任何訊息，您會誤以為金鑰已安裝而繼續執行下一個指令。

請檢查檔案本身，而非建立檔案的指令。

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

正常的金鑰環會輸出 pub 行以及包含 Tailscale 名稱的 uid 行。零位元組的檔案僅會輸出 gpg: no valid OpenPGP data found. 而無其他內容。若檔案內容為 HTML 錯誤頁面，輸出結果亦同；此時對其執行 head -c 80 會顯示網頁開頭，而非二進位金鑰資料。

若金鑰環中沒有可用的金鑰，sudo apt update 在下載索引後會拒絕使用。您會看到包含 Tailscale 儲存庫及其套件組合的 W: GPG error 行，接著是 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

嚴重的情況發生在兩個檔案指定了不同的金鑰環（keyring）路徑時，因為 apt 無法判斷該使用哪一個金鑰來管理儲存庫。此時會顯示 E: Conflicting values set for option Signed-By regarding source，接著列出儲存庫及其套件集，並在兩個金鑰環路徑之間顯示 !=，隨後拒絕繼續執行：

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 區段，並將 signed-by 選項轉換為 Signed-By。

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

Ubuntu 24.04 所搭載的 apt 版本早於該子指令的引入時間，因此說明列會立即告知您的版本是否支援。若不支援，請直接從磁碟中現有的那一行建立區段，確保基礎資訊來自供應商提供的檔案，而非手動輸入。

. /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

該指令會輸出所寫入的區段，讓您在執行下一次 apt update 前能檢查各欄位。其中四個欄位值得深入了解，因為它們各自會導致不同的錯誤：

• URIs 停在儲存庫的根目錄。若將 dists/noble 部分貼入其中會導致 404 錯誤，因為 apt 會自行附加 dists/<suite> 並請求 dists/noble/dists/noble。
• Suites 為代號（codename），即單行格式中位於中間的值。
• Signed-By 接受金鑰檔案的絕對路徑。它也接受內嵌的裝甲金鑰（armored key），此時金鑰的每一行需縮排一個空格，且金鑰內的空白行需寫為單一個點。
• Enabled: no 可在不刪除的情況下停用來源，這比重新命名更容易復原，也更容易向接手人員說明。

第三方儲存庫建議每個檔案僅保留一個區段；若將多個區段放在一起，請務必在區段之間保留空白行。儲存庫索引已包含 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 發送的標頭，以及它所連接的代理伺服器（若有）。請將其與對相同 URL 執行的普通 curl 指令進行比較。若 curl 回傳 200 而 apt 回傳 403，則兩者的請求在中間設備所關注的項目上有所差異，最常見的原因是 User-Agent：

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

請務必釐清相反的情況。在完全沒有 IPv4 位址的 VPS 上，強制使用 IPv4 無法解決問題，因為根本沒有可供流量傳輸的 IPv4 路由。在這種情況下，您需要使用供應商提供的 NAT64 搭配 DNS64，或是使用具備 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。這對您的預期管理很重要：若代理伺服器封鎖了儲存庫，此腳本無法繞過限制。它會以同樣的方式失敗，且輸出資訊更少。將下載的腳本透過 pipe 傳送給 root 權限的 shell 執行是一種權衡，而非解決方案，因為您必須信任伺服器當下回傳的內容，且無法保留執行內容的副本。若您選擇此權衡，請務必清楚其風險：

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

靜態二進位檔。 同一伺服器在 pkgs.tailscale.com/stable 的靜態二進位檔區段發布了純 tarball。截至 2026 年 8 月，穩定版本為 1.102.2，64 位元 x86 檔案為 tailscale_1.102.2_amd64.tgz。您需自行放置 tailscale 客戶端與 tailscaled daemon，並自行管理該 daemon，因此不會有 apt upgrade 路徑，且未來的每次更新都必須手動下載。此方案適用於隔離網路（air-gapped）主機，或必須鎖定特定版本的情況。

Ubuntu 原生套件。 並不存在。若未設定供應商儲存庫而執行 sudo apt install tailscale，最終會停在 E: Unable to locate package tailscale，且執行再多次 apt update 也無法改變結果。若您實際需要的是自行控制的協調伺服器，而非 Tailscale 託管的服務，那是另一個決策：執行 Headscale 作為您的控制伺服器 涵蓋了相關內容，而 Tailscale 與純 WireGuard 的比較 則探討了您是否真的需要這些機制。

套件已安裝，但 tailscaled 無法啟動

在 apt 完成安裝後，若出現錯誤，問題通常出在 daemon。

systemctl status tailscaled
sudo journalctl -u tailscaled -n 50

若在共享宿主核心的容器虛擬化環境（如 LXC 或 OpenVZ）使用 VPS，日誌中會出現關於 /dev/net/tun 不存在的訊息。daemon 需要 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 驗證其簽章。常見原因是金鑰環（keyring）大小為 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 執行 daemon。缺點是升級不便：沒有 apt 套件可自動更新，每次更新皆須手動處理。Ubuntu 官方封存庫不包含 tailscale 套件，因此在未設定官方套件庫的機器上執行 sudo apt install tailscale 會停在 E: Unable to locate package tailscale。