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

Linuxにv2rayNをインストールする際、いきなりコマンドを実行するのではなく、まず使用するパッケージ形式を確認します。Debian、Ubuntuとその主要な派生版は通常debパッケージを使用し、Fedora、openSUSEなどRPMパッケージ体系のディストリビューションはrpmパッケージを使用します。形式を間違えても、システムが自動的に別形式へ変換することはありません。

CPUアーキテクチャも確認が必要です。一般的なデスクトップPCでは x86_64 と表示され、ダウンロードページではx64に対応する場合があります。一部の端末では aarch64 または arm64 と表示されます。インストールパッケージのアーキテクチャはシステムと一致させてください。不一致の場合、パッケージマネージャーがエラーを表示するか、起動時にプログラムが終了します。

uname -m
cat /etc/os-release

uname -m でCPUアーキテクチャを確認できます。/etc/os-release にはディストリビューション名、バージョン、識別情報が記載されています。GNOMEやKDE Plasmaなどのデスクトップ環境は複数のディストリビューションに導入できるため、見た目だけでシステムの種類を判断しないでください。

DebianとUbuntuでは、次のコマンドでパッケージマネージャーが認識しているアーキテクチャを確認できます。

dpkg --print-architecture

FedoraとopenSUSEでは、RPMでアーキテクチャを確認できます。

rpm --eval '%{_arch}'

v2rayNはデスクトップクライアントです。この記事の起動、システムプロキシ、自動起動の手順は、グラフィカルなデスクトップセッションがあるLinuxシステムを前提としています。端末環境しかない端末では、デスクトップクライアントは適切な構成とはいえません。インストールできても、グラフィカルセッションや表示サービス、デスクトップコンポーネントが不足しているとメインウィンドウを開けない場合があります。

ダウンロード前に確認する4項目

  • ディストリビューション体系:debとrpmのどちらを使うかを確認し、ファイルのアイコンだけで判断しないでください。
  • CPUアーキテクチャ:パッケージのアーキテクチャを uname -m の結果に合わせます。
  • デスクトップセッション:GNOME、KDE Plasmaなどのデスクトップ環境に正常にログインできることを確認します。
  • 旧バージョンの状態:v2rayNをインストール済みの場合は、アップグレードまたは再インストールの前に起動中のクライアントを終了します。

インストールパッケージは、当サイトのクライアント入手ページからダウンロードしてください。ダウンロード後、まずファイルマネージャーでファイルがダウンロードディレクトリにあることを確認してから、端末を開きます。ブラウザーによって「ダウンロード」ディレクトリ、指定したディレクトリ、前回使用したディレクトリなど保存先が異なるため、端末で指定するパスを実際の保存場所に合わせてください。

Debian・Ubuntuでdebパッケージをインストール

DebianとUbuntuでは、ローカルのdebパッケージに対して apt install を使う方法を優先します。dpkg -i を単独で実行する場合と異なり、APTはパッケージが宣言する依存関係を解析し、現在設定されているソフトウェアソースから依存パッケージを補います。コマンド内の ./ は重要です。現在のディレクトリにあるローカルファイルを指定するもので、同名のソフトウェアソース上のパッケージを検索する指定ではありません。

手順1:ダウンロードディレクトリに移動してファイル名を確認

cd ~/Downloads
ls -lh v2rayN*.deb

一部の日本語デスクトップ環境ではダウンロードディレクトリがローカライズされた名前で表示されますが、実際のパスはXDGユーザーディレクトリの設定で決まる場合があります。~/Downloads が存在しない場合は、まず実際のダウンロード先を確認します。

xdg-user-dir DOWNLOAD

次に、コマンドが返したディレクトリへ移動します。ls を実行すると、完全なdebファイル名が表示されます。バージョン更新でファイル名が変わることがあるため、現在端末に保存されている名前を使ってください。

手順2:APTでローカルパッケージをインストール

sudo apt update
sudo apt install ./v2rayN-linux-64.deb

上記のファイル名はコマンドの構造を示す例です。ダウンロードしたファイル名が異なる場合は、コマンド末尾を端末に表示された完全な名前へ変更してください。sudo のパスワード入力中に、端末にアスタリスクやドットが表示されないのは正常です。入力後にEnterキーを押してください。

apt update はパッケージソースのインデックスを更新するだけで、システム全体を自動更新するものではありません。インデックスを更新すると、「依存パッケージは存在するが現在のインデックスに見つからない」という問題を減らせます。ネットワークが一時的に利用できず、依存パッケージも未導入の場合、APTは必要なコンポーネントを補えません。

手順3:dpkg実行後に残った依存関係を解決

以前に sudo dpkg -i を実行し、「依存関係の問題」や「パッケージが未設定」と表示された場合、同じdpkgコマンドを繰り返す必要はありません。まずAPTで未完了の依存関係を修復します。

sudo apt --fix-broken install
sudo dpkg --configure -a

1つ目のコマンドは不足している依存パッケージを確認してインストールし、2つ目のコマンドは展開済みだが設定が完了していないパッケージの設定を続行します。完了後、ローカルdebのインストールコマンドを再実行します。依存パッケージが見つからない場合は、ディストリビューションのバージョンがサポート対象か、ソフトウェアソースが利用可能か、パッケージが現在のシステム向けかを確認してください。

手順4:アプリケーションメニューから起動

インストール後は、まずデスクトップのアプリケーションメニューでv2rayNを検索します。メニューに表示されれば、デスクトップエントリがシステムに認識されています。アイコンがすぐ表示されない場合は、デスクトップセッションからログアウトして再ログインするか、端末で実行コマンドを確認します。

command -v v2rayN
v2rayN

2つ目のコマンドは、起動時の端末出力を確認するのに適しています。ウィンドウが正常に表示されたら、テストのため端末を閉じ、アプリケーションメニューから起動します。コマンドが存在しないと表示された場合は、インストール先を推測せず、まずパッケージ一覧から実際の場所を確認してください。

dpkg -L v2rayn | grep -E 'bin/|applications/'

パッケージ名の大文字・小文字や表記は、バージョンによって変わる場合があります。パッケージがインストールされていないと表示されたら、dpkg -l | grep -i v2ray を実行し、結果に表示されたパッケージ名を使ってください。

Fedora・openSUSEでrpmパッケージをインストール

RPMはパッケージ形式であり、依存関係の解析、ソフトウェアソースの利用、インストールを担う管理ツールはDNFとZypperです。低レベルの rpm -i でもファイルをインストールできますが、DNFやZypperのように依存関係を自動解決しません。そのため、デスクトップユーザーにはディストリビューション標準の高機能パッケージマネージャーが適しています。

Fedora:DNFでインストール

まずダウンロードディレクトリへ移動し、ファイルを確認します。

cd ~/Downloads
ls -lh v2rayN*.rpm

ファイルの存在を確認したら、次を実行します。

sudo dnf install ./v2rayN-linux-64.rpm

新しいFedoraでは、コマンド内部で新世代のDNFが使われる場合がありますが、ローカルrpmのインストール方法は変わりません。実行前にトランザクション概要を確認し、新規インストール、アップグレード、削除の項目を重点的に確認してください。通常、ローカルクライアントのインストールでデスクトップの基盤ソフトウェアを大量に削除することはありません。

インストールが途中で中断された場合は、RPMデータベースとインストール済みの状態を確認します。

rpm -qa | grep -i v2ray
sudo dnf check

dnf check は、インストール済みパッケージ間の依存関係の問題を検出します。未完了のシステム更新が原因なら、まず現在のパッケージ処理を完了してからv2rayNを再インストールしてください。強制的な上書きを繰り返すより、一貫した状態へ戻しやすくなります。

openSUSE:Zypperでインストール

openSUSEでも、まずダウンロードディレクトリのrpmファイルを確認し、Zypperで依存関係を解決します。

cd ~/Downloads
ls -lh v2rayN*.rpm
sudo zypper install ./v2rayN-linux-64.rpm

Zypperは複数の依存関係解決案を提示する場合があります。デスクトップ環境とシステムの基盤ライブラリを維持する案を優先してください。大規模なダウングレードや主要コンポーネントの置き換えを要求する案は、いったんキャンセルし、パッケージが現在のディストリビューションのバージョンに対応しているか確認します。

インストール後は、次のコマンドでパッケージ内のファイルの場所を確認できます。

rpm -ql v2rayn | grep -E 'bin/|applications/'

パッケージ名とコマンドが一致しない場合は、rpm -qa | grep -i v2ray を実行して正確な名前を取得します。アプリケーションメニューがまだ更新されていない場合は、デスクトップセッションからログアウトして再ログインしてください。端末から一度起動し、完全なエラー情報を確認する方法もあります。

初回起動、サブスクリプション追加、コアの確認

v2rayNのウィンドウが開いても、デスクトッププログラムのインストールが完了しただけで、プロキシ経路が利用可能とは限りません。初回起動後は「設定の追加、サブスクリプション更新、ノード選択、コア起動、システムプロキシ設定」の順に進めます。各手順を確認してから次へ進むと、サブスクリプション、ノード、デスクトッププロキシのどこに問題があるかを切り分けやすくなります。

  1. サブスクリプションを追加:サブスクリプショングループまたは設定で完全なURLを登録し、保存後に手動で更新します。
  2. ノード一覧を確認:更新後にサーバー項目が表示され、プロトコル欄がサーバー側の情報と一致していることを確認します。
  3. 使用するノードを選択:利用する項目を選び、現在のアクティブサーバーに設定します。
  4. コアを起動:ログ欄を確認し、ポート使用中、設定の解析失敗、コア起動失敗などの表示がないことを確認します。
  5. システムプロキシを設定:コアが正常に動作してから、システムプロキシの自動設定を選択します。

VMessとVLESSは異なるプロキシプロトコルです。クライアントはノード設定に応じて対応するコア設定を生成するため、一方のプロトコルを手作業で別のプロトコルへ書き換える必要はありません。サブスクリプション更新後にノードが表示されない場合は、URLが完全か、サブスクリプションが有効か、更新操作でエラーが返っていないかを確認します。サブスクリプションの内容が空という問題を、クライアントの再インストールで解決しようとしないでください。パッケージのインストールとサブスクリプションの応答は別の段階です。

v2rayNデスクトップ版は通常、XrayまたはV2Fly系のコアと組み合わせて使用できます。実際に選択できる項目は現在のバージョンの画面に従ってください。既存のサブスクリプションに特定のトランスポート方式やプロトコル拡張が含まれる場合は、それらのパラメータを解析できるコアを使用します。コアを切り替えた後は関連プロセスを再起動し、ログに「未対応フィールド」や設定解析エラーがないか確認してください。

まずログを確認して接続失敗箇所を切り分ける

ログに「待ち受けポートを起動しました」といった情報が出ていれば、通常はローカルプロキシの入口が作成されています。ただし、リモート接続の成功を意味するわけではありません。実際の接続は対象サイトへアクセスした時に発生します。ローカルポートが使用中と表示された場合は、v2rayNの設定で待ち受けポートを変更するか、そのポートを使用している古いプロセスを停止します。

ss -lntp
ps -ef | grep -i v2ray

ss -lntp で待ち受け中のTCPポートを確認できます。一般ユーザーではすべてのプロセス情報を見られない場合があるため、必要に応じて sudo ss -lntp を使います。v2rayNを2つ起動すると、後から起動したインスタンスが同じローカルポートを確保できない場合があります。トレイに残っている古いインスタンスを完全に終了してから、クライアントを再起動してください。

Linuxデスクトップのシステムプロキシ設定

コアの動作とシステムプロキシは別々の状態です。コアはローカルプロキシポートを開いてリモートサーバーへ接続し、システムプロキシはデスクトップアプリにそのローカルポートへリクエストを送るよう指示します。コアだけを起動してシステムプロキシを設定しない場合、ブラウザーなどのアプリは直接ネットワークへ接続することがあります。

v2rayNでシステムプロキシの自動設定を選択したら、まずデスクトップ環境のネットワークまたはプロキシ設定を開き、HTTP、HTTPS、SOCKSの項目が適切に変わっていることを確認します。表示形式はデスクトップ環境とクライアントのバージョンによって異なります。他のPCのポートをそのまま使わず、現在のv2rayN設定画面に表示されるローカルポートを基準にしてください。

GNOMEデスクトップで確認

GNOMEでは「設定」を開き、「ネットワーク」のプロキシ設定で、モードが手動になっているか、アドレスが本機を指しているかを確認できます。コマンドで現在のプロキシモードを確認することもできます。

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy.http host
gsettings get org.gnome.system.proxy.http port

プロキシをクライアントが自動制御している場合、GNOMEの設定で同時に何度も手動変更することはおすすめしません。両方で操作すると、クライアントでは有効に見える一方、デスクトップには別のポートが保存されることがあります。v2rayNを終了する前に、クライアントの「システムプロキシを解除」などの操作を使い、デスクトップを通常の接続方式へ戻してください。

KDE Plasmaデスクトップで確認

KDE Plasmaでは、システム設定のネットワークプロキシ画面で構成を確認できます。Plasmaのバージョンによりメニューの場所は多少異なりますが、確認点は同じです。プロキシアドレスは本機、ポートはv2rayNが現在待ち受けているポートと一致している必要があります。変更後、起動中のアプリは新しい設定を読み込むために再起動が必要な場合があります。

ブラウザーと端末で動作が異なる理由

デスクトップのシステムプロキシに従うアプリもあれば、独自のネットワーク設定を持つアプリ、環境変数だけを読み取るコマンドラインツールもあります。そのため、「ブラウザーはアクセスできるのに、端末のコマンドはプロキシを通らない」ことが、必ずしもコアの障害とは限りません。まずアプリがどのプロキシ設定を参照するかを判断し、必要なら個別に設定します。

現在の端末セッションだけで一時的にプロキシを使う場合は、v2rayNに表示される実際の待ち受け方式とポートに合わせて環境変数を設定します。以下はコマンドの構造のみを示したもので、ポートはクライアント画面と一致させてください。

export http_proxy=http://127.0.0.1:10808
export https_proxy=http://127.0.0.1:10808
export all_proxy=socks5://127.0.0.1:10808

現在のポートが10808でない場合は、実際の値に変更します。端末を閉じると、これらの一時変数は無効になります。ローカルポートを確認しないままシェルの起動ファイルへ書き込むと、端末を開くたびに存在しないプロキシ入口を参照するため注意してください。

自動起動とログイン後の起動を設定

デスクトップクライアントでいう「自動起動」は、正確には「ユーザーがグラフィカルなデスクトップへログインした後に自動起動する」ことを指します。v2rayNはデスクトップセッション、トレイ、ユーザー設定ディレクトリを必要とするため、システムレベルのバックグラウンドサービスとして先に強制起動する方法には向きません。まずクライアント設定の自動起動を使い、そのデスクトップ環境で機能しない場合にXDG自動起動ディレクトリを使用してください。

方法1:クライアント内蔵の設定を有効にする

  1. v2rayNの設定を開き、自動起動またはログイン後に起動する項目を見つけます。
  2. 設定を保存し、クライアントを完全に終了します。
  3. 現在のデスクトップユーザーからログアウトし、再度ログインします。
  4. トレイアイコン、プロセス、ログを確認し、インスタンスが1つだけ起動していることを確認します。
  5. クライアント起動後、システムプロキシの状態が期待どおり復元されるか確認します。

テストでは、ウィンドウを閉じるだけでなく、ログアウトして再ログインしてください。一部のデスクトップ環境ではメインウィンドウを閉じるとトレイへ最小化され、プロセスが実際には動作し続けます。この状態では自動起動が本当に機能しているか確認できません。

方法2:既存のデスクトップエントリをautostartへコピー

パッケージのインストール後は、通常デスクトップエントリファイルが提供されます。まずファイルを検索し、現在のユーザーの自動起動ディレクトリへコピーします。

find /usr/share/applications -iname '*v2rayn*.desktop'
mkdir -p ~/.config/autostart
desktop_file="$(find /usr/share/applications -iname '*v2rayn*.desktop' | head -n 1)"
test -n "$desktop_file" && cp "$desktop_file" ~/.config/autostart/

コピー後、ログアウトして再ログインします。1つ目のコマンドで結果が返らない場合は、パッケージのファイル一覧からデスクトップファイルの場所を確認してください。未知のプログラムパスを指す自動起動項目を作成しないでください。deb系では dpkg -L、rpm系では rpm -ql で確認できます。

ログイン後にv2rayNが2つ起動する場合、クライアント内蔵の自動起動項目と、手動でコピーしたXDG自動起動項目が同時に有効になっています。どちらか1つだけ残してください。ユーザーディレクトリ内の重複項目を削除できます。

rm -f ~/.config/autostart/*v2rayN*.desktop
rm -f ~/.config/autostart/*v2rayn*.desktop

削除前に ls -la ~/.config/autostart でファイルを確認できます。Linuxではファイル名の大文字・小文字が区別されるため、ここでは一般的な大小文字の形式をそれぞれ処理しています。自動起動項目を削除しても、v2rayNのアンインストールやサブスクリプション、クライアント設定の削除にはなりません。

デスクトップウィンドウをシステムサービスで起動しない

グラフィカルクライアントをシステムレベルのサービスとして直接登録すると、表示環境を見つけられない、ユーザーセッションへ接続できない、誤ったホームディレクトリを読み込む、管理者権限で設定ファイルを作成するといった問題が起こりがちです。デスクトップユーザーはクライアント内蔵の設定またはXDG autostartを使ってください。ユーザーサービス、デスクトップセッションの環境、プログラムの起動引数を明確に理解している場合に限り、追加のサービス管理方式を検討します。

よくあるインストール・起動トラブルの対処

パッケージのアーキテクチャが一致しない

uname -m を再実行し、ダウンロードしたファイルに記載されたアーキテクチャと照合します。x64パッケージをarm64システムへ直接インストールすることはできず、その逆も同様です。アーキテクチャの不一致は依存関係不足ではないため、ランタイムを追加しても解決しません。

パッケージをダブルクリックしても反応しない

ファイルマネージャーからのダブルクリックは、デスクトップ環境のソフトウェアインストールフロントエンドに依存します。フロントエンドが未インストール、権限ダイアログが隠れている、ファイル関連付けに問題がある場合、ダブルクリックしても目立った反応がないことがあります。APT、DNF、Zypperでインストールすればエラーを直接確認でき、パス、アーキテクチャ、依存関係のどこに問題があるか判断しやすくなります。

起動後にウィンドウが空白になる、またはすぐ終了する

まず端末から起動し、完全な出力を記録します。デスクトップセッションが正常か、グラフィックコンポーネントが揃っているか、パッケージが現在のディストリビューションのバージョンに対応しているかを確認してください。大規模なシステム更新直後なら、ログアウトまたは再起動して、新しく導入されたグラフィックライブラリとデスクトップコンポーネントを完全に読み込ませます。

ユーザー設定ディレクトリの権限も確認します。以前に sudo でグラフィカルクライアントを直接起動した場合、一部の設定ファイルが管理者ユーザーの所有となり、通常ユーザーが書き込めなくなることがあります。v2rayNを常に管理者権限で実行しないでください。まずユーザーディレクトリ内の関連ファイルの所有者を確認し、このクライアントに属すると確認できたディレクトリだけ権限を修正します。

クライアントは正常に起動するが、ウェブページに接続できない

4層の順番で確認します。第1層はノードが選択されているか、第2層はコアが正常に起動してローカルポートを待ち受けているか、第3層はシステムプロキシがそのポートを指しているか、第4層は対象アプリがシステムプロキシに従うかです。最初からサブスクリプションを削除したり、クライアントを再インストールしたりしないでください。

一部のサイトだけ失敗する場合は、ルーティングの振り分けルールも確認します。v2rayNはドメイン、アドレス範囲、ルールセットに応じて、直接接続、プロキシ、ブロックを選択できます。誤ったルールにより、対象リクエストが適切でない出口へ送られることがあります。テスト時は判断しやすいルーティングモードへ一時的に切り替え、基本経路が正常だと確認してから、カスタムルールを1つずつ確認して元に戻します。

サブスクリプションの更新は成功したが、一覧が変わらない

まず正しいサブスクリプショングループを更新しているか確認し、更新ログを確認します。応答が空、またはクライアントが解析できない内容を返すサブスクリプションもあります。URL、グループ設定、サーバー側の形式を確認してください。パッケージのインストールが正常でも、サブスクリプションの内容が有効とは限りません。両者は分けて対処します。

再起動後、システムプロキシが無効なポートを指している

これは通常、システムプロキシの復元がクライアントより先に行われたか、v2rayNの自動起動に失敗したことが原因です。まずデスクトップのシステムプロキシを解除し、クライアントを起動してコアのポートを確認してから、自動設定を再び有効にします。その後、自動起動項目が重複していないか、ログイン後にクライアントがクラッシュしていないか、ローカルポートを他のプログラムが使用していないか確認します。

アンインストール、再インストール、アップグレードの手順

アップグレード前にv2rayNを終了し、旧プロセスがファイルやローカルポートを使い続けないようにします。同じパッケージ体系で新しいバージョンをインストールすれば、APT、DNF、Zypperは通常アップグレード処理として認識します。実行前にトランザクション概要を読み、パッケージ名とアーキテクチャが正しいことを確認してください。

アンインストールする場合は、まずシステムプロキシを解除してクライアントを終了します。Debian、Ubuntuでは正確なパッケージ名を確認してからAPTで削除し、Fedora、openSUSEではRPMでパッケージ名を確認してから対応する管理ツールで処理します。/usr 配下の個別ファイルを直接削除しないでください。パッケージデータベース上ではインストール済みのまま残ります。

dpkg -l | grep -i v2ray
rpm -qa | grep -i v2ray

アプリのアンインストールとユーザー設定の削除は別の作業です。通常のアンインストールでは、再インストール後に復元できるよう、ユーザーディレクトリ内のサブスクリプション、ルーティング、画面設定が保持されます。問題の原因が設定内容なら、パッケージを再インストールするだけでは解決しない場合があります。リセットが必要な場合は、必要なサブスクリプション情報を先にバックアップし、クライアントのリセット機能を使うか、設定ディレクトリを確認したうえで処理してください。