Ubuntu 安裝 Tailscale 顯示 apt 錯誤怎麼修
Ubuntu 安裝 Tailscale 失敗多半是 apt 錯誤。先讀取狀態碼與完整 URL,再修正 Ubuntu 代號或 signing keyring,避免盲目重裝。
為什麼 Ubuntu 上的 Tailscale 安裝錯誤其實是 apt 錯誤
Ubuntu 上的 Tailscale 安裝錯誤,幾乎總是在任何 Tailscale 程式碼執行前發生。這些是 apt 錯誤。Ubuntu 並未提供自有的 tailscale 套件:截至 2026 年 10 月,對照 Ubuntu 套件庫後,唯一符合的項目是 Go 輔助程式庫與 python3-tailscale,因此 daemon 必須來自 Tailscale 自己位於 pkgs.tailscale.com 的 apt repository。
加入該 repository 會寫入 2 個檔案。其中 1 個檔案告訴 apt 套件所在的位置。另一個檔案包含公開金鑰,apt 會用它來驗證 repository index 的簽章。以下幾乎所有錯誤,都是這 2 個檔案其中之一內容錯誤,或 apt 與 repository 之間的裝置拒絕了請求。
以下是 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 tailscalenoble 是 Ubuntu 24.04 的代號,會同時出現在 2 個 URL 中。第二個命令會在 /etc/apt/sources.list.d/tailscale.list 中寫入一行註解與一行 deb,而 cat 會顯示實際寫入的內容。
cat /etc/apt/sources.list.d/tailscale.list請將 deb 那一行解讀為由 4 個欄位組成的位址:方括號中的選項 [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg]、透過 https 存取的 repository 基底位置 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失敗的第三方 repository 會如下所示。您機器上的代號與 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 年 10 月檢查時,noble 會傳回包含 Origin: Tailscale 與 Codename: noble 的已簽署索引。將 noble 替換為您自己錯誤訊息中的代號,再次執行。若 curl 取得 200,而 apt 取得錯誤,表示 repository 正常,問題出在 apt 自身的設定。
狀態碼提供的資訊
404 Not Found表示該軟體庫在該路徑沒有檔案。在pkgs.tailscale.com上,該路徑幾乎總是 URL 中的代號。403 Forbidden表示有元件回應,但拒絕了要求。截至 2026 年 10 月,該軟體庫對不存在的路徑會回傳 404,因此 403 表示問題可能出在伺服器與 Tailscale 之間的代理伺服器、過濾設備或防火牆。401 Unauthorized或407 Proxy Authentication Required表示代理伺服器要求 apt 未傳送的認證資訊。- 連線錯誤或名稱解析錯誤表示根本沒有進行 HTTP 通訊。請跳至 IPv6 區段。
URL 中的代號不是 Tailscale 發布的代號
Tailscale 會為每個 Ubuntu 代號建立獨立目錄。指定不存在的代號時,伺服器上沒有可提供的 dists/<codename>,因此會收到 404。供應商在 pkgs.tailscale.com/stable 提供的清單會列出目前存在的代號。2026 年 10 月時,清單範圍從 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 命令,並使用新的代號。這會覆寫兩個檔案。如果升級程序本身中途停止,導致 dpkg 回報套件尚未完成設定,而不只是此套件庫發生問題,請先復原失敗的發行版升級。因為如果 apt 無法完成系統設定,修正 tailscale.list 也無法持續生效。
第三種情況是時間差。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/nullShell 會先建立完整的管線,再執行其中的程式。因此,sudo tee 會先開啟金鑰環路徑,並立即將其截斷為 0 bytes。接著,如果 curl 失敗,且 -f 使其在任何 HTTP 錯誤時失敗,curl 就不會寫入任何內容,並以非零狀態結束。檔案會維持 0 bytes。管線的結束狀態取決於最後一個命令,也就是 tee;由於該命令成功,整個管線看起來也會成功。畫面沒有任何輸出,接著執行下一個命令,誤以為金鑰已安裝。
請檢查檔案,不要只檢查建立檔案的命令。
ls -l /usr/share/keyrings/tailscale-archive-keyring.gpg
gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg正常的金鑰環會輸出一行 pub,以及一行列出 Tailscale 名稱的 uid。0 byte 檔案只會輸出 gpg: no valid OpenPGP data found.,沒有其他內容。若檔案寫入的是 HTML 錯誤頁面,結果也相同;對它執行 head -c 80 時,會顯示網頁開頭,而不是二進位金鑰資料。
若金鑰環不含可用的金鑰,sudo apt update 會下載索引,然後拒絕使用該索引。你會看到一行 W: GPG error,其中列出 Tailscale repository 與其套件組;接著會看到 The following signatures couldn't be verified because the public key is not available: NO_PUBKEY,後面帶有 16 字元的金鑰 ID;其下方則會顯示 repository 未簽署的錯誤。請注意 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.04 LTS 將自有套件來源移至 deb822 格式,/etc/apt/sources.list 也因此變成 /etc/apt/sources.list.d/ubuntu.sources。Tailscale 仍發布單行格式。於 October 2026 查閱時,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,接著顯示套件庫及其套件版本,再以 != 分隔兩個 keyring 路徑,然後拒絕繼續:
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-sourcesUbuntu 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 前檢查各欄位。以下 4 個欄位值得詳細了解,因為它們各自會以不同方式失敗:
URIs僅能填寫儲存庫的基底位址。將dists/noble部分貼入其中會得到 404,因為 apt 會自行附加dists/<suite>,並要求dists/noble/dists/noble。Suites是代號,必須完全使用單行格式中間的值。Signed-By接受金鑰環檔案的絕對路徑。也可以在其下方直接內嵌 ASCII armored 金鑰;金鑰的每一行都必須縮排 1 個空格,而金鑰內的每個空白行都必須寫成單獨的句點。Enabled: no可停用來源而不刪除來源。這比重新命名更容易復原,也更方便向下一位維護人員說明。
第三方儲存庫請每個檔案保留 1 個段落。如果將多個段落放在同一檔案中,請在段落之間加入空白行。儲存庫索引已將 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,表示兩個請求在某些中間設備在意的內容上有所不同,最常見的原因是 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 mirror 的雲端對外連線防火牆;在這種情況下,應在防火牆上允許 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 位址的 proxy。其徵兆是連線錯誤中列出 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。這會影響您的預期:它無法繞過代理程式封鎖的軟體套件儲存庫。它只會以較少的輸出,遭遇相同的失敗。將下載的指令碼直接以 root 身分導入 shell 是一項取捨,不是解決方案,因為您信任伺服器當下傳回的內容,而且不會保留實際執行內容的副本。如果您接受這項取捨,請先充分了解其風險:
curl -fsSL https://tailscale.com/install.sh -o install.sh
less install.sh
sh install.sh靜態二進位檔。 同一部伺服器會在 pkgs.tailscale.com/stable 的 static binaries 區段發布一般 tarball。截至 2026 年 10 月,stable 版本為 1.102.4,而 64 bit x86 檔案是 tailscale_1.102.4_amd64.tgz。您必須自行放置 tailscale 用戶端與 tailscaled daemon,也必須自行監督 daemon,因此不會有 apt upgrade 路徑,未來每次更新都必須自行記得下載。這適合用於隔離網路主機,或您必須固定使用某個確切版本的情況。
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在使用共用主機核心之容器虛擬化的 VPS 上,例如 LXC 或 OpenVZ,日誌會出現 /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 repository 未簽署?
因為 apt 已下載 repository index,但無法使用 /usr/share/keyrings/tailscale-archive-keyring.gpg 驗證其簽章。通常是因為 keyring 大小為 0 bytes:sudo tee 在 curl 尚未下載任何內容前就截斷了檔案,而 pipeline 因 tee 成功而回報成功。執行 gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg。正常的 keyring 會輸出一行 pub,以及一行列出 Tailscale 名稱的 uid;空白或損毀的 keyring 則會輸出 gpg: no valid OpenPGP data found.。請先將金鑰下載至暫存檔並在該處檢查,確認後再以模式 0644 複製到正確位置,讓 _apt 使用者可以讀取。
Tailscale URL 中應填入哪個 Ubuntu codename?
使用 /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 手動取得 index,確認選擇正確。
將 Tailscale 安裝指令碼透過管線傳給 shell 執行是否安全?
這是必須審慎決定的取捨。該指令碼來自 Tailscale,執行內容與手動步驟相同:讀取 /etc/os-release,寫入相同的 keyring 與相同的 /etc/apt/sources.list.d/tailscale.list,然後安裝套件。代價是以 root 身分執行伺服器當下回傳的所有內容,且不會保留執行內容的紀錄。請使用 -o install.sh 下載指令碼,先閱讀內容,再視需要執行;如此可保有便利性,同時避免無法檢視執行內容。若 repository 已遭封鎖,該指令碼也無法解決問題,因為它使用的 URL 與先前失敗的 URL 相同。
如何在不使用 apt repository 的情況下於 Ubuntu 安裝 Tailscale?
使用發布於 pkgs.tailscale.com 的 static tarball。截至 2026 年 10 月,版本為 1.102.4,其中 amd64 檔案名稱為 tailscale_1.102.4_amd64.tgz。你必須自行安裝 tailscale 與 tailscaled 程式,並自行透過 systemd 執行 daemon。代價是升級:沒有 apt package 可供下載新版本,因此每次更新都必須手動進行。Ubuntu 的 archive 沒有自行提供 tailscale package,因此在沒有 vendor repository 的機器上,sudo apt install tailscale 會停在 E: Unable to locate package tailscale。