Linux版v2rayNのインストール｜deb/rpmパッケージと自動起動設定

インストール前に確認すること：ディストリビューション、アーキテクチャ、デスクトップ環境

v2rayNは、ノードの管理、コアの起動、プロキシ設定を行うデスクトップクライアントです。deb/rpmパッケージでインストールできるのはアプリ本体で、ノードやサブスクリプションは別途必要です。ターミナルのみで利用するサーバーは、この記事の対象環境ではありません。また、デスクトップクライアントを起動時に動作するシステムサービスとして扱わないでください。

まずターミナルでシステム情報を確認します。UbuntuやDebianでは通常deb、Fedoraでは通常rpmを選びます。CPU名のx86_64はx64、aarch64はarm64に対応します。同じパッケージ形式でも、異なるディストリビューションやアーキテクチャでそのまま使えるとは限りません。

cat /etc/os-release
uname -m
printf 'デスクトップ：%s\nセッション：%s\n' "$XDG_CURRENT_DESKTOP" "$XDG_SESSION_TYPE"

ダウンロードページからLinux用パッケージを選びます。以下のコマンドを実行しやすいよう、ダウンロードしたdebファイルをv2rayN.deb、rpmファイルをv2rayN.rpmにリネームし、そのファイルがあるディレクトリでターミナルを開いてください。これはローカルでのファイル名の取り決めであり、パッケージ内のバージョン、アーキテクチャ、パッケージ名は変わりません。

deb/rpmでインストール：パッケージマネージャーで依存関係を解決

インストール前にパッケージ情報を確認しましょう。アーキテクチャの選択ミスやファイル形式の間違いを事前に見つけられます。Webページの応答内容をインストールパッケージとして扱わないでください。また、依存関係のエラーを無視する強制オプションも使わないでください。

Debian / Ubuntu：aptでローカルのdebをインストール

dpkg-deb -f ./v2rayN.deb Package Version Architecture
sudo apt update
sudo apt install ./v2rayN.deb

./はカレントディレクトリにあるファイルを指定します。省略してリポジトリのパッケージ名として扱うことはできません。単独でdpkg -iを実行する場合と異なり、aptは有効なソフトウェアリポジトリを使って依存関係を解決できます。依存関係のエラーでインストールが中断した場合は、まずsudo apt --fix-broken installの処理内容を確認し、必要なソフトウェアが削除されないことを確かめてから実行してください。

Fedora：dnfでローカルのrpmをインストール

rpm -qp --queryformat '%{NAME} %{VERSION}-%{RELEASE} %{ARCH}\n' ./v2rayN.rpm
sudo dnf install ./v2rayN.rpm

dnfで依存関係が不足していると表示されたら、ディストリビューションのバージョン、リポジトリの状態、パッケージの対象環境を確認してください。DebianのライブラリファイルをFedoraにコピーしたり、依存関係を満たすために共有ライブラリのシンボリックリンクを安易に作成したりしないでください。パッケージを展開できても、アプリが正常に起動するとは限りません。

1. パッケージ情報を確認

   パッケージのVersionとArchitectureを確認します。Debianのamd64とRPMで一般的なx86_64は、どちらもx64アーキテクチャを示します。

2. インストールを完了

   該当するaptまたはdnfコマンドを実行し、ターミナルに表示されたエラー全文を記録してください。「インストール失敗」だけでは原因を特定できません。

3. クライアントを起動

   アプリケーションメニューでv2rayNを検索し、現在のユーザーで起動します。GUIアプリをsudoで起動しないでください。

4. ノードを追加して接続をテスト

   共有リンクをコピーしたら、メインウィンドウのノード一覧を右クリックし、「クリップボードから共有リンクをインポート」を選択します。ノードを選択して「アクティブサーバーに設定」を実行してください。表示文言はバージョンによって多少異なる場合があります。

プロキシ設定：待ち受けを確認してからデスクトップに設定

インストールが完了しただけでは、まだ準備の第一段階です。アクティブノードが利用可能であること、コアが起動していること、ローカルのインバウンドが待ち受けていることも確認してください。「設定」→「パラメーター設定」でローカルの待ち受けポートと関連するインバウンド設定を確認し、クライアントのログで実際の起動状況を調べます。バージョンによって設定の場所が異なる場合があるため、古いスクリーンショットの位置を頼りにしないでください。

以下では、クライアントが127.0.0.1:10808でHTTPプロキシまたは混合インバウンドを提供しているものとします。実際のポートが異なる場合は、デスクトップの設定とテストコマンドの両方を変更してください。そのポートがSOCKS接続のみを受け付ける場合、HTTPプロキシ欄には指定できません。通常、待ち受けアドレスを0.0.0.0に変更する必要はありません。変更すると、他のデバイスからプロキシポートに接続できる状態になるおそれがあります。

HTTPSプロキシ欄は「HTTPSサイトへのアクセスに使用するプロキシ」を意味し、ローカルにTLSプロキシサーバーを構築する必要があるという意味ではありません。HTTPプロキシはCONNECTを使ってHTTPSリクエストを転送できます。また、システムプロキシの設定ですべての通信がプロキシ経由になるわけではありません。ターミナルの一部のプログラム、独立したネットワークコンポーネント、個別にプロキシを設定したアプリは、デスクトップの設定に従わないことがあります。

• プロキシ設定の方法は一つに絞りましょう。クライアントからデスクトップのプロキシを正しく設定できる場合は、クライアントの設定を使います。そうでない場合は、デスクトップの設定画面から手動で入力してください。
• 手動で設定する場合は、localhost,127.0.0.1,::1などのローカルアドレスを除外リストに追加します。区切り文字はデスクトップ環境の画面に表示される指定に従ってください。
• まず通常のシステムプロキシで接続を確認し、追加の権限やルーティング設定が必要なTUNモードは、その後に検討してください。

接続を確認：ポート、リクエスト、ブラウザーを個別にテスト

ノード一覧に表示される遅延時間だけでは、接続全体を検証できません。TCP接続が成功しても、宛先ポートに到達できる可能性があると分かるだけです。実際のプロキシ経由の通信に近い接続テストに加えて、ブラウザーからもアクセスを確認してください。まず待ち受けを調べ、次にプロキシを明示したコマンドでリクエストし、最後にデスクトップアプリがプロキシ設定を読み込んでいるか確認します。

# サンプルポートの待ち受けを確認
ss -lntp 'sport = :10808'

# HTTPプロキシを明示して、デスクトップ設定の影響を避ける
curl --noproxy "" --proxy http://127.0.0.1:10808 \
  --connect-timeout 5 --max-time 15 \
  -I https://example.com/

example.comは公開されているサンプルサイトです。このコマンドはリクエストの経路をテストするためのもので、サブスクリプションURLではありません。HTTPレスポンスヘッダーが返れば、そのリクエストが指定したプロキシ経由で応答を受け取ったことを示します。すべてのサイトやルーティングルールが正常だと確認できるわけではありません。curlがインストールされていない場合、Debian/Ubuntuではsudo apt install curl、Fedoraではsudo dnf install curlを実行してください。

「システムプロキシに従う」設定のブラウザーは、通常、新しい接続を開始すると設定が反映されます。それでも反映されない場合は、ブラウザーを完全に終了してから再起動してください。DNS、ルーティング、ノード、待ち受けポートを同時に変更すると、成功・失敗の原因を特定できなくなります。一度に一項目だけ変更し、リクエストの時刻と対応するログを記録してください。

自動起動：デスクトップのログイン項目を使い、GUIアプリをシステムサービスにしない

ここでいう「起動時の自動起動」は、正確には「ユーザーがデスクトップにログインした後の起動」です。ログイン画面のままでは、ユーザーのデスクトップセッションはまだ開始されていません。v2rayNはGUIセッションとユーザー設定に依存します。システムサービスとして登録してもデスクトップのログイン項目の代わりにはならず、表示環境、権限、設定ディレクトリの不一致を招くおそれがあります。

インストール済みパッケージからデスクトップエントリーを探す

インストールパッケージによってプログラムのパスやデスクトップファイル名が異なる場合があります。Execの値を推測で決め打ちしないでください。以下の2つのコマンドからインストール形式に合う方を選び、パッケージがあるディレクトリで実行して、パッケージのメタデータから実際のデスクトップエントリーを確認します。

# Debian / Ubuntu
pkg=$(dpkg-deb -f ./v2rayN.deb Package)
dpkg -L "$pkg" | grep -E '/applications/[^/]+\.desktop$'

# Fedora
pkg=$(rpm -qp --queryformat '%{NAME}' ./v2rayN.rpm)
rpm -ql "$pkg" | grep -E '/applications/[^/]+\.desktop$'

ファイルマネージャーで確認したv2rayNのデスクトップファイルをコピーし、現在のユーザーの~/.config/autostart/に置きます。ディレクトリがない場合は作成してください。XDG_CONFIG_HOMEを設定している場合は、既定のパスではなく、そのディレクトリ内のautostart/を使います。

mkdir -p "${XDG_CONFIG_HOME:-$HOME/.config}/autostart"

• コピーする前にデスクトップファイルを開き、Exec=がインストール先のプログラムを指していることを確認します。元の引数を保持し、推測したパスに置き換えないでください。
• Hidden=trueやデスクトップ環境を制限するフィールドが含まれていないか確認してください。既存の無効化設定があると、ログイン後に起動しない場合があります。
• GNOMEでは、インストール済みのスタートアップアプリ管理ツールから追加できます。KDE Plasmaでは「システム設定」→「自動起動」からアプリを追加します。設定場所の分類はバージョンによって異なります。
• デスクトップ設定を使う方法とファイルをコピーする方法のどちらか一方を選んでください。ログイン項目を二重に作ると、二重起動やポート競合の原因になります。

設定後、ウィンドウを閉じるだけでなく、一度ログアウトして再ログインするとログイン項目を確認できます。クライアントが1つだけ起動していることを確かめてから、待ち受けポートとプロキシの状態を確認してください。ログイン項目で保証されるのはプログラムの起動だけです。アクティブノードへの自動接続やシステムプロキシの自動設定に対応しているかは、現在のバージョンの設定を個別に確認してください。

よくあるトラブル：依存関係、デスクトップエントリー、ポート競合

トラブルシューティングでは、ディストリビューションのバージョン、アーキテクチャ、パッケージ内のバージョン、エラーの全文を記録してください。何度も再インストールするより効果的です。権限の問題を隠すために管理者としてクライアントを実行しないでください。ユーザー設定がroot所有で保存され、次回の通常起動で設定を保存できなくなるおそれがあります。

アップグレードとロールバック：ユーザー設定を保護し、ログイン項目を確認

今後のアップグレードでも、同じパッケージマネージャーを使って新しいdeb/rpmファイルをインストールします。アップグレード前にクライアントを終了し、クライアントのバックアップ機能を使うか、実際の設定保存先を確認してユーザーデータをバックアップしてください。設定の保存先はバージョンやパッケージ方法によって異なるため、プログラムのディレクトリと同じだと決めつけないでください。バックアップにはサブスクリプションの認証情報が含まれる場合があります。現在のユーザーが管理できる場所に保管してください。

1. 新しいパッケージの対象ディストリビューションとCPUアーキテクチャを確認します。
2. クライアントを終了し、前述の該当するローカルパッケージのインストールコマンドを実行します。
3. クライアントを一度手動で起動し、アクティブノード、待ち受けポート、リクエストの結果を確認します。
4. ユーザーのログイン項目に設定した実行パスを確認し、最後にログアウト・再ログインしてテストします。

一時的に無効にする場合は、まずシステムプロキシをオフにし、次にクライアントを終了してから、デスクトップのログイン項目を無効にします。アンインストールする場合は、前述の手順で調べた実際のパッケージ名を指定してaptまたはdnfで削除してください。ユーザーディレクトリ内のログイン項目のコピーや設定は残ることがあるため、別途確認が必要です。プログラムのアンインストールとデスクトッププロキシ設定の復元は別の作業です。アンインストールすればプロキシ設定も元に戻るとは限りません。