Shadowrocket Linux版のインストール方法｜deb・rpm・AppImageの選び方

この記事の概要

UbuntuやDebianではdeb、Fedoraなどdnfを使うディストリビューションではrpmを選びます。独立したファイルとして使いたい場合はAppImageも選択肢です。まずディストリビューションとCPUアーキテクチャを確認し、パッケージのインストール、実行権限の設定、初回起動、接続確認まで説明します。サービスプロバイダーからサブスクリプションを取得済みであることを前提としています。インストールが完了しても、ネットワーク接続の設定が済んだとは限りません。

1. ディストリビューション・アーキテクチャ・パッケージを確認

ShadowrocketのLinux版は無料です。サイトのダウンロードページにあるLinux欄からパッケージを選んでください。deb、rpm、AppImageは配布形式の違いであり、サブスクリプションが異なるわけではありません。拡張子だけで使用中のCPUに適合するかどうかは判断できないため、ダウンロード前にディストリビューション、パッケージのアーキテクチャ、ページに記載された動作要件を確認しましょう。

まずターミナルを開き、次の2つのコマンドを実行します。/etc/os-releaseはディストリビューションの確認に、uname -mは現在のカーネルのアーキテクチャ確認に使います。よく使われるx86_64とaarch64は互換性がありません。また、パッケージ管理ツールではそれぞれamd64、arm64と表記される場合があります。

cat /etc/os-release
uname -m

Ubuntu、Debianおよび互換ディストリビューション：debを選び、aptでローカルファイルをインストールします。依存関係はパッケージ管理ツールが処理します。
Fedoraなどdnfを使うディストリビューション：rpmを選び、dnfでインストールします。拡張子が同じだからといって、RPM系のすべてのディストリビューションで同じパッケージが使えるとは限りません。
その他のデスクトップ向けディストリビューション：AppImageのアーキテクチャと動作環境の要件を確認してください。AppImageでも、あらゆるLinux環境で実行できるとは限りません。

2. aptでローカルのdebファイルをインストール

以下のコマンドはBashで実行します。ダウンロードしたdebファイルを見つけやすい場所に置き、ファイルマネージャーのプロパティなどで完全な絶対パスを確認してください。パスを入力するときに引用符で囲んだり、ブラウザーのダウンロードリンクをローカルパスとして使ったりしないでください。コマンド内の変数参照がパスに含まれる空白を処理します。

read -r -p "debファイルの完全な絶対パスを貼り付けてください：" pkg
test -f "$pkg" && sudo apt install "$pkg"

apt installの後ろにローカルファイルのパスを指定すると、そのファイルをインストールします。同じ名前のアプリをソフトウェアリポジトリから検索するわけではありません。絶対パスを使えば、作業中のディレクトリが違うためにファイルが見つからない問題を避けられます。ターミナルでパスワードを求められた場合は、現在のLinuxユーザーの認証パスワードを入力します。入力中は通常、文字が表示されません。

ファイルを確認

ダウンロードページでdebを選び、ブラウザーのダウンロードが完了するまで待ちます。ダウンロード中の一時ファイルではないことを確認し、ページに記載されたアーキテクチャも確認してください。
インストールを実行

ターミナルのプロンプトに完全なパスを貼り付けてEnterキーを押します。aptが表示するインストール・更新・削除の項目を確認してから、続行してください。
依存関係を解決

依存関係を満たせないというメッセージが表示されたら、まずsudo apt updateを実行し、元のインストールコマンドを再度試してください。それでも失敗する場合は、不足している依存パッケージ名を記録し、依存関係を無視して進めないでください。
初回起動

インストール後、デスクトップのアプリケーションメニューでShadowrocketを検索し、通常のユーザーとして起動します。メニューがすぐに更新されない場合は、デスクトップに再ログインしてから確認してください。

パッケージのアーキテクチャが合わないというメッセージが表示された場合は、強制インストールを使わず、ダウンロードページで適切なパッケージを選び直してください。ライブラリのバージョンが古いというエラーは、ソフトウェアリポジトリを更新しても解決しない場合があります。現在のディストリビューションが提供するシステムライブラリでは、要件を満たせない可能性があります。対応環境を確認し、アプリ1つをインストールするためにシステムの中核ライブラリを安易に置き換えないでください。

3. dnfでローカルのrpmファイルをインストール

dnfを使うシステムでも、debの場合と同様に、ダウンロード済みのローカルファイルを明示してディストリビューションのパッケージ管理ツールに依存関係を解決させます。以下も絶対パスを使用します。ファイル名を変更する必要はなく、ダウンロードしたファイル名をあらかじめ決めておく必要もありません。

read -r -p "rpmファイルの完全な絶対パスを貼り付けてください：" pkg
test -f "$pkg" && sudo dnf install "$pkg"

確認項目が表示された場合：依存関係の入手元と処理内容を確認してください。デスクトップの重要なコンポーネントが誤って削除されないことを確かめてから続行します。
依存関係が見つからないと表示された場合：まずシステムのソフトウェアリポジトリが利用可能か確認します。sudo dnf makecache --refreshでメタデータを更新してから、インストールを再度試してください。
アーキテクチャまたはディストリビューションに互換性がないと表示された場合：インストールを中止し、ダウンロードページの要件を確認してください。依存関係を無視したり、システムファイルを強制的に置き換えたりしてエラーを回避しないでください。
完全性・署名・信頼性に関するエラーが表示された場合：エラーメッセージを保存し、ファイルがサイトのダウンロード手順で取得されたものか確認してから、再ダウンロードしてください。パッケージ管理ツールのセキュリティチェックを無効にしないでください。

インストールが成功した時点では、パッケージファイルと依存関係がシステムに配置されたにすぎず、プロキシが有効になったわけではありません。まずアプリケーションメニューからShadowrocketを起動し、サブスクリプションの追加と接続設定を行ってください。トラブルシューティングでは、「アプリのインストールに失敗する」問題と「インストール後にリクエストが失敗する」問題を分けて扱い、原因がネットワークにある場合に再インストールを繰り返さないようにしましょう。

4. AppImageに実行権限を付与して起動

AppImageは通常、aptやdnfでシステムパッケージとして登録せず、独立したファイルとして実行します。ファイルを個人用の固定ディレクトリに移動してから、実行権限を付与することをおすすめします。ブラウザーの一時ディレクトリから起動し続けると、ダウンロードファイルの整理時にアプリも削除されるおそれがあります。

read -r -p "AppImageファイルの完全な絶対パスを貼り付けてください：" app
if test -f "$app"; then
  chmod u+x "$app" && "$app"
fi

chmod u+xはファイルの所有者に実行権限を付与します。続くコマンドでファイルを直接起動します。通常の起動にsudoは必要ありません。デスクトップ環境から起動しても反応がない場合は、何度もダブルクリックするより、ターミナルに表示されたエラーを確認すると原因を特定しやすくなります。

ファイルの実行条件

実行権限: chmod u+xで付与
ファイルの保存場所: 安定した個人用ディレクトリに置く
CPUアーキテクチャ: ダウンロードページの記載と本機のアーキテクチャが一致
起動時のユーザー: 通常のデスクトップユーザーとして実行

独立したファイルでも、ホストシステムの互換環境に依存します。

よくあるエラーの確認ポイント

Permission denied: 実行権限とマウントオプションを確認
Exec format error: アーキテクチャとファイルの完全性を優先して確認
FUSE関連のエラー: ディストリビューションに適合する実行コンポーネントを確認
共有ライブラリの不足: 動作要件とシステムライブラリのバージョンを確認

エラーの内容に応じて対処し、アプリ全体の権限を上げて診断の代わりにしないでください。

ファイルがあるパーティションにnoexecマウントオプションが設定されていると、実行権限を付与していても起動できないことがあります。実行可能な個人用ディレクトリにファイルを移動して、再度試してください。FUSE関連コンポーネントの名称はディストリビューションによって異なります。まずシステムのパッケージ情報を確認し、別のディストリビューション向けのインストールコマンドをそのまま実行しないでください。

5. 初回起動後にサブスクリプションを追加して振り分けを確認

まずアプリのウィンドウが正常に表示されることを確認してから、ネットワークを設定します。サブスクリプションリンクはサービスプロバイダーから入手し、機密情報として保管してください。該当する項目が画面にある場合は、Home右上の「+」からTypeにSubscribeを指定し、リンクを入力して保存後、サブスクリプションを更新します。デスクトップ版のレイアウトがモバイル版と異なる場合は、現在の画面に表示されている項目を使ってください。

追加後、想定した項目がリストに表示されているか確認し、既存の項目を1つ選んで接続します。サブスクリプション名が表示されていても、更新が成功したとは限りません。リストが空の場合は、まずサブスクリプションのリクエストエラーを解決してください。Configの構成ファイルとHomeのサーバー項目は別のものです。サーバーを追加しても、ルールが利用目的に合うとは限りません。

Config

推奨

現在選択している構成ファイルに従って、プロキシ対象になったリクエストを処理します。ルールは上から順に照合され、プロキシと直接接続のどちらを使うかは一致したルールとポリシーによって決まります。地域によって一律に決まるわけではありません。

おすすめの用途：構成ファイルを確認したうえで日常的に振り分ける場合

Proxy

プロキシ対象のリクエストをプロキシ経由にします。Configの設定と短時間比較するときに便利です。もともとプロキシ対象ではないアプリの通信が、自動的に対象になるわけではありません。

おすすめの用途：プロキシ接続とルール照合のどちらに問題があるか切り分ける場合

Direct

プロキシ対象のリクエストを直接接続にします。直接接続とプロキシ経由の違いを確認するには、同じ接続先と同じアプリを使ってテストしてください。

おすすめの用途：短時間の直接接続テストを行う場合

ルールの確認では、まず以下3行の意味を確認します。これは構文例であり、完全な構成ファイルではありません。PROXYは現在の構成に存在する有効なポリシーに対応している必要があります。例を既存の構成に上書きしたり、実在するWebサイトがどの経路を使うか判断するために使ったりしないでください。

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX：指定したドメインのサフィックスに一致します。例のドメインは構文の説明用です。
IP-CIDR：接続先のIPアドレス範囲に一致します。例にはプライベートアドレス範囲を使っています。
FINAL：それ以前のルールに一致しない場合に使われる最終ポリシーです。ルールの末尾に記述してください。

Linuxでは、「プロキシアプリが実行中」であることと「接続先のアプリがプロキシを使っている」ことを区別する必要があります。システムの通信がアプリによって処理されるか、ブラウザーやターミナルで個別の設定が必要かは、現在有効なネットワークモードによって異なります。画面にローカルの待ち受けアドレスとポートが表示される場合は、実際の値を設定してください。ポート番号が常に特定の値だと決めつけないでください。

6. インストール後によくある問題への対処

AppImageをダブルクリックしても起動しません。再インストールが必要ですか？

まず第4章の手順でターミナルから実行し、エラー出力を確認してください。Permission deniedの場合は、実行権限とnoexecを確認します。FUSEや共有ライブラリのエラーが出た場合は、ディストリビューションに合わせて実行コンポーネントを確認してください。エラーメッセージを確認する前に、ダウンロードしたパッケージが原因だと決めつけないでください。

初回起動時にシステムの認証ダイアログが表示されたら、どうすればよいですか？

まず、要求元と操作内容を確認してください。パッケージのインストール時に求められる管理者認証と、実行時にネットワーク設定を変更するための認証は別のものです。直前に該当する操作を行い、表示内容がその操作に合っている場合にのみ許可してください。ダイアログを消すために、グラフィカルアプリを常にroot権限で実行しないでください。

ブラウザーではWebページを開けるのに、ターミナルからのリクエストが失敗する場合は？

ターミナルが直接接続のままになっていないか、古いプロキシ環境変数が残っていないか確認してください。env | grep -i proxyを実行して確認し、現在の待ち受けアドレスとポートを照合できます。HTTPプロキシとSOCKSプロキシは種類を混同しないでください。設定を変更したら、同じターミナルセッションで再度テストします。

サブスクリプションの更新に失敗したら、インストール形式を変える必要がありますか？

まずインストール形式を変える必要はありません。サブスクリプションリンクが完全か、有効期限が切れていないか、現在のネットワークからリンク先にアクセスできるかを確認し、返される内容についてサービスプロバイダーに問い合わせてください。エラーを記録する際は、リンク内のtokenなどの認証情報を隠し、サブスクリプションリンク全体をスクリーンショットやログに載せないようにしてください。

確認では、一度に変更する条件を1つにしてください。たとえば同じブラウザーと接続先を使い、まずDirect、次にProxyでテストしてから、Configでルールを確認します。ブラウザーでは成功してターミナルでは失敗する場合は、まずアプリごとのプロキシ設定の違いを確認してください。両方とも失敗する場合は、再インストールを繰り返すのではなく、接続状態、DNS、サービスプロバイダーから提供された設定を確認します。

7. 今後の更新と削除に関する注意点

ローカルのdebまたはrpmをインストールしても、アプリの更新用ソフトウェアリポジトリがシステムに登録されるとは限りません。新しいパッケージを入手するときは、引き続きサイトのダウンロードページを確認し、アプリを終了してから対応する方法でインストールしてください。AppImageは独立したファイルとして保管します。入れ替える前に古いプロセスを終了し、デスクトップのショートカットが古いパスを参照していないか確認してください。

更新前：自分の構成をバックアップし、サブスクリプション情報を安全に保管してください。パッケージ管理ツールによるプログラムファイルの更新は、個人設定のバックアップにはなりません。
deb / rpmの削除：まずグラフィカルなソフトウェア管理ツールのインストール済み一覧でパッケージ名を確認してから削除してください。アプリの表示名からシステムのパッケージ名を推測しないでください。
AppImageの削除：プロセスを終了してから該当ファイルを削除し、自分で作成したショートカットも確認してください。プログラムファイルを削除しても、ユーザー設定が同時に削除されるとは限りません。
ネットワーク設定を元に戻す：ブラウザーやターミナルにローカルプロキシを手動設定していた場合は、アプリの終了後に設定を元に戻してください。そのままでは、リクエストが停止済みの待ち受けポートに送信され続けることがあります。

インストール形式は、ディストリビューション、アーキテクチャ、メンテナンス方法に合わせて選びます。インストール時の問題はパッケージ管理ツールやターミナルのエラーを確認し、接続時の問題はサブスクリプション、通信の対象範囲、振り分け設定を確認してください。2つの確認手順を分けることで、不要な再インストールを減らし、診断に役立つ情報を残せます。