サブスクリプションを読み込んだものの、接続できるか確認できていないデスクトップユーザー向けです。まず候補ノードを絞り、ポート接続テストと実接続テストの違いを確認します。最後に、使用中のサーバーやローカル待ち受け、システムプロキシ、ルーティングログをチェックします。速度測定に成功しても、ブラウザーの通信がプロキシ経由とは限りません。この記事では、その違いを順を追って検証します。
1. 初回接続前の確認
v2rayNは設定・管理用のクライアントで、実際のプロキシ接続は選択したコアが処理します。サブスクリプションにサーバーが表示されていても、設定情報を取得できたことしか分かりません。認証情報が有効か、サーバーが稼働中か、ブラウザーの通信がローカルプロキシに渡されているかは別途確認が必要です。この記事ではWindowsのデスクトップ画面を基準に説明します。バージョンによってメニュー名が異なる場合があります。
初回のトラブルシューティングではシステムプロキシを使い、TUNモードは一時的に無効にします。両方を同時に使うと原因を特定しにくくなります。システムプロキシを変更したりネットワークを制御したりする他のソフトも終了し、ルーティング設定はそのままにして、一度に複数の条件を変えないようにしましょう。
- サブスクリプションの内容を確認：一覧にサーバーアドレス、ポート、プロトコルが表示されていることを確認します。ノード名に含まれる地域名や回線名だけで品質を判断しないでください。
- システム時刻を確認：Windowsの「設定」→「時刻と言語」→「日付と時刻」で、時刻とタイムゾーンを確認します。時刻が大きくずれていると、証明書の検証やプロトコル認証に失敗することがあります。
- コアの稼働状況を確認：クライアントのログ欄を開き、起動失敗、設定の解析エラー、待ち受けポートの競合がないか確認します。
- サブスクリプション情報を保護：サブスクリプションURLや共有リンクには、通常、アクセスに必要な認証情報が含まれています。トラブルシューティング用のスクリーンショットでは、URL、ユーザーID、認証情報を隠してください。
2. 候補ノードとテストの手順
候補を少数に絞ると、複数ノードの同時テストによるネットワークへの影響を抑えられます。ノード名は識別用にすぎません。VLESS、VMess、Trojan、Shadowsocksといったプロトコル名から、遅延の順位を判断することもできません。距離、接続回線、サーバー負荷、テスト先の場所など、さまざまな要因が結果に影響します。
-
候補を選ぶ
サーバー一覧でCtrlキーを押しながら、候補ノードを3つ選びます。用途や地域が希望に合うものを優先し、最初からサブスクリプション全体を何度も測定するのは避けましょう。
-
Tcpingを実行
選択した項目を右クリックし、「Tcping」を含む遅延テストを実行します。まずは繰り返しタイムアウトするノードを特定します。TCP接続では、このテストでサーバーアドレスとポートに到達できるかを確認できます。
-
実接続を測定
同じノードを選択したまま右クリックし、「サーバーの実接続遅延をテスト」を選びます。結果が更新されるまで待ちます。実行されるのはテストであり、ブラウザーの通信が候補ノードごとに自動で切り替わるわけではありません。
-
繰り返し比較
候補ノードごとに実接続テストを3回行い、テスト先とローカルネットワークの条件は変えないでください。最も低い値だけでなく、成功した回数と結果のばらつきを記録します。
-
使用するノードに設定
対象の項目を右クリックして「アクティブサーバーに設定」を選びます。アクティブ表示が切り替わったことを確認し、ログに新たな起動エラーや接続エラーがないか確認します。
2つのノードの遅延が近い場合は、テストが安定して成功し、実際のページ表示も安定する方を選びましょう。初回接続時にすぐダウンロード速度を測る必要はありません。転送速度テストは通信量を消費するうえ、同時に行う遅延テストにも影響する可能性があります。
3. Tcpingと実接続遅延の違い
Tcpingで主に確認できるのは、サーバーのTCPポートに接続できるかどうかです。プロキシプロトコルの認証は行われず、リモート側から目的のWebサイトにアクセスできることも保証しません。一方、実接続遅延テストでは、テスト用のプロキシ接続を使って指定先にリクエストを送ります。そのため、より多くの通信経路を確認できます。具体的な計測範囲や成功条件は、クライアントのバージョンとテストの実装によって異なります。
| テスト方法 | 主に確認できること | このテストだけでは確認できないこと |
|---|---|---|
| Tcping | ローカルPCからサーバーアドレスのTCPポートに接続できるか | プロキシの認証情報が有効か、TLS設定が正しいか、Webページを閲覧できるか |
| 実接続遅延 | テスト用プロキシ経由で指定したHTTPまたはHTTPSの接続先にリクエストが届くか | すべてのWebサイトへのアクセス、ブラウザーのシステムプロキシ利用、長時間の通信速度 |
| ブラウザーでのアクセス | 現在のプロキシ設定とルーティング設定で、使用中のアプリから実際にアクセスできるか | 他のアプリも同じ入口と通信経路を使っているか |
実接続テストの結果は、DNS、プロトコルのハンドシェイク、TLS、サーバーの外向き通信、テスト先の応答にも左右されます。Tcpingの値が低くても、実接続がタイムアウトすることがあります。反対に、テスト先が利用できないために、他のサイトには接続できるノードが失敗と表示される場合もあります。テスト先を記録し、ノード間の比較中に変更しないでください。
4. システムプロキシとローカル待ち受けの確認
アクティブサーバーを設定した後は、アプリからプロキシに接続するための入口も設定します。v2rayNのメイン画面下部にある「システムプロキシ」メニューから「システムプロキシを自動設定」を選びます。これにより、システム設定にプロキシアドレスが登録されます。主にこの設定を参照するアプリに適用され、すべての通信を強制的にプロキシ経由にする機能ではありません。
Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」で手動プロキシの情報を確認します。この記事の例を使う場合、プロキシアドレスはローカルPCを指し、ポートはクライアントのHTTPまたは混合入口と一致している必要があります。リモートノードのアドレスとポートをここに直接入力しないでください。
クライアントのローカル入口
- 待ち受けアドレス
127.0.0.1- ポートの例
10808- 入口の種類
- HTTPとSOCKSのリクエストを受け付ける混合入口
- 確認場所
- メイン画面下部の待ち受け情報とパラメータ設定
ここで説明しているのはローカルの入口です。HTTP専用ポートを使う場合は、そのHTTPポートを設定してください。
Windowsのシステムプロキシ
- 入口を有効にする
- 「システムプロキシ」→「システムプロキシを自動設定」
- プロキシアドレス
127.0.0.1- プロキシポート
- ローカルのHTTPポートまたは混合ポートと同じ値
- 適用範囲
- システムプロキシ設定を参照し、プロキシを迂回しないアプリのリクエスト
アドレスとポートが一致しているだけでは不十分です。対応する入口が実際に待ち受けていることも確認してください。
PowerShellで次のローカルポート確認を実行できます。ポートが10808でない場合は、実際の値に置き換えてください。結果のTcpTestSucceeded : Trueが示すのは、ローカルのTCPポートに接続できることだけです。待ち受けているプロセスがv2rayNであることや、リモートプロキシが使えることを保証するものではありません。
Test-NetConnection -ComputerName 127.0.0.1 -Port 108085. ブラウザーでのアクセスと外向き通信の確認
普段使っているHTTPSページのうち、正常に表示されるか判断しやすいものをブラウザーで開きます。以前から開いているタブに内容が表示されているだけで判断せず、ページを再読み込みするか、新しいプライベートウィンドウで開いて、キャッシュや拡張機能の影響を抑えましょう。システムプロキシを有効にしても、通常は証明書を変更する必要はありません。接続エラーを解決するために証明書検証を無効にしないでください。
- 入口を確認：ブラウザーがシステムプロキシを使っているか、同じローカル入口を明示的に設定している必要があります。拡張機能やブラウザーポリシーで別のプロキシが設定されている場合、Windowsの設定は反映されないことがあります。
- リクエストを確認：クライアントのログから、直前にアクセスした接続先ホストと接続記録を探します。必要に応じて一時的にログレベルを上げ、確認後は元に戻してください。詳細ログにはアクセス先の情報が含まれる場合があります。
- ルーティングを確認：そのリクエストが実際にどのアウトバウンドを使ったか確認します。ルールによっては直接接続に振り分けられるため、「ページが開いた」という事実だけではリモートノード経由とは判断できません。
- 別の条件でも確認：アクティブノードを変え、同じページへのアクセス結果を比較します。出口IPの確認ページを使う場合は、そのリクエストがルーティングルールによって直接接続に振り分けられていないことも確認してください。
ブラウザーの設定とローカルプロキシの動作を切り分けるには、Windowsターミナルからプロキシを明示してサイトにアクセスできます。次のコマンドはレスポンスヘッダーのみを取得します。ローカルポートを変更している場合は、パラメーターも合わせて変更してください。
curl.exe --head --proxy http://127.0.0.1:10808 https://7v2ray.com/6. 初回接続でよくあるトラブル
「ローカル待ち受け → アプリの入口 → ルーティング → リモート接続 → 接続先の応答」の順に確認します。まず問題がどの段階で発生しているかを特定し、その設定だけを変更してください。ノード、DNS、プロトコル設定、テスト先を同時に変えると、どの変更が効いたのか判断できません。
Tcpingは成功するのに、実接続がタイムアウトする場合
まずテスト先が変わっていないことを確認し、失敗した時間帯のログを開きます。認証エラーの場合はサブスクリプションの状態を確認します。TLSエラーの場合はシステム時刻と、サーバーが要求するサーバー名を確認します。接続タイムアウトの場合は、サーバーへの接続と接続先からの応答を切り分けてください。VLESSのFlow、REALITYの公開鍵、トランスポート方式をむやみに変更しないでください。
実接続は成功するのに、ブラウザーでページを開けない場合
「システムプロキシ」→「システムプロキシを自動設定」をもう一度確認し、Windowsのプロキシ設定でアドレスとポートを確認します。プロキシを明示したcurlコマンドでもテストしてください。コマンドは成功するのにブラウザーで失敗する場合は、ブラウザーのプロキシ拡張機能、組織のポリシー、個別サイトのエラーを優先して確認します。
ログにaddress already in useと表示される場合
待ち受けポートが使用中です。まずクライアントを二重に起動していないか確認し、そのポートを使っている他のプログラムを終了します。「設定」→「パラメータ設定」でローカル待ち受けポートを変更する方法もあります。その後、システムプロキシを再設定し、システム側のポートと新しい待ち受けポートを一致させてください。
遅延は低いのに、ダウンロードが遅い場合
遅延テストで測定するのは小さなリクエストへの応答であり、継続的なデータ転送速度ではありません。他の速度テストを停止し、同じファイルまたは同じサービスで候補ノードを比較してください。特定の接続先だけが遅いかどうかも確認します。接続先固有の帯域制限やルーティングの問題を、1回の遅延測定だけで説明することはできません。
クライアントを終了すると、かえってインターネットに接続できなくなる場合
Windowsにローカルポートを指す手動プロキシ設定が残っていないか確認します。v2rayNを再起動できる場合は、「システムプロキシ」→「システムプロキシをクリア」で元に戻せます。クライアントを起動できない場合は、Windowsのプロキシ設定で該当する手動プロキシを無効にしてください。ウィンドウを閉じただけでは、プログラムが終了しているとは限りません。
初回接続の完了は、「どこかに低い遅延が表示された」ことではありません。アクティブサーバーが明確で、ローカル入口に接続でき、ブラウザーが想定した入口を使い、ルーティングとログから実際の通信経路を説明できることが目安です。この確認手順を覚えておけば、サブスクリプションの更新やネットワークの切り替え後も、同じ方法で問題を特定できます。