v2rayNの初回接続ガイド｜ノード選び・実接続遅延テスト・プロキシ動作確認

1. 読み込み後にノードとローカル待ち受けを確認

サブスクリプションの更新に成功しても、クライアントが解析可能な設定を取得できたというだけで、すべてのノードに接続できるとは限りません。v2rayNは管理画面で、実際に接続を確立するのは選択中のコアです。サーバー一覧に名前、アドレス、プロトコルが表示されたら、テストを行い、アクティブサーバーに設定してコアを起動します。

この記事では、Windows版v2rayNを使用します。Desktop版とWPF版ではメニューの位置が異なる場合があります。以下ではメニュー名を手がかりに操作してください。同じ項目が見つからない場合は、画面とバージョンを確認し、スクリーンショットだけを頼りに設定を推測しないでください。初回の確認ではTUNをオフにし、ルーティングや待ち受けの競合を避けるため、ほかのプロキシアプリも停止してください。

1. サブスクリプション一覧を確認

   メイン画面で「サブスクリプショングループ」を開き、読み込んだグループを選択して、サーバー一覧に項目があることを確認します。有効期限と通信量も確認してください。ノード名に含まれる地域名はラベルにすぎず、実際の出口の所在地や接続可否を示すものではありません。

2. 待ち受けポートを確認

   「設定」→「パラメーター設定」を開き、ローカル待ち受けポートの設定を探して、ポート番号と対応するプロキシの種類を控えます。以下では、このPCで設定済みの混合ポート 10808 を例にします。画面に別の番号が表示されている場合は、コマンド内の番号も同じものに置き換えてください。

3. ノードを少数選んでテスト

   まず同じサブスクリプションから3～5個のノードを選び、比較的近い地域のものや、サービス提供元が現在のネットワーク向けとして案内している回線を優先します。最初から数百個を同時にテストすると、並列リクエストが結果に影響するおそれがあります。

4. ログウィンドウを開く

   メイン画面のログ欄を開き、コアの起動メッセージを確認します。address already in use と表示された場合は、まずローカルポートの競合を解消してください。この状態で接続先ノードを切り替えても、通常は解決しません。

2. 実接続遅延の測り方と結果の見方

テストするノードを選び、サーバー一覧の右クリックメニューから「サーバーの実接続遅延をテスト」を実行し、結果が表示されるまで待ちます。画面によっては、メニュー名の後に複数選択やショートカットの案内が付くことがあります。テスト中はコアを何度も切り替えたり、テスト先を変更したり、サブスクリプションを更新したりしないでください。結果の比較が難しくなります。

実接続遅延テストでは、ノード経由で指定されたテスト先にアクセスします。サーバーのTCPポートに接続できるかだけを調べるより、実際のプロキシ経路に近い測定です。ただし、結果が示すのは「現在のネットワーク・ノード・テスト先」での一回の測定にすぎません。すべてのサイトが使えることや、ダウンロード速度を保証するものではありません。テスト先に問題があると、正常な回線でも複数のノードが一斉に失敗することがあります。

最低遅延の一回だけでなく、複数回の結果で選ぶ

候補のノードを3回続けてテストし、各回の間に数秒待ちます。たとえば、あるノードの結果が120、135、128ミリ秒で、別のノードが80ミリ秒、タイムアウト、900ミリ秒なら、初回接続には前者が向いています。これは結果の読み方を示す例であり、本サイトでの実測値や回線性能を保証するものではありません。帯域幅や混雑状況、接続先サービスの速度制限によっては、遅延の小さいノードでもダウンロードが遅くなることがあります。

• 複数回のテストに成功したノードを最低2つ残し、後で比較できるようにします。
• すべて失敗した場合は、システム時刻、サブスクリプションの有効期限、テスト先を先に確認します。プロトコル設定を一括変更するのは避けてください。
• 1つのノードだけが失敗する場合は、そのノードのアドレスとポート、サービス提供元の稼働状況を確認します。個別の問題をクライアント全体の不具合と混同しないようにしましょう。

3. アクティブサーバーを設定してシステムプロキシを有効化

サーバー一覧からテストに成功したノードを選び、右クリックして「アクティブサーバーに設定」を選択します。コアが再読み込みされるまで待ってください。一覧で選択中の項目とアクティブサーバーは別のため、現在のアクティブ項目を確認します。次に、タスクトレイの「システムプロキシ」から「システムプロキシを自動設定」を選び、ログに起動エラーが出ていないか確認します。

初回の確認では、一時的に「ルーティング」→「グローバル」を選ぶと、通常のリクエストがプロキシ経由になりやすくなり、ルールによる振り分けの影響を抑えられます。ここでいう「グローバル」とは、コアが受け付けた接続のルーティング方法を指します。すべてのアプリが自動的に通信を渡すという意味ではなく、ループバックやLANなどの特殊なルールが必ず無効になるわけでもありません。確認後は、日常利用に適した振り分けモードに戻してください。

4. ブラウザーで確認：ページ、出口、ログを照合

システムプロキシを有効にしたら、Windowsのシステムプロキシ設定に従うブラウザーで、これまで開いたことのないページを新しいタブで開きます。プロキシ拡張機能や独自のプロキシ設定、独自の除外ルールを使っている場合は、いったん無効にしてください。ページが開けただけでは、もともと直接接続できるサイトの可能性もあるため、十分な証拠にはなりません。

1. 新しいリクエストを確認：普段使うHTTPSサイトを開いて再読み込みし、キャッシュされたページだけで判断しないようにします。ログと照合できるよう、テストした時刻も記録してください。
2. 出口を確認：信頼できるIPアドレス確認サイトを使い、直接接続時とプロキシ接続時のグローバルIPアドレスを比較します。サブスクリプションやアカウント情報の入力を求めないサービスを選んでください。
3. 出力先を確認：同じ時刻の対象ドメインと出力先をコアのログで確認します。直接接続と表示されている場合、リクエストはコアに届いたものの、ルーティングルールによって直接接続に振り分けられた可能性があります。
4. 振り分けを再確認：グローバルモードから通常のルールに戻した後、プロキシ経由にしたい接続先と、直接接続する想定の接続先の両方にアクセスし、それぞれの動作が設定どおりか確認します。

出口のIPアドレスが変わったことは有用な証拠ですが、位置情報データベースの更新が遅れていたり、同じ回線で複数の出口が使われたりすることがあります。国名や都市名だけで判断せず、「出口の地域名がノード名と異なる」ことを接続失敗と決めつけないでください。IPアドレス、実際のリクエスト、ログを合わせて判断します。ログレベルが低く個々の記録が残らない場合も、それだけでコアを経由していないとは言えません。

5. コマンドラインで確認：ブラウザーを介さずローカルプロキシを指定

コマンドラインのプログラムは、Windowsのシステムプロキシを参照するとは限りません。ローカルコアからリモートノードまでの経路を確認するため、以下ではSOCKSプロキシを明示的に指定します。システムプロキシの設定には依存しません。前提として、このPCの 127.0.0.1:10808 がSOCKSまたは混合待ち受けを提供している必要があります。ポートが異なる場合は、先に置き換えてください。

PowerShellで以下のコマンドを実行します。curl.exe を使うことで、一部の環境で同名のコマンドエイリアスが実行されるのを防げます。socks5h は接続先のホスト名をプロキシ側で解決する指定です。ローカルでの名前解決が経路に与える影響を切り分けるのに適しています。NO_PROXY 環境変数を設定している場合は、テスト対象のドメインがプロキシを迂回しないことを確認してください。

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

接続先サイトからHTTPレスポンスが返れば、この明示的なプロキシリクエストで必要な通信が完了したことを示します。403などが返った場合は、サイト側のアクセス制限と通信経路の不具合を切り分ける必要があります。この結果だけでは、ブラウザーもプロキシを経由しているとは証明できません。直接接続との比較が必要な場合は、以下のコマンドを実行できます。どちらも成功しても、「両方開けた」というだけでは出口が同じかどうかは判断できません。

curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com

• 127.0.0.1に接続できない：サブスクリプションをすぐに変更せず、まずコアが起動しているか、ポート番号が正しいか確認します。
• ローカル接続後にタイムアウトする：リモートノード、テスト先、コアのログを確認し、テストに成功した別のノードでも比較します。
• 明示的なプロキシ接続は成功するが、ブラウザーは失敗する：システムプロキシ、ブラウザー独自の設定、拡張機能を確認します。アプリ側の接続設定に原因がある可能性が高いです。
• ブラウザーは成功するが、コマンドは失敗する：コマンドに指定したポートとプロキシプロトコルを確認します。ブラウザーとコマンドが同じ接続口を使うとは限りません。

必要に応じてポートの待ち受けを確認

PowerShellでローカルの待ち受けを調べます。出力の OwningProcess はプロセスIDです。待ち受けが見つかっても、ポートを使用しているプログラムが分かるだけです。タスクマネージャーの「詳細」タブで、その番号が想定したコアのものか確認してください。何も出力されない場合は、ログに戻って起動エラーを解消します。

Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

6. 初回接続でよくある質問と最終確認

初回接続の完了は、緑色の数値が一つ表示されることではなく、再現可能な結果で判断します。アクティブサーバーが明確で、コアが正常に待ち受け、明示的なプロキシリクエストが成功し、ブラウザーの出口とルーティングが想定どおりであることを確認してください。最後に、使えるノード、ローカルポート、通常利用時のルーティングモードを記録します。後で問題が起きた際、同じ条件でテストすれば、複数の設定を同時に変更せず原因を特定できます。