サブスクリプションにノードが表示されても、プロキシが有効になったとは限りません。インポート直後のデスクトップユーザー向けに、「接続テスト → アクティブサーバーに設定 → システムプロキシを有効化 → 出口とログを確認」の順で初回の動作確認を進めます。ここではWindows版v2rayNを中心に、ノードの接続可否、アプリからの接続、ルーティングの適用という3つの条件を個別に確認します。
1. 接続前にローカルポートとテスト範囲を確認
v2rayNはクライアントの操作画面で、実際の接続は起動中のプロキシコアが処理します。サブスクリプションにはノードのアドレス、プロトコル、認証情報が含まれます。システムプロキシは一部のアプリにリクエストをローカルの入口へ送るよう指示し、ルーティングルールはリクエストを直接接続するか、リモートノード経由で転送するかを決めます。どれか1つでも正しく設定されていないと、「ノードを選んだのにWebページが開かない」という状態になります。
初回のトラブルシューティングでは、まずTUNモードをオフにし、システムプロキシを変更しているほかのアプリも終了します。これにより、システムプロキシ経由の通信だけを確認でき、仮想ネットワークアダプターによる通信の横取りでポートやブラウザー設定の問題が見えなくなるのを防げます。以下の数値はテスト用に明示した値であり、測定結果でも、すべての環境におけるデフォルト値でもありません。
「設定」→「パラメータ設定」を開き、インバウンド関連のローカル待受ポートを確認してから、メイン画面下部に表示されるHTTP、SOCKS、または混合の入口と照合します。バージョンによって設定項目の名称や配置が異なる場合があるため、実際に表示されている入口の種類を確認してください。HTTPとSOCKSで待受ポートが異なる場合は、後述の2つのコマンドにもそれぞれ正しいポートを指定します。同じ数値をすべての箇所にそのまま入力しないでください。
2. 接続テストでノードを選び、アクティブサーバーに設定
接続遅延テストでは、通常、指定したノード経由でテスト先へリクエストを送るため、サーバーのTCPポートを確認するだけのテストより実際の利用状況に近い結果が得られます。ただし、確認できるのは「そのノードからそのテスト先まで」の経路が使えることだけです。すべてのWebサイト、プロトコル、継続的なダウンロードが正常に動くことを保証するものではありません。原因を特定しにくくなるため、テスト中はDNS、ルーティング、通信パラメーターを同時に変更しないでください。
-
ノードを確認
メイン画面で、インポートしたサブスクリプショングループを開き、ノード名、アドレス、プロトコルが揃っているか確認します。通信量の説明や有効期限の案内だけが表示された項目は、接続可能なノードとして扱わないでください。
-
複数ノードをテスト
候補のノードをいくつか選択し、右クリックしてテストメニューを開き、「サーバーへの実接続遅延をテスト」を選択します。バージョンによっては、メニュー項目に「複数選択」と表示される場合があります。「実接続」と記載された項目を選び、TCP遅延のみのテストは選ばないでください。
-
候補を再テスト
実接続遅延の列で結果を確認し、正常に応答したノードを残します。候補のノードはさらに2回テストし、タイムアウトが繰り返されないか確認してください。一度だけ記録された最短値で、長期的な安定性を判断しないでください。
-
アクティブサーバーに設定
対象のノードを右クリックして「アクティブサーバーに設定」を選び、メイン画面に表示される現在のサーバー情報を確認します。ノードをテストしただけでは、そのノードが実際の接続先として選ばれたことにはなりません。
-
起動状態を確認
画面下部のログを確認し、コアがすぐに終了していないことを確かめます。待受ポートの競合、設定の解析エラー、未対応のプロトコル項目が表示された場合は、起動時の問題を解決してからブラウザーで確認してください。
3. システムプロキシとグローバルルーティングを個別に設定
Windows版では、メイン画面下部またはタスクトレイの右クリックメニューから「システムプロキシ」→「システムプロキシを自動設定」を選びます。続いてWindowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスとポートがv2rayNのローカルHTTP入口を指しているか確認します。ここにリモートノードのアドレスを入力しないでください。システムプロキシが接続するのは、ローカルで待ち受けているポートです。
システムプロキシとルーティングは別の設定です。前者はアプリからのリクエストをローカルプロキシに送るかどうかを決め、後者はコアに渡されたリクエストの転送方法を決めます。初回の動作確認では、直結ルールの影響を減らすため、一時的に「グローバル」ルーティングを使うと確認しやすくなります。検証後は、普段使うルールベースのルーティングに戻してください。
システムプロキシ＋一時的なグローバルルーティング
おすすめ「システムプロキシ」で自動設定を有効にし、「ルーティング」ではグローバルプロキシ用のプリセットを選びます。両方を設定すると、ブラウザーのリクエストが現在のノードを経由しているか確認しやすくなります。
おすすめの用途：初回接続の確認、ルールベースのルーティングによる影響の切り分け。
システムプロキシ＋通常のルールベースルーティング
アプリはローカルの入口に接続しますが、コアはドメイン名やアドレスなどのルールに応じて、直接接続するかプロキシ経由にするかを選びます。出口確認サイトもルールによって直接接続される場合があります。
おすすめの用途：接続確認後の日常利用。
アクティブサーバーの設定のみ
コアからリモートへの出口は利用可能になりますが、プロキシを設定していないアプリは通常、従来のネットワーク経路で接続します。ステータスバーにノード名が表示されても、ブラウザーが接続できている証拠にはなりません。
おすすめの用途：アプリ内でプロキシを手動設定する場合、またはコマンドラインだけでテストする場合。
ここでいう「グローバル」とは、コアが適用するルーティング範囲を指し、PCの全通信が自動的にプロキシ経由になるという意味ではありません。システムプロキシを使わないアプリ、独自のプロキシを設定したブラウザー拡張機能、一部のUDPリクエストは個別に確認が必要です。この記事のブラウザーでの確認は、システムプロキシに従うHTTP・HTTPSリクエストを主な対象としています。
4. ブラウザーで確認：出口アドレスとアクセスログを照合
信頼できる出口確認サービスを1つ選び、前後の比較には同じサービスを使います。たとえば、ブラウザーのアドレスバーに https://api.ipify.org と入力すると、そのリクエストから見えるグローバルIPアドレスを確認できます。この種のサービスにはアクセス元の出口アドレスが伝わります。サブスクリプションURLや認証情報を含むスクリーンショットを第三者に送らないでください。
- 直結時の基準を記録：TUNをオフにし、ほかのアプリがプロキシを適用していない状態でシステムプロキシを一時的に解除してページを再読み込みし、表示されたアドレスを記録します。
- プロキシ経由の結果を記録：「システムプロキシを自動設定」に戻し、同じアクティブノードを維持したまま、一時的にグローバルルーティングを使って同じページを再読み込みします。
- ログの転送先を確認：現在のログレベルでアクセス記録を確認できる場合は、対象ドメインのリクエストを探し、転送先が直結ではなくプロキシになっていることを確認します。コアによって出力先のラベルが異なるため、実際の設定と照らし合わせて判断してください。
- ブラウザー側の設定を確認：プロキシ管理用の拡張機能や、ブラウザー独自のプロキシ設定を確認します。プライベートウィンドウはキャッシュの影響を減らせますが、拡張機能やプロキシ設定が無効になるとは限りません。
出口アドレスが異なる場合、2つのリクエストが異なる出口を経由した可能性が高いと判断できます。同じアドレスだった場合は、ルーティングルールやアプリの接続設定を引き続き確認してください。それだけでノードが使えないとは判断できません。また、2回のリクエストでIPv4とIPv6がそれぞれ使われていないか確認します。異なるアドレスファミリーの結果は、そのまま比較できません。ブラウザーのキャッシュに古い結果が残る場合もあるため、必要に応じて強制再読み込みして再試行してください。
5. コマンドラインで確認：プロキシ指定と直結を比較
コマンドラインツールがWindowsのシステムプロキシを参照するとは限りません。プロキシアドレスを明示すると、「アプリがシステム設定を参照しているか」という要素を切り離し、ローカルの入口からリモートの出口までの接続を直接確認できます。Windows PowerShellでは、古い環境で curl が別のコマンドに割り当てられて引数の意味が変わるのを避けるため、curl.exe を使用してください。
HTTPプロキシの入口
- プロキシアドレス
127.0.0.1- 例のポート番号
10808- コマンドのオプション
--proxy http://127.0.0.1:10808- 必要な条件
- このポートがHTTPプロキシまたは混合インバウンドに対応している
HTTPSの接続先にはHTTP CONNECTでトンネルを確立します。ローカルの入口にhttpと指定しても、接続先とのTLS通信が無効になるわけではありません。
SOCKSプロキシの入口
- プロキシアドレス
127.0.0.1- 例のポート番号
10808- コマンドのオプション
--proxy socks5h://127.0.0.1:10808- 必要な条件
- このポートがSOCKSまたは混合インバウンドに対応している
socks5hは接続先のドメイン名をプロキシ側で解決するため、curlがローカルで先に名前解決するのを防げます。
ポートを確認したら、以下のコマンドを1つずつ実行します。1つ目はプロキシを使わず、プロキシ環境変数も無視する直結テストです。後の2つはHTTPとSOCKSの入口をそれぞれテストします。ローカルの入口が混合インバウンドでない場合は、該当するコマンドのポートを実際の値に変更してください。以下のコマンドには実測結果は含まれません。返されるアドレスや所要時間は、実行環境の出力を確認してください。
# 直結時の基準：TUNやほかの透過プロキシを無効にして実行
curl.exe -4 --noproxy "*" --connect-timeout 5 --max-time 15 https://api.ipify.org
# HTTPプロキシ：NO_PROXYの除外リストを空にし、指定した入口を必ず使用
curl.exe -4 --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 https://api.ipify.org
# SOCKSプロキシ：接続先のドメイン名をプロキシ側で解決
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 https://api.ipify.org最初の2つのコマンドでは -4 を使い、直結側とローカル接続側でアドレスファミリーが異なる影響を減らします。SOCKSで接続先をリモート解決する場合、最終的な接続先のアドレスファミリーは、プロキシ側の名前解決と経路選択によって決まります。結果に異なるアドレスファミリーが含まれる場合は、ログも確認してください。文字列が同じかどうかだけで判断しないでください。
| 応答の内容 | まず確認する項目 | 次に行う操作 |
|---|---|---|
| ローカルポートへの接続が拒否される | コアが起動していない、またはポートの指定が間違っている | ステータスバーに表示された入口を確認し、待受失敗のログを確認します。 |
| ローカルの入口には接続できるが、リクエストがタイムアウトする | リモートへの接続、接続先への到達性、またはDNS | 実接続テストに成功した別のノードに切り替え、ほかの条件は変えずに試します。 |
| コマンドは成功するが、ブラウザーでは失敗する | システムプロキシ、またはブラウザー側の上書き設定 | システムプロキシを自動設定し直し、プロキシ管理用の拡張機能を一時的に無効にします。 |
| プロキシ経由と直結のコマンドで出口アドレスが同じ | コアのルーティングで直結が選択されている | 一時的にグローバルプロキシルーティングに切り替え、転送先のログを確認します。 |
6. 初回接続でよくある質問
接続テストに成功したのに、Webサイトが開かないのはなぜですか？
テストでは特定の接続先を使用します。ブラウザーがローカルプロキシに接続していない場合や、対象サイト側に個別の接続問題がある場合もあります。まず「アクティブサーバーに設定」されていることを確認し、次に「システムプロキシ」→「システムプロキシを自動設定」を確認します。最後に、プロキシを明示したコマンドで同じ接続先へリクエストし、段階ごとに原因を絞り込みます。
遅延が最も小さいノードが、最速のノードですか？
そうとは限りません。実接続遅延はテストリクエストの完了時間を示すもので、ダウンロード速度を表すものではありません。まず、テストを安定して通過するノードを選び、実際に使うWebサイトに同じ時間帯にアクセスして確認します。一括ダウンロードによる速度測定はサブスクリプションの通信量を消費するため、起動のたびに行う必要はありません。
ログに「address already in use」と表示された場合は？
通常は、ローカルの待受ポートを別のプロセスが使用しています。クライアントを重複して起動していないか確認してください。ポートを変更する必要がある場合は、「設定」→「パラメータ設定」でインバウンドポートを変更し、保存して関連サービスを再起動します。その後、システムプロキシを設定し直し、コマンドラインのポートも更新してください。
VLESSノードに切り替えたとき、プロトコル項目を再入力する必要はありますか？
通常、正しく作成されたサブスクリプションにはサーバーが必要とする項目が含まれています。通信方式、TLS、REALITY、flowのパラメーターをむやみに変更しないでください。未対応の項目に関するエラーが出た場合は、まず使用中のコアがその組み合わせに対応しているか確認し、サブスクリプションの提供元に設定を問い合わせます。項目を変更しても、サーバー側との不一致は解消されません。
クライアントを終了した後にWebページが開かなくなった場合、どうすればよいですか？
まずv2rayNを再起動し、「システムプロキシ」メニューから「システムプロキシを解除」を選びます。クライアントを起動できない場合は、Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」で残っている手動プロキシを無効にし、ほかのプロキシアプリが通信を制御していないか確認してください。
7. 動作確認後、通常のルーティングに戻す
初回接続で確認すべきなのは、ステータスバーにノード名が表示されることだけではありません。ローカルの入口に接続できること、プロキシを明示したリクエストが成功すること、ブラウザーの接続設定が正しいこと、対象リクエストが想定した転送先を通ることを確認します。判断材料を記録しておけば、何度も速度テストを繰り返すより、次回のトラブルシューティングに役立ちます。
- 再テスト済みのノードをアクティブノードとして残し、所属するサブスクリプショングループも記録しておきます。更新後に案内用の項目を誤って選ぶのを防げます。
- 一時的なグローバルルーティングを通常のルールベースルーティングに戻し、よく使うWebサイトを確認します。一部のサイトが直結に戻るのは、ルールどおりの動作です。
- 実際に使用するHTTP・SOCKSポートを記録し、リモートサーバーのポートとローカルの待受ポートを混同しないようにします。
- サポートを依頼する際は、クライアントのバージョン、コアの種類、発生時刻、個人情報を伏せたエラーメッセージを伝えてください。サブスクリプションURL、認証ID、接続情報は必ず隠してください。