サブスクリプションを読み込んだものの、ノードが使えるかまだ分からないデスクトップユーザー向けです。「ノード設定の確認 → 実接続テスト → 使用サーバーに設定 → システムプロキシを有効化 → ログと出口IPを照合」の順に進めると、ノードの障害、プロキシ入口の問題、ルーティングの振り分けを切り分けられます。この記事ではWindows版v2rayNを例に説明します。最初からTUNを有効にする必要はありません。
接続前に確認すること：サブスクリプションとローカル接続口
サブスクリプションの更新に成功しても、クライアントがサーバー情報を取得できたというだけで、すべてのノードに接続できるとは限りません。まず一覧にアドレス、ポート、プロトコルが表示されているか確認し、サブスクリプションが有効かもチェックします。VMessやVLESSなどのプロトコルでは、認証情報やトランスポート設定も必要です。遅延を下げようとして、提供元が指定したTLS、SNI、トランスポートパスをむやみに変更しないでください。
この記事では、Windows版v2rayN 7.x系で一般的なメニュー名を使用します。マイナーバージョンによってボタンの位置や表記が多少異なる場合があります。まず「設定」→「パラメーター設定」を開き、ローカルの待ち受けポートを確認します。続いてメイン画面下部の「システムプロキシ」とルーティングの選択状態を確認してください。以降のコマンド例では、HTTPプロキシに対応するローカルの混合ポートが 127.0.0.1:10808 で待ち受けているものとします。実際の値はパラメーター設定と起動ログで確認してください。
ノード選択：実接続の遅延はTCP遅延より実用に近い指標
TCP遅延テストで確認できるのは、接続先のアドレスとポートにTCP接続できるかどうかです。認証情報が正しいことや、TLS、トランスポート層、リモート出口が正常であることまでは確認できません。実接続テストでは、ノード経由でテスト先にリクエストを送るため、初回の候補選びに適しています。ただし、結果が示すのは、その時点でテスト先にアクセスできたかどうかだけです。
実接続の遅延
おすすめメイン画面で候補ノードを選択し、右クリックして「サーバーの実接続遅延をテスト」を選びます。プロキシ経由で設定済みのテスト先にアクセスするため、ポートの疎通確認だけでは見つからない接続問題を検出できる場合があります。
用途：初回の候補選びや、ノード変更後の接続確認
TCP遅延
右クリックメニューの「サーバー遅延をテスト Tcping」では、TCPポートへの到達性をすばやく確認できます。数値が表示されても、プロキシが使えるとは限りません。別のトランスポート方式に依存するノードは、この結果だけで判断しないでください。
用途：ポートに到達できない場合と、その後のハンドシェイク失敗を見分ける補助
ダウンロード速度テスト
速度テストでは実際に通信が発生するため、接続を確認した後のスループット比較に適しています。速度が出ても、Webページの初回表示が必ず速いとは限りません。サブスクリプション全体に対して頻繁に一括実行するのも避けましょう。
用途：使えるノードを少数に絞った後、大容量ファイル転送向けの候補を選ぶ
候補ノードを3～5個選び、それぞれ3回ずつテストして連続して成功するか確認しましょう。以下は結果の読み方を示す例であり、本サイトでの実測値ではありません。ノードAは180、195、188ミリ秒、ノードBは95ミリ秒、タイムアウト、110ミリ秒でした。初回接続では、Bの最小値だけを見るのではなく、Aのように安定した候補を優先します。
- すべてタイムアウトする：まずPCから通常どおりインターネットに接続できることを確認します。次にテスト先が利用可能か、サブスクリプションの期限が切れていないか、ログに共通のハンドシェイクエラーがないかを確認してください。
- 一部だけタイムアウトする：連続して成功するノードに切り替えて再確認します。全体設定を急いで変更する必要はありません。
- 遅延は正常なのに対象サイトを開けない：対象サイトへのアクセスを別途確認してください。テスト先にアクセスできても、すべてのサイトにアクセスできるとは限りません。
初回接続：使用サーバーに設定してからシステムプロキシを有効化
一覧で強調表示されている行が、必ずしも現在使用中のサーバーとは限りません。テストは選択した項目に対して実行できます。そのため、「テストに成功したこと」と「現在の通信がそのノードを経由していること」は別です。テスト後、使用サーバーとして明示的に設定し、コアの再読み込みが成功するまで待ちましょう。
-
候補を選択
サーバー一覧で、実接続テストに連続して成功したノードをクリックします。右クリック後、操作対象を確認してください。サブスクリプショングループを切り替えた後、以前と同じ行位置だからといって同じノードだと判断しないようにしましょう。
-
使用サーバーに設定
右クリックして「使用サーバーに設定」を選び、一覧の使用中マークとログの再読み込み結果を確認します。選択行の背景色だけを見て切り替え成功と判断しないでください。
-
プロキシを設定
メイン画面下部の「システムプロキシ」メニューから「システムプロキシを自動設定」を選びます。タスクトレイアイコンの「システムプロキシ」サブメニューからも操作できます。今回は「システムプロキシをクリア」を選ばないでください。
-
ルーティングを確認
現在のルーティングモードを記録します。ルールによる振り分けの影響を切り分ける場合は、一時的にクライアントの「グローバル」プロキシルーティング設定を選びます。確認後は、普段使っている振り分け設定に戻してください。
-
新しいリクエストを実行
ブラウザーで新しいウィンドウを開いて対象ページにアクセスし、画面下部のログも確認します。ブラウザーが古い接続を再利用している場合は、ブラウザーを完全に終了してから起動し直し、同じテストを行ってください。
動作確認：ブラウザー・出口IP・ログを照合
Webページが開いただけでは、プロキシが有効になった証拠として不十分です。そのサイトには元から直接接続できる場合や、振り分けルールによって直接接続されている場合があります。同じ接続先に対して、プロキシなし、プロキシを明示指定、システムプロキシに従うブラウザーのそれぞれで結果を確認する方法が確実です。
| 確認項目 | 操作方法 | 結果の意味 |
|---|---|---|
| 直接接続の基準 | プロキシを経由せずIP確認サイトにリクエストを送り、返されたアドレスを記録する | 現在のネットワークからそのサイトへ直接接続した場合の出口を確認できる |
| プロキシを明示指定 | ローカル混合ポートを経由して、同じIP確認サイトにリクエストを送る | ローカルの入口、選択したノード、リモート出口までの経路を確認できる |
| ブラウザーでアクセス | システムプロキシを有効にしてから、ブラウザーで同じIP確認サイトを開く | プロキシを明示指定した場合と比較し、ブラウザーが想定した入口を経由しているか確認する |
| ログを照合 | リクエストを送った時刻のログで、対象ドメイン、出口のタグ、エラーを確認する | リクエストがコアに入った後、プロキシ経由、直接接続、拒否のいずれになったかを判断する手がかりになる |
Windows PowerShellでは、curl.exeを使って結果を比較できます。実行ファイル名を明示すると、一部の環境で同じ名前のエイリアスと混同するのを防げます。以下では公開IP確認APIを使用します。リクエストによって現在の出口アドレスがサイトに送信されるため、プライバシーに合わせて確認サービスを選んでください。ポートが10808ではない場合は、実際に使用しているHTTPまたは混合待ち受けポートに置き換えてください。
# プロキシを明示的にバイパスして直接接続の基準を確認
curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 https://api.ipify.org
# ローカルのHTTP／混合プロキシ入口を明示して使用
curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://api.ipify.orgこれら2つのコマンドもコアのルーティング設定の影響を受けます。比較する際は、先ほど記録した一時的なグローバルプロキシ設定を使用してください。2つ目のコマンドで直接接続とは異なるグローバルIPアドレスが返されたら、ブラウザーで https://api.ipify.org を開き、ブラウザーの結果と2つ目のコマンドの結果を比較します。IP所在地データベースには誤差があるため、表示された国や都市だけでノードが切り替わったか判断しないでください。
- プロキシを明示指定すると成功するのに、ブラウザーには直接接続のアドレスが表示される：まずシステムプロキシの設定、ブラウザーのプロキシ拡張機能、ブラウザー独自のプロキシ設定を確認してください。
- 2つのアドレスが同じ：まずIP確認サイトへの通信が直接接続ルールに該当していないか確認し、次に使用サーバーを確認します。アドレスが同じというだけでは、プロキシの失敗を証明できません。
- IP確認には成功するのに、目的のサイトを開けない：そのサイトに適用されるルーティング、DNS、サーバー側の制限を確認してください。すぐにクライアントを再インストールする必要はありません。
ログはリクエストを送った時刻と照らし合わせてください。現在のログレベルが警告またはエラーのみの場合、アクセス記録がないからといって、リクエストがコアを経由していないとは限りません。必要であれば「設定」→「パラメーター設定」でログレベルを一時的に変更し、リクエストを再実行します。ログにはドメインやアドレスなどが含まれる場合があります。調査後は元の設定に戻し、共有前に機密情報を隠してください。
よくある問題：失敗した箇所から原因を絞り込む
実接続テストは成功するのに、ブラウザーでページを開けない場合
まず上記のプロキシを明示指定するコマンドを実行します。コマンドが成功した場合は、「システムプロキシ」→「システムプロキシを自動設定」が適用されているか確認し、ブラウザーのプロキシ拡張機能を一時停止してください。コマンドも失敗する場合は、使用サーバー、現在のルーティング、リクエスト時刻のログを確認します。実接続テストとブラウザーでは接続先が異なるため、結果を相互に置き換えて判断することはできません。
127.0.0.1:10808への接続に失敗すると表示される場合
これはローカルの入口に接続できていない状態で、リモートノードの遅延が高いという意味ではありません。「設定」→「パラメーター設定」で待ち受けポートを確認し、コアが正常に起動しているかログを確認してください。ログにアドレスが使用中と表示された場合は、PowerShellで Get-NetTCPConnection -LocalPort 10808 -State Listen を実行して使用状況を確認できます。プロセスを特定してから対処し、正体の分からないシステムプロセスを直接終了しないでください。
システムプロキシを有効にしたら、すべてのページが開けなくなった場合
まず「システムプロキシ」から「システムプロキシをクリア」を選び、直接接続でページが開けるか確認します。直った場合は、ノードを再テストしてローカルポートを確認してください。直接接続でも開けない場合は、まずPCのネットワークを確認します。クライアントを終了する前にもシステムプロキシをクリアし、待ち受けが停止したローカルポートへアプリが接続し続けないようにしてください。
ログに証明書エラーが出た場合、証明書の検証を無効にしてもよいですか？
まずWindowsの「設定」→「時刻と言語」→「日付と時刻」でシステム時刻を同期します。次に、ノードのTLSサーバー名が提供元の指定するSNIと一致しているか確認してください。証明書の検証は有効のままにし、検証のスキップを通常の対処法にしないでください。設定が不明な場合はサブスクリプションを更新し、提供元に確認しましょう。
初回接続の完了は、スイッチの色が変わったかどうかでは判断できません。繰り返し確認できる証拠がそろっていることが基準です。ノードの実接続テストが連続して成功し、使用サーバーが明確で、プロキシを明示指定したリクエストが成功し、ブラウザーのアクセスも想定どおりで、今回のリクエストに対応する接続エラーがログにないことを確認します。確認後は普段の振り分け設定に戻してから、日常的に使うサイトでテストしましょう。調査用の設定をそのまま使い続けるのを防げます。
- 使える予備ノードを1つ確保し、メインノードに問題が起きたら切り替えて再テストしましょう。
- ポート、ルーティング設定、失敗した時刻を記録し、サブスクリプションURL全体を保存・公開しないでください。
- 振り分け設定に戻した後、中国本土のサイトに直接接続時の出口が表示されるのは想定どおりの場合があります。すべてのサイトで同じ出口が表示される必要はなく、適用されるルールに基づいて判断してください。