初回接続では、ノードでプロキシ通信ができること、ノードがアクティブサーバーに設定されていること、ブラウザーのリクエストがローカルプロキシに渡されていることの3点を確認します。ノードをインポートしたものの接続できているか分からないデスクトップユーザー向けに、「ノード選択 → 実接続テスト → システムプロキシ → ブラウザーとログの確認」の順で説明します。遅延の数値だけで判断しないことが大切です。
まずアクティブノードを選び、接続状態を確認
サーバー一覧にノードが表示されていても、設定がインポート済みということしか分かりません。行を選択すること、接続テストを行うこと、その行をアクティブサーバーに設定することは、それぞれ別の操作です。初めて使うときは、提供元が明確で設定内容がそろったノードを選び、テストに通ったらアクティブサーバーに設定します。ノード、ルーティング、DNSを同時に変更すると、失敗の原因を特定しにくくなります。
以下では、Windows版の従来のWPF画面で使われる名称を例に説明します。クロスプラットフォーム版ではボタンの位置や表示名、ショートカットキーが異なる場合があります。実際の画面の右クリックメニューや下部のステータス表示を確認してください。v2rayNは設定とプロキシを管理するクライアントで、実際の接続はコアが処理します。ウィンドウが開いていても、コアが正常に起動しているとは限りません。
-
ノードの提供元を確認する
メイン画面のサーバー一覧を開き、サブスクリプショングループにノードがあることを確認します。一覧が空なら先にインポートしてください。ノードが表示されている場合、テストのために同じサブスクリプションを重複して追加する必要はありません。サブスクリプションURLはアクセス情報です。公開されるスクリーンショットに載せないでください。
-
テストするノードを選択する
サーバー一覧で行を選択し、右クリックして「サーバーの実接続遅延をテスト」を選びます。従来の画面では通常 Ctrl+R で実行できます。操作前にメニューでショートカットキーを確認してください。初回は少数のノードだけをテストし、多数の同時テストによる影響を避けましょう。
-
アクティブサーバーに設定する
テストに通ったノードを右クリックし、「アクティブサーバーに設定」を選びます。従来の画面では通常 Enter キーで実行できます。その後、アクティブ表示とステータスバーのサーバー名を確認してください。選択行のハイライトだけで判断しないようにしましょう。
-
コアのログを確認する
メイン画面のログ欄を確認し、起動失敗、設定の解析エラー、アドレスの使用中などのメッセージがないか調べます。該当するエラーがある場合は、先にローカルでの起動問題を解消してからブラウザーで確認してください。
TCPingと実接続テストで分かること
TCPingで主に確認できるのは、サーバーのアドレスとポートにTCP接続できるかどうかです。ポートに接続できても、プロキシ認証、トランスポートのパス、TLSのネゴシエーションが正しいとは限りません。ノードのトランスポート方式によって、この指標の参考度も変わります。ネットワークに到達できるかの初期確認には使えますが、ノードが使えることを単独で証明するものではありません。
実接続の遅延テストでは、テスト対象へのリクエストをテストするノード経由で送信するため、TCPingより実際のプロキシ利用に近い結果が得られます。ただし、確認できるのは「このノードからこのテスト対象にアクセスできたか」です。すべてのサイトにアクセスできることや、現在のブラウザーがプロキシを使っていることまでは分かりません。テストはシステムプロキシとは別に実行できる場合があるため、システムプロキシが無効でも数値が表示されることがあります。
| 確認項目 | 確認できること | 直接は判断できないこと |
|---|---|---|
| TCPing | その時点のネットワークからサーバーのTCPポートに接続できるか | プロキシ認証の成功、ブラウザーがプロキシ経由で通信していること |
| 実接続の遅延 | テスト対象のノードから指定されたテスト先へのプロキシリクエストが完了するか | すべての接続先で使えること、ダウンロード速度が速いこと |
| ブラウザーでのアクセス | 現在のブラウザーから現在の接続先のコンテンツを取得できるか | ほかのアプリもプロキシ経由で通信すること、そのリクエストが必ず直結ではないこと |
| リクエストに対応するログ | 関連フィールドがログにある場合、接続先と選択されたアウトバウンドを確認できる | 端末上のすべての通信がプロキシ経由になること |
ノードを比較するときは、テスト先、ネットワーク環境、テスト方法をそろえます。同じノードを3回続けて測り、最小値だけでなくタイムアウトが繰り返されないか確認しましょう。あらゆる環境に共通する「合格遅延」の基準はありません。地理的な距離、接続先、回線によって結果は大きく異なります。偶然低い数値が出ることより、リクエストが安定して完了することのほうが参考になります。
- TCPingは成功するが、実接続はタイムアウトする：ノードの設定、プロトコルのハンドシェイク、テスト先への到達性を優先して確認します。
- 実接続テストは成功するが、ブラウザーで開けない：アクティブノード、システムプロキシ、ブラウザー独自のプロキシ設定を優先して確認します。
- Webページは開くが、大きなファイルのダウンロードが遅い：遅延は転送速度を示すものではありません。回線の混雑、ノードの負荷、接続先サービスの速度制限を確認しましょう。
システムプロキシを有効にし、ローカルの待ち受けポートを確認する
実接続テストに成功したら、v2rayNの「システムプロキシ」メニューから「システムプロキシを自動設定」を選びます。従来のWindows画面では、下部のステータスバーまたはタスクトレイのメニューから開けます。ここでいう「自動設定」は、クライアントがシステムのプロキシ設定を書き換えるという意味です。名称だけを見て、ブラウザーのPACスクリプト方式だと解釈しないでください。
システムプロキシとルーティングモードは別の設定です。システムプロキシは、その設定に従うアプリのリクエストをローカルプロキシに渡すかどうかを決めます。ルーティングは、コアが受け取ったリクエストのアウトバウンドを決めます。初回の検証ではTunモードを無効にし、システムプロキシを変更するほかのプログラムも一時的に終了して、入口を一つに絞ると切り分けやすくなります。
ローカルの待ち受けアドレスには通常 127.0.0.1 を使います。これは自分の端末を表します。バージョンや既存の設定によってポート番号は異なり、古い設定ではHTTPとSOCKSを別々のポートで待ち受ける場合もあります。手順に 10808 と書かれていても、そのまま設定を上書きしないでください。クライアントの「設定」→「パラメーター設定」でローカル待ち受けの項目を確認し、システムプロキシのアドレスと照らし合わせます。
クライアント側で確認する項目
- アクティブサーバー
- ステータスバーに選択中のノードが表示されている
- 待ち受けアドレス
- ローカルループバックアドレス 127.0.0.1
- 待ち受けポート
- 例：10808。現在の設定を確認
- コアの状態
- 起動済みで、ポート使用中のエラーがない
混合ポートはHTTPとSOCKSの両方のリクエストを受け付けます。別々に待ち受ける場合は、対応するプロトコルのポートを使ってください。
システムとブラウザー側で確認する項目
- Windowsでの設定場所
- 設定 → ネットワークとインターネット → プロキシ
- プロキシアドレス
- クライアントのローカル待ち受けアドレスと一致している
- プロキシポート
- HTTPプロキシを受け付けるポートと一致している
- ブラウザーの設定
- システムプロキシを使用し、プロキシ拡張機能は一時的に無効にする
システム画面で確認できるのは、プロキシ設定が反映されていることまでです。コアとノードが正常に動作しているかは、実際にリクエストを送って確認する必要があります。
macOSでは「システム設定」→「ネットワーク」→現在のネットワークサービスの「詳細」→「プロキシ」で該当項目を確認できます。メニューの階層はOSのバージョンによって異なります。ブラウザーに独自のプロキシ設定がある場合は、ブラウザー側の設定を確認してください。システムプロキシは端末の全通信を自動的に引き受ける仕組みではありません。システムプロキシに従わないアプリは、個別に設定する必要があります。
ブラウザーのリクエストとログでプロキシ接続を確認する
確認したいのは単に「Webページが開くか」ではなく、「新しいリクエストがローカルプロキシを経由し、想定どおりのアウトバウンドを選んだか」です。日本国内のサイトがすぐに開いても、ルーティングルールで直結になっている可能性があります。ページに古い内容が表示される場合は、キャッシュが原因かもしれません。ブラウザー、ログ、出口情報を組み合わせて判断しましょう。
- 新しいリクエストを送る：ブラウザーで新しいウィンドウを開き、信頼できるHTTPSページにアクセスします。必要に応じて強制再読み込みしてください。シークレットウィンドウは一部のキャッシュや拡張機能の影響を抑えられますが、それだけでプロキシが有効になるわけではありません。
- 時刻を照合する：リクエストを送った時刻を記録し、v2rayNのログに該当する接続先が表示されるか確認します。ログの詳細度はコアとログレベルによって異なります。アクセス記録が見当たらない場合は、該当するログが有効かを確認してください。記録がないだけで、リクエストがクライアントを経由していないとは判断できません。
- アウトバウンドを確認する：ログにルーティング結果が記録されている場合、接続先がdirectではなくプロキシ経由のアウトバウンドを使っているか確認します。分割ルーティングでは、一部の接続先が直結になるのは正常な場合があります。クライアントに接続記録があるだけでは不十分です。
- 出口を比較する：信頼できる出口IP確認ページを使って現在の結果を記録し、条件をそろえて直結時の結果と比較します。サーバーへの接続アドレスが、そのまま出口アドレスになるとは限りません。
- 設定を元に戻す：診断のためにルーティングモードやログレベルを一時変更した場合は、検証後に元へ戻します。初回テストで詳細なログを常時有効にする必要はありません。
ブラウザーの設定とノードの障害を切り分けるには、プロキシを明示して指定できるコマンドを使えます。以下はWindowsターミナルの例で、ローカルの 10808 が実際にHTTPプロキシリクエストを受け付けることを前提としています。設定が異なる場合は、実際のポートに置き換えてください。例では公開ドキュメントのドメインにアクセスしますが、固定の速度測定サービスではありません。
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --output NUL --write-out "HTTP %{http_code}\n" https://example.com/このコマンドはリクエストを明示的にローカルプロキシへ渡しますが、最終的なアウトバウンドはコアのルーティング設定で決まります。HTTPレスポンスが返れば、このプロキシ指定リクエストに応答があったことを示しますが、接続先のサービスが正常に使えるとは限りません。ローカルアドレスに接続できない場合は、待ち受けポートを確認してください。証明書エラーが出た場合は、システム時刻とエラーの詳細を確認し、証明書検証を安易に無効にしないでください。
初回接続でよくある誤判定と確認の順番
トラブルシューティングでは、テスト対象とアクティブノードを一つずつに絞り、一度に変更する項目も一つだけにします。まずローカルの待ち受けを確認し、次にノード経由のリクエスト、最後にブラウザーと分割ルーティングを調べます。実際の問題箇所を確かめないまま、サブスクリプションの再インポート、コアの交換、クライアントの再インストールを繰り返すのを防げます。
遅延の数値が表示されるのに、Webページが開かないのはなぜ？
まず、その数値がTCPingではなく実接続テストの結果か確認します。次に、テストしたノードがアクティブサーバーに設定されているかを確認してください。その後、「システムプロキシ」→「システムプロキシを自動設定」と、ブラウザーのプロキシ設定を確認します。ある行のテストに成功しても、ブラウザーが自動でその行のノードを使うわけではありません。
実接続テストがすべてタイムアウトする場合、ノードがすべて使えなくなった？
必ずしもそうとは限りません。まずログにコアの起動エラーがないか、システム時刻とネットワークが正しいか確認します。次に「設定」→「パラメーター設定」で速度テスト関連の項目を確認してください。項目のグループ名は画面によって異なる場合があります。テスト先を変更する前に元の値を記録し、アクセスできることを確認した適切なテスト先で比較してください。
クライアントを終了すると、ブラウザーもインターネットにつながらなくなるのはなぜ？
システムが引き続きローカルプロキシを参照していないか確認します。クライアントを再度起動し、「システムプロキシ」→「システムプロキシをクリア」を選んでから、通常の手順で終了してください。クライアントを起動できない場合は、システムのプロキシ設定から今回設定したプロキシ項目を無効にします。組織の管理下にある端末では、先に管理者へ相談してください。
ブラウザーではアクセスできるのに、ほかのソフトで接続できないのはなぜ？
そのソフトがシステムプロキシに従うか、独自のHTTPまたはSOCKSプロキシ設定を持つか確認します。手動設定する場合は、実際にローカルで待ち受けているポートを指定してください。これらの方法でアプリを接続できないと確認できた場合に限り、必要に応じてTunモードを検討しましょう。初回の検証で複数の通信経路を重ねないでください。
遅延は低いのに、ダウンロード速度が遅いのはなぜ？
小さなリクエストの往復時間では、継続的なデータ転送の性能は分かりません。ノードを変えずに、接続先や時間帯を変えて比較し、特定のサイトだけが遅いのか確認してください。遅延の数値を下げるためだけに、Muxを有効にしたりトランスポート方式を変更したりしないでください。実際のプロトコルとサーバー側の条件に合った設定が必要です。
初回の検証が終わったら、アクティブノード、待ち受けポート、システムプロキシのモード、ルーティングモードを記録しておきましょう。遅延のスクリーンショットだけを保存するより、問題の再現に役立ちます。後で接続に問題が起きたときも、同じ順番で確認できます。基本操作は入門ガイドを、問題の種類に応じた調査はトラブル対処ガイドをご覧ください。