この記事では、Shadowrocket Linux版をインストールする前のディストリビューションとアーキテクチャの確認、deb・rpmのインストールコマンド、AppImageへの実行権限の付与、初回起動後の設定確認について説明します。利用中のサービス事業者から提供された情報やサブスクリプションをお持ちで、Linuxデスクトップにクライアントをインストールする方向けです。まずシステムとインストールパッケージの適合を確認し、その後に依存関係を処理します。アプリが起動するかどうかと、接続できるかどうかは別々に確認してください。
1. ディストリビューション・アーキテクチャ・パッケージ形式を確認
Shadowrocket Linux版のインストールパッケージは、当サイトの全プラットフォームのダウンロードページから選択してください。deb、rpm、AppImageは異なる配布形式であり、プロキシプロトコルや接続プランの違いを示すものではありません。デスクトップの見た目だけでディストリビューションを判断しないでください。GNOMEやKDEはデスクトップ環境であり、それだけでaptとdnfのどちらを使うかは決まりません。
まずターミナルで以下の読み取り専用コマンドを実行します。1つ目でシステム情報、2つ目でプロセッサのアーキテクチャを確認できます。調査のために出力を共有する場合、通常必要なのはディストリビューション名、アーキテクチャ、エラーメッセージだけです。アカウント情報を提供する必要はありません。
cat /etc/os-release
uname -mシステムを確認
- NAME / ID
- /etc/os-releaseを読み取り、実際のディストリビューション名を確認します。
- ID_LIKE
- ディストリビューションの系統を判断する参考情報です。各ディストリビューション固有のパッケージ管理方法の代わりにはなりません。
- uname -m
- x86_64とaarch64は異なるアーキテクチャです。対応するインストールパッケージを選んでください。
ダウンロードページに掲載されているアーキテクチャを基準にしてください。パッケージ形式を変えても、アーキテクチャの不一致は解消しません。
パッケージ形式を選択
- Debian / Ubuntu
- debを選び、aptでローカルファイルをインストールして依存関係を処理します。
- Fedora系
- rpmを選び、dnfでローカルファイルをインストールして依存関係を処理します。
- その他のディストリビューション
- AppImageの対応状況を確認し、アーキテクチャと実行環境もチェックしてください。
AppImageもシステムライブラリ、デスクトップ環境、ランタイムの条件に左右されるため、すべてのLinuxシステムで使えるわけではありません。
コンテナ、GUIのないサーバー、リモート端末でシステムを実行している場合、インストールに成功してもデスクトップアプリを実行できるとは限りません。まず、現在のセッションでGUIアプリを起動できることを確認してから、クライアントの設定を進めてください。この記事はLinuxデスクトップを対象としており、デスクトップアプリのインストール手順はサーバーサービスの構築手順とは異なります。
2. Debian / Ubuntu：aptでローカルのdebをインストール
ダウンロードページでアーキテクチャに合ったdebを選び、ダウンロードしたファイルの絶対パスを確認してください。以下のコマンドはBashで1行ずつ実行します。プロンプトが表示されたら、実際の絶対パスを入力してください。たとえば、ファイルマネージャーからパスをコピーして貼り付けます。入力したパスの前後に余分な引用符を付けないでください。コード内の変数に実際のファイルパスが入るため、パッケージのファイル名を推測する必要はありません。
read -r -p "debファイルの絶対パスを入力: " deb_path
dpkg-deb -f "$deb_path" Package Architecture
sudo apt update
sudo apt install "$deb_path"dpkg-deb -fはパッケージ内のメタデータを読み取るだけで、インストールは行いません。一般的なアーキテクチャの対応は、システムがx86_64と表示する場合はパッケージのamd64、システムがaarch64と表示する場合はarm64です。最終的にはダウンロードページに掲載されたパッケージと照合してください。値が明らかに一致しない場合は、インストールを中止してパッケージを選び直してください。
- 絶対パスを使用：
apt installでローカルファイルとして認識させる必要があります。相対パスを使う場合は、ファイル名だけでなく./から始めてください。 - 依存関係の処理内容を確認：aptはインストール、アップグレード、削除する項目を表示します。デスクトップのコンポーネントが多数削除される計画が表示された場合は、いったん中止し、ソフトウェアソースとディストリビューションへの対応状況を確認してください。
- ダウンロードエラーと依存関係エラーを区別：ファイルを読み込めない場合はパスを確認します。依存関係を解決できない場合は、ソフトウェアソースが利用可能か、システムがサポート対象かを確認してください。同じコマンドを繰り返し実行しないでください。
dpkg -iの実行後に依存関係エラーが表示されても、アプリを使える状態になったとは限りません。dpkgはパッケージのインストール状態を管理しますが、aptのようにソフトウェアソースから依存関係を解決して取得することはありません。インストール後、未設定のパッケージに関するエラーがターミナルに残っていないことを確認し、アプリ一覧からShadowrocketを起動してください。
3. Fedora系：dnfでローカルのrpmをインストール
rpmも拡張子だけでなく、まずアーキテクチャを確認してください。Fedora系では通常、dnfを使ってローカルのrpmとその依存関係を処理します。rpmを採用する他のディストリビューションには、独自のパッケージ管理ツールや依存関係の命名規則がある場合があります。拡張子が同じだからといって、Fedoraのソフトウェアソース設定をそのまま使わないでください。
read -r -p "rpmファイルの絶対パスを入力: " rpm_path
rpm -qp --queryformat '%{NAME} %{ARCH}\n' "$rpm_path"
sudo dnf install "$rpm_path"照会コマンドでは、ダウンロードしたパッケージを照合しやすいように、名前とアーキテクチャだけを表示します。dnfのトランザクション確認画面には、インストール対象と依存関係の取得元が表示されます。パッケージが当サイトのダウンロードページから入手したもので、アーキテクチャが一致し、依存関係の処理内容に問題がない場合にのみ続行してください。パッケージの競合が発生した場合はエラー出力を保存し、依存関係を無視したり強制上書きしたりするオプションで問題を隠さないでください。
No such file or directoryと表示された場合は、ブラウザーのダウンロード履歴に表示された名前ではなく、ファイルの実際のパスを入力しているか確認してください。- 依存関係を解決できない場合は、現在のディストリビューションのソフトウェアソースと対応要件を確認してください。他のディストリビューションからシステムライブラリを安易にコピーしないでください。
- インストール後は通常ユーザーとしてGUIアプリを起動してください。インストール時にsudoを使ったからといって、アプリの実行にもsudoが必要になるわけではありません。
4. AppImage：実行権限を付与してターミナルから起動
AppImageは通常、aptやdnfを使ってシステムに登録する必要はありません。まず、現在のユーザーが書き込み可能で、長期的に保存できる場所にファイルを置き、実行権限を付与してください。ファイルをブラウザーの一時ディレクトリに置いたままにすると、ダウンロードファイルの整理後に起動できなくなることがあります。ファイルを移動した場合、既存のデスクトップショートカットのパスも更新が必要になることがあります。
read -r -p "AppImageファイルの絶対パスを入力: " app_path
chmod u+x "$app_path"
"$app_path"chmod u+xはファイルの所有者にのみ実行権限を追加します。最後の行でファイルを直接実行すると、起動エラーをターミナルに表示できるため、ダブルクリックしてもウィンドウが開かない場合の調査に役立ちます。デスクトップクライアント全体をsudoで起動しないでください。また、ファイルのアクセス権を過度に広げても、一般的な解決策にはなりません。
- Permission denied：実行権限だけでなく、ファイルが
noexecオプションでマウントされたパーティションにある可能性もあります。システムのマウント設定を変更する前に、実行可能なユーザーディレクトリへファイルを移して再試行してください。 - Exec format error：まずアーキテクチャを確認してください。実行権限を追加しても、x86_64とARMアーキテクチャを切り替えることはできません。
- FUSE関連のエラー：一部のAppImageランタイムでは、互換性のあるFUSEユーザー空間ライブラリが必要です。現在のディストリビューションの説明に従って依存関係を確認し、既存のFUSEコンポーネントを安易に削除または置き換えないでください。
- GLIBC関連のエラー：実行環境がパッケージの要件を満たしていない可能性があります。システムのlibcを手動で上書きしないでください。対応要件を確認し、適合するパッケージまたはサポート対象のシステム環境を選んでください。
AppImageファイルに実行権限を付与しても、自動的にシステムサービスになるわけではありません。また、自動更新やデスクトップメニューとの連携が備わっているとは限りません。更新する場合はダウンロードページで入手方法を確認し、実行中のインスタンスを終了してから、パッケージの説明に従ってファイルを置き換えてください。
5. 初回起動：インストールの問題と接続の問題を切り分ける
ウィンドウが開くなら、ローカルでの実行確認の一部は完了しています。その状態でWebページにアクセスできない場合は、すぐにパッケージを入れ替えて再インストールするのではなく、接続情報、ルーティングモード、システムのネットワーク設定を確認してください。以下の手順は、ご自身が利用するサービス事業者とサブスクリプションをすでにお持ちであることを前提としています。サブスクリプションURLには認証情報が含まれることがあるため、スクリーンショットやログを共有する前にURL全体を隠してください。
-
起動を確認
アプリ一覧またはAppImageファイルからShadowrocketを起動し、ウィンドウが開いた状態を保てることを確認してください。すぐに終了する場合は、まずターミナルから同じ操作を行ってエラーを記録します。サブスクリプションの調査には進まないでください。
-
接続情報を追加
Home → + → Type → Subscribeを選び、ご自身のサブスクリプションURLを入力して保存します。URLの形式は
https://example.com/sub?token=xxxxのようになります。これは書式の例であり、接続には使用できません。実際の操作画面は、現在のLinux版ビルドに表示される内容を確認してください。 -
設定を確認
サブスクリプションの更新後、想定した項目が一覧に表示されることを確認し、Configで現在の設定とポリシー参照を確認します。サブスクリプションの取得失敗と、登録済みの接続項目が利用できない問題は別々に調査し、それぞれのエラー情報を保存してください。
-
ルーティングを確認
Home → Global Routingで現在の選択を確認してください。設定ルールを検証する場合はConfigを使い、設定内のポリシー名が有効であることを確認します。Directの状態でプロキシ接続が機能するかどうかを判断しないでください。
Home、Config、Global Routingは該当機能を見つけるための項目です。プラットフォームごとに画面上の表示が異なる場合があります。モバイル版のメニューを探すためにLinuxパッケージを繰り返しインストールしないでください。システムプロキシとアプリ内ルーティングも別のレイヤーです。クライアントの処理対象になった接続だけがルーティングモードの影響を受けます。クライアントのスイッチだけを見て、すべてのデバイス通信が処理されていると判断することはできません。
6. インストール後のGlobal Routingの選び方
パッケージ形式によってルールの判定方法が変わることはありません。インストール後はGlobal Routingを使い、「接続自体の問題」か「設定ルールが適用されていない問題」かを切り分けられます。以下ではShadowrocket内のルーティングモードだけを比較します。テスト前に、ご自身の有効な接続情報が読み込まれていることを確認してください。
Config
推奨現在の設定にあるルールとポリシーに従って接続を処理します。ルールを使ってもすべての接続がプロキシ経由になるわけではありません。実際の処理結果は、適用されたルール、ポリシーの宛先、設定内のフォールバック処理によって異なります。
適した用途：確認済みの設定を使い、ルールに従って日常的に接続する場合。
Proxy
クライアントの処理対象となる接続を、選択したプロキシポリシーに渡します。ルール判定による影響を抑えて調査できますが、OS上のすべての通信が必ず処理されるわけではありません。
適した用途：選択した接続と設定ルールの違いを短時間で確認する場合。
Direct
クライアントの処理対象となる接続を直接接続として処理します。DNS、システムファイアウォール、物理ネットワークの問題を修復する機能ではなく、プロキシ接続が利用可能であることを確認する用途にも使えません。
適した用途：プロキシ経路の影響を除外し、ローカルネットワークへの到達性を比較確認する場合。
ProxyではアクセスできてConfigでは失敗する場合、debやrpmを再インストールするのではなく、Configでルールの順序とポリシー参照を確認してください。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレスの範囲、GEOIPはIPアドレスの地域情報に基づいて照合します。FINALは最終的なフォールバックルールです。これらのルールの動作は、実際の設定と接続情報によって異なります。
7. インストール・アップデートに関するよくある質問
debをダウンロードしたのに、aptで見つからないのはなぜですか？
aptに渡している値がローカルファイルのパスか確認してください。絶対パスを使うか、ファイルのあるディレクトリに移動して./から始まる相対パスを指定します。ファイル名だけを入力すると、ソフトウェアソース内のパッケージ名として解釈される場合があります。ブラウザーのダウンロードが完了していることも確認してください。
AppImageをダブルクリックしても反応しません。再ダウンロードが必要ですか？
まずターミナルでこの記事の権限付与と起動のコマンドを実行し、実行権限、アーキテクチャ、ランタイムに関するエラーを切り分けてください。FUSEまたはGLIBCに関するエラーが表示される場合は、該当する環境要件に対処します。同じファイルを再ダウンロードしても、通常はシステムの依存関係は変わりません。
アップグレード時にdebからAppImageへ切り替えられますか？
まずアプリのエクスポート機能で設定をバックアップし、古いインスタンスを終了してください。パッケージ形式によって設定の保存場所、起動方法、デスクトップとの連携が異なる場合があり、自動で移行されるとは限りません。新しいインスタンスが使えることを確認してから、古いパッケージをアンインストールするか判断し、2つのインスタンスを誤って同時に起動しないようにしてください。
インストールは完了したのに、サブスクリプションの更新に失敗し続けるのはなぜですか？
サブスクリプションURL全体、ネットワークへの到達性、サービス事業者から返されたエラーを確認してください。ターミナルや公開ログにtokenを漏らさないでください。ウィンドウが起動し、ローカル設定を読み込める場合は、ネットワークタイムアウトをパッケージ形式の問題と決めつけず、まずサブスクリプションの取得経路を調べてください。
インストールの問題を報告する際は、ディストリビューション名、uname -mの出力、選択したパッケージ形式、実行したコマンド、エラーメッセージ全文をまとめてください。アプリのインストール先や実行ファイル名を推測で決めつけないでください。また、パスワード、PrivateKey、サブスクリプションtokenを含む設定を、そのまま問題の説明に添付しないでください。