SSD Nodes Learn 🎉 VPS $5.50/月〜
ガイド Matt Connor著者 Matt Connor ・更新日 2026-08-13

UbuntuでTailscaleをインストールできないときの対処法

UbuntuでTailscaleのインストールに失敗したら、aptが表示したステータスコードと完全なURLを確認します。リリースのcodenameや署名用keyringの問題を切り分ける方法を解説します。

Ubuntu で Tailscale のインストールが失敗するのは apt のエラーです

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

このリポジトリを追加すると、2 つのファイルが書き込まれます。一方のファイルには、パッケージの格納場所を apt に伝えます。もう一方のファイルには、リポジトリインデックスの署名を検証するために apt が使用する公開鍵が保存されます。以下に示す失敗のほとんどは、この 2 つのファイルのいずれかが正しくないか、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 のコードネームで、2 つの 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 経由でアクセスするリポジトリのベース URL pkgs.tailscale.com/stable/ubuntu、スイート noble、コンポーネント main が続きます。apt はベース URL とスイートを結合して 1 つの 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 年 8 月に確認した時点では、noble は Origin: Tailscale と Codename: noble を含む署名済みインデックスを返します。noble を実際のエラーに表示された codename に置き換え、もう一度実行します。apt ではエラーになった箇所で curl が 200 を返す場合、リポジトリは正常で、問題は 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 では、このコマンドが Mint 独自のコードネームである wilma を出力します。Tailscale はこのコードネーム用のパッケージを公開していません。Ubuntu のベースリリースを確認してください。

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

Ubuntu では、2 つの値は同じです。派生ディストリビューションでは、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 コマンドを再実行し、両方のファイルを上書きして修正してください。

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

シェルはどちらのプログラムより先にパイプライン全体を構築します。そのため、sudo tee は直ちに keyring のパスを開き、サイズを 0 byte に切り詰めます。その後 curl が失敗し、-f によって HTTP エラー時にも失敗する設定になっていると、curl は何も書き込まず、ゼロ以外の終了ステータスで終了します。ファイルは 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 をダウンロードした後、それを拒否します。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 が表示されなければ停止し、ファイルをコピーしないでください。0644 モードは重要です。apt は取得と検証のために非特権ユーザーの _apt へ切り替えるため、root だけが読み取れる keyring は apt が使用できません。

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

Ubuntu 24.10 では、Ubuntu 自身のソースが deb822 形式へ移行し、/etc/apt/sources.list が /etc/apt/sources.list.d/ubuntu.sources になりました。Tailscale は引き続き 1 行形式を公開しています。2026 年 8 月時点で、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 が、そのリポジトリで使用する keyring を判断できないためです。apt は E: Conflicting values set for option Signed-By regarding source と表示し、続けてリポジトリとその suite、!= を挟んだ 2 つの 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/

ファイルは 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 は、そのサブコマンドより前のバージョンです。そのため、ヘルプの表示を確認すれば、使用中の 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 にはリポジトリのベース URL までを指定します。dists/noble の部分まで貼り付けると 404 になります。apt は dists/<suite> を自動的に追加し、dists/noble/dists/noble を要求するためです。
  • Suites はコードネームです。1 行形式の中央に記述されていた値とまったく同じものを指定します。
  • Signed-By には、keyring ファイルの絶対パスを指定します。ここには armored key をインラインで記述することもできます。その場合、key の各行を 1 個のスペースでインデントし、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 の認証局ではなく、プロキシによって発行されたものだからです。もう 1 つの一般的な原因は、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 が表示される場合、resolver ライブラリが IPv6 を優先している一方で、サーバーに正常な IPv6 経路がないため apt は失敗しています。次のコマンドで 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 からディストリビューションを判定し、このガイドで修正してきたものと同じ /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 年 8 月時点の安定版は 1.102.2 で、64 bit x86 用ファイルは tailscale_1.102.2_amd64.tgz です。tailscale クライアントと tailscaled デーモンを自分で配置し、デーモンも自分で監視するため、apt upgrade パスはありません。また、以後の更新は毎回ダウンロードする必要があります。エアギャップ環境のホストや、特定のバージョンを厳密に固定する必要がある場合には、この方法を選ぶ理由があります。

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

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 リポジトリは署名されていないと表示するのはなぜですか？

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. が出力されます。キーを一時ファイルにダウンロードしてそこで確認し、mode 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 を報告します。編集する前に、https://pkgs.tailscale.com/stable/ubuntu/dists/<codename>/InRelease に対して curl -sS -o /dev/null -w '%{http_code}\n' でインデックスを手動取得し、選択が正しいことを確認してください。

シェルにパイプして Tailscale のインストールスクリプトを実行しても安全ですか？

これは、意図的に判断すべきトレードオフです。スクリプトは 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 で停止します。

#tailscale#apt#troubleshooting#gpg-keys#ubuntu