v2rayN 初回接続の確認：ノード選択・実接続テスト・プロキシ有効性のチェック

まずノードを選択し、再現可能なテスト条件を整える

ノードが一覧に表示されるのは、サブスクリプションの解析または手動追加が完了したことを示すだけで、v2rayN が現在そのノードを使っているとは限りません。初回確認では、メイン一覧で対象ノードをクリックしてから Enter キーを押すか、右クリックメニューからアクティブサーバーに設定します。アクティブな行には通常、色やチェックマークなどの選択表示が付きます。表示は v2rayN 7.x のマイナーバージョンやテーマによって異なりますが、基準はメイン画面に現在のアクティブサーバーが明確に表示されていることです。

初回テストでは、複雑なルーティング、複数のサブスクリプショングループ、カスタム DNS を同時に有効にしないでください。対象ノードを1つだけ残し、既定または動作を説明しやすいルーティングモードを使い、ローカルのプロキシポートを使用中の同種アプリを終了します。Windows 11 24H2 では、システム時刻とタイムゾーンも確認してください。VMess、TLS 1.3、および時刻検証が必要な一部の接続は、大きな時刻ずれの影響を受けることがあります。

1. アクティブノードを確認する

   サーバー一覧で設定を1つ選び、Enter キーを押します。その後、メイン画面またはタスクトレイの状態を確認し、マウスでハイライトされているだけでなく、現在のアクティブサーバーになっていることを確かめます。

2. コアの種類を確認する

   「設定」→「パラメーター設定」→「Core タイプ」を開き、現在のプロトコルが互換性のある Xray または V2Ray コアで処理されていることを確認します。変更後はコアを再起動してから、次のテストに進みます。

3. ローカルポートを記録する

   パラメーター設定で、ローカルの待受アドレスとポートを記録します。一般的な例では SOCKS が 127.0.0.1:10808、HTTP が 127.0.0.1:10809 ですが、実際の確認では画面に表示されている現在の値を基準にしてください。

4. サービスを起動する

   v2rayN のコアを起動または再起動し、画面下部の情報欄を確認します。ポート使用中、設定の解析失敗、コアの終了がすぐに表示された場合は、ブラウザーのテストを続けず、先にエラーを解決してください。

5. テスト条件を保存する

   テスト日時、ノード名、ネットワークの種類、ルーティングモードを記録します。後でノードを変更するときに変える項目をノードだけにすれば、違いがサーバー側によるものか、ローカル設定によるものか判断できます。

実接続テスト・遅延テスト・ダウンロード速度測定の違い

v2rayN の右クリックテストメニューには、遅延、実接続遅延、ダウンロード速度などの項目が同時に表示される場合があります。通常の遅延値は、特定の探測に対する往復時間を示すだけです。サーバーによっては探測に応答せずタイムアウトしますが、プロキシ接続は利用できる場合があります。逆に、探測遅延が非常に短くても、VMess や VLESS の認証情報、通信経路、TLS パラメーターの検証に成功したことは証明できません。

「サーバーの実接続遅延をテスト」は、初回の切り分けに適しています。選択した設定を使って実際のアウトバウンド接続を確立し、接続完了までの時間を返します。結果が 186 ms や 420 ms であれば、少なくともそのテストでは、コアが対象リクエストをそのノード経由で完了できたことを示します。タイムアウトが続く場合は、ブラウザーの設定を先に変更するのではなく、サーバーアドレス、ポート、UUID、通信方式、セキュリティ層、現在のネットワークを確認してください。

ダウンロード速度測定では実際の通信が発生し、結果は測定対象、サーバー負荷、無線ネットワークの品質、ローカル回線速度にも左右されます。初回確認で最高値を追う必要はありません。まず実接続テストを3回連続で成功させ、その後に短時間の速度測定を1回行えば十分です。1回目が 210 ms、2回目が 235 ms、3回目が 890 ms なら、最低値だけでノードを選ばず、さらに2ラウンド測定して中央値を取ってください。

システムプロキシを有効にし、ブラウザーで実際のアクセスを確認する

実接続テストに成功したら、次に確認するのが Windows のシステムプロキシです。v2rayN のタスクトレイメニューを開き、「システムプロキシを自動設定」を選択します。バージョンによっては、メイン画面にも同じ項目への入口があります。その後、Windows の「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシの欄にローカルアドレスとポートが表示されていることを確認します。Windows にリモートサーバーのアドレスを手動入力しないでください。ここでは、v2rayN がローカルで待ち受けている入口を指定します。

パラメーター設定で HTTP ポートが 10809 と表示されている場合、Windows のプロキシには通常、ループバックアドレス 127.0.0.1 とポート 10809 が設定されます。使用中のバージョンに混合ポートがある場合は、画面に表示された実際の待受ポートを確認してください。ポート番号は固定のルールではありません。基本ポートを変更した場合は、システムプロキシと手動設定のアプリも同じ値に更新する必要があります。

ブラウザーを確認するときは、まずすべてのウィンドウを完全に終了してから再起動し、古い接続やキャッシュの影響を避けます。普段から安定してアクセスできる HTTPS ページを2つ開き、それぞれを3回更新しながら、v2rayN の上り・下り通信量と接続ログを確認します。ページが正常に開くこと、通信量のカウントが変化すること、対象ドメインへの 443 ポート接続がログに表示されること。この3つが同時に成立して初めて、単一ページの結果より信頼できる証拠になります。

• ページは開くがログに新しい接続がない：ページがキャッシュから表示されたか、ブラウザーが Windows のシステムプロキシに従っていない可能性があります。新しいプライベートウィンドウを開き、以前に開いていないページへアクセスして再確認してください。
• ログに接続はあるがページが待機し続ける：ログのアウトバウンドエラー、DNS の解析結果、ルーティングの適用状況を確認し、リクエストが誤って直通または遮断ルールに送られていないことを確かめます。
• 一方のブラウザーは成功し、もう一方は失敗する：すぐにノードを変更せず、失敗したブラウザー固有のプロキシ設定、拡張機能、企業ポリシーを先に確認してください。
• v2rayN を終了しても同じページにアクセスできる：そのページ自体にプロキシが不要な可能性があり、システムプロキシが有効になった証拠にはなりません。経路の違いを明確に確認できるテスト対象を選んでください。

ログでポート・DNS・プロトコル・ルーティングの問題を特定する

ログの目的は、単に「接続成功」という曖昧な一文を探すことではありません。リクエストがローカル待受、ルーティング判定、リモートへのアウトバウンド接続を順に通過したかを確認することが目的です。初回の切り分けではログ画面を表示したまま、古い記録を消してからブラウザーを1回更新します。サブスクリプション更新、速度測定、複数アプリのリクエストが混ざった長いログより、数十行程度の記録のほうが判断しやすくなります。

以下は構造を示す例であり、すべての Xray または V2Ray コアがまったく同じ英語を出力するわけではありません。重要なのは、ローカルリクエストが受け付けられたか、対象がアクセスしたばかりのドメインと 443 ポートか、最終的にプロキシ経由と直通のどちらでアウトバウンド接続したか、そしてエラーが解析・ハンドシェイク・リモート接続のどの段階で発生したかです。

127.0.0.1:53124 accepted tcp:example.com:443 [proxy]
dns: resolved example.com
outbound: proxy connection established
traffic: uplink 6.8 KB, downlink 42.3 KB

accepted に相当する記録がまったく見つからない場合、リクエストはまだ v2rayN に到達していません。システムプロキシのポート、ブラウザーを再起動したか、ローカルファイアウォールの規則を確認してください。ログに address already in use と表示される場合、通常は 10808 または 10809 が別のプロセスに使用されています。競合するアプリを終了するか、「設定」→「パラメーター設定」で未使用のポートに変更し、システムプロキシを再設定してください。

DNS の問題では、IP アドレス宛てなら接続できるのにドメイン名では失敗する、またはログに解析タイムアウトが繰り返し表示されることがあります。まず v2rayN の現在の既定 DNS 設定に戻し、追加したばかりのカスタムサーバーや複雑な分流ルールを一時的に取り消して、同じドメインを再テストします。既定条件で復旧したことを確認してから、カスタム DNS、ドメインルール、GeoSite の分類を1つずつ追加してください。どの層の変更で結果が変わったのか分からなくなるのを防げます。

ルーティングの問題では、リクエストが最終的にどのアウトバウンドへ送られたかを確認します。ノードの実接続テストに成功していても、ブラウザーの対象がルールによって direct または block に送られると、ページの結果は想定と異なります。まず単純で動作を説明しやすいルーティングモードに切り替えて再テストします。プロキシ経由のアウトバウンドが正常だと確認できたら、カスタムルールを戻し、ドメイン、IP、ポート、インバウンドタグの条件を1つずつ確認してください。

初回接続でよくある判断ミス

初回利用で起こりやすい問題は、特定のパラメーターを完全に間違えることより、異なる段階の成功サインを混同することです。サブスクリプションの更新成功は、購読先アドレスを読み取れたことを示すだけです。ノードの読み込み成功は、内容を解析できたことを示すだけです。実接続テストの成功は、コアが今回のテストリクエストを完了できたことを示すだけです。システムプロキシの有効化も、Windows の設定に従うアプリへローカルプロキシの入口を提供するだけです。

もう1つよくあるのが、変更する変数を増やしすぎることです。ノードの変更、Core タイプの変更、DNS の書き換え、ルーティングの切り替え、ローカルポートの変更を同時に行い、最後にページが開くかだけを確認します。結果が改善しても、何が効果をもたらしたのか分かりません。悪化した場合は元に戻すのも困難です。元の設定をコピーして保存し、毎回1項目だけ変更し、同じテストを3回完了してから次へ進む方法が安全です。

4層の結果で初回接続を確認する

初回接続の確認は、4つの層に整理できます。設定層でアクティブノードとコアの互換性を確認し、接続層で実接続テストが安定して成功することを確認します。経路引き継ぎ層では Windows のシステムプロキシがローカル待受ポートを指していることを確認し、アプリ層ではブラウザーのリクエストがログに入り、プロキシ経由のアウトバウンド接続を通ることを確認します。4層すべてに具体的な証拠がそろって、初めて確認完了です。

1. 設定層：アクティブサーバー名がテスト予定のノードと一致し、Core タイプが現在の VMess または VLESS 設定を処理でき、起動後に設定解析エラーがない。
2. 接続層：実接続テストを5回連続で実行し、少なくとも成功回数と中央値遅延を記録する。2回を超えて失敗する場合は、いったん停止してノードとネットワークを確認する。
3. 経路引き継ぎ層：Windows のシステムプロキシが 127.0.0.1 と v2rayN の現在の HTTP または混合ポートを指し、ポートが他のアプリに使用されていない。
4. アプリ層：ブラウザーを再起動して2つの HTTPS ページにアクセスし、対象ドメインへの 443 ポートリクエストがログに表示され、通信量のカウントが連動して変化し、ページが安定して読み込まれる。

ここまでの確認が終わってから、サブスクリプションの自動更新、複雑なルーティング、アプリごとのプロキシ、DNS の調整を検討してください。すべての高度なオプションを一度に追加するより、再現性のある基本設定を先に作るほうが保守しやすくなります。後で特定のアプリだけが失敗しても、確認済みのノードプロトコルを最初から疑う必要はなく、アプリ層からローカル入口へ直接切り分けられます。