v2rayNをWindowsにインストールする方法｜WPF版とDesktop版の選び方・よくあるトラブル

この記事の概要

初めてインストールする場合は、まずWindowsのアーキテクチャを確認し、Desktop版かWPF版を選びます。ファイルをすべて解凍し、ランタイムの警告に対処したら、サブスクリプションを登録してサーバーを選択し、システムプロキシを有効にして実際に接続できるか確認しましょう。初回利用時やアップデート後に起動できなくなった場合に向けて、画面、コア、ローカルの待ち受け、システムプロキシを切り分け、異なる原因を混同しない方法を解説します。

配布版を選ぶ：WPF版とDesktop版の違い

WPFはWindowsの画面技術です。v2rayNのWPF版は従来型のデスクトップ操作を引き継ぎ、Desktop版はクロスプラットフォームのUIを採用しています。主な違いは画面と配布形式であり、プロキシプロトコルの違いではありません。また、どちらか一方が速いとも限りません。同じサーバーでも、実際の通信速度はコアやルーティング、通信設定、ネットワーク環境によって変わります。

Desktop版

WPF版

従来型のWindows UIを使いたい方に適しています。ただし、WPF版だからといって古いシステムで使えるとは限りません。新しいバージョンに必要なランタイムやシステム要件は、各配布版のリリース情報で確認してください。

おすすめ：従来型のUIに慣れていて、Windowsでの利用環境が整っている方。

Windowsの「設定」→「システム」→「バージョン情報」を開き、「システムの種類」を確認します。x64システムでは通常x64版を選び、ARM64端末では対応するネイティブ版を選びましょう。64ビットと表示されていても、CPUが必ずx64とは限りません。ランタイムとクライアントで異なるアーキテクチャのものを混在させないでください。

ダウンロードと解凍：書き込み可能なフォルダーを用意

クライアントのダウンロードページからWindows版を選びます。配布ファイルはインストーラー形式と圧縮ファイル形式があります。インストーラーはウィザードに従ってインストールし、圧縮ファイルはすべて解凍してから、フォルダー内の実行ファイルを起動してください。圧縮ソフトのプレビュー画面から直接実行するのは避けましょう。

アーキテクチャを確認

Windowsの「設定」→「システム」→「バージョン情報」でx64またはARM64を確認し、ダウンロードページに記載されたUIの種類とアーキテクチャを照合します。アイコンやファイルサイズだけで判断しないでください。
すべて解凍

圧縮ファイルを右クリックして「すべて展開」を選び、たとえば現在のユーザーが書き込める D:\Tools\v2rayN に保存します。中のサブフォルダーもすべて保持し、v2rayN.exe だけをコピーしないでください。
初回起動

メインプログラムを起動します。ランタイムが必要というメッセージが表示されたら、フレームワーク名、メジャーバージョン、アーキテクチャを控え、プログラムを終了してから該当する依存関係を追加し、再起動してください。
コアを確認

「設定」→「パラメーター設定」を開き、現在のバージョンで利用できるコア関連の項目を確認します。接続を開始したらログも確認してください。コアが見つからないと表示される場合は、配布ファイルのフォルダーがすべてそろっているか、セキュリティソフトの隔離履歴に該当ファイルがないかを確認します。
作業フォルダーを維持

設定を正常に保存できることを確認してから、ショートカットを作成します。アップデート前に旧プロセスを終了して設定をバックアップし、新しいフォルダーで新版を先に検証しましょう。複数バージョンのプログラムやコアのファイルを同じ場所に混在させないでください。

設定を書き込む必要があるポータブル版は、保護されたシステムフォルダーに置かないようにしましょう。通常のシステムプロキシ設定に管理者権限は不要です。問題が起きるたびに管理者として実行しても、ファイル不足は解消されず、フォルダーのアクセス権の問題も見えにくくなります。TUNなどの機能を使う場合は、プログラムの案内に従って必要な権限を設定してください。

ランタイムの依存関係：エラー表示に合わせて追加

「.NETをインストール済み」だけでは、必要な依存関係がそろっているとは限りません。フレームワーク依存型の配布版は、特定のランタイム系列を必要とします。自己完結型の配布版には通常、必要なランタイムが含まれていますが、OSやネイティブコンポーネントの要件は残ります。自己完結型かどうかはリリース情報で確認し、ファイルの拡張子だけで判断しないでください。

メッセージ・症状	まず確認すること	対処方法
.NETのインストールまたは更新を求められる	表示されたフレームワーク名、メジャーバージョン、アーキテクチャ	Microsoftの公式配布元から、要件に合ったランタイムを入手します。通常の実行にSDKは不要です。
Microsoft.WindowsDesktop.Appが見つからない	通常の.NET Runtimeだけをインストールしていないか	表示された要件に合うWindows Desktop Runtimeをインストールし、x64またはARM64も確認します。
特定のDLLが見つからないと表示される	解凍したファイル一式、隔離履歴、DLLのファイル名	配布ファイル一式を入手し直して依存関係を確認します。出所不明のダウンロードサイトからDLLだけを入手しないでください。
ウィンドウが一瞬表示されて消える	旧プロセスの残存、システム要件、起動ログ	まず新しいフォルダーで完全な配布版を試し、ログやWindowsのイベントログをもとに原因を特定します。
画面は開くがコアを起動できない	コアのファイルパス、待ち受けポート、設定の生成結果	コア側のエラーを解決してください。画面が開くこととプロキシ接続が確立することは別です。

.NETの異なるメジャーバージョンは共存できますが、新しいメジャーバージョンをインストールしても、古いバージョンの要件が自動的に満たされるとは限りません。特にWPFがデスクトップランタイムに依存する場合は、Windows Desktop Runtimeと通常の.NET Runtimeを区別してください。古い手順に従って特定世代のランタイムを固定でインストールするのではなく、起動時のメッセージに示された要件を一つずつ確認しましょう。

初回のサブスクリプション登録：リストを更新してから接続先を設定

まずメインプログラムが起動することを確認してから、サブスクリプションを設定します。サブスクリプションURLは複数のサーバー設定を取得・更新するためのものです。vmess://、vless://などの共有リンクは、通常、単一ノードの設定を表します。単一ノードのリンクをサブスクリプションURL欄に貼り付けても、クリップボードからのインポートにはなりません。

グループを作成：「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、新しいグループを追加して分かりやすい名前を入力します。URL欄にサブスクリプションURL全体を貼り付けて保存してください。
ノードを取得：メイン画面に戻り、「サブスクリプショングループ」メニューから該当する更新操作を実行します。バージョンによっては、現在のグループのみ更新、すべてのグループを更新、プロキシ経由で更新などの選択肢があります。実際のメニュー表示に従ってください。
更新結果を確認：グループにノードが表示されるか確認し、ログにネットワークエラー、認証失敗、非対応形式のメッセージがないか確認します。グループ名が表示されていても、サブスクリプションの内容を取得できたとは限りません。
サーバーを選択：一覧で対象ノードを右クリックし、「アクティブサーバーに設定」を選びます。現在の状態が選択したノードと一致していることを確認してから、実際に接続をテストしてください。

初回インストール時に利用可能なプロキシがない場合は、「プロキシ経由で更新」を機械的に選ばないでください。直接アクセスでサブスクリプションURLを開けないときは、URLが有効であることとネットワークからアクセスできることを確認し、利用可能な接続を使って更新します。反対に、正常に動作するプロキシがすでにあるなら、決まった手順に合わせるためだけに直接接続へ切り替える必要はありません。

サブスクリプションの更新に成功して接続できない場合は、サービスの有効期限、端末の時刻、ノード設定がすべてそろっているかを確認します。VMessとVLESSはプロトコル名で、サブスクリプションは設定を配布する方法です。サブスクリプションを登録しても、サーバー側とクライアント側で一致しない設定が自動修正されるわけではありません。

システムプロキシとローカルポート：起動中のコアに通信を渡す

まずコアが起動していることを確認し、v2rayNの「システムプロキシ」メニューから「システムプロキシを自動設定」を選択します。Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」でシステムプロキシの状態を確認できます。システムプロキシが適用されるのは、その設定に従うアプリだけです。すべてのプロセスの通信が自動的にプロキシ経由になるわけではありません。

127.0.0.1

ローカルのループバックアドレス。リモートノードのアドレスではありません

10808

ポートは説明用の例です。実際の待ち受け設定を確認してください

2層

システムプロキシの入口とクライアントのルーティングを個別に確認

以下の2つのカードはトラブルシューティング用の設定例であり、すべてのバージョンの初期値ではありません。「設定」→「パラメーター設定」で実際の待ち受けポートと受信方式を確認してください。HTTPまたは混合プロキシに対応しているポートだと確認できた場合に限り、後述のHTTPテストコマンドを使えます。古い手順をそのままコピーして、別バージョンのポートを自分の環境の設定だと思い込まないでください。

クライアントの待ち受け設定例

待ち受けアドレス: 127.0.0.1
ローカルポート: 10808
受信方式: HTTPまたは混合受信
LANからのアクセス: 無効

このPCだけで使う場合はループバックで待ち受け、意図せずLANにプロキシを公開しないようにします。

システムプロキシの確認項目

プロキシアドレス: 127.0.0.1
プロキシポート: 実際のHTTP受信ポートと一致
コアの状態: 正常に起動
サーバーの状態: アクティブサーバーを設定済み

システムプロキシは通信の入口にすぎません。通信をプロキシ経由にするか、直接接続するか、遮断するかはルーティングルールで決まります。

ローカルポートが使用中だと、コアが起動できない一方で、Windowsには以前のプロキシ設定が残ることがあります。その場合、ブラウザーは正しく待ち受けていないポートへリクエストを送るため、ネットワーク全体が切断されたように見えます。ポートを変更したら、システムプロキシも忘れずに更新し、アプリ内で手動設定したプロキシが古いポートを参照していないか確認してください。

接続を確認：待ち受け、プロキシ、ルーティングの順に調べる

まずローカルポート、次にプロキシ経由のリクエスト、最後に実際に使うアプリを確認します。以下のコマンドはPowerShellで実行します。HTTPプロキシが 127.0.0.1:10808 で待ち受けていることを確認済みの前提です。実際の設定が異なる場合は、先にポートを置き換えてください。リクエスト先は説明用です。特定のサイトでの結果だけで、すべてのサイトに接続できるかは判断できません。

Get-NetTCPConnection -LocalPort 10808 -State Listen
Test-NetConnection 127.0.0.1 -Port 10808
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://www.microsoft.com/

待ち受けが確認できない：コアのログに戻り、ポートの競合、設定エラー、ファイル不足を確認します。ブラウザーの設定を何度も切り替えるのは避けてください。
ローカルポートには接続できるが、リクエストに失敗する：ノード、DNS、TLS、ルーティングを確認します。TCPポートに接続できても、ローカルの入口が存在することしか分からず、リモート接続の成功を示すものではありません。
明示的なプロキシリクエストは成功するが、ブラウザーでは失敗する：ブラウザー独自のプロキシ設定、拡張機能、ポリシー、システムプロキシが別のプログラムによって書き換えられていないかを確認します。
一部のアプリだけ失敗する：該当アプリがシステムプロキシに従うか確認します。必要であればTUNの利用を検討してください。ファイアウォールを無効にすることを通常の解決策にしないでください。

curl.exeがHTTPステータスコードを返す場合、少なくとも何らかのHTTP応答にリクエストが到達しています。アクセス拒否などのステータスが返っても、ローカルプロキシが起動していないとは限りません。また、テスト用ドメインがルーティング設定で直接接続に指定されていると、ローカルプロキシを明示してもコアから直接接続されることがあります。ノードが実際に通信を処理したかを判断するには、ルーティングの適用結果と接続ログをあわせて確認してください。

接続確認の進め方：まずシステムプロキシ、必要に応じてTUNを検討

ブラウザーでの通常のアクセス

まずシステムプロキシの自動設定を有効にします。
ブラウザーがシステムプロキシを引き継いでいるか確認します。
ノードのログと照らし合わせて、ルーティングと接続結果を確認します。

システムプロキシに従わないアプリ

まずアプリ単独でプロキシを設定できるか確認します。
より広い範囲の通信をプロキシ経由にする必要がある場合に、TUNを検討します。
有効にする前に、権限、DNS、ほかのVPNとの競合を確認します。

一度に変更する設定は一つにします。システムプロキシでの接続確認が済んでから、より複雑な通信制御やルーティングの要件に対応しましょう。

アップデートと終了：プロキシ設定の残存、ファイルの混在、設定消失を防ぐ

アップデート前に、UIの種類、実際の待ち受けポート、ルーティング設定、設定の保存場所を記録し、プログラムを終了してから設定をバックアップします。ポータブル版とインストール版では設定の保存先が異なる場合があるため、設定が必ず実行ファイルの隣にあるとは限りません。サブスクリプションURLには認証情報が含まれることがあるため、バックアップはアクセスを制限したフォルダーに保存し、トラブル時のスクリーンショットに表示しないでください。

よくある問題	まず行うこと	避けること
新版を起動したら設定がおかしい	旧版のフォルダーを残してバックアップを取り、別のフォルダーで新版を検証してから、サポートされている方法で設定を移行します。	異なるUI版のファイルを混ぜたまま、すべてのファイルを上書きする。
アドレスが使用中と表示される	ポートを使用しているプロセスを特定し、重複起動したインスタンスを終了するか、待ち受けポートを変更します。	同じポートを奪い合うように、複数のインスタンスを続けて起動する。
終了後にブラウザーでネットに接続できない	Windowsのプロキシ設定を確認し、停止したローカルサービスを参照する設定を解除します。	原因を確認せずに、ネットワーク設定全体をリセットする。
サブスクリプションの更新後にノードが減った	グループのフィルター、更新ログ、サブスクリプションサーバーから返された内容を確認します。	調査の手がかりを失うような形で、ローカル設定をすぐにすべて削除する。
管理者として起動したときだけ設定を保存できる	設定フォルダーのアクセス権を確認し、現在のユーザーが書き込める場所に移します。	アクセス権を修正せず、常に管理者権限で実行する。

正常に終了する前に、「システムプロキシ」から「システムプロキシを解除」を選択してからクライアントを終了できます。プログラムが異常終了した場合は、Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシやスクリプトが停止済みのローカルサービスを参照していないか確認してください。職場や学校のネットワークで指定されたプロキシ設定がある場合は、元の設定を記録してから対応し、むやみにすべて解除しないでください。