「行を選択する」「アクティブサーバーに設定する」「システムプロキシを有効にする」は、それぞれ別の操作です。サブスクリプショングループ、サーバー一覧、ログ、設定の順に確認しましょう。サブスクリプションを追加したもののメイン画面の使い方がまだ分からない方に向けて、グループの更新、ノードのテスト、プロキシ状態の確認方法を解説します。読み終えるころには、最初に記録されたログを手がかりに、次の確認箇所を判断できるようになります。
メイン画面の見方：設定・選択・動作状態を区別する
v2rayNのメイン画面は設定を行う場所であり、接続成功を証明する画面ではありません。サーバー一覧にはノードの設定、サブスクリプショングループにはノードの取得元が表示されます。ログにはコアの動作状況、画面下部のステータス欄にはシステムプロキシやルーティングなどの状態が示されます。一覧にノードが表示されていても、クライアントに設定が登録されていることしか分かりません。
この記事では、Windowsデスクトップ版の日本語UIではなく、中国語UIを操作基準として説明します。バージョンや画面によってメニューの配置は異なり、システムプロキシの項目がウィンドウ下部とトレイメニューの両方にある場合もあります。ボタンの位置ではなく、メニュー名を手がかりに探してください。操作前に「ヘルプ」→「バージョン情報」でバージョンを記録し、トラブルの確認時にはOSとコアのバージョンも控えておきましょう。
| エリア | 主な用途 | ここだけでは判断できないこと |
|---|---|---|
| サーバー一覧 | プロトコル、アドレス、ポート、テスト結果の確認とアクティブサーバーの設定 | ノードが表示されても、接続できるとは限らない |
| サブスクリプショングループ | ノードの取得元を切り替え、URLを保存してサブスクリプションを更新 | グループを切り替えても、アクティブサーバーは切り替わらない |
| ログ | コアの起動、接続リクエスト、エラーの確認 | リクエストが1件記録されても、すべてのアプリがプロキシを通るとは限らない |
| 画面下部のステータス欄 | システムプロキシ、ルーティング、ローカルの待ち受け情報を確認 | システムプロキシを有効にしても、すべての通信がプロキシ経由になるとは限らない |
| 設定 | ローカルの待ち受け、画面動作、その他の実行オプションを変更 | ローカルポートを変更しても、リモートサーバーのポートは変わらない |
サーバー一覧の操作：先にアクティブサーバーを設定してからテスト
行をクリックすると、通常は編集や右クリック操作の対象として選択されます。選択時の背景色を、アクティブサーバーの印と混同しないでください。対象ノードを右クリックし、「アクティブサーバーに設定」を選択したうえで、アクティブ表示とその後のログを確認します。設定後にコアの設定が再読み込みされ、一時的に起動ログが表示されることがあります。
一覧の「ポート」は通常、リモートノードが提供するサービスのポートです。一方、設定にあるローカル待ち受けポートは、アプリがv2rayNに接続するための入口です。用途が異なるため、同じ番号にする必要はありません。プロトコル、トランスポート方式、TLS、認証の各パラメーターはまとめて確認してください。別のノードが使えるからといって、ポートやドメインだけをコピーしても接続できるとは限りません。
- ノードを編集する：右クリックメニューから該当プロトコルの編集項目を開き、アドレス、ポート、トランスポートの設定を確認します。サブスクリプションから取得したノードは、まず取得元の設定を確認し、一時的な変更を恒久設定と混同しないようにしましょう。
- サーバーの実接続遅延を測定する：テスト対象の行を選択してから、右クリックメニューの実接続遅延テストを実行します。複数選択時は対象だけをテストし、一覧全体へのテストリクエストが一度に集中しないようにしてください。
- 並べ替え結果：列見出しをクリックしたら、昇順か降順かを確認します。空欄、失敗した結果、数値では並べ替えの扱いが異なる場合があり、先頭に表示された項目が最良とは限りません。
- 項目を削除する：先に所属するサブスクリプショングループを確認してください。サブスクリプションから取得したノードを手動で削除しても、次回の更新後に再表示されることがあります。削除が失敗したわけではありません。
サブスクリプショングループの管理：絞り込みと更新は別の操作
サブスクリプショングループには取得元を登録し、同じ取得元のノードをまとめます。グループを切り替えると一覧の表示範囲が変わりますが、サブスクリプションの内容が自動で再取得されるわけではなく、アクティブサーバーが切り替わるわけでもありません。一覧が突然空になった場合は、まず検索条件をクリアして全グループに戻し、ノード自体が削除されたか確認してください。
-
グループ設定を開く
「サブスクリプショングループ」→「サブスクリプショングループの設定」を開きます。既存のグループを選ぶか、新しいグループを追加してください。メモには「普段使い」「予備」など取得元を判別できる内容を入力し、サブスクリプションURL全体は記載しないようにしましょう。
-
サブスクリプションURLを保存する
グループ設定にサブスクリプションURL全体を入力して保存します。URLのクエリパラメーターも認証情報の一部であることが多いため、ドメインとパスだけを残してはいけません。画面を撮影する前に、URL全体を隠してください。
-
サブスクリプションを更新する
「サブスクリプショングループ」→「すべてのサブスクリプションを更新（プロキシを使用しない）」を選んで更新します。現在のネットワークからサブスクリプションURLにアクセスできず、利用可能なプロキシ経路がある場合は、「すべてのサブスクリプションを更新（プロキシを使用）」を試してください。
-
更新結果を確認する
更新結果のメッセージを確認し、対象グループに戻ってノード名、アドレス、プロトコルを確認します。更新に成功したら、アクティブサーバーを設定して実接続遅延をテストしましょう。「サブスクリプションの取得成功」と「ノードへの接続成功」は別です。
サブスクリプションを更新すると取得元のノードが置き換わる場合があり、サブスクリプション上のノードを直接編集しても変更が保持されないことがあります。パラメーターを一時的に試すときは、まず独立した項目として複製し、サブスクリプションによる上書き対象でないことを確認してから、1項目ずつ変更して比較してください。自動更新の間隔は一覧を取得するためのもので、ノードの接続テストに代わるものではありません。サブスクリプション側でリクエスト頻度が制限されている場合は、更新を繰り返して解決しようとしないでください。
ログとステータスの確認：リクエストの経路を追う
まずログ表示を有効にし、アクティブサーバーを切り替えてから、接続可能と分かっているHTTPSアドレスにアクセスします。時系列に沿って、コアが起動したか、ローカルリクエストを受け取ったか、どのアウトバウンドに振り分けられたか、最後にエラーが出たかを確認してください。最後の1行だけを切り取るのではなく、最初に出た起動エラーにも注目しましょう。後から繰り返し表示される接続失敗より、原因の特定に役立つことがあります。
ログに記録された接続先のドメイン、IP、ポート、ルーティングタグは、通信経路を判断する手がかりになります。ただし、記録の詳しさはログレベルとコアによって異なります。すべてのリクエストが表示されないからといって、通信がなかったとは限りません。必要に応じて一時的にログの詳細度を上げ、問題を一度再現したら元の設定に戻してください。アクセス記録を不要に長期間残さないようにしましょう。
| ログのキーワード | まず確認すること | 次に行うこと |
|---|---|---|
address already in use | ローカル待ち受けポートが使用中 | 重複して起動しているプロセスを終了するか、使用中のプロセスを確認してローカルポートを変更する |
connection refused | 接続先のアドレスとポートでサービスが待ち受けているか | 接続先がローカルの入口かリモートノードかを確認し、それぞれに対応するサービスを調べる |
i/o timeout | ネットワーク経路、リモートサービス、リクエスト先 | 同じテスト先を使い、接続できると確認済みの別ノードと比較する |
x509 | システム時刻、証明書の有効期限、サーバー名 | システム時刻を合わせ、サブスクリプションのTLS設定を確認する。証明書検証は無効にしない |
画面下部の通信速度だけでは、特定のブラウザーがプロキシを経由している証拠にはなりません。他のプログラムが通信している可能性もあります。確認時は無関係な処理を止め、システムプロキシの状態を確認してから、対象リクエストのログと出口IPを調べてください。ルーティングによって一部の接続先が直接接続されることもあるため、「プロキシが有効」と「すべてのサイトで出口が変わる」は同じ意味ではありません。
設定の確認：ローカルポートとリモートポートを区別する
「設定」→「パラメーター設定」を開き、まずローカル待ち受けポートと「LANからの接続を許可」などの関連項目を確認します。バージョンによって項目のタブが異なる場合があります。変更前に現在値を記録し、一度に変更するのは1項目だけにしてください。待ち受け設定を保存したら、起動ログで実際に反映されたアドレスとポートを確認しましょう。
以下は項目間の関係を説明するための例であり、すべてのバージョンの既定値でも、インポート可能なノード設定でもありません。ローカルに混合プロキシの入口を用意し、リモートノードがTLS対応のサービスポートを使う場合を想定すると、次のように分けて記録できます。
ローカル待ち受けの例
- 待ち受けアドレス
- 127.0.0.1
- 待ち受けポート
- 10808
- 入口の種類
- 混合プロキシの入口
- LANからの接続
- 無効
アプリがこのポートから対象プロトコルを利用するのは、実際の設定が混合プロキシ入口になっている場合だけです。起動ログで確認してください。
リモートノードの例
- サーバーアドレス
- node.example.invalid
- サーバーポート
- 443
- プロトコル
- VLESS
- トランスポートのセキュリティ
- TLS
接続できない説明用アドレスです。実際のノード設定はサブスクリプションの取得元に従ってください。この4項目だけで完全な設定を組み立てることはできません。
記録を確認しやすくするため、トラブル対応で使う3種類の数値を分けておきましょう。以下は前述の例、またはプロトコル範囲の説明用であり、実測値ではありません。
- ローカル待ち受け：アプリが接続するローカルの入口を指定します。ポートを変更した場合は、プロキシを手動設定しているアプリ側も変更してください。
- LANからの接続：他の端末からこの入口を使う必要がある場合に限り有効にし、ファイアウォールで接続元を制限してください。ローカルプロキシのポートをインターネットに直接公開しないでください。
- コアの選択：ノードのプロトコルとトランスポートの仕様に合ったものを選びます。プロトコルや項目を認識できない場合は、実際に起動しているコアとバージョンを確認してください。セキュリティ設定を削除して無理に起動しないでください。
- 起動・画面の動作：OS起動時の自動起動や最小化などの項目は動作方法を変えるもので、サーバーに接続できない問題や認証エラーは解決しません。
システムプロキシとTUNの選択：用途に合わせて確認
メイン画面下部またはトレイメニューの「システムプロキシ」→「システムプロキシを自動設定」を選ぶと、OSのプロキシ設定に従うアプリがローカルの入口を使います。終了前に「システムプロキシを解除」を選べば、プログラム終了後も停止したローカルポートをシステムが参照し続ける事態を避けられます。ブラウザー拡張機能やアプリ独自のプロキシ設定がシステム設定より優先される場合があるため、個別に確認してください。
用途別の比較：システムプロキシとTUN
システムプロキシを使う
- システムプロキシ設定に従うブラウザーやデスクトップアプリに適しています。
- ローカルポートが待ち受け中であることを確認してから、自動設定を有効にします。
- アプリ側でプロキシを個別設定している場合は、古いポートを参照していないか確認します。
TUNモードを使う
- システムプロキシに従わないプログラムを、ネットワーク層でプロキシ経由にしたい場合に適しています。
- 管理者権限が必要になる場合があります。仮想ネットワークアダプター、DNS、ルーティングも確認してください。
- 競合するネットワーク制御ソフトを停止してから、対象アプリで動作を確認します。
どちらの接続方式もルーティングルールの影響を受けます。まず片方を正常に動かし、確認後にもう片方を追加してください。複数の設定を同時に変えるのは避けましょう。
ルーティングの設定によって、通信はプロキシ経由のアウトバウンドにも直接接続のアウトバウンドにも振り分けられます。特定のサイトを調べるときは、現在のルーティング設定を記録してから、リクエストログと出口を確認してください。ルールを一時的に切り替えた場合は、確認後に元の設定へ戻します。プロキシの動作確認のために、未確認の全通信プロキシ設定をそのまま使い続けないでください。特にLAN内アドレスやローカルサービスへのアクセスに注意が必要です。操作の詳細はシステムプロキシの説明とTUNモードの説明をご覧ください。
よくある画面操作の疑問
別のノードを選んだのに、出口が変わらないのはなぜ？
ノードをクリックして選択するだけでなく、右クリックして「アクティブサーバーに設定」を実行してください。次に、対象のリクエストが直接接続に振り分けられていないかを確認します。以前の接続結果を新しいノードの結果と混同しないよう、既存のテスト接続を閉じるか、テスト対象のアプリを再起動してから試してください。
サブスクリプション更新後に一覧が空になりました。ノードがすべて消えたのでしょうか？
検索ボックスを空にして全グループに戻し、更新結果のメッセージを確認してください。取得内容がサブスクリプションとして認識できない場合や、URLの認証が無効になっている場合は、サブスクリプションURL全体とサービスの状態を確認します。すべてのグループを何度も削除して作り直す必要はありません。
実接続遅延は測定できるのに、ブラウザーでサイトを開けないのはなぜ？
「システムプロキシ」が自動設定されているかを確認し、ブラウザー独自のプロキシ設定も調べてください。実接続遅延テストで確認できるのはテスト用の経路です。ブラウザーのプロキシ入口、DNS、接続先サイトへのルーティングまでは確認できません。
設定変更後にポート使用中というログが出た場合は？
まず、重複して起動しているv2rayNを終了してから再起動してください。それでもポートが使用中の場合は、OSのツールで使用中のプロセスを特定します。ポートを変更する必要がある場合は、「設定」→「パラメーター設定」で変更し、プロキシポートを手動指定しているアプリも更新してください。
問い合わせるとき、画面のどの情報を共有すればよいですか？
クライアント、OS、コアの各バージョン、使用しているプロキシ方式、問題の再現前後に出たエラーログを共有してください。サブスクリプションURL、認証情報、不要な接続先は隠します。原因の層を判断できるよう、エラーのキーワード、発生順、ポートの関係は残してください。
一通り確認するときは、「サブスクリプションを更新 → アクティブサーバーを設定 → 実接続遅延をテスト → システムプロキシを確認 → リクエストログを確認」の順で進めます。各手順の結果を記録し、問題が出た段階で止めて原因を調べてください。これにより、サブスクリプションの取得失敗、コアの起動失敗、アプリがプロキシを使っていない状態を切り分けられ、関係のないメニューで設定を何度も変更せずに済みます。