v2rayN初回接続ガイド：ノード選択・実接続遅延テスト・プロキシ有効性の確認

接続前に購読とコアを確認する

初回起動後、リスト内の任意のノードをすぐにダブルクリックしないでください。v2rayNのサーバーリストは設定の集合にすぎず、ノード名やプロトコル、アドレスが表示されていても、接続できるとは限りません。開始前にシステム時刻が正確であること、購読が正常に更新されていること、現在の設定で使用するコアの種類を確認しましょう。VMess、VLESS、Trojanなどの設定は通常Xrayコアで処理されます。購読に複数のプロトコルが含まれる場合、コアとプロトコルの対応能力が合わないと、起動直後に設定エラーがログへ記録されることがあります。

v2rayN 7.xの画面レイアウトはマイナーアップデートで変わることがありますが、主な操作は購読グループ、サーバー、設定、画面下部のシステムプロキシ領域に集約されています。初めて使うときは購読グループを1つだけ残し、まず1つのノードで接続を確認してから、ルーティングルールや他のグループを追加するのがおすすめです。これによりログのエラーを特定の設定と結び付けやすくなり、同名ノードによる判断の混乱も防げます。

1. システム時刻を合わせる

   OSの日付と時刻の設定で自動同期を有効にします。端末の時刻が標準時刻から数分ずれていると、時刻確認を必要とする接続がハンドシェイク段階で失敗することがあります。

2. 購読を追加する

   「購読グループ」→「購読グループの設定」→「追加」を開き、グループ名を入力して完全な購読URLを貼り付け、保存してメイン画面に戻ります。

3. ノードを更新する

   「購読グループ」→「すべての購読を更新（プロキシを経由しない）」を選択します。リストにプロトコル、別名、アドレスが表示されたら、画面下部のログに購読の解析エラーが記録されていないか確認します。

4. コアを確認する

   「設定」→「パラメーター設定」→「Core タイプ」を開き、初回接続では購読のプロトコルに応じてXrayを選択します。設定を保存したら、コア設定を一度再読み込みします。

5. デフォルトのルーティングを維持する

   初回検証では、クライアントに設定されている基本ルーティングをそのまま使用し、複数のカスタムルールを同時にインポートしないでください。基本接続が成功してから、直接接続・プロキシ・ブロックの振り分けを設定します。

購読リストからテスト可能なノードを選ぶ

購読リストは地域、回線、倍率などで名前が付けられていることが多いものの、名前だけで現在の利用可否を判断することはできません。ノードを選ぶ際は、まずプロトコル欄とアドレスが完全かを確認し、地理的に近く、名前にメンテナンス中や期限切れを示す表示がないものを選びます。距離は往復遅延に影響しやすい一方、ピーク時の負荷、入口回線、サーバー側の混雑でも実際の結果は変わるため、地域名だけで結論を出さないでください。

一度に数十個のノードをインポートした場合は、まず別名やグループで5～10個の候補に絞り、その後に実接続遅延テストを行います。すべてのノードを何度もテストする必要はありません。短時間に大量の接続を確立すると、結果がローカルネットワークの揺らぎの影響を受けやすくなるためです。初回の目的は理論上最速の設定を選ぶことではなく、ハンドシェイクを安定して完了できるノードを1～3個見つけることです。

同じノードで1回目が82ミリ秒、2回目が96ミリ秒なら、よくある変動の範囲です。1回目が90ミリ秒で、2回目が900ミリ秒を超える、またはすぐにタイムアウトする場合は、いったん候補の後ろに回します。テスト値は連続性と合わせて判断し、1回だけ最小値が出たからといってすぐ固定して使わないでください。

Pingではなく実接続遅延で利用可否を判断する

Pingは主にICMPパケットの往復時間を測定します。一方、プロキシ接続では、ドメイン解決、TCPなどのトランスポート層の確立、TLSハンドシェイク、プロトコル認証、サーバー側からの外向き接続まで必要です。サーバーによってはICMPを制限している場合もあり、Pingには応答するのにプロキシポートは利用できないこともあります。そのため、初回のノード選びではPingの数値だけでなく、v2rayNの実接続遅延機能を使ってください。

サーバーリストで候補ノードを選択し、「サーバー」メニューの「サーバー実接続遅延をテスト」を使用します。リストの右クリックメニューから同名の機能を選ぶこともできます。複数テストではShiftまたはCtrlでノード数を絞って選択してください。テスト後、結果は遅延列に記録されます。タイムアウト、空欄、負の値のような結果は、ログと併せて確認します。

上記の数値は選別方法を理解するための例であり、すべてのネットワークが満たすべき基準ではありません。家庭の固定回線、モバイルホットスポット、企業ネットワークでは基礎遅延が異なり、夜間のピーク時には変動も大きくなります。より確実な判断基準は、候補ノードが連続して結果を返し、2回の差が過度に広がらず、実際にページを開いたりリクエストを送ったりした際にタイムアウトが続かないことです。

• 遅延の数値が表示される：テストリクエストが少なくとも1回は実際の接続を完了したことを示しますが、システムプロキシとアプリの通信経路は引き続き確認する必要があります。
• すべてタイムアウトする：まずローカルネットワーク、システム時刻、購読の有効性、コアのログを確認し、すぐにノードの地域が原因だと決めつけないでください。
• 一部のノードだけ成功する：まず成功したノードで初回接続を完了し、その後、他のノードのプロトコルパラメーターやサービス状態を個別に確認します。
• 数値が大きく変動する：30秒間隔を空けて再テストし、同時にテストするノード数を減らして一時的な混雑を切り分けます。

ノードを起動し、3段階でプロキシの有効性を確認する

ノードを選んだら、その行をダブルクリックするか、右クリックメニューからアクティブサーバーに設定します。続いて画面下部のステータス領域を確認し、コアが動作していることを確かめます。v2rayNでよく使われるローカル待受ポートはSOCKS 10808、HTTP 10809ですが、バージョンや既存設定によっては混合ポートが使われることもあります。「設定」→「パラメーター設定」に表示されるローカルポートを基準にしてください。

コアが動作していることは、ローカルプロキシの入口が確立されたことを示すだけです。ブラウザーがその入口を使うかどうかは、システムプロキシの状態に左右されます。OSのプロキシ設定に従うデスクトップアプリでは、v2rayN画面下部のシステムプロキシメニューから「システムプロキシを自動構成」を選択します。「システムプロキシをクリア」のままだと、ノードがアクティブでも通常のブラウザーリクエストが直接接続を続けることがあります。

1. コアの起動を確認する

   画面下部のステータスバーと実行ログを確認し、アクティブサーバー名が正しいこと、ログにポート競合・設定解析・認証失敗の情報がないことを確かめます。

2. システムプロキシを有効にする

   画面下部のシステムプロキシメニューで「システムプロキシを自動構成」を選択し、テストに使うブラウザーのウィンドウを完全に閉じてから再起動します。古い接続の再利用を避けるためです。

3. 実際のリクエストを送る

   これまで開いたことのない通常のWebページを開き、2回再読み込みします。ページが安定して読み込まれたら、アクセスログに該当ドメインとプロキシ経由の外向き接続記録があるか確認します。

4. 直接接続時と比較する

   一時的に「システムプロキシをクリア」を選択して同じページを再度リクエストし、その後、自動構成に戻します。2つの状態でアクセス経路が想定どおりになっていることを確認し、テスト後は必要なモードを維持します。

3段階目は特に重要です。「Webページが開ける」だけでは、リクエストがプロキシを経由した証拠になりません。対象サイトがもともと直接接続できる場合や、ブラウザーが切り替え前に確立した接続を再利用している場合もあります。より確実な方法は、v2rayNのアクセスログも同時に確認することです。ページを更新した際に新しいドメイン記録が現れ、その記録がプロキシ経由の外向き接続に割り当てられていれば、アプリからローカルポート、コア、リモートノードまでの経路が接続できたと判断できます。

curl -I --proxy http://127.0.0.1:10809 https://example.com

コマンドラインツールは通常、デスクトップのシステムプロキシを自動的には引き継ぎません。上の例ではローカルHTTPプロキシポートを明示的に指定しており、10809が利用できるかを確認できます。パラメーター設定に別のポートが表示されている場合は、同じ番号に置き換えてください。HTTPレスポンスヘッダーが返れば、そのコマンドがプロキシ経由のリクエストを完了したことを示しますが、実際の外向き接続についてはコアのログでも確認してください。

ブラウザーで成功してからターミナルとルーティングを設定する

初回接続では、まずシステム設定に従うブラウザーで一連の確認を完了し、その後にターミナル、開発ツール、その他のアプリへ広げます。プログラムによってプロキシ設定の読み取り方は異なります。システムプロキシに従うもの、自身の設定だけを読むもの、HTTPまたはSOCKSアドレスを明示的に渡す必要があるものがあります。ブラウザーは成功するのにコマンドラインだけ失敗する場合、必ずしもノードの障害とは限らず、まずアプリ自身のプロキシ入口を確認すべきです。

ルーティングモードは、リクエストがコアに入った後、どの外向き接続を使うかを決めます。基本ルールでは、一部の宛先を直接接続にし、別の宛先をプロキシに渡し、広告ドメインや特定アドレスをブロックすることもできます。初回検証で複雑なルールを急いで重ねないでください。まずデフォルトルールを動かし、ログで対象ドメインがどの外向き接続に一致したかを確認します。ルールの順序が競合する場合、前方の一致項目が先に結果を決めることがあります。

Windows、macOS、Linuxでは、デスクトップアプリがシステムプロキシに従うかをアプリごとに確認する必要があります。Androidでは、v2rayNGまたはv2flyNGで接続した後、アプリ別プロキシからテスト対象のプログラムが除外されていないかにも注意してください。複数の端末で「一方は接続できるが、もう一方はできない」場合は、まず購読の更新日時、選択中のノード、システム時刻を比較し、次に両端のコア機能を比較します。別のプラットフォーム向けのローカルルーティング設定をそのままコピーしないでください。

初回接続でよくある失敗

すべての候補ノードで実接続テストを完了できない場合は、共通するローカル条件から確認します。複数のノードが同時に使えない場合、単一ノードの障害よりも、購読が更新されていない、システム時刻がずれている、コアが起動していない、DNS解決に問題がある、ローカルポートが競合している可能性のほうが高いです。この状態でノードを1つずつ再試行しても、同じエラーを繰り返すだけです。

実行ログは、エラーが発生した段階を切り分ける主な手掛かりです。接続拒否は通常、対象アドレスまたはポートが接続を受け付けていないことを示します。タイムアウトは、規定時間内にネットワーク通信が完了しなかったことを示します。認証エラーやユーザー情報エラーの場合は、購読パラメーターに戻ってUUID、パスワード、転送方式、TLS関連設定を確認します。1つの状態メッセージだけを見て全パラメーターを変更せず、まずローカル待受、リモートハンドシェイク、ルーティングによる外向き接続のどの段階で失敗したかを特定してください。

1つのノードだけが失敗し、他のノードは正常な場合、ローカルのプロキシ経路はおおむね利用可能で、確認範囲をそのノードに絞れます。購読を更新し直したうえで、アドレス、ポート、転送方式、TLS、サーバー名などの項目を比較してください。不足しているパラメーターを手作業で推測することはおすすめしません。購読から提供された設定は項目間の整合性を保つ必要があり、1項目だけを変更すると新たなハンドシェイクエラーが発生することがあります。

基本検証後の設定手順

基本接続が成功した後は、変更する変数を毎回1つに絞ります。安定したノードを1つ固定し、DNS解決を確認してからルーティングを設定し、最後にアプリ単位のプロキシを扱う順序がおすすめです。変更するたびに実際のリクエストとログ照合を繰り返すことで、どの設定が結果を変えたのかを明確にできます。

• 第1段階：実接続テストに合格したアクティブノードを1つ残し、正常時の遅延範囲を記録します。
• 第2段階：DNS解決が安定しているか確認し、複数のDNS方式とルーティングルールを同時に変更しないようにします。
• 第3段階：必要に応じて直接接続・プロキシ・ブロックのルールを追加し、ログで一致順序を確認します。
• 第4段階：ターミナルや特定のアプリに、HTTP、SOCKS、またはアプリ別プロキシの入口を明示的に設定します。
• 第5段階：Windows、macOS、Android、Linuxそれぞれで独立した接続確認を行い、別のプラットフォームの状態で代用しないようにします。

初回接続で重要なのは、単に「接続済み」という表示を見ることではありません。購読に有効な設定が存在し、実接続テストでリモートハンドシェイクが完了し、ローカルコアが正常に待ち受け、アプリの通信がプロキシポートへ入り、ルーティングルールがリクエストを正しい外向き接続へ送るという、再現可能な確認の流れを作ることです。速度が変化したりページにアクセスできなくなったりした場合も、この流れに沿って段階ごとに原因を特定でき、クライアントを何度も再インストールしたり、むやみにノードを切り替えたりする必要がなくなります。