v2rayNの初回接続ガイド｜ノード選択・実接続テスト・プロキシ設定の確認

接続前の確認：サブスクリプション、コア、ローカル待ち受け

v2rayNはクライアントの画面を提供し、実際の接続は選択したコアが処理します。サブスクリプションの更新に成功しても、クライアントがノード情報を取得・解析できたことを示すだけで、サーバーが現在稼働していることや、契約に利用可能な通信量が残っていることを保証するものではありません。初回は既存のサブスクリプション設定を維持し、DNS、トランスポート、ルーティング、証明書の設定を一度に変更しないでください。

以下のメニュー名は、一般的な中国語インターフェースをもとにしています。デスクトップ版のビルドによって、項目の分類や句読点が異なる場合があります。特定のバージョンや既定ポートを前提としていません。待ち受けアドレスとポートは、使用中のクライアント設定と起動ログを確認してください。

1. サブスクリプションを更新

   「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、対象グループのURLを確認します。次に「サブスクリプショングループ」から該当する更新操作を実行してください。まだ接続できない場合は、通常、まずプロキシを経由せずに更新します。失敗したら更新ログを確認し、同じグループを繰り返し追加しないでください。

2. ノードを確認

   サーバー一覧で候補のノードをダブルクリックし、サーバーアドレス、ポート、プロトコル、トランスポートの設定を確認します。アドレスが空欄でないこと、リモートポートがサブスクリプションの値と一致することを確認してください。ノード名に含まれる地域名は選択の手掛かりにすぎず、出口の検証に代わるものではありません。

3. コアを確認

   「設定」→「パラメーター設定」を開き、Coreの種類に関する項目を確認します。VLESSやREALITYなどの設定は、対応するフィールドを扱えるコアが必要です。初回接続では、インポートしたノードに対するクライアントの適用結果を維持し、ログに未対応フィールドがないか確認してください。

4. ローカル入口を記録

   「設定」→「パラメーター設定」のローカル待ち受け設定でプロキシポートを記録し、ログに表示された待ち受けアドレスも確認します。以下ではHTTPまたは混合プロキシの入口として 127.0.0.1:10808 を例にします。実際の設定が異なる場合は、コマンド内のポートを置き換えてください。

ノード選択：地域を確認してからプロトコル設定を見る

最初の候補は2〜3個に絞ります。ネットワーク的に近いノードを1つ、別地域の予備を1つ選びます。サブスクリプションに複数のトランスポート方式がある場合は、プロトコルまたはトランスポートが異なる候補をもう1つ加えてください。近い地域のノードが必ず速いとは限りません。ネットワーク間の接続状況、サーバーの負荷、出口回線によって実際の使い勝手は変わります。

プロトコル名だけで性能の優劣は決まりません。VMessとVLESSでは認証方式が異なり、WebSocketはトランスポート方式、TLSとREALITYは接続のセキュリティ設定に関係します。これらの項目はサーバー側の設定と一式で一致させる必要があります。以下は確認項目の組み合わせ例で、任意のノードにそのまま適用できる設定ではありません。

実接続テスト：ポートへの接続とプロキシ経由のリクエストを区別

TCP遅延テストで分かるのは、主にサーバーポートへの接続状況であり、ノード認証の成功を示すものではありません。実接続テストでは、ノード経由でテスト先へ実際にリクエストを送信します。「このプロキシ経路でアクセスを完了できるか」をより直接的に確認できます。テスト先、計測範囲、成功の判定方法はクライアントの設定や実装によって異なるため、結果は実際のアクセスとあわせて確認してください。

1. 候補を選ぶ

   サーバー一覧からテストするノードを2〜3個選択します。複数選択する場合はCtrlキーを押しながらクリックしてください。まずは少数ずつテストし、大量の同時リクエストによってローカルネットワークやサーバーの制限が結果に影響するのを避けます。

2. 実接続テストを実行

   右クリックしてサーバーメニューを開き、「サーバーの実接続遅延をテスト」または同等の実接続テスト項目を選択します。「サーバーの遅延をテスト」で表示されるTCPの結果を、同じ指標として扱わないでください。

3. 繰り返し比較

   このラウンドが終わってから次をテストし、同じテスト先を使って3回繰り返します。成功の有無、遅延の大きな変動、連続タイムアウトを記録し、最も低い値だけで判断しないでください。

4. 接続先に設定

   対象ノードを右クリックし、「アクティブサーバーに設定」を選択して、アクティブ表示が切り替わったことを確認します。その後ログを開き、新しい設定の読み込みとコアの起動が成功したか確認してください。テスト対象を選んだだけでは、現在のアクティブノードは自動で切り替わりません。

実接続の遅延はダウンロード速度ではなく、動画が途切れず再生できるかどうかも示しません。複数のノードが同じテスト先で失敗する場合は、まずテスト先が利用可能か、接続先で制限されていないか、どのルーティングでリクエストが送られたかを確認してから、すべてのノードが同時に使えなくなったか判断してください。テスト日時、接続ネットワーク、テスト先を記録しておくと、遅延の数値だけを撮影するより原因を調べやすくなります。

システムプロキシとルーティング：2つの経路を分けて確認

Windowsの場合、v2rayNのタスクトレイメニューにある「システムプロキシ」から「システムプロキシを自動設定」を選びます。これにより、システムプロキシ設定に従うアプリがローカル入口に接続します。すべてのプログラムを経由させる設定ではなく、TUNを有効にするものでもありません。ブラウザー独自のプロキシ設定、拡張機能、組織のポリシーによってシステム設定が上書きされる場合があります。

初回の切り分けではシステムプロキシ経由の接続を使い、仮想ネットワークアダプター、権限、システムルートの問題が同時に加わらないよう、TUNは有効にしないでください。グローバルプロキシルーティングをテストした後は、普段使うルールベースの振り分けに戻し、対象サイトをもう一度確認します。ここでいう「グローバル」とは、コアに入った通信を選択したルーティング方式でどう処理するかを指し、すべてのアプリの通信がコアに入ったことを意味しません。

ブラウザーと出口IP：あとから確認できる記録を残す

まずローカルプロキシを明示したリクエストで入口を確認し、次にブラウザーでシステムプロキシを検証します。これにより、「ノード自体が失敗している」場合と「ブラウザーがプロキシを使っていない」場合を切り分けられます。以下のコマンドはWindowsのターミナルで実行します。curl.exeでcurlプログラムを明示的に呼び出します。ここでは、ローカルにHTTPプロキシ対応の 10808 入口が用意されているものとします。

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --head https://example.com

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://api.ipify.org

curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 https://api.ipify.org

1つ目のコマンドは、ローカル入口を経由してHTTPSリクエストを完了できるか確認します。HTTPステータスが返った場合は、そのステータスが接続先サービスによるものか、中間のエラーページによるものかを確認してください。ターミナルに文字が表示されたというだけでは成功と判断できません。2つ目のコマンドは、現在のルーティングを経由したリクエストのグローバル出口IPを表示します。3つ目は、curlの明示的なアプリケーション層プロキシを使わない比較用のコマンドです。TUNや他のネットワークトンネルが有効な場合、3つ目の結果はトンネルを完全に経由しない出口を示すものではありません。

• プロキシ経由のコマンドは成功するが、ブラウザーでは失敗する：まずシステムプロキシのポート、ブラウザー独自の設定、拡張機能を確認してください。すぐにコアを再インストールする必要はありません。
• プロキシ経由と直接接続で出口が異なる：2回のリクエストで観測された出口が異なることを示します。同じ検出サービスにブラウザーからアクセスした場合も一致するか確認してください。
• 出口IPが同じ：まず検出ドメインが直接接続のルールに一致していないか、アクティブノードを切り替えたかを確認します。IPが同じというだけで、プロキシが起動していないとは判断できません。
• 出口地域が想定と異なる：地域判定データベースによって結果が異なる場合があります。別の検出元と接続先サービスの実際の判定も確認し、ノード名だけで判断しないでください。

ブラウザーの検証では、コマンドと同じ検出先を開いて更新し、出口IPを記録してから、実際に利用するウェブサイトにアクセスします。「アクティブノード、ルーティングモード、検出先、出口IP、時刻」の5項目を残してください。IPは1回のリクエストで観測された出口にすぎず、すべてのアプリ、ドメイン、DNSリクエストが同じ経路を使うことを証明するものではありません。

よくある接続失敗：ログの位置から原因を絞り込む

失敗した場合は、まずエラーが発生した層を確認します。コアの起動に失敗しているなら、ブラウザーを何度も更新しても意味がありません。ローカル入口が正常に応答しているなら、待ち受けポートを変更してもリモート認証の問題は解決しないことがあります。ログにサブスクリプションURL、UUIDなどの接続情報が含まれる場合は、スクリーンショットを共有する前に該当箇所を隠してください。

初回接続の最低条件は、一覧に遅延の数値が表示されることではありません。アクティブノードの読み込みが成功し、プロキシを明示したリクエストが成功し、ブラウザーが想定した入口を使い、接続先サイトへの通信が想定したアウトバウンドを通ることです。この4点を確認してから自動更新、普段使うルールベースの振り分け、その他の詳細設定に進みましょう。問題が起きたときに戻せるよう、一度に変更する項目は1つにしてください。