Linuxのデスクトップ環境があり、v2rayNを導入したい方を対象にしています。まずディストリビューションとCPUアーキテクチャを確認し、システムのパッケージマネージャーでインストールします。次にデスクトップの起動項目、コア、ローカルプロキシポートを確認し、最後にログイン後の自動起動を設定します。ここでいう「自動起動」はデスクトップへのログイン後にクライアントを起動する設定であり、ログイン前にバックグラウンドサービスとして動かすことではありません。
インストール前に確認すること:ディストリビューション、アーキテクチャ、パッケージ
v2rayNは、ノード管理やサブスクリプション更新、プロキシコアの起動を行うデスクトップクライアントです。Linux版の利用にはグラフィカルなデスクトップ環境が必要です。ターミナルのみのサーバーに、この記事のデスクトップ向け手順をそのまま適用することはできません。v2rayNGとv2flyNGはAndroid向けクライアントであり、Linux用パッケージの代わりにはなりません。
パッケージ形式はディストリビューション、アーキテクチャはCPUによって決まります。まず次の2つのコマンドを実行してください。見た目でパッケージを選んだり、Windows版の実行ファイルをLinuxのパッケージマネージャーに渡したりしないでください。
cat /etc/os-release
uname -m
Ubuntu / Debian
- パッケージ形式
- deb
- インストールツール
- apt
- x64の表記
- x86_64(パッケージのアーキテクチャ表記はamd64)
- ARM64の表記
- aarch64(パッケージのアーキテクチャ表記はarm64)
ディストリビューションの対応要件も確認してください。パッケージ形式が合っていても、すべてのOSバージョンで使えるとは限りません。
Fedora / openSUSE
- パッケージ形式
- rpm
- Fedoraのツール
- dnf
- openSUSEのツール
- zypper
- 一般的なアーキテクチャ
- x86_64 / aarch64
公開中のパッケージで実際に提供されているアーキテクチャを選び、別のアーキテクチャのパッケージを無理にインストールしないでください。
ダウンロードページからLinux用パッケージを選びます。この記事では特定のバージョンに限定しません。パッケージ名や依存関係、画面表示はバージョンによって変わることがあります。トラブル時に確認できるよう、インストール前にバージョンとアーキテクチャを控えておきましょう。
deb・rpmのインストール:パッケージマネージャーで依存関係を解決
ローカルパッケージのインストールには、apt、dnf、zypperを使うのがおすすめです。パッケージに記載された依存関係を確認し、設定済みのシステムリポジトリから必要なコンポーネントを取得します。低レベルのツールで展開するだけでは、依存関係が解決されず「インストール済みなのに動かない」状態になりやすくなります。
Ubuntu・Debianにdebをインストール
cd "$HOME/Downloads/v2rayn-linux"
ls -lh ./*.deb
dpkg-deb -f ./*.deb Package Version Architecture Depends
sudo apt update
sudo apt install ./*.deb
./を付けると、aptはリポジトリ内のパッケージ名ではなくローカルファイルとして扱います。Architectureを確認してからインストールしてください。別の方法でインストールした際に依存関係が未解決になった場合は、sudo apt --fix-broken installを実行できます。ただし、インストール・削除される項目を先に確認し、内容を見ずに確定しないでください。
Fedoraにrpmをインストール
cd "$HOME/Downloads/v2rayn-linux"
ls -lh ./*.rpm
rpm -qp --queryformat '%{NAME} %{VERSION}-%{RELEASE} %{ARCH}\n' ./*.rpm
rpm -qp --requires ./*.rpm
sudo dnf install ./*.rpm
openSUSEにrpmをインストール
cd "$HOME/Downloads/v2rayn-linux"
ls -lh ./*.rpm
rpm -qp --queryformat '%{NAME} %{VERSION}-%{RELEASE} %{ARCH}\n' ./*.rpm
sudo zypper refresh
sudo zypper install ./*.rpm
ランタイムも推測で追加しないでください。ビルドによって配布方法は異なり、Linux用パッケージすべてに.NETの追加インストールが必要なわけではありません。まずパッケージの依存関係と起動時のエラーを確認します。共有ライブラリが不足している場合は、該当するディストリビューションでそのライブラリを提供するパッケージを調べてください。Windows向けのランタイム修復手順をそのまま使わないでください。
初回起動:デスクトップの起動項目、ノード、ポートを確認
インストール後、アプリケーションメニューからv2rayNを検索し、通常のユーザーで起動します。ソフトウェアのインストールに管理者権限が必要でも、グラフィカルクライアントの日常的な起動には通常必要ありません。sudoで起動すると、別ユーザーのディレクトリに設定が保存され、次回通常起動したときに「設定が消えた」ように見えることがあります。
-
デスクトップの起動項目を確認
アプリケーションメニューでv2rayNを検索します。見つからない場合は、
grep -il 'v2rayn' /usr/share/applications/*.desktopを実行し、パッケージにデスクトップ起動ファイルが含まれているか確認してください。まず起動方法を確認し、自動起動の設定はその後に行いましょう。 -
ノードをインポート
ノードの共有リンクがある場合は、リンク全体をコピーし、メイン画面で「サーバー」→「クリップボードからURLを一括インポート」を選択します。サブスクリプションを追加するには、「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、URLを入力して保存した後、「すべてのサブスクリプションを更新(プロキシを使用しない)」を実行します。
-
起動状態を確認
ノードを選択してアクティブサーバーに設定し、画面下部のログにコアの起動エラーがないか確認します。VMessとVLESSはノードのプロトコルです。画面が開いたからといって、選択したコアやノードの設定が正しく動作しているとは限りません。
-
ポートを確認
「設定」→「パラメータ設定」を開き、使用中のバージョンに表示されているローカル待受ポートを確認します。
ss -lntpで実際の待受状態と照合してください。パラメータ設定でポートを変更した場合は、テストコマンドとアプリのプロキシアドレスも同じ値に変更します。
以下の数値は説明とテスト用のポート例であり、すべてのバージョンで同じ値がデフォルトになるわけではありません。HTTPとSOCKSに対応した混合ポートを使うバージョンもあれば、古い設定のように入口が分かれている場合もあります。画面とログを基準にし、古い記事のポート番号を新しい設定に流用しないでください。
ss -lntp | grep -E ':(10808|10809)\b'
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com
2つ目のコマンドは、実際のSOCKSポートが10808の場合にのみ使用してください。socks5hは接続先のドメイン名をプロキシ側で解決します。HTTPレスポンスが返れば、そのリクエストが指定した入口を経由したことは確認できますが、すべてのアプリがプロキシ経由になったわけではありません。Linuxアプリのデスクトップシステムプロキシへの対応状況はさまざまで、ターミナルのプログラムが設定を読み取るとも限りません。
ログイン時の自動起動:デスクトップ項目とバックグラウンドサービスを区別
「v2rayN Linux 自動起動」で検索すると、デスクトップへのログイン後にGUIクライアントを起動する設定と、システム起動後にバックグラウンドプロセスを動かす設定が混同されがちです。この記事では前者を扱います。画面環境、デスクトッププロキシ設定、ユーザー設定はいずれもログインセッションに属するため、クライアントをそのままシステムサービスに登録する方法は適切ではありません。
XDGログイン時の自動起動項目
おすすめ既存のデスクトップ起動項目を、現在のユーザーの~/.config/autostart/にコピーします。起動コマンドはパッケージに用意された内容をそのまま使います。XDG Autostartに対応するデスクトップ環境で利用できます。
対象:デスクトップへのログイン時にv2rayNを自動で開きたい方。
デスクトップの「自動起動するアプリ」から設定
デスクトップ環境に用意された「自動起動するアプリ」などのツールで、同じログイン時の起動項目を管理します。ツール名はデスクトップ環境によって異なります。すでに項目がある場合はそれだけを有効にし、手動で重複登録しないでください。
対象:GUIで操作し、必要に応じてチェックを切り替えたい方。
systemdサービス
サービスとして動かすには、セッション環境や設定ファイルの場所、プロセスのライフサイクルを別途扱う必要があります。systemdのシステムサービスを、一般ユーザー向けデスクトップクライアントの自動起動に使うべきではありません。
対象:バックグラウンドのコアサービスが必要で、サービス設定を個別に管理できる管理者。
パッケージ付属のデスクトップ起動項目をコピー
重複して起動しているウィンドウがあれば、先に終了します。以下のコードはBashで実行してください。システムのデスクトップ項目を検索し、一致するものがちょうど1つの場合に限ってコピーします。見つからない場合や複数見つかった場合は、実行ファイルの場所を推測せずに調べてください。
bash <<'BASH'
mapfile -t launchers < <(grep -il 'v2rayn' /usr/share/applications/*.desktop 2>/dev/null)
if [ "${#launchers[@]}" -ne 1 ]; then
printf '起動項目が%s個見つかりました。パッケージ付属の起動ファイルを確認してください。\n' "${#launchers[@]}"
printf '%s\n' "${launchers[@]}"
exit 1
fi
autostart_dir="${XDG_CONFIG_HOME:-$HOME/.config}/autostart"
mkdir -p "$autostart_dir"
install -m 644 "${launchers[0]}" "$autostart_dir/v2rayn.desktop"
grep -E '^(Type|Exec|TryExec|Path|Hidden|OnlyShowIn|NotShowIn|X-GNOME-Autostart-enabled)=' \
"$autostart_dir/v2rayn.desktop"
BASH
Execは起動コマンドです。元のファイルの内容を使い、推測したパスに書き換えないでください。TryExecが設定されている場合は、指定されたプログラムを見つけられる必要があります。見つからないと、デスクトップ環境が起動項目を無視することがあります。Hidden=trueは起動項目を無効にします。X-GNOME-Autostart-enabled=falseが設定されている場合も、デスクトップ環境によっては起動がスキップされます。OnlyShowInとNotShowInは、起動項目を表示するデスクトップ環境を制限します。条件が合わない場合は、元の項目の用途を確認してからユーザー側のコピーを編集してください。- クライアントがすでに自動起動項目を作成している場合は、2つ目をコピーしないでください。同じプログラムのウィンドウが2つ開いても、起動の信頼性は高まりません。
このファイルは644の権限で保存すればよく、実行権限は不要です。デスクトップ環境はログイン時の自動起動項目として読み込みます。デスクトップファイルを手動でクリックする際に「信頼」設定が必要かどうかは別の仕組みです。自動起動のためにファイルの権限をむやみに広げないでください。
動作確認と元に戻す方法:一度ログアウトして起動結果を確認
自動起動項目を保存したら、デスクトップから一度ログアウトして再ログインします。画面ロックを解除しただけでは、ログイン時の自動起動は再実行されません。最初の確認でPC全体を再起動する必要はありません。まず起動までの流れを確認しましょう。
- ログイン後にv2rayNが起動していることを確認します。ウィンドウやトレイの表示方法は、クライアントの設定とデスクトップ環境のトレイ対応状況によって異なります。
- 現在のユーザーのプロセスを確認します:
pgrep -a -i v2rayn。プロセスが見つかっても、コアが正常に起動したとは限りません。クライアントのログも確認してください。 - ノードが残っていること、アクティブサーバーが正しく選択されていること、ローカルポートが待ち受けていることを確認します。
- 前のセクションの、プロキシを明示したリクエストをもう一度実行し、プロキシが必要なアプリも個別にテストします。
- ログイン後に自動接続したい場合は、クライアントがアクティブサーバーを復元する設定になっているか確認してください。デスクトップの起動項目が行うのはプログラムの起動だけで、無効になったノードを修復することはできません。
この記事で作成したログイン時の起動項目を取り消すには、ユーザー側のコピーを削除します。システムのアプリケーションメニューにある起動項目には影響しません。このコマンドはこの記事で指定したファイルだけを対象にします。別の方法で作成した項目は、対応するツールで無効にしてください。
rm -f "${XDG_CONFIG_HOME:-$HOME/.config}/autostart/v2rayn.desktop"
アップグレードには、同じ配布元の新しいパッケージを使ってapt、dnf、zypperのいずれかでインストールします。通常は古いソフトウェアファイルが置き換わります。アップグレード前に、クライアントが実際に使用しているデータディレクトリをバックアップしてください。設定が常に決まった場所に保存されるとは限りません。サブスクリプションURL、ノードの認証情報、カスタムルーティングは保護が必要なデータです。
よくある問題:インストールできたのに正しく動かない
アプリケーションメニューにアイコンはあるのに、クリックしても起動しない
デスクトップファイルのExec行を確認し、実際のプログラムのパスを使って現在のユーザーのターミナルから起動します。エラー出力はそのまま残してください。%Uや%Fなどのデスクトップフィールドコードが含まれている場合、手動で試すときは取り除きます。行全体を確認せずにシェルへ渡さないでください。共有ライブラリが不足している場合は依存関係を調べ、アーキテクチャエラーの場合は適切なパッケージを選び直します。
手動では起動するのに、ログイン後は起動しない
ユーザーの自動起動ディレクトリにファイルがあるか、Hiddenで無効になっていないか、Execのプログラムが現在も存在するかを確認します。次に、デスクトップ環境がXDG Autostartに対応しているか確認してください。journalctl --user -bで今回の起動時のユーザーログを確認できますが、起動失敗がすべて記録されるとは限りません。
サブスクリプションの更新がタイムアウトする。インストールに問題がある?
まずインストールの問題とネットワークの問題を切り分けます。メイン画面が動いていても、サブスクリプションURLに接続できるとは限りません。URL全体、システム時刻、ネットワークを確認し、すでに使えるノードで接続してから「すべてのサブスクリプションを更新(プロキシを使用)」を実行してください。ログを共有する前に、サブスクリプションのトークンとノードの認証情報を隠してください。
クライアントは起動しているのに、ターミナルの通信が直接接続される
ターミナルのツールがデスクトップのシステムプロキシを使うとは限りません。まずcurl --proxyで確認済みのローカル入口を指定してテストします。明示的なプロキシ指定で通信できる場合は、アプリ自体のプロキシ設定を確認してください。「プログラムが起動している」「システムプロキシが有効」「ルールでプロキシ経由のアウトバウンドが選択されている」は、それぞれ別の状態です。
アップグレード後にクライアントのプロセスが2つ起動している
クライアントの自動起動設定、デスクトップの自動起動アプリ、ユーザーのautostartディレクトリを確認し、起動項目を1つだけ残してください。古いバージョンがまだ動いていないかも確認します。パッケージをアップグレードしても、古いプロセスが終了するとは限りません。まず通常の方法で終了し、新しいデスクトップ起動項目から起動してログを確認してください。
確認すべき点は、パッケージのアーキテクチャが正しい、通常ユーザーで手動起動できる、コアの起動エラーがない、プロキシポートが使える、再ログイン後に一度だけ起動する、の5つです。それぞれ別の問題として順に確認すれば、何度も再インストールするより効率よく原因を特定できます。