Windowsで初めてv2rayNを設定する方や、起動できない、サブスクリプションが空、接続後もブラウザーを利用できないといった問題を解決したい方に向けたガイドです。まずアーキテクチャとUI版を選び、ファイルの展開、サブスクリプションの更新、使用サーバーの選択、システムプロキシの設定を進めます。最後にログ、待ち受けポート、プロキシを明示したリクエストを確認し、原因をクライアント・コア・アプリのどこにあるか切り分けます。
1. デスクトップ版とWPF版:UI版を選び、アーキテクチャを確認
v2rayNは設定・管理用のUIで、実際の接続は呼び出されたプロキシコアが処理します。デスクトップ版はクロスプラットフォームのUI、従来のWPF版はWindows向けのUI技術を採用しています。主な違いは画面構成、操作方法、配布パッケージの依存関係です。「デスクトップ版」か「WPF版」かだけで、特定のサーバー設定に接続できるかどうかは判断できません。
デスクトップ版
おすすめ初めて使う場合はデスクトップ版から始めるとよいでしょう。この記事の手順に沿って、サブスクリプショングループ、使用サーバー、システムプロキシ、ルーティングの4つの項目を確認してください。
おすすめのユーザー:初めて設定する方、クロスプラットフォームのUIを使いたい方。
従来のWPF版
従来のWindows版の操作に慣れている方に適しています。異なるUI版のプログラムファイルを混在させないでください。別の版に切り替えるときは、設定をバックアップしてから別のフォルダーに展開し、動作を確認しましょう。
おすすめのユーザー:WPF版の操作に慣れていて、従来の操作手順を維持したい方。
ダウンロード前に、Windowsの「設定」→「システム」→「バージョン情報」を開き、「システムの種類」を確認します。「x64 ベース プロセッサ」と表示される場合はx64版を選び、ARM64デバイスでは対応するアーキテクチャの版を選んでください。UIが互換レイヤー上で起動しても、同梱のコアが対応しているとは限りません。メイン画面が表示されたかどうかだけで判断しないでください。
- UI版:ボタンや画面の配置を決めるもので、プロトコルの種類とは異なります。
- プロセッサアーキテクチャ:メインプログラムとコアの両方に対応したものを選び、異なるアーキテクチャのファイルを組み合わせないでください。
- 配布パッケージの依存関係:自己完結型のパッケージには通常必要なランタイムが含まれます。ランタイムに依存するパッケージでは、対応コンポーネントのインストールが必要です。選んだパッケージの説明と起動時のメッセージを確認してください。
2. ファイルをすべて展開して初回起動
圧縮ファイルは D:\Tools\v2rayN など、書き込み可能なフォルダーにすべて展開してください。圧縮ソフトのプレビュー画面からメインプログラムを直接起動したり、実行ファイルだけを取り出したりしないでください。UI、コア、データファイルは、配布パッケージ本来のフォルダー構成を保つ必要があります。
-
パッケージを確認
当サイトのダウンロードページで、WindowsのアーキテクチャとUI版に合ったパッケージを選びます。選んだバージョンを控えておき、トラブルシューティング中に複数バージョンのファイルを同じフォルダーへ上書きしないでください。
-
すべてのファイルを展開
エクスプローラーで圧縮ファイルを右クリックし、「すべて展開」を選びます。アカウントから書き込み可能な場所にフォルダー全体を展開し、保護されたプログラムフォルダーへの配置は避けてください。
-
メインプログラムを起動
展開先のフォルダーから
v2rayN.exeを起動します。まずメイン画面と通知領域のアイコンが表示されることを確認してください。この時点ではサーバー設定がないため、接続が正常かどうかはまだ判断できません。 -
起動ログを確認
メイン画面のログまたは情報欄を確認します。ランタイム不足、コアが見つからない、アクセス拒否などのメッセージがある場合は、サブスクリプションを登録する前に解決してください。
ウィンドウを閉じても、プログラムが通知領域で動作し続ける場合があります。再起動する前にタスクバーの通知領域を確認し、「ウィンドウが非表示になった」状態を「起動に失敗した」と誤認しないようにしてください。更新やファイルの置き換えを行うときは、通知領域のメニューから終了し、関連するコアのプロセスも停止したことを確認します。
3. サブスクリプションの登録:URLを保存した後に更新する
サブスクリプションURLは複数の設定を取得するためのもので、サーバーアドレスや一般的なWebリンクではありません。アカウント情報やアクセストークンが含まれることがあるため、パスワードと同様に安全に保管してください。画面にサブスクリプショングループを追加しただけでは、URLが保存されただけです。更新を実行して初めてサーバー一覧に項目が表示されます。
-
グループを新規作成
メイン画面で「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、新しい項目を追加します。識別しやすい名前とサブスクリプションURLを入力して保存してください。バージョンによって追加の操作は「追加」またはプラス記号で表示されます。
-
サブスクリプションを更新
「サブスクリプショングループ」メニューに戻り、「すべてのサブスクリプションを更新(プロキシを使用しない)」を実行します。利用可能な接続をまだ確立していない場合は、まず直接取得を試し、ログに表示されるリクエスト結果を確認してください。
-
設定を確認
サーバー一覧に項目が追加されたか確認し、種類、アドレス、ポートが妥当かをチェックします。グループで絞り込んでいる場合は、該当するグループに切り替えてください。フィルター結果が空でも、インポートに失敗したとは限りません。
-
使用サーバーに設定
サーバー一覧で対象の項目を右クリックし、「アクティブサーバーに設定」を選びます。行を選択しただけでは使用する設定が切り替わらない場合があります。アクティブ表示と、その後に出力されるコアのログを確認してください。
利用可能な接続があり、サブスクリプションサービスへのアクセスにプロキシが必要な場合は、メニューからプロキシ経由の更新も試せます。利用可能なサーバーがない状態で、この項目を何度も選ばないでください。更新リクエスト自体にも、正常に動作するプロキシ経路が必要です。
- リクエストに失敗する:URLが改行で途切れていないか、トークンの有効期限が切れていないか、PCの日付と時刻が正しいかを確認します。
- 取得できたのに項目がない:応答がログインページやエラーページではないか、クライアントが認識できない形式のサブスクリプションではないかを確認します。
- 共有リンクが1件だけある:リンク全体をコピーし、「サーバー」→「クリップボードからURLを一括インポート」を選びます。サブスクリプションURLの保存とは別の手順です。
VMess、VLESSなどの種類はサーバー側の設定と一致させる必要があります。ポート、ユーザーID、通信方式、TLS、サーバー名などのパラメーターを推測で補わないでください。サブスクリプションを更新すると、手動で変更した項目が上書きされる場合があります。一時的に変更する場合は、設定を複製して独立させ、比較用に元のグループを残してください。
4. システムプロキシとルーティング:通信の入口と出口を個別に設定
使用サーバーを選んだら、メイン画面下部または通知領域のメニューにある「システムプロキシ」から「システムプロキシを自動設定」を選びます。Windowsのプロキシ接続先を、ローカルの待ち受けアドレスに設定する操作です。ルーティングは、コアに入った通信をプロキシ、直接接続、その他の設定済みアウトバウンドのどれに振り分けるかを決定します。両者は別の設定です。
初回の確認:まずシステムプロキシを使い、その後ルーティングを確認
アプリの通信をプロキシ経由にする
- 「システムプロキシ」から「システムプロキシを自動設定」を選びます。
- Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」で、ローカルのアドレスとポートを確認します。
- ブラウザー専用のプロキシ拡張機能を使っている場合は、システム設定を上書きしていないか確認します。
コアのアウトバウンドを選ぶ
- まずクライアントに用意されている標準のルーティングプリセットを選びます。
- 対象ドメインがカスタムルールによって直接接続またはブロックに設定されていないか確認します。
- 比較のため、一時的にグローバルプロキシへ切り替えて動作を確認し、検証後は普段使うルールに戻します。
システムプロキシを使わないアプリは、ルーティングを変更しても自動的にプロキシ経由にはなりません。コアに入った通信が直接接続に振り分けられている場合も、システムプロキシを再設定するだけでは解決しません。
初回のトラブルシューティングでは、TUNの有効化、DNSの変更、LANアクセスの許可を同時に行う必要はありません。まずシステムプロキシに従うブラウザー1つでアクセスできることを確認し、必要に応じて適用範囲を広げてください。TUNは通信の取り込み方が異なり、仮想ネットワークインターフェース、権限、ルーティングも関係するため、基本的なインストール問題と同時に検証しないでください。
終了前にクライアントで「システムプロキシを解除」を選び、通知領域のメニューから終了することをおすすめします。異常終了後にブラウザーでアクセスできなくなった場合は、Windowsのプロキシ設定に停止済みのローカルポートが残っていないか確認してください。今回のテストで設定した項目だけを解除し、組織や他のソフトウェアが管理するプロキシ設定は上書きしないでください。
5. ローカルポート:実際の待ち受けを確認してから使用中のプロセスを調べる
待ち受けポートは、バージョンや既存の設定によって異なります。以下の2つの数値は、よくある設定を見分けるための例であり、すべてのバージョンを同じ値に変更する必要はありません。「設定」→「パラメーター設定」を開き、ローカルの待ち受けポートとインバウンドの種類を確認して、コアの起動ログと照らし合わせます。
ログに address already in use または待ち受けのバインド失敗が表示された場合は、別のクライアントや他のプログラムがポートを使用していないか確認します。PowerShellで次の読み取り専用コマンドを実行してください。実際のポートが異なる場合は、コマンドのポート番号を変更します。
Get-NetTCPConnection -State Listen -LocalPort 10808 -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Id 1234
2つ目のコマンドの 1234 はプロセスIDの例です。1つ目の出力にある OwningProcess の値に置き換えてください。出力がない場合は、検索時点で該当するTCP待ち受けが見つからなかったことを意味します。まだ起動していない可能性もあるため、ポートが使用中だとは判断できません。
- 使用中のプロセスが古いインスタンス:通知領域から古いインスタンスを正常に終了してから、使いたいバージョンを起動します。
- 使用中のプロセスが別のプログラム:まず用途を確認し、正体のわからないプロセスをすぐに終了しないでください。v2rayN側で
10818などの空きポートに変更できます。 - ポートを変更した後:設定を再読み込みするかコアを再起動してから、システムプロキシを設定し直します。アプリに手動入力したプロキシポートも忘れずに変更してください。
- ローカルPCだけで使用する場合:
127.0.0.1などのループバックアドレスでの待ち受けを基本とし、ローカルの問題を調べるためにLANへむやみに公開しないでください。
6. ランタイム不足とコアの起動失敗
ダブルクリックしてもまったく起動しない場合と、画面は表示されるが接続できない場合は別の問題です。前者はUIプログラムの依存関係、後者はコアのログを確認します。サブスクリプションを何度も登録しても、ランタイム不足は解決しません。ランタイムをインストールしても、サーバーの認証パラメーターの誤りは直りません。
| 症状 | まず確認する項目 | 対処方法 |
|---|---|---|
| .NETのインストールまたは更新を求められる | メッセージに表示されたフレームワーク名、バージョン、アーキテクチャ | 配布パッケージの要件に合うランタイムをインストールします。「Windows Desktop Runtime」が明記されている場合、基本ランタイムだけのコンポーネントで代用しないでください。 |
| 画面は表示されるが、コアのファイルが見つからない | ファイルがすべて展開されているか、セキュリティソフトで処理されていないか | 信頼できる配布元であることを確認し、ファイルをすべて再展開します。別バージョンのフォルダーからコアのファイルだけを抜き出してコピーしないでください。 |
| 設定の生成後、コアがすぐに終了する | ログに最初に記録された具体的なエラー | 設定項目の非互換、リソースファイルの不足、ポートのバインド失敗を切り分け、エラーの種類に応じて対処します。 |
| TLSまたは証明書のエラー | システム時刻、サーバー名、サーバー側のパラメーター | システム時刻を合わせて設定を確認します。証明書検証の無効化を万能な解決策として使わないでください。 |
別バージョンの手順を見て、特定の大きなバージョン番号の.NETを決め打ちでインストールしないでください。フレームワークの依存関係は配布版によって異なるため、現在表示されている起動メッセージを確認します。インストール済みコンポーネントを調べるには、コマンドラインで dotnet --list-runtimes を実行できます。このコマンドが使えない場合でも、自己完結型パッケージが起動できないとは限りません。
v2rayN、V2Fly、Xrayは異なるレイヤーのソフトウェアです。v2rayNは設定を管理するクライアントで、V2FlyとXrayはProject Vのエコシステムから発展したコアプロジェクトです。VLESSや特定のセキュリティ・通信方式の組み合わせを使う場合は、その組み合わせに対応したコアが必要です。エラーを消すためだけにUI上でコアを次々と切り替えず、まずサーバー側の要件を確認してください。
7. 接続確認:アプリの問題と接続の問題を切り分ける
遅延テストで結果が表示されても、そのテスト方式でリクエストに応答があったことしか分かりません。ブラウザーのすべての通信経路が正常とは限りません。検証中は同じ使用サーバーと同じ接続先を保ち、設定を1つずつ変更して、どの操作で結果が変わったか確認してください。
- コアの動作を確認:起動ログに設定の解析エラーやポートのバインドエラーがなく、ローカルポートが待ち受け状態であることを確認します。
- プロキシを明示して接続:コマンドラインからローカルのHTTPまたはmixedインバウンドを指定してアクセスし、アプリがシステムプロキシを参照しているかという条件を切り離します。
- ブラウザーを確認:コマンドが成功してブラウザーだけ失敗する場合は、システムプロキシ、拡張機能、ブラウザー固有のネットワーク設定を確認します。
- 普段のルールに戻す:一時的にグローバルプロキシにして成功した場合は、元のルーティングに戻して、特定の振り分けルールが原因か確認します。
以下のコマンドは、ローカルの 10808 でHTTPまたはmixedプロキシが使える場合に限り有効です。SOCKSインバウンドしかない場合、HTTPプロキシのアドレスとしてそのまま入力できません。--max-time 15 はリクエスト全体の待ち時間を最大15秒に制限するオプションであり、速度やサービスの可用性を示すものではありません。
curl.exe --proxy http://127.0.0.1:10808 --max-time 15 -I https://example.com/
ローカルポートに接続できない場合は、待ち受けの状態を確認します。ローカル接続が確立した後にリモート側でタイムアウトする場合は、使用サーバー、サーバー側の状態、ルーティングログを確認してください。HTTP応答を受信した場合は、ステータスコードが成功を示すものでなくても、何らかのHTTPエンドポイントから応答が届いています。内容を確認して判断し、一律にプロキシ失敗とみなさないでください。
設定が完了したら、使用可能な設定、待ち受けポート、ルーティングモードを記録し、必要な設定をバックアップします。アップグレード時は元に戻せるフォルダーを残し、新しいフォルダーで起動と接続を確認してから、普段使う起動先を切り替えてください。UI版、コア、カスタムルールを同時に変更すると、原因の特定が難しくなります。