v2rayNを起動したものの、接続できているか判断できない方に向けた解説です。ここではWindowsでの操作を例に、サブスクリプションの確認、候補ノードのテスト、使用サーバーの設定、ブラウザーでの動作確認を順に紹介します。「サーバーに接続できる」「ローカルプロキシが通信を転送する」「アプリが実際にプロキシを使う」は別々の状態です。遅延の数値だけで判断しないよう、それぞれを確認しましょう。
接続前に確認すること：サブスクリプションとローカルポート
v2rayNはクライアントの操作画面で、実際の接続は選択したコアが処理します。サブスクリプションからサーバー設定を取得しても、プロキシ接続が確立したとは限りません。追加後、一覧にサーバーアドレス、ポート、プロトコルなどが表示されているか確認してください。グループ名だけでサーバーが表示されない場合は、まずサブスクリプションの更新問題を解決します。
デスクトップ画面やバージョンによってメニューの位置が多少異なる場合があります。「サブスクリプショングループ」「設定」「システムプロキシ」などの項目を目印にしてください。まず、システムプロキシを変更するほかのプログラムを終了します。初回の動作確認ではTUNを有効にせず、仮想NIC、ルーティング、権限などの要因を減らしましょう。
-
サブスクリプションを確認
「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、グループのURLが正しく保存されていることを確認します。次に「サブスクリプショングループ」から「すべてのサブスクリプションを更新（プロキシを使用しない）」を実行してください。利用可能なプロキシがあり、直接接続での更新に失敗する場合は、プロキシ経由での更新を試します。
-
サーバーを確認
更新したサブスクリプショングループに切り替え、サーバー一覧に項目が表示されるか確認します。一覧が空の場合は、ログでダウンロード、解析、認証に関するエラーを確認し、サブスクリプションが有効かどうかも調べてください。
-
ポートを控える
「設定」→「パラメーター設定」を開き、ローカルリスナーの設定でHTTPまたは混合リスナーのポート番号を控えます。この記事のコマンドでは
10808を例にしています。実際の番号が異なる場合は置き換えてください。リモートサーバーのポート番号を入力しないよう注意してください。 -
ログを表示する
メイン画面にログ欄を表示し、コアの起動後に終了を繰り返す、リスナーの起動に失敗する、ポートが使用中といったメッセージが出ていないか確認します。画面を操作できても、コアが正常に動作しているとは限りません。
実接続遅延テスト：使えるノードを絞り込む
TCP遅延は、サーバーの指定ポートにTCP接続できるかを主に示します。実接続遅延テストでは通常、ノードの設定を使ってテスト用アドレスにアクセスするため、プロキシのハンドシェイクやリクエスト処理も含めて確認できます。そのため、TCP遅延が測定できても実接続に失敗することはあり得ます。ポートには到達できても、認証、トランスポート、セキュリティ層、接続先へのリクエストで問題が起きている可能性があります。
サーバー一覧でCtrlキーを押しながら候補を少数選び、右クリックして「サーバーの実接続遅延をテスト」を実行します。まずは3～5件で十分です。サブスクリプション全体を一度に並列テストする必要はありません。結果はローカルネットワーク、テスト先、サーバー負荷の影響を受けるため、1回の測定結果を安定性の順位とみなさないでください。
以下の数値は読み方を示す例であり、当サイトでの実測値ではありません。ノードAが2回とも180 ms、210 ms、ノードBが95 msの後にタイムアウトした場合、初回接続ではまずノードAで動作確認するのが適切です。1回だけ低遅延でも、繰り返し失敗するなら候補としては不安定です。また、遅延の数値からダウンロード速度を直接推測することはできません。
| 結果の組み合わせ | 判断できること | 次の手順 |
|---|---|---|
| TCPと実接続の両方に成功 | 現在のテスト条件では、ポートに接続でき、プロキシ経由のリクエストも成功 | 使用サーバーに設定し、ブラウザーで確認 |
| TCPは成功、実接続はタイムアウト | ポートに接続できるだけでは、ノードが使えるとは判断できない | サブスクリプションの有効性とログを確認し、別の候補ノードと比較 |
| すべてのノードで実接続に失敗 | ローカル環境またはテスト先に共通の問題がある可能性 | ネットワーク、システム時刻、コア、テスト先を確認 |
| 実接続は成功するが、目的のWebサイトは開けない | テスト先に接続できることだけが確認できた状態 | Webサイト、ルーティングルール、アプリのプロキシ設定を確認 |
ノードを選択：使用サーバーとシステムプロキシを設定
テストに成功したら、対象サーバーを右クリックして「使用サーバーに設定」を選び、使用中の表示とログを確認します。行が選択状態でハイライトされているだけでは不十分です。一覧で選択中の項目と、実際に使用するサーバーは別のものです。切り替え後、コアが設定を再読み込みするまで待ってから、新しいリクエストを送信してください。
続いて、メイン画面下部またはトレイアイコンの右クリックメニューから「システムプロキシ」→「システムプロキシを自動設定」を選びます。システムプロキシ設定に従うアプリをローカルリスナーに接続する機能であり、デバイス上のすべての通信を処理するわけではありません。コアに届いたリクエストの振り分け方はルーティングモードで決まるため、両方を個別に確認しましょう。
ローカルプロキシの接続先
- リッスンアドレス
127.0.0.1- ポート番号の例
10808- ポートの種類
- HTTP、またはHTTPに対応した混合リスナー
- アプリの接続方法
- システムプロキシまたはアプリで手動設定したプロキシ
ポート番号はパラメーター設定に従ってください。SOCKS専用ポートに、この記事のHTTPプロキシ用コマンドをそのまま使用することはできません。
初回確認時の状態
- 使用サーバー
- 実接続テストに成功した候補ノード
- システムプロキシ
- システムプロキシを自動設定
- TUNの状態
- 一時的に無効
- ルーティングの確認
- テスト先の通信がプロキシ経由になっているか確認
一時的な調査でグローバルプロキシのルーティングを使った場合は、確認後に必要な振り分けルールへ戻してください。
Windowsでは「設定」→「ネットワークとインターネット」→「プロキシ」でシステムプロキシの状態を確認できます。手動プロキシのアドレスは、127.0.0.1:10808のようにローカルリスナーに合わせてください。設定がすぐに元に戻る場合は、ノードを何度も切り替えるのではなく、ほかのプロキシソフト、ブラウザー拡張機能、組織のポリシーを確認します。
プロキシの動作確認：コマンド、ブラウザー、ログで照合
確認は2段階で行います。まずローカルの接続先がリクエストを受け付けること、次にブラウザーがその接続先を使うことを確認します。コマンドでプロキシを明示すれば、アプリがシステムプロキシを読み取っているかという不確定要素を切り分けられます。ただし、それだけではブラウザーがシステムプロキシを使用している証明にはならず、コアが最終的にリモートのプロキシ出口を選んだことも確認できません。
手順1：ローカルプロキシを明示してアクセス
Windowsのターミナルで次のコマンドを実行します。ここではcurl.exeを使い、一部のPowerShell環境でcurlが別のコマンドとして解釈されるのを避けます。テスト先は公開されている例示用ドメインです。ここにアクセスできても、すべてのWebサイトに接続できるとは限りません。
curl.exe --proxy http://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 20 -I https://example.com--proxyにはローカルのHTTPプロキシ接続先を指定します。ポート番号はクライアントの設定と一致させてください。--noproxyを指定して除外対象をローカルアドレスに限定し、環境側の広範な除外設定によって今回の外部テストがプロキシを迂回するのを防ぎます。--connect-timeout 10は接続時の待ち時間を制限し、--max-time 20はリクエスト全体の制限時間を指定します。どちらも単位は秒です。-Iはレスポンスヘッダーを取得します。接続先がHEADリクエストに対応していない場合は外し、通常のリクエストに切り替えてログも確認してください。
200 Connection establishedと表示されただけでは、接続先のページが正常に返されたとは限りません。ローカルプロキシがHTTPSトンネルのリクエストを受け付けたことを示しているだけの場合があります。最終的な接続先のレスポンスや、その後に発生するエラーも確認してください。127.0.0.1に接続できないというエラーが出た場合は、リモート回線を疑う前にコアとローカルポートを確認します。
手順2：ブラウザーの接続先と出口を確認
- システムプロキシに従うブラウザーを使用し、プロキシ設定を上書きする拡張機能は一時的に無効にします。すでに読み込み済みのタブだけで判断せず、テストページを開き直してください。
- リクエストを送信した時刻を記録し、v2rayNのログで該当するドメインや接続を探します。アクセスログが必要な場合は、使用中のバージョンで利用できるログ設定から、一時的にアクセスログを有効にしてください。
- ログの接続先が想定したプロキシ経由のアウトバウンドであり、直接接続ではないことを確認します。ドメイン名が表示されるだけでは、リクエストがリモートノードを経由した証明にはなりません。
- 信頼できる同じ公開IPアドレス確認ページを使い、直接接続時とプロキシ接続時の出口アドレスを比較します。確認リクエスト自体がプロキシのルールに一致している必要があります。アドレスの違いは補助的な証拠にはなりますが、ルーティングの確認に代わるものではありません。
v2rayNの初回接続でよくある質問
遅延の数値は表示されるのに、Webページが開かないのはなぜ？
まず、表示されているのがTCP遅延か実接続遅延かを確認し、次に使用サーバーと「システムプロキシ」→「システムプロキシを自動設定」を確認してください。上記のプロキシを明示するコマンドで比較します。コマンドでは成功してブラウザーでは失敗する場合は、ブラウザーのプロキシ接続先、拡張機能、既存の接続を優先して確認しましょう。
すべてのノードがタイムアウトします。サブスクリプションを再追加するべきですか？
まずコアが正常に起動しているか、システムの日付と時刻が正しいかを確認し、次にサブスクリプションの期限切れを調べます。複数のノードから同じテスト先に接続できない場合は、「設定」→「パラメーター設定」で、現在のバージョンに用意されているテスト先の設定を確認します。有効性を確認できるHTTPSアドレスで再テストしてください。証明書の検証を無効にしてエラーを回避しないでください。
ノードを切り替えても出口アドレスが変わらない場合は？
まず新しいリクエストを送信し、使用サーバーの表示を確認してください。複数のノードが同じ出口を共有する場合もあり、ブラウザーが既存の接続を再利用している可能性もあります。テスト用のタブを閉じてから再アクセスし、必要に応じてブラウザーを再起動します。出口アドレスの比較だけでなく、アウトバウンドのログも確認してください。
ポートが使用中というログが出た場合、どこを変更すればよいですか？
「設定」→「パラメーター設定」を開き、空いていることを確認したポートにローカルリスナーを変更して保存し、コアを再起動します。たとえば10818に変更した場合は、システムプロキシを再設定し、手動でプロキシを設定したアプリとテストコマンドのポートも合わせて変更してください。正体のわからないシステムプロセスをむやみに終了しないでください。
実接続遅延は短いのに、ダウンロードが遅いのは正常ですか？
実接続遅延が示すのは短いリクエストの応答時間であり、帯域幅ではありません。同じファイル、ネットワーク、時間帯で、利用できることを確認済みの2つのノードを比較してください。ダウンロード速度はサーバー負荷、回線の混雑、接続先の速度制限にも左右されます。ミリ秒単位の遅延から直接換算することはできません。
確認後の設定：再現できる接続状態を記録
初回接続に成功したら、次回の問題切り分けに役立つ最低限の情報を記録します。サブスクリプショングループ名、使用ノードのメモ、ローカルポート、システムプロキシの状態、ルーティングモード、テスト日時です。サブスクリプションのトークン、パスワード、ノードの認証情報全体は、公開ドキュメントに記録しないでください。
- 利用可能なノード：実接続テストを2回以上行い、実際に必要な接続先へアクセスできること。
- ローカルの接続先：プロキシを明示したリクエストが成功し、リッスンポートとアプリの設定が一致していること。
- ブラウザーの通信経路：システムプロキシを使用し、ログで想定したアウトバウンドに対応していること。
- 設定を元に戻す：通常の振り分け設定に戻し、一時的に有効にした詳細ログを無効にします。プロキシを使わない場合は「システムプロキシ」→「システムプロキシを解除」を実行してください。
これで「サブスクリプションを追加できた」「ノードのテストに成功した」「現在のアプリでプロキシが有効になった」ことを、それぞれ個別に確認できました。次に問題が起きたときは、失敗した段階から調べましょう。サブスクリプションを何度も更新したり、複数の設定を同時に変更したりするより、原因を特定しやすくなります。