この記事では、v2rayNを初めて起動した方や、アップデート後に機能の場所が分からなくなった方に向けて、v2rayN 7.15.4の画面を例に、メニューバー、サブスクリプショングループ、サーバー一覧、実行ログ、設定の役割を順に説明します。読み終える頃には、現在のノードがどのグループに属するか、どのノードが使用中か、接続失敗時にどのログを確認するか、Coreタイプとローカルポートをどこで確認するかが分かります。
まずメインウィンドウの機能マップを把握する
画面のポイント
v2rayNのメインウィンドウは、操作の流れに沿って5つの領域に分けて考えると分かりやすくなります。上部メニューはコマンドを実行し、サブスクリプショングループは設定元を分類し、サーバー一覧はノードの表示と選択を行います。ログ領域は動作状況を報告し、下部のステータス領域は現在のプロキシモード、使用中のサーバー、ローカルの待ち受けポートを表示します。トラブルシューティングでは、この流れに沿って確認し、すべてのメニューを何度も行き来しないようにしましょう。
画面のポイント
7.xのマイナーバージョンによってアイコンの位置やメニュー名が変わることはありますが、データの関係は基本的に変わりません。サブスクリプショングループはノードではなく、ノードも実際に稼働しているアウトバウンドそのものではありません。一覧の設定をアクティブサーバーに指定し、対応するコアを起動して初めて、その設定が接続に使われます。システムプロキシの有効・無効は、ブラウザーなどのアプリがトラフィックをv2rayNへ渡せるかを決める別のスイッチです。
メインウィンドウの2つの確認ルート
通常の接続手順
- 正しいサブスクリプショングループを選択
- 実接続による遅延テストを実行
- アクティブサーバーに設定
- システムプロキシモードを確認
トラブルシューティング手順
- アクティブサーバー名を確認
- コアの起動ログを確認
- 10808、10809ポートを確認
- ルーティングとDNSの記録を確認
通常の操作ではグループからステータスバーへ進み、トラブルシューティングではステータスバーからサーバー設定とコアログへ逆にたどります。
画面のポイント
メニューバーの「サーバー」は、設定1件ごとの追加、編集、削除、インポート、アクティブサーバーへの設定を行います。「サブスクリプショングループ」では購読URLと更新操作を管理し、「設定」にはシステムプロキシ、ルーティング、各種設定、コア関連の項目がまとめられています。初めて使うときは、この3つの入口だけ覚えておけば十分です。エクスポート、バックアップ、バージョン情報の確認が必要になったら、ほかのメニューを使いましょう。
サーバー一覧の各列の意味
画面のポイント
サーバー一覧は設定の一覧表で、1行がコアで読み込める1つのアウトバウンド設定に対応します。アドレス、ポート、プロトコル、トランスポート方式は購読または手動入力の情報です。一方、遅延や速度などの項目は、このPCでテストを実行した結果です。テスト値はノード品質を永久に示すものではなく、ネットワーク経路、サーバー負荷、測定時刻が変われば数値も変化します。
画面のポイント
「エイリアス」は通常、購読元が設定したノード名で、地域、回線、用途の識別に使われます。「アドレス」は接続先ホスト名またはIPアドレス、「ポート」はリモートサービスの待ち受けポートです。ローカルの10808と混同しないでください。「ネットワーク」にはtcp、ws、grpcなど、「セキュリティ」にはtls、reality、noneなどが表示されます。VMessやVLESSなどのプロトコル項目とトランスポート層の項目は組み合わせて確認する必要があり、1列だけでは完全な接続条件を判断できません。
| 一覧の項目 | 表示内容 | トラブル時の確認ポイント |
|---|---|---|
| エイリアス | ノード名と回線情報 | 選択中の行が目的の地域またはグループに属しているか確認 |
| アドレス / ポート | リモートサーバーの接続先 | 名前解決失敗、ポート到達不能、購読データの異常を特定 |
| プロトコル | VMess、VLESSなどのアウトバウンドプロトコル | どのコアで、どのプロトコル設定を処理すべきか判断 |
| トランスポート / セキュリティ | TCP、WebSocket、gRPC、TLS、Realityなどの組み合わせ | パス、SNI、フィンガープリント、Flowなどの追加項目を確認 |
| 実接続遅延 | プロキシハンドシェイク後に得られた応答時間 | 通常のpingより、実際のプロキシ接続確立に近いコストを確認できる |
| 速度 | ダウンロードテスト中に測定されたスループット | 低遅延ノードと高帯域幅ノードを見分けるために使用 |
画面のポイント
たとえば、同じグループにある2つの設定の実接続遅延が186 msと312 msなら、前者のほうが通常はWeb閲覧に適しています。ダウンロード速度が4.8 MB/sと12.4 MB/sなら、後者は大容量ファイルの転送に向く可能性があります。遅延と帯域幅は異なる指標なので、1つの列だけで並べ替えてノードを固定しないようにしましょう。
画面のポイント
行を選択して「アクティブサーバーに設定」を実行すると、通常はハイライト、色、またはステータスバーの文字で現在の設定が示されます。行をマウスでクリックするだけでは、通常は選択状態になるだけで、コアが切り替わったとは判断できません。切り替え後は、下部に表示されるアクティブサーバー名を確認し、ログに新しいアウトバウンド設定の読み込み記録があるか確認してください。
サブスクリプショングループでノードを整理する方法
画面のポイント
サブスクリプショングループには、購読URL、更新ルール、その取得元から生成されたサーバー一覧が保存されます。1つのグループに複数のノード設定を含めることも、更新動作を個別に設定することもできます。仕事用、テスト用、予備回線を別々のグループに分けると、すべてのノードを1つの長い一覧に詰め込むより問題を特定しやすく、誤削除や誤切り替えも減らせます。
画面のポイント
購読を更新すると、v2rayNは購読内容を取得し、対応する設定を解析します。更新成功は、クライアントが購読データを取得して処理できたことを示すだけで、含まれるすべてのノードが接続できるという意味ではありません。更新後は、まず一覧の件数とエイリアスが変わったか確認し、次に対象グループで実接続テストを実行します。グループを切り替えて一覧が空になった場合は、すぐに購読を追加し直すのではなく、先にフィルター条件を確認してください。
-
現在のグループを確認
画面のポイント
メインウィンドウのサブスクリプショングループ領域で対象グループを選び、更新前のノード数を18件のように記録しておきます。別の取得元の一覧を更新結果と取り違えるのを防げます。
-
購読設定を確認
画面のポイント
「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、有効状態、メモ、購読URLの対応関係を確認します。同名のグループはメモで区別してください。
-
グループを更新
画面のポイント
「サブスクリプショングループ」→「現在の購読を更新」を選び、ステータス表示が完了するまで待ちます。すべての取得元を更新する場合は、「すべての購読を更新」を実行します。
-
有効な設定をテスト
画面のポイント
サーバー一覧で対象行を選び、実接続遅延テストを実行します。186 msのような具体的な結果が表示されれば、プロキシハンドシェイク全体が成功しています。空欄やタイムアウトの場合はログを確認してください。
-
コアタイプを確認
画面のポイント
「設定」→「パラメータ設定」→「Coreタイプ」からコア選択画面を開き、対象プロトコルがXrayまたはv2flyに割り当てられているか確認します。保存後、コアを再起動してください。
画面のポイント
更新後にノード数が減っても、必ずしも解析エラーとは限りません。購読元が回線構成を変更した可能性もあります。ノード数、エイリアス、プロトコル列を比較し、更新ログに認識できない設定タイプが出ていないか確認してください。購読から生成されたノードを手動で変更した場合、次回更新で上書きされることにも注意が必要です。長期的に残すカスタム設定は、独立したグループに置くとよいでしょう。
ログパネルで確認すべき情報
画面のポイント
ログは1行ずつ読むことより、接続経路がどの段階で止まったかを確認するために役立ちます。起動時は、設定の読み込み、コアプロセスの稼働、ローカルポートの待ち受けを確認し、アクセス時はDNS、ルーティングの一致、リモート接続の結果を確認します。最初の段階で失敗している場合、ブラウザーのプロキシやルーティングルールを調整し続けても問題は解決しません。
画面のポイント
正常な起動の流れは、v2rayNが実行用設定を生成し、Xrayまたはv2flyコアを起動し、ローカルの待ち受けアドレスが確立された後、アプリのトラフィックが127.0.0.1へ入るというものです。以前のバージョンではSOCKSポートが10808、HTTPポートが10809であることが一般的でした。7.xの一部の設定では混合待ち受けを使うため、最終的には「設定」→「パラメータ設定」に表示されるローカルポートを基準にしてください。
起動確認の例
Core: Xray
SOCKS: 127.0.0.1:10808
HTTP: 127.0.0.1:10809
Active server: HK-02 VLESS Reality
Routing: domainStrategy = AsIs
Test result: true connection latency 186 ms
- ポートの競合:ログにbind、address already in use、待ち受け失敗が表示された場合は、10808または10809を使用している古いプロセスを終了するか、パラメータ設定で未使用のポートに変更します。
- ドメイン名の解決:resolve、DNS timeoutなどの記録がある場合は、DNS設定と現在のネットワークで基本的な名前解決ができるか確認してから、問い合わせ方法の変更が必要か判断します。
- リモート接続のタイムアウト:connection timeout、context deadline exceededが表示された場合は、同じグループの別ノードを再テストし、特定ノードの障害かローカルネットワークの問題かを切り分けます。
- 認証失敗:ユーザー識別子、キー、Reality公開鍵、shortIdに関する記録がある場合は、購読を再更新して設定項目を確認します。テストを繰り返してもパラメータは修正されません。
- ルーティングによる拒否:接続がblockアウトバウンドで処理されている場合は、ルールの一致順序と、inboundTag、domain、ip、outboundTagの対応関係を確認します。
画面のポイント
ログのwarningが必ずしも接続を中断するとは限りません。互換性設定の一部が無視されても、コアが正常に待ち受けを続ける場合があります。優先して対応すべきなのは、プロセス終了、設定解析失敗、待ち受け失敗につながるerrorです。まず起動時刻付近にある最初の重要なエラーを探し、次にそれによって発生した後続エラーを確認します。
画面のポイント
問題を再現するときは、古いログを消去するか現在時刻を記録してから、目的の操作を1回だけ実行します。たとえば14:32:10にノードを切り替え、14:32:15にテストページを開いたなら、その時間帯を重点的に確認します。数時間前のタイムアウトを現在の問題と誤認せずに済み、切り替え前後のアクティブサーバーやルーティング結果も比較しやすくなります。
コア設定への入口と4種類の重要パラメータ
画面のポイント
v2rayNの主要なスイッチがすべてサーバー編集画面にあるわけではありません。個別サーバーの編集画面はリモート側のプロトコル設定を扱い、ローカル待ち受けポート、Coreタイプ、ログレベル、一部のDNS動作は「設定」→「パラメータ設定」にあります。システムプロキシモードとルーティングモードは、より上位のトラフィック入口と振り分けを制御します。変更時は、どの層を調整しているのかを明確にしてください。
画面のポイント
Coreタイプは、どのコアが設定を処理するかを決めます。v2rayNのデスクトップ版では、VLESSやRealityなどの設定にXrayを使うことが多く、プロトコルに応じてv2flyを選ぶこともできます。Coreタイプを変更したら設定を保存してコアを再起動し、実際に起動したコア名をログで確認してください。プルダウンの選択だけを変えて再起動しなければ、現在のプロセスは古い設定を使い続ける可能性があります。
ローカルプロキシの入口
- SOCKSアドレス
- 127.0.0.1
- SOCKSポート
- 10808
- HTTPポート
- 10809
- 用途
- ローカルアプリのトラフィックを受け付ける
ポートはパラメータ設定に表示される実際の値を使用し、ブラウザーの手動プロキシには同じポートを入力します。
Coreタイプ
- メニューの場所
- 設定 → パラメータ設定
- 主に使うコア
- Xray
- 選択可能なコア
- v2fly
- 適用に必要な操作
- 保存してコアを再起動
選択結果がサーバーのプロトコルとトランスポート設定に合っているか確認し、起動ログで再確認します。
システムプロキシモード
- 無効
- システムプロキシを変更しない
- 自動設定
- ルールに従ってトラフィックを送信
- グローバル
- システムトラフィックをローカルプロキシへ渡す
- 確認場所
- メインウィンドウのステータス領域
コアが起動しているのにWebページへ直接接続される場合は、システムプロキシモードが想定どおりかをまず確認します。
ログとルーティング
- ログレベル
- warning / info
- トラブルシューティング用レベル
- info
- ドメインポリシー
- AsIs
- ルールの重要項目
- outboundTag
トラブルシューティングが終わったら通常のログレベルに戻し、ルーティングを変更した後は対象ドメインへ実際にアクセスして確認します。
画面のポイント
システムプロキシ、Coreタイプ、ルーティングモードは連続した関係にあります。アプリがまずリクエストをローカルプロキシポートへ送り、コアがサーバー設定を読み込み、最後にルーティングルールに従ってダイレクト、プロキシ、ブロックのいずれかのアウトバウンドを選択します。Webページが開けないときは、この順序で原因を特定してください。Coreタイプを直接変更しても、見た目の症状が変わるだけで、ポート、ノード、ルールにある本当のエラーが解決しないことがあります。
メイン画面でよくある疑問と素早い切り分け
画面のポイント
画面に慣れれば、ほとんどの問題は、グループが更新されていない、ノードがアクティブサーバーに設定されていない、コアが正常に待ち受けていない、システムトラフィックがローカルプロキシに入っていない、という4種類に分類できます。まず該当する種類を特定してから設定を変更するほうが、ノードを次々に交換したり購読を何度もインポートしたりするより、再現性のある結果を得やすくなります。
ノードをダブルクリックしても以前の回線のままなのはなぜ?
画面のポイント
まず下部のステータス領域に表示されるアクティブサーバー名を確認します。変わっていなければ、対象行を右クリックして「アクティブサーバーに設定」を実行し、コアを再起動します。その後、ログで新しい設定が読み込まれたことを確認してください。
購読は更新成功なのに、なぜ一覧が変わらない?
画面のポイント
更新したばかりのグループを表示しているか確認し、一覧のフィルター条件を解除します。更新前後のノード数を18件のように記録してください。件数もエイリアスも変わっていなければ、購読内容自体が変更されていない可能性があります。
実接続遅延が空欄の場合、どこを確認すればよい?
画面のポイント
まずコアが起動しているか確認し、次にテスト時間帯のDNS、接続タイムアウト、認証に関する記録を確認します。10808の待ち受けに失敗している場合は、遅延テストで使えるローカルの入口を確保するため、先にポート競合を解消してください。
コアは動作しているのに、ブラウザーが直接接続するのはなぜ?
画面のポイント
システムプロキシモードとブラウザー自身のプロキシ設定を確認します。手動設定では、SOCKSを127.0.0.1:10808に指定し、HTTPはパラメータ設定に表示されるポートを入力します。リモートサーバーのポートと混同しないでください。
ルーティングモードを切り替えた後、どう確認すればよい?
画面のポイント
コアを再起動し、ダイレクト接続とプロキシ接続を想定した対象へそれぞれアクセスします。infoレベルのログで一致したoutboundTagを確認してください。すべてのリクエストが同じアウトバウンドに送られる場合は、ルールの順序とフォールバックルールの位置を確認します。
画面のポイント
最後に、次の固定手順でメイン画面を確認できます。グループを確認し、ノードを選択し、実接続テストを実行し、アクティブサーバーに設定し、システムプロキシを確認し、対象ページを開き、該当時間帯のログを読みます。各手順には画面上で確認できる明確な結果があるため、異常があればその層で対処でき、購読、ポート、コア、ルーティングを同時に変更する必要はありません。