SSD Nodes Learn Hosting plans →
ガイド Matt Connor著者 Matt Connor

UbuntuでTailscaleのインストールエラーを直す方法

UbuntuのTailscaleインストールエラーはaptが原因のことが大半です。表示されたステータスコードと完全なURLを確認し、release codenameや署名keyringの誤りを修正します。

Ubuntu で Tailscale のインストールエラーが apt エラーになる理由

Ubuntu で Tailscale のインストールエラーが発生する場合、ほとんどは Tailscale のコードが実行される前に起きています。apt のエラーです。Ubuntu には独自の tailscale パッケージがありません。2026年10月に Ubuntu のパッケージアーカイブを確認したところ、一致したのは Go のヘルパーライブラリと python3-tailscale だけでした。そのため、daemon は pkgs.tailscale.com にある Tailscale 独自の apt repository から取得する必要があります。

この repository を追加すると、2つのファイルが書き込まれます。1つは、パッケージの場所を apt に伝えます。もう1つは、repository index の署名を検証するために apt が使用する公開鍵を保持します。以下の失敗のほぼすべては、この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 tailscale

noble は Ubuntu 24.04 の codename で、両方の URL に含まれています。2つ目のコマンドは、コメント行と1つの deb 行を /etc/apt/sources.list.d/tailscale.list に書き込みます。cat を実行すると、そこに書き込まれた内容を正確に確認できます。

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

この deb 行は、4つのフィールドから成るアドレスとして読み取ります。最初が角括弧内のオプション [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg]、次が https 経由で到達する repository base の pkgs.tailscale.com/stable/ubuntu、その次が suite の noble、最後が component の main です。apt は base と suite を結合して1つの URLを作成し、その 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.

次の対応を決めるのは、その出力にある2つの情報です。ステータスコードと、E: Failed to fetch 行に表示された完全な URL です。末尾の要約行だけを見て推測しないでください。URL をコピーし、自分でサーバーに問い合わせます。

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

codename が Tailscale で公開されている場合、200 と表示されます。2026年10月に確認したところ、noble は Origin: Tailscale と Codename: noble を含む署名付きインデックスを返します。noble を実際のエラーに表示された codename に置き換えて、もう一度実行します。apt ではエラーになった箇所で curl が 200 を返す場合、リポジトリには問題がなく、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 では、このコマンドが Mint 独自のコードネームである wilma を出力します。Tailscale はそのコードネーム用のパッケージを公開していません。Ubuntu のベースリリースを確認してください。

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

Ubuntu では、両方の値は同じです。派生ディストリビューションでは、VERSION_CODENAME が派生ディストリビューションの名前で、UBUNTU_CODENAME がそのベースとなる Ubuntu のリリースです。両方の URL で UBUNTU_CODENAME を使用してください。

2 つ目の原因は、リリースアップグレードです。Ubuntu のアップグレードツールは実行時にサードパーティーのソースを無効にします。そのため、Ubuntu 24.04 を 26.04 にアップグレードした後、/etc/apt/sources.list.d/tailscale.list がコメントアウトされているか、現在は resolute になっているマシンで noble を指定したままになっています。新しいコードネームを指定して 2 つの curl コマンドを再実行し、両方のファイルを上書きして修正します。アップグレード自体が途中で停止し、今回のリポジトリだけでなく dpkg が未設定のパッケージについてもエラーを出している場合は、まず 失敗したリリースアップグレードから復旧してください。apt がシステムの設定を完了できない状態では、tailscale.list を修正しても維持できません。

3 つ目の原因は、公開時期のずれです。新しい Ubuntu リリースの公開後数週間は、コードネームが Canonical には存在していても Tailscale にはまだ存在しないことがあります。ファイルを前の LTS のコードネームに設定すれば通常はインストールできますが、その場合は古いリリース向けに作成されたビルドを実行することになります。実際にインストールされた内容を apt policy tailscale で確認し、正式なコードネームが公開されたらファイルを戻してください。

keyring が空で、書き込みコマンドも何も出力しない

このケースは静かに進みます。多くの場合、ここで問題が確定します。keyring のコマンドをもう一度確認してください。

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 は直ちに keyring のパスを開き、サイズを 0 byte に切り詰めます。その後 curl が失敗すると、-f により HTTP エラー時に失敗するため、curl は何も書き込まず、nonzero で終了します。ファイルは 0 byte のままです。パイプラインの終了ステータスは最後のコマンドのステータスです。最後のコマンドは tee で、正常終了します。何も表示されないため、key がインストールされたと思い込み、次のコマンドへ進んでしまいます。

ファイルを書き込んだコマンドではなく、ファイル自体を確認してください。

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

正常な keyring では、pub の行と、Tailscale を示す uid の行が表示されます。0 byte のファイルでは gpg: no valid OpenPGP data found. だけが表示されます。HTML のエラーページを取得したファイルでも同じ結果になり、head -c 80 を実行すると、バイナリの key データではなく Web ページの先頭が表示されます。

使用可能な key を持たない keyring では、sudo apt update が index をダウンロードした後、その index を拒否します。Tailscale repository とその suite を示す W: GPG error の行、続いて 16 文字の key id を示す The following signatures couldn't be verified because the public key is not available: NO_PUBKEY というテキスト、その下に repository が署名されていないというエラーが表示されます。apt のメッセージが示している内容に注意してください。index のダウンロードには成功していますが、署名を検証できていません。これは key の問題であり、ネットワークの問題ではありません。keyring ファイル自体が存在しない場合は、メッセージがさらに異なり、Could not open file /usr/share/keyrings/tailscale-archive-keyring.gpg でパスが直接示されます。

ダウンロードに失敗しても正常な keyring が破壊されないように、key は 2 段階で書き込んでください。

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 が表示されなければ、停止してファイルをコピーしないでください。Mode 0644 も重要です。apt は取得と検証のために非特権の _apt ユーザーへ切り替えるため、root だけが読み取れる keyring は apt が使用できない keyring です。

.list ファイルと .sources ファイルが同じリポジトリを記述している

Ubuntu 24.04 LTS では、Ubuntu 独自のソースが deb822 形式に移行し、/etc/apt/sources.list が /etc/apt/sources.list.d/ubuntu.sources になりました。Tailscale は現在も1行形式を公開しています。2026年10月時点で、pkgs.tailscale.com からダウンロードできる .sources ファイルはありません。その URL は 404 を返します。したがって、システムに tailscale.sources がある場合は、自分で作成したか、ガイドに従って手動で作成したものです。さらに tailscale.list も残っている場合、apt は同じリポジトリを2つのファイルで重複して記述された状態として扱います。

軽い場合は、更新のたびに警告が表示されます。

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

深刻な場合は、2つのファイルで異なる keyring パスが指定されている場合に発生します。apt は、どの鍵がリポジトリに適用されるのか判断できません。E: Conflicting values set for option Signed-By regarding source を表示し、続いてリポジトリとその suite、さらに != を挟んで2つの keyring パスを表示し、その後処理を中止します。

E: The list of sources could not be read.

この状態になると、update だけでなく、すべての apt コマンドが停止します。いずれかのファイルを削除するまで解消しません。Ubuntu 独自のリポジトリでも同じ障害が発生します。deb822 移行後に発生する重複した apt ソースのエラーでは、一般的なケースを順に説明しています。

削除する前に、Tailscale への言及があるファイルをすべて確認してください。

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

残すファイルを1つ選びます。もう一方を失わずに無効化するには、名前を変更してください。apt が読み込むのは .list または .sources で終わるファイルだけです。そのため、tailscale.list.bak は読み込まれず、参照用にディスク上へ残ります。

deb822 の source ファイルを正しく記述する

新しい形式を使う場合は、リポジトリのアドレスを再入力するのではなく、既存のファイルを変換してください。アドレスの入力ミスが、上記のエラーの直接的な原因になるためです。最近の apt には、.list ファイルを deb822 スタンザへ書き換え、signed-by オプションを Signed-By として移行するコンバーターが含まれています。

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

Ubuntu 24.04 に含まれる apt は、このサブコマンドより前のバージョンです。そのため、help の出力を確認すれば、使用中の apt が対応しているかどうかをすぐに判断できます。対応していない場合は、すでにディスク上にある行を基にスタンザを作成してください。こうすれば、ベース URL はキーボードからの入力ではなく、ベンダーのファイルから取得されます。

. /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 は codename です。1行形式の中央に記述されていた値と完全に同じです。
  • Signed-By には、keyring ファイルの絶対パスを指定します。また、その下に armored key をインラインで記述することもできます。この場合、鍵の各行を1個のスペースでインデントし、鍵の内部にある空行はそれぞれ単独のドットとして記述します。
  • Enabled: no は、削除せずに source を無効化します。名前を変更するより元に戻しやすく、次の担当者にも説明しやすい方法です。

サードパーティーのリポジトリでは、1ファイルにつき1つのスタンザにしてください。複数のスタンザを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 が送信したヘッダー、接続に使用したプロキシがあればその情報が表示されます。同じ URL に対する通常の curl の結果と比較します。curl が 200 を返し、apt が 403 を返す場合、2 つのリクエストにはプロキシなどの中継装置が識別できる違いがあります。通常は 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 経路がないため失敗しています。原因を確認するため、1 回だけ 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 経路がないためです。その場合は、プロバイダーが提供する DNS64 付き NAT64、または IPv4 アドレスを保持するプロキシが必要です。症状として、IPv6 アドレスを示す接続エラーが表示されます。そのため、真の原因を示すのは curl -6 の行です。

フォールバックと、それぞれの代償

ベンダーのインストールスクリプト。 curl -fsSL https://tailscale.com/install.sh | sh は Tailscale が案内しているコマンドです。スクリプトを読むと、/etc/os-release からディストリビューションを判定し、このガイドで修正してきた同じ2つのパス、/usr/share/keyrings/tailscale-archive-keyring.gpg と /etc/apt/sources.list.d/tailscale.list に、同じ URL から書き込みます。これは期待値を決めるうえで重要です。プロキシがブロックしているリポジトリを迂回することはありません。出力が少ないだけで、同じように失敗します。ダウンロードしたスクリプトを root でシェルにパイプする方法は、解決策ではなくトレードオフです。その時点でサーバーが返す内容を信頼することになり、実行した内容のコピーも残らないためです。この方法を選ぶなら、リスクを理解したうえで実行してください。

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

静的バイナリ。 同じサーバーの pkgs.tailscale.com/stable にある静的バイナリのセクションでは、通常の tarball も公開されています。2026年10月時点の stable release は 1.102.4 で、64 bit x86 用ファイルは tailscale_1.102.4_amd64.tgz です。tailscale クライアントと tailscaled デーモンを自分で配置し、デーモンも自分で監視するため、apt upgrade パスは存在しません。また、以後の更新は毎回ダウンロードする必要があります。エアギャップ環境のホストや、特定のバージョンを正確に固定する必要がある場合には、この方法を選ぶ価値があります。

Ubuntu 独自のパッケージ。 そのようなパッケージはありません。ベンダーのリポジトリを設定せずに sudo apt install tailscale を実行すると E: Unable to locate package tailscale で終了し、apt update をどれだけ変更しても状況は変わりません。Tailscale のホスト型サーバーではなく、自分で管理する coordination server が必要なら、それは別の判断です。Headscale を自分の control server として実行する方法で説明し、Tailscale と通常の WireGuard の比較で、この仕組みが必要かどうかを説明しています。

パッケージはインストールされたが、tailscaled が起動しない

apt の処理が正常に完了すると、問題はデーモン側に移ります。

systemctl status tailscaled
sudo journalctl -u tailscaled -n 50

LXC や OpenVZ など、ホストのカーネルを共有するコンテナ仮想化を使用した VPS では、ログに /dev/net/tun が存在しないという行が記録されます。デーモンは tailscale0 インターフェースを作成するために TUN デバイスを必要としますが、そのコンテナには割り当てられていません。プロバイダーにコンテナで TUN を有効にするよう依頼するか、自分専用のカーネルを使用できる KVM プランへ移行してください。KVM では追加設定なしで動作します。

その後、sudo tailscale up はログイン URL を表示し、tailscale status には 100.64.0.0/10 範囲のアドレスを持つマシンが表示されます。ここに表示されたマシンは、VPS からプライベートサブネットを広告する場合でも、VPS を exit node として使用する場合でも、構築の基盤として利用できます。

FAQ

apt はなぜ Tailscale repository が署名されていないと表示するのですか?

apt が repository index をダウンロードしたものの、/usr/share/keyrings/tailscale-archive-keyring.gpg に対して署名を検証できなかったためです。通常の原因は keyring が 0 bytes になっていることです。sudo tee が curl のダウンロード失敗前にファイルを切り詰め、パイプの最後の tee が成功したため、パイプ全体が成功として報告されました。gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg を実行してください。正常な keyring では pub の行と、Tailscale を示す uid の行が出力されます。一方、空または破損した keyring では gpg: no valid OpenPGP data found. が出力されます。キーを一時ファイルにダウンロードしてそこで確認し、その後 mode 0644 で所定の場所にコピーしてください。これにより _apt user が読み取れます。

Tailscale URLs にはどの Ubuntu codename を指定すればよいですか?

/etc/os-release の UBUNTU_CODENAME の値を使用してください。Ubuntu 24.04 では noble、Ubuntu 26.04 では resolute です。Ubuntu から派生した distribution で lsb_release -cs は使用しないでください。Linux Mint 22 では wilma と出力され、その名前では Tailscale は何も公開していないため、apt は dists/wilma/InRelease で 404 を報告します。編集前に、https://pkgs.tailscale.com/stable/ubuntu/dists/<codename>/InRelease に対して curl -sS -o /dev/null -w '%{http_code}\n' を使い、手動で index を取得して選択内容を確認してください。

shell にパイプした Tailscale install script を実行しても安全ですか?

この方法を意図的に選択する必要があります。script は Tailscale から提供され、手動手順と同じ処理を行います。/etc/os-release を読み取り、同じ keyring と同じ /etc/apt/sources.list.d/tailscale.list を書き込み、その後 package をインストールします。一方で、その時点で server が返した内容を root で実行し、記録を残さないことになります。-o install.sh でダウンロードして内容を確認し、その後、利便性を優先するなら実行してください。repository がブロックされている場合、この方法でも解決できません。すでに失敗したものと同じ URLs を使用するためです。

apt repository を使わずに Ubuntu に Tailscale をインストールするにはどうすればよいですか?

pkgs.tailscale.com で公開されている static tarballs を使用してください。2026 年 10 月時点では version 1.102.4 で、amd64 file の名前は tailscale_1.102.4_amd64.tgz です。tailscale と tailscaled の programs は自分でインストールし、daemon も systemd で自分で実行します。問題は upgrades です。新しい version を取得する apt package がないため、更新のたびに手動作業が必要です。Ubuntu の archive には独自の tailscale package がないため、vendor repository がない machine では sudo apt install tailscale が E: Unable to locate package tailscale で停止します。