ノードのインポートが完了しても、設定が一覧に追加されたことを示すだけです。v2rayNを初めて使うときは、接続先への到達性、プロキシのハンドシェイク、ローカルの待ち受け、ブラウザーの通信がプロキシを経由しているかを順に確認しましょう。この記事ではWindowsでの操作を中心に、「候補ノードをテスト → 使用するノードを選択 → システムプロキシを有効化 → 実際の通信を確認」の順で解説します。遅延の数値が緑色というだけで、接続成功と判断しないことが大切です。
1. インポート後はノードを確認してから速度を測る
v2rayNは、接続設定を管理し、コアを起動してローカルプロキシへの入口を提供するデスクトップクライアントです。ノード一覧の各行は通常、サーバーへの接続パラメーターをまとめたもので、接続が確立済みという意味ではありません。サブスクリプションの更新が完了し、ノード名が正しく表示されていても、サーバーがその認証情報を受け付けているとは限りません。
最初は候補ノードを少数に絞り、数百件の設定を一度にテストするのは避けましょう。大量の同時接続はPCやネットワークに負荷をかけ、サーバー側の接続制限に触れる可能性もあります。初回確認は3～5件で十分です。提供元が明確で、設定項目がそろっており、サービスが正常なものを優先してください。
- サブスクリプショングループを確認：更新したばかりのグループを選び、同じ名前の古い設定を除外します。サブスクリプションを更新しても、含まれるすべてのノードが使えるとは限りません。
- 重要な設定項目を確認：ノードの編集画面を開き、アドレス、ポート、プロトコル、トランスポート方式、安全性に関する設定を確認します。VLESSやVMessなどの認証情報に加え、TLSやトランスポートの設定もサーバー側と一致させる必要があります。
- システム時刻を合わせる：Windowsの日付、時刻、タイムゾーンが正しいことを確認し、時刻を同期します。時刻が大きくずれていると、証明書の検証や一部プロトコルの認証に影響することがあります。
- 設定を変えずに使う：初回接続では、提供元の設定をそのまま使います。速度テストのためにSNIやトランスポートのパスを変更したり、証明書の検証を無効にしたりしないでください。
2. TCPingと実接続テストで確認できること
TCPingで主に確認できるのは、ノードのアドレスとポートへのTCP接続です。一方、実接続テストではノード設定を使ってプロキシ経由のリクエストを送り、クライアントに設定されたテスト先へアクセスします。測定する経路が異なるため、数値をそのまま比べることはできません。TCPingの結果だけでWebページが表示できると判断するのも禁物です。
実接続テスト
おすすめ初回接続時の候補選びに使います。一般に、ローカルのテスト用コア、ノード認証、トランスポートのハンドシェイク、接続先へのリクエストが関係するため、TCPポートだけを調べるより実際のプロキシ利用に近いテストです。計測範囲や成功条件は、使用中のバージョンの実装に従います。
用途：ノード設定が使えるかの確認、普段使うノードの選定。
TCPingによる遅延テスト
接続先のTCPポートに到達できるかを素早く確認します。ポートに接続できても、プロトコル認証の成功や、ノードからWebサイトへの通信が正常とは限りません。TCP以外のトランスポートを使う設定では、参考になる度合いがさらに下がります。
用途：アドレスの誤り、ポートへの接続不可、明らかなネットワーク障害の初期確認。
たとえば、あるノードのTCPingが35ミリ秒でも実接続がタイムアウトするなら、認証情報、TLS設定、サーバー側の出口、テスト先などに問題がある可能性があります。一方、別のノードはTCPingが80ミリ秒、実接続が210ミリ秒でも安定して成功するなら、初回接続の候補としては後者が適しています。ここに記載した数値は読み取り例であり、当サイトでの実測値ではありません。
判断の基本：まず成功率、次に遅延
実接続テストを繰り返して安定して成功するノードを残し、同じテスト先で遅延を比較します。TCPingの数値が低くても、プロキシ経由のリクエストが繰り返し失敗するノードは、現在のメインノードに適しません。
3. 実接続テストを3回行い、同じ接続先で比較する
ノード一覧から候補を選び、右クリックメニューで「サーバーの実接続遅延をテスト」または同様の項目を探します。複数選択する場合は、Ctrlキーを押しながら選択します。テストされるのは選択した設定だけです。テストしたノードがアクティブになるとは限らず、ブラウザーのプロキシが自動で有効になるわけでもありません。
- テスト先を確認：「設定」→「パラメーター設定」を開き、速度測定や実接続テストに関する項目を探して、現在のテストURLを確認します。テスト先自体にアクセスできない場合、複数のノードが同時に失敗することがあります。
- 1回目を実施：候補を3～5件選んで実接続テストを行い、成功、タイムアウト、その他のエラーを記録します。ローカルの帯域を使い切らないよう、ダウンロードはまだ開始しないでください。
- さらに2回テスト：数秒待ってから、ネットワーク、テスト先、候補ノードを変えずにテストします。3回とも成功するノードを、一度だけ極端に低い数値が出たノードより優先してください。
- 使用するノードを設定：候補を選び、右クリックメニューの「アクティブサーバーに設定」または同等の操作を実行します。一覧のアクティブ表示が移動したことを確認してください。
- 起動結果を確認：画面下部のログを確認し、コアがすぐに終了していないこと、待ち受け失敗や設定の解析エラーなどがないことを確認します。
遅延テストは通信速度の測定ではありません。実接続の遅延が低い場合、小さなリクエストへの応答が速いとは考えられますが、大きなファイルのダウンロード速度までは分かりません。サーバーの負荷、回線の混雑、接続先の速度制限などにより、「低遅延なのにダウンロードが遅い」こともあります。
4. システムプロキシを設定してブラウザーをローカルの入口につなぐ
アクティブノードの設定で決まるのは「クライアントがどの接続パラメーターを使うか」です。システムプロキシの設定で決まるのは「アプリがリクエストをどこへ渡すか」です。この2つは別々の設定です。Windowsでは、タスクトレイのv2rayNアイコンを右クリックし、「システムプロキシ」→「システムプロキシを自動設定」を選んでから、クライアントに表示されるシステムプロキシの状態を確認します。
ローカルの待ち受けポートは、現在のパラメーター設定と起動ログで確認してください。以下では 127.0.0.1:10808 を例にします。このポートがHTTPプロキシ、またはHTTPに対応した混合入口を提供していることが前提です。実際の設定が異なる場合はポート番号を置き換えてください。SOCKS専用の入口にはHTTPプロキシ用コマンドをそのまま使えません。
- Windows側を確認：Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、プロキシのアドレスとポートがクライアントと一致しているか確認します。画面の配置はWindowsのバージョンによって多少異なります。
- ブラウザー側を確認：最初の動作確認には、システムプロキシに従う標準設定のブラウザーを使います。プロキシ切り替え拡張機能をインストールしている場合は、システム設定を上書きしていないか確認してください。
- ルーティングを確認：システムプロキシはリクエストをクライアントに渡すかどうかを決めるだけです。クライアントに入ったリクエストは、ルーティングルールによって直接接続、プロキシ経由、またはブロックに振り分けられる場合があります。
- 別のモードと混同しない：システムプロキシはすべてのプログラムの通信を引き受ける機能でも、TUNでもありません。初回のトラブルシューティングでは、複数の入口を同時に変更せず、システムプロキシを単独で確認してください。
5. ブラウザー・コマンド・ログでプロキシの動作を確認する
普段どおりアクセスできるHTTPSページを開き、基本的なネットワーク接続に問題がないことを確認します。次に、現在のルーティングルールでプロキシ経由になるはずの接続先を開きます。ページが表示できるだけでは、プロキシが動作している証拠になりません。キャッシュから表示されている場合や、ルールによって直接接続されている場合があるためです。新しいリクエストのログも合わせて確認しましょう。
- 新しいリクエストを送信：ブラウザーで新しいウィンドウを開いて対象ページにアクセスし、必要に応じて強制再読み込みします。ログで該当リクエストを見つけやすいよう、テスト時刻を記録しておきましょう。
- 接続先を確認：クライアントのログで、対象のドメイン名や接続記録を探します。ログに出力タグが表示される場合は、現在の設定に照らしてプロキシ経由か直接接続かを判断してください。
- 実際の通信内容を確認：ページ本文、画像、ログイン時のリクエストがそれぞれ異なるドメインに接続する場合があります。トップページは表示されても画像が読み込めないときは、すぐにすべてのノードを変更せず、失敗したドメインを個別に確認してください。
ブラウザーの設定とローカルプロキシの問題を切り分けるには、Windows PowerShellでプロキシを明示してリクエストを送信できます。以下のコマンドで確認できるのは、ローカルプロキシの入口から例示したHTTPSサイトまでのリクエスト経路です。ブラウザーがシステムプロキシに従っているかは自動で検証されません。テスト前に、例のポートが実際の設定と一致していることを確認してください。
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -I https://example.comここでは接続タイムアウトを10秒、全体のタイムアウトを30秒に設定し、失敗したリクエストを長時間待たないようにしています。HTTPレスポンスヘッダーを受信できれば、接続先または途中の機器から少なくとも応答が返ったことを示します。ステータスが403でも、接続先による拒否や出口側の制限などを切り分けてください。ローカルポートへの接続不可と単純に判断してはいけません。このコマンドもコアのルーティング設定の影響を受けます。リモートノードを経由したことを確認するには、出力先の記録も併せて確認してください。
判断の目安：明示的なプロキシ指定では成功し、ブラウザーでは失敗する場合はアプリの入口を確認
まずシステムプロキシのポート、ブラウザー拡張機能、アプリ独自のプロキシ設定を確認します。明示的なプロキシ指定のコマンドも失敗する場合は、ローカルの待ち受け、コアのログ、ノードの実接続テストに戻って確認しましょう。最初からクライアントを再インストールする必要はありません。
6. よくあるトラブルと原因別の対処
一度に変更するのは1つの項目だけにしましょう。ノードの変更、DNSの修正、ルーティングの切り替え、別の通信制御モードの有効化を同時に行うと、原因を特定しにくくなります。「どの操作が成功し、どれが失敗したか」を記録するほうが、接続ボタンを何度も押すより効果的です。
TCPingには数値が出るのに実接続が毎回タイムアウトします。ノードに問題がありますか？
必ずしもそうとは限りません。まずテストURLにアクセスできるか確認し、次にノードの認証情報とトランスポート設定を見直します。提供元の異なる複数のノードが同じテスト先で失敗する場合は、信頼でき、アクセス可能だと分かっている別のHTTPSテスト先で再確認してください。テストを通すために証明書の検証を無効にしてはいけません。
実接続テストは成功するのにブラウザーで開けません。まず何を確認すればよいですか？
まず対象ノードがアクティブサーバーに設定されていることを確認し、「システムプロキシ」→「システムプロキシを自動設定」が有効か確認します。次に、上記の明示的なプロキシ指定コマンドを試します。コマンドは成功してブラウザーだけ失敗する場合は、ブラウザーのプロキシ拡張機能、独自プロキシ設定、古いポート設定を優先して確認してください。
ログに「ポートが使用中」と表示されます。どう調べればよいですか？
まず、重複して起動しているクライアントを終了し、実際の待ち受けポートを確認します。Windowsでは、下記のコマンドで10808に関連する接続とプロセスIDを確認できます。出力があるだけで競合とは限りません。LISTENINGの行を重点的に確認し、タスクマネージャーでプロセスを特定してください。正体の分からないシステムプロセスをそのまま終了しないでください。
遅延が負の値になったりテストに失敗したりします。ネットワークが極端に遅いのでしょうか？
このような表示は通常、実際の遅延ではなく失敗を示します。エラーの詳細を確認し、タイムアウト、認証失敗、証明書エラー、テスト用コアの起動失敗などを切り分けてから再テストしてください。失敗時の値を遅延の平均に含めないでください。
開けるWebサイトと開けないWebサイトがあります。プロトコルを変更すべきですか？
まず、アクセスできないドメインのルーティング先とDNSエラーを確認します。同じノードでほかのHTTPSページには安定してアクセスでき、特定の接続先だけ失敗する場合は、接続先の制限やルーティングルールを優先して確認してください。プロトコルの変更は、あらゆるアクセス障害に効く万能策ではありません。
netstat -ano | findstr :108087. 初回接続の完了条件と終了時の確認
初回接続の完了は「画面に緑色の数値が表示された」ことではなく、アプリからリモート接続先まで通信が通る証拠を確認できた状態です。安定したメインノードと予備ノードを1つずつ確保すれば十分です。数ミリ秒の差を追って、設定全体を毎日変更する必要はありません。
- 同じテスト先で、候補ノードの実接続テストが繰り返し成功する。
- 使用中のアクティブノードが明確で、コアの稼働中に起動エラーや待ち受けエラーが繰り返し発生しない。
- ローカルプロキシのアドレス、システムプロキシの設定、アプリが実際に使うポートが一致している。
- 対象ページで新しいリクエストが発生し、ログに記録されたルーティング先が想定どおりである。
- クライアントを完全に終了する前に、「システムプロキシ」を「システムプロキシを解除」に切り替えてください。停止したローカルポートをシステムが参照し続けるのを防げます。
今後トラブルが起きたら、逆の順に確認できます。まずアプリの通信がプロキシに入っているか、次にルーティングが正しいか、最後にノードとサーバーの状態を調べます。設定のインポートや基本設定については使い方ガイドを、VMess、VLESS、トランスポート層の設定についてはプロトコルの詳しい解説をご覧ください。