この記事は、Debian 12、Ubuntu 24.04、Fedora 42などのデスクトップ版ディストリビューションでv2rayN 7.xを使うユーザー向けです。CPUアーキテクチャの確認、deb/rpmの導入、不足している依存関係の修復、Xrayコアの選択、システムプロキシの確認、XDGデスクトップエントリ、ログイン時の自動起動を扱い、Wayland、GNOME、KDE Plasma環境で混同しやすい点も説明します。
インストール前にディストリビューション、アーキテクチャ、デスクトップセッションを確認
Linux版v2rayNはAvaloniaベースのデスクトップUIを採用しており、Windows版のWPF系列とは位置付けが異なります。Linuxのグラフィカルセッションでサブスクリプション、ノード、ルーティングルール、ローカルプロキシを管理できますが、インストールパッケージはディストリビューションのパッケージ管理方式とCPUアーキテクチャに合わせる必要があります。Debian、Ubuntuおよび派生システムでは通常debパッケージを、Fedora、Rocky LinuxなどRPM体系のシステムではrpmパッケージを選びます。
まず端末でシステム情報を確認し、デスクトップの見た目だけでディストリビューションを判断しないでください。`amd64`または`x86_64`は一般的な64ビットIntel/AMD機、`arm64`または`aarch64`は64ビットARM機に対応します。ダウンロードページではプラットフォームにLinuxを選び、実際のアーキテクチャに合うパッケージを取得します。
cat /etc/os-release
uname -m
echo "$XDG_CURRENT_DESKTOP"
echo "$XDG_SESSION_TYPE"
debインストールパッケージ
おすすめAPTに依存関係の処理を任せられ、Debian 12、Ubuntu 22.04/24.04および同じパッケージ体系を使うデスクトップディストリビューションに適しています。
対応環境:Debian、Ubuntuおよびdeb系デスクトップ環境
rpmインストールパッケージ
DNFでインストールしてRPMデータベースに登録します。アップグレード、アンインストール、デスクトップエントリはすべてシステムのパッケージマネージャーで管理できます。
対応環境:Fedoraおよびrpmパッケージ体系のデスクトップ環境
アーカイブ
管理者権限がない環境や並行テストに適していますが、プログラムのパス、デスクトップエントリ、アップグレードは自分で管理する必要があります。
対応環境:一時的なテスト、ユーザーディレクトリへの配置
debまたはrpmパッケージでインストール
ダウンロードが完了したら、まずパッケージの保存先ディレクトリへ移動し、ディストリビューション標準のパッケージマネージャーを実行します。低レベルのツールだけで強制的に展開するのは避けてください。グラフィックライブラリ、トレイ対応、デスクトップ統合に必要な依存関係が自動で補われない場合があります。以下のコマンドにあるファイル名は、ダウンロードページに表示された実際の名前へ置き換えてください。
-
インストールパッケージを確認
ls -lh *.deb *.rpm 2>/dev/nullを実行し、パッケージ形式とマシンのアーキテクチャを確認します。x86_64の端末にはaarch64ビルドをインストールしないでください。 -
パッケージをインストール
Debian/Ubuntuでは
sudo apt install ./v2rayN-linux-x64.deb、Fedoraではsudo dnf install ./v2rayN-linux-x64.rpmを使用します。 -
クライアントを起動
アプリケーションメニューでv2rayNを検索します。デスクトップデータベースがまだ更新されていない場合は、ログアウトして再ログインするか、端末で
v2rayNを実行して起動時の出力を確認します。 -
コアを選択
「設定」→「パラメータ設定」→「Core タイプ」を開き、VLESS、VMessなどのノードを普段使いする場合はXrayを選択して保存します。
-
サブスクリプションをインポート
「サブスクリプショングループ」でURLを追加し、グループを更新してからノードを選択します。その後、コアのログでリスニングが正常に開始されているか確認します。
# Debian / Ubuntu
cd ~/Downloads
sudo apt install ./v2rayN-linux-x64.deb
# Fedora
cd ~/Downloads
sudo dnf install ./v2rayN-linux-x64.rpm
APTまたはDNFでインストールすると、パッケージマネージャーがファイルの所属を記録します。新しいインストールパッケージを取得したら、同じ種類のインストールコマンドを再実行して上書きアップグレードできます。設定データは通常、現在のユーザーディレクトリに保存されます。rootでグラフィカルクライアントを直接起動すると、root所有の設定ファイルが作成され、一般ユーザーのセッションから既存のサブスクリプションを読み込めなくなるため避けてください。
依存関係、権限、起動失敗に対処
インストール失敗は通常、パッケージのアーキテクチャ不一致、システムリポジトリの依存関係不足、グラフィカルセッションの構成不足の3種類に分かれます。端末に「wrong architecture」や「not supported architecture」と表示されたら、`uname -m`を再確認してください。APTが依存関係を満たせないと報告した場合は、まずシステムのパッケージソースを更新し、APTに依存関係を修復させます。
# Debian / Ubuntu インデックスを更新して未完了の依存関係を修復
sudo apt update
sudo apt --fix-broken install
# Fedora キャッシュを更新してローカルパッケージを再試行
sudo dnf makecache
sudo dnf install ./v2rayN-linux-x64.rpm
# プログラムが PATH に登録されているか確認
command -v v2rayN
プログラムが起動してもトレイアイコンが表示されないからといって、コアが動作していないとは限りません。GNOME、KDE Plasmaなどデスクトップごとにステータストレイの実装が異なるため、メインウィンドウ、プロセス、コアログを同時に確認してください。Waylandセッションでは、システムプロキシはデスクトップ設定または環境変数が引き継ぎます。ウィンドウがWaylandで描画されるかXWaylandで描画されるかとは別の問題です。
インストールパッケージをダブルクリックしても反応しない?
端末を開いてダウンロードディレクトリへ移動し、sudo apt install ./ファイル名.debまたはsudo dnf install ./ファイル名.rpmを使用します。端末にアーキテクチャ、依存関係、リポジトリに関する具体的なエラーが表示されます。
起動後にメインウィンドウがすぐ消える?
まず端末でv2rayNを直接実行してエラー出力を確認し、続けてjournalctl --user -b | tail -n 80を実行して現在のログインセッションの最近の記録を確認します。
サブスクリプションの更新がタイムアウトし続ける?
システム時刻とタイムゾーンが正しいことを確認します。利用可能なノードがある場合は、まずそのノードに接続し、サブスクリプション設定でプロキシ経由の更新を有効にします。同時に、URLに空白や改行が混入していないか確認してください。
ノードに接続できるのにウェブページが開かない?
コアのログでローカルポートがリッスンされているか確認し、システムプロキシが有効になっていることを確認します。一般的なローカルHTTPポートは10809、SOCKSポートは10808ですが、最終的には「設定」→「パラメータ設定」にあるローカル設定に従ってください。
ウィンドウを閉じてもプロセスが動作している?
これはトレイ常駐モードでよく見られる動作です。完全に終了する場合はクライアントメニューの終了コマンドを使い、pgrep -a v2rayNでグラフィカルプロセスが停止したことを確認します。
デスクトップエントリとアプリケーションメニューを統合
正規のdeb/rpmパッケージは通常、`.desktop`ファイルをインストールし、v2rayNをアプリケーションメニューに表示します。デスクトップエントリは単なるショートカットではなく、プログラム名、起動コマンド、アイコン、カテゴリ情報を含みます。システム全体のエントリは通常`/usr/share/applications/`に、現在のユーザー向けの上書き項目は`~/.local/share/applications/`にあります。
アプリケーションメニューにすぐ表示されない場合は、まず実際のエントリファイルを探してからデスクトップデータベースを更新します。誤った実行パスを推測で作成しないでください。`command -v v2rayN`またはパッケージのファイル一覧を使い、パッケージがプログラムをどこへインストールしたか確認します。
# パッケージがインストールしたデスクトップエントリを検索
find /usr/share/applications ~/.local/share/applications \
-maxdepth 1 -iname '*v2rayn*.desktop' 2>/dev/null
# Debian / Ubuntu パッケージ内のファイルを確認
dpkg -L v2rayn | grep -E 'applications|/bin/'
# Fedora パッケージ内のファイルを確認
rpm -ql v2rayN | grep -E 'applications|/bin/'
# 現在のユーザーのデスクトップエントリデータベースを更新
update-desktop-database ~/.local/share/applications 2>/dev/null || true
推奨構成:プログラムはシステムパッケージ、セッション設定はユーザーディレクトリで管理
システムレベルのファイル
- プログラムはAPTまたはDNFでインストール・アップグレード
- デスクトップエントリは/usr/share/applicationsに保存
- アンインストール時にパッケージマネージャーが登録済みファイルを削除
ユーザーレベルの設定
- サブスクリプションとルーティング設定は現在のログインユーザーに属する
- 自動起動エントリは~/.config/autostartに配置
- 他のユーザーのデスクトップセッションを変更する必要はない
プログラムファイルと個人設定を分離すれば、パッケージのアップグレード時にサブスクリプショングループを作り直す必要がなく、自動起動の影響も現在のデスクトップアカウントに限られます。
エントリが存在するのにアイコンが表示されない場合は、まずデスクトップセッションからログアウトして再ログインします。一部のデスクトップ環境ではアプリケーション一覧がキャッシュされるため、データベースを更新しただけではメニューがすぐ再構築されないことがあります。`.desktop`ファイルを手動編集する場合は、`Exec`フィールドが移動済みのアーカイブディレクトリを指していないこと、UTF-8テキストで保存されていること、`Type=Application`が維持されていることにも注意してください。
ログインセッションに合わせて自動起動
デスクトップクライアントでいう「起動時の自動起動」は、正確には「ユーザーがグラフィカルセッションへログインした後の自動起動」です。XDG Autostart仕様に依存し、rootのsystemdシステムサービスとして設定するものではありません。v2rayNには現在のユーザーのディスプレイサーバー、トレイ、設定ディレクトリ、デスクトッププロキシ環境が必要であり、ログイン前に起動しても通常これらの条件を利用できないためです。
最も確実な方法は、パッケージがすでに提供している`.desktop`エントリを再利用し、現在のユーザーの`~/.config/autostart/`へコピーすることです。これにより起動コマンドとアイコンのパスがアプリケーションメニューと一致し、プログラムのパスを再入力する必要もありません。
mkdir -p ~/.config/autostart
desktop_file="$(find /usr/share/applications \
-maxdepth 1 -iname '*v2rayn*.desktop' -print -quit)"
cp "$desktop_file" ~/.config/autostart/v2rayN.desktop
chmod 644 ~/.config/autostart/v2rayN.desktop
grep -E '^(Name|Exec|Type|Hidden)=' \
~/.config/autostart/v2rayN.desktop
- GNOME:「スタートアップアプリケーション」でユーザーレベルの自動起動項目を管理できます。システムにその画面がない場合も、XDGエントリをコピーすれば動作します。
- KDE Plasma:「システム設定」→「自動起動」でアプリケーションを追加できます。`~/.config/autostart/`を直接使用することも可能です。
- マルチユーザー環境:各ユーザーが自分の自動起動エントリを個別に管理し、個人のサブスクリプション設定をシステムレベルのディレクトリに置かないでください。
- 一時的に無効化:エントリ内の`Hidden=false`を`Hidden=true`に変更するか、ユーザーレベルの`.desktop`ファイルを別の場所へ移動します。
コア、システムプロキシ、ルーティング分岐を設定
インストールが完了しても、クライアントが動作できるようになっただけです。実際に通信がプロキシを通るかどうかは、コア、ノード、システムプロキシに左右されます。v2rayNは設定を管理してコアを起動し、XrayはVLESS、VMessなどのプロトコル接続を処理し、システムプロキシはデスクトッププロキシ設定に対応するアプリの通信をローカルのリスニングポートへ転送します。この3層を分けて確認してください。
- 「設定」→「パラメータ設定」→「Core タイプ」でXrayを選択し、保存してからコアを再起動します。
- サブスクリプショングループを追加し、サブスクリプションを更新して遅延と可用性が正常なノードを選択します。サブスクリプションURLを単一ノードのリンクとして直接インポートしないでください。
- ローカルSOCKSおよびHTTPのリスニング設定を確認します。一般的な組み合わせは`127.0.0.1:10808`と`127.0.0.1:10809`です。
- システムプロキシを有効にして通常のブラウザーで確認します。コマンドラインだけが接続できない場合は、端末のプログラムがデスクトップのプロキシ設定を読み取るか確認してください。
- 必要に応じてグローバルモードまたはルーティング分岐を選択します。ルールは順番に照合されるため、ドメインルール、IPルール、最終出口が互いに上書きし合わないようにしてください。
| 確認レイヤー | 確認場所 | 正常な状態 | 異常時に優先して確認する項目 |
|---|---|---|---|
| クライアント | v2rayNメインウィンドウ | サブスクリプショングループとノード一覧が表示される | サブスクリプションを再更新し、グループの状態を確認 |
| コア | コアログ | ポート占有や設定解析エラーがない | Core タイプ、ポート、ルーティングルールを確認 |
| ローカルリスニング | 127.0.0.1 | 10808/10809など設定したポートがリッスン中 | ポートを占有している古いプロセスを終了するか、ポートを変更 |
| デスクトッププロキシ | システムネットワーク設定 | HTTP/SOCKSがローカルのリスニングアドレスを指している | システムプロキシの設定を再実行 |
| ルーティング | ルーティング設定 | 対象ドメインがルールに従って指定の出口へ進む | 配列の順序と最終照合ルールを確認 |
端末の`curl`、パッケージマネージャー、その他のコマンドラインツールでは、デスクトップのシステムプロキシが自動的に有効になるとは限りません。必要に応じて現在の端末セッションで`http_proxy`、`https_proxy`、`all_proxy`を設定し、ポートをv2rayNのローカルリスニングポートに合わせます。テスト後は`unset`で変数を削除し、クライアント終了後も後続のコマンドがローカルポートへ接続しようとするのを防ぎます。
export http_proxy=http://127.0.0.1:10809
export https_proxy=http://127.0.0.1:10809
export all_proxy=socks5://127.0.0.1:10808
# テスト終了後に削除
unset http_proxy https_proxy all_proxy
アップグレード、アンインストール、日常のメンテナンス
deb/rpmでインストールする主な利点は、プログラムファイルをシステムのパッケージマネージャーで継続的に追跡できることです。アップグレード前にv2rayNを正常終了し、同じアーキテクチャの新しいパッケージをインストールします。完了後、「設定」→「パラメータ設定」→「Core タイプ」、ローカルポート、自動起動エントリを確認し、旧設定が現在のユーザーによって読み込まれていることを確認してください。
プログラムをアンインストールすると、APTとDNFはシステムに登録されたプログラムとデスクトップエントリを削除しますが、ユーザーディレクトリ内のサブスクリプション、ログ、自動起動用コピーは残る場合があります。再インストールするだけなら個人設定を急いで削除しないでください。今後使わないと決めた場合は、保存したいルーティングルールを先にバックアップしてから、ユーザーレベルの自動起動項目を削除します。
# Debian / Ubuntu アンインストール
sudo apt remove v2rayn
# Fedora アンインストール
sudo dnf remove v2rayN
# 現在のユーザーの自動起動エントリを削除
rm -f ~/.config/autostart/v2rayN.desktop
- アップグレードのたびに一度クライアントを起動し、コアログに設定移行の通知がないか確認します。
- ポートを変更したら、システムプロキシと端末の環境変数も同時に更新し、クライアント側だけを変更しないでください。
- サブスクリプションの更新に失敗した場合は、まずネットワークのタイムアウト、URLの無効化、証明書の時刻エラーを切り分けてから、プロキシ経由で更新するか判断します。
- ルーティングルールを変更したら、具体的なドメインで照合結果を確認し、ノードに「接続済み」と表示されるだけで分岐が有効だと判断しないでください。
- 自動起動に問題がある場合は、クライアントをシステムサービスへ変更するのではなく、まず`.desktop`の`Exec`パスを確認します。