V2Rayの初回接続ガイド｜ノード選択・実接続遅延テスト・出口IP確認

サブスクリプショングループとノードの提供元を確認

まず、クライアント、コア、サブスクリプションの役割を区別しましょう。v2rayNはサブスクリプショングループやノード、プロキシ設定を管理し、実際の接続はコアが処理します。サブスクリプションURLから取得できるのはノード設定であり、クライアントのダウンロード先ではありません。更新に成功しても、解析可能な設定を取得できたというだけで、すべてのサーバーに現在のネットワークから接続できるとは限りません。

この記事では、v2rayNで一般的な中国語表示の画面を例に説明します。バージョンによってメニューの場所やショートカットキーが異なる場合があるため、操作時は画面に表示されたメニュー名を確認してください。初回のトラブルシューティングでは、通信経路を切り分けやすくするため、TUNをオフにしてシステムプロキシとの併用を避けます。

1. グループを確認する

   上部の「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、対象グループのサブスクリプションURLを確認します。「追加」から新しいグループを作成する場合は、提供元が分かる名前を付けてください。ログイン後の管理画面URLをサブスクリプションURL欄に入力しないでください。

2. サブスクリプションを更新する

   「サブスクリプショングループ」メニューに戻ります。利用できるプロキシがまだない初回は、「すべてのサブスクリプションを更新（プロキシを使用しない）」を選択します。サブスクリプションサーバーへのアクセスにプロキシが必要な場合は、接続できる状態になってから、プロキシ経由で更新する項目を選んでください。

3. 候補を絞る

   更新したサブスクリプショングループに切り替え、まずは提供元が現在の回線に適していると案内しているノードや、用途が明確なノードを2〜3個選びます。地域名はメモにすぎず、実際の出口を示すものではありません。速度が保証されるわけでもありません。

4. テストを実行する

   候補の行を選択して右クリックし、「サーバーの実接続遅延をテスト」を実行します。テストが完了してから結果を比較してください。サブスクリプションの更新、一括速度テスト、アクティブサーバーの切り替えを同時に行わないでください。

5. ノードを有効にする

   テストに成功した候補を右クリックし、「アクティブサーバーに設定」を選択します。アクティブの表示が切り替わったことを確認し、コアの起動エラーがログに出ていないかも確認しましょう。行をクリックして選択しただけでは、接続に使うサーバーが切り替わらない場合があります。

TCPingと実接続遅延の違い

TCPingで主に確認できるのは、サーバーの指定ポートにTCP接続できるかどうかです。サブスクリプションに含まれるユーザー識別情報、TLS設定、プロキシプロトコルのハンドシェイクが正しいか、プロキシ経由で目的のWebページを開けるかまでは検証しません。ポートに到達できてもプロトコル認証に失敗する場合、TCPingに数値が表示されることがあります。

実接続遅延テストではノード経由で実際のテストリクエストを送るため、TCPingよりアプリでのアクセスに近い結果が得られます。ただし、テスト先、DNS、タイムアウト、ノードの出口、クライアントの実装によって結果は変わります。テスト成功は今回のリクエストが完了したことを示すだけで、すべてのサイトにアクセスできることや、ダウンロード速度を保証するものではありません。

「設定」→「パラメーター設定」を開き、現在のバージョンで指定されている実接続テスト先とタイムアウト設定を確認します。数値を良く見せるためにテスト先を何度も変更しないでください。すべてのノードで失敗する場合は、関連ドメインを名前解決できるか、システム時刻が正しいか、テスト先が一時的に利用できなくなっていないかを確認します。すぐにサブスクリプション全体が無効だと判断しないでください。

• 数値が表示される：今回のテスト結果が得られた状態です。ブラウザーでも確認し、同じネットワーク、同じテスト先で複数回の結果を比較しましょう。
• タイムアウトまたは失敗と表示される：ログを確認し、接続タイムアウト、証明書エラー、認証失敗を切り分けます。負の値だけを見て原因を決めつけないでください。
• 数値の変動が大きい：時間をおいて再テストし、帯域を使う作業を一時停止しましょう。一度の最低値だけで並べて結論を出さないでください。

システムプロキシを有効にしてローカルポートを確認

アクティブサーバーに設定した後は、アプリからのリクエストをクライアントに送る設定も必要です。Windowsでは、v2rayNのタスクトレイアイコンを右クリックし、「システムプロキシ」→「システムプロキシを自動設定」を選びます。初回確認には、システムプロキシに対応したブラウザーを使いましょう。コマンドラインツールやゲーム、独自にプロキシを設定するアプリでは、この設定が自動で使われないことがあります。

「設定」→「パラメーター設定」でローカルリスナーの設定を確認し、Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」にある手動プロキシのアドレスと照合します。以下の数値は説明用の設定例であり、すべてのバージョンの既定値を示すものではありません。現在のクライアント画面に表示される値を基準にしてください。

ノードのリモートポートをローカルプロキシのポートとしてそのまま使うことはできません。ログに address already in use やバインド失敗が表示される場合、該当するリスナーが使用中の可能性があります。クライアントが重複起動していないか確認し、ポートを調べてください。ポートを変更したら、システムプロキシも再設定し、古いポートを参照したままにならないようにします。

出口IPとルーティングの振り分けを確認

アクセス元IPを表示できる確認ページを選び、現在のルーティングルールを確認します。プロキシ経由で外部に接続できるか確かめるには、ルーティング設定を一時的にグローバルプロキシにして比較します。確認後は通常の振り分け設定に戻してください。ここでいうグローバルプロキシはルーティング方法のことで、PC上のすべてのアプリが自動的にプロキシを使うという意味ではありません。

1. 直結時の基準を記録。TUNをオフにしたまま、「システムプロキシ」→「システムプロキシを解除」を選んで確認ページを再読み込みし、現在の公開出口IPを記録します。ブラウザー独自のプロキシ設定がある場合は、先に無効にして条件をそろえてください。
2. プロキシ経由で比較。「システムプロキシを自動設定」に戻し、アクティブサーバーがテストに成功したノードと一致していることを確認してから、同じ確認ページを再読み込みし、出口IPを記録します。
3. リクエストの経路を確認。現在のルーティングルールと利用できるログをもとに、確認先のドメインが直結かプロキシ経由かを判断します。ノードを変更したら再度アクセスしてください。ページに前回の結果がキャッシュされている場合は、新しいセッションを開くか、別の確認ページでも検証します。
4. 通常のルールに戻す。一時的に設定したグローバルプロキシを解除し、実際に使うサイトへアクセスします。確認ページで検証できても、すべての宛先に対して振り分けルールが意図どおりとは限りません。

IPの位置情報データベースは更新が遅れることがあり、同じ出口でもサービスによって異なる都市が表示される場合があります。ノードのメモ、サーバーの接続先アドレス、出口IPはそれぞれ別の情報です。中継サーバーや出口ゲートウェイを経由する場合、これらが異なるのは正常です。メモに記載された地域名ではなく、実際のリクエスト経路を判断の基準にしてください。

ブラウザーごとのシステムプロキシの違いを避けたい場合は、ローカルHTTPプロキシを明示してリクエストを送信できます。以下のコマンドはWindowsで利用できる curl.exe 向けです。10808 がHTTPまたは混合受け入れポートであり、現在のルーティングで宛先へのリクエストがプロキシ経由になることを確認してから実行してください。

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

このコマンドで確認できるのは、ローカルの入口を経由してサンプルサイトにアクセスし、HTTPレスポンスヘッダーを受け取れるかどうかです。出口IPは表示されません。プロキシ入口に http:// を使っても、宛先のHTTPS通信が平文になるわけではありません。HTTPSの宛先には通常、HTTP CONNECTでトンネルを確立します。レスポンスを受け取れた後は出口を別途確認し、タイムアウトした場合はログを使って失敗した段階を特定してください。

初回接続を失敗箇所ごとに切り分ける

現在のノード、テスト時刻、エラー全文を記録し、一度に変更する項目は一つだけにします。ノード変更、DNS変更、ローカルポート変更、TUN有効化を同時に行うと、接続が復旧しても何が効いたのか分からなくなります。スクリーンショットやログを共有する前に、サブスクリプションURL、ユーザー識別情報、その他の認証情報を削除してください。

初回接続の検証結果を記録する

初回接続後は、最も低い遅延値を覚えておくより、再現できる確認記録を残すほうが役立ちます。ネットワーク、サブスクリプションの内容、ノードの出口は変化します。次に問題が起きたとき、同じ手順で比較すれば、原因がサブスクリプションの更新、コアの接続、アプリからの通信、ルーティングの振り分けのどこにあるか判断しやすくなります。

• 設定を確認：クライアントのバージョン、サブスクリプショングループ名、アクティブノードのメモ、テスト時刻を記録します。サブスクリプションの認証情報は公開ドキュメントに保存しないでください。
• 通信経路を確認：実接続遅延テストを1回以上実施し、実際にHTTPSサイトへアクセスします。TCPingの結果だけで接続完了と判断しないでください。
• 出口を確認：確認先、確認時のルーティングルール、出口の結果を記録します。異なるルールで得た結果を後から直接比較しないようにしてください。
• 設定を元に戻す：通常の振り分け設定に戻し、クライアント終了後のシステムプロキシが想定どおりの状態であることを確認します。使われていないポートを指す設定を残さないでください。

サブスクリプションの追加やプロキシ設定を確認し直す場合は、サブスクリプショングループの操作、実接続遅延の解説、システムプロキシの設定をご覧ください。システムプロキシに従わないアプリの通信も扱う必要がある場合は、TUNの設定手順を確認してください。基本的な接続問題が未解決のまま、複雑な通信制御で覆い隠さないようにしましょう。