v2rayNにサブスクリプションをインポート済みで、まだ初回接続を完了していない方に向けた内容です。まずノード情報とコアの種類を確認し、実接続遅延テストを実行。その後システムプロキシを有効にし、コアのログ、ブラウザーの出口IP、明示的なプロキシ指定コマンドの3つの観点から結果を検証します。
接続前にノードとローカル設定を確認する
操作のポイント
サブスクリプションの更新に成功しても、クライアントがサーバー設定を取得できただけで、ノードへの接続が完了したわけではありません。ノード一覧にあるアドレス、ポート、プロトコル、通信方式、TLS設定は一体として使用する必要があります。VLESSやVMessなどのプロトコル名は設定の一部にすぎません。あるノードのアドレスと別のノードのポートを組み合わせたり、初回接続前にUUID、フロー制御、SNI、通信パスを不用意に変更したりしないでください。
操作のポイント
この記事では、v2rayN 7.12.5のデスクトップ画面をメニューの参照例にしています。細かなバージョンによって表示文言は多少異なる場合がありますが、確認する手順は同じです。まずサブスクリプショングループを選び、サブスクリプションを更新してから、Coreの種類とローカル待受ポートを確認します。VLESSやRealityの設定では通常Xrayを選択します。既存のVMess、WebSocketノードもXrayで読み込めます。
サブスクリプションを更新
メイン画面の「サブスクリプショングループ」を開き、現在のグループを選択して「現在のサブスクリプションを更新」を実行します。サーバー一覧にノードが表示され、更新日時が古い記録のままになっていないことを確認してください。
コアを選択
「設定」→「パラメーター設定」→「Coreの種類」を開き、一般的なVLESS、VMessノードにはXrayを選択します。保存してメイン画面に戻り、設定が適合しないコアで処理され続けないようにします。
ポートを確認
「設定」→「パラメーター設定」で、ローカルSOCKSの待受ポートを確認します。この記事では10808を例にしています。画面に別の番号が表示されている場合は、以降のコマンドも同じ番号に置き換えてください。
時刻を合わせる
システムの日付、時刻、タイムゾーンを自動同期に設定します。時刻のずれが大きいと、証明書の有効期間を誤判定してTLSハンドシェイクに失敗することがあります。
古いプロキシを終了
同じポートを使用している古いクライアントを終了してから、v2rayNを起動します。1つのポートを2つのプロセスが同時に使用することはできません。ログにaddress already in useと表示された場合は、特にここを確認してください。
実接続遅延で最初のノードを選ぶ
操作のポイント
ノード名に含まれる地域や倍率だけで、利用可能かどうかを判断することはできません。初回接続で最も参考になる指標は実接続遅延です。クライアントがローカルのプロキシコアから実際のリクエストを送信し、プロトコル認証、トランスポート層の確立、TLSハンドシェイクまで行うため、通常のネットワーク層の遅延よりもWebページを開くときの体感に近い結果になります。
操作のポイント
サーバー一覧で同じサブスクリプション内の候補ノードを選択し、右クリックして「サーバーをテスト」から「実接続遅延」を実行します。最初は3～8個程度に絞れば十分で、数百件を一度にテストする必要はありません。結果が186 ms、242 ms、611 ms、タイムアウトだった場合は、まず前2つを試します。500 msを超えるノードでも接続できる場合はありますが、初回表示の応答は通常遅くなります。
通常の遅延
主にこの端末から対象アドレスまでの基本的なネットワーク往復時間を示します。結果は速く出ますが、プロキシプロトコルや暗号化のハンドシェイクまで完了するとは限りません。
適している用途：到達不能なアドレスの早期除外
実接続遅延
おすすめプロキシコアを介して実際に接続するため、ブラウザーでのアクセスに近い結果になります。初回のノード選択で最も参考にしやすい指標です。
適している用途：初回接続のノード選び、日常的なノード切り替え
ダウンロード速度テスト
データを継続的に転送してスループットを確認します。テスト先、回線の混雑、ローカル回線の帯域、ノード側の速度制限の影響を受けます。
適している用途：利用可能なノード間での大容量ファイルの速度比較
| 実接続の結果 | 初回接続の判断 | 次の操作 |
|---|---|---|
| 80～300 ms | 通常は初回候補にできる | アクティブサーバーに設定してプロキシを起動 |
| 300～500 ms | 接続できるが応答は遅めの可能性 | 同じ地域の他のノードと比較 |
| 500 ms超 | 高遅延または回線混雑 | 予備として残し、先にノードを切り替える |
| タイムアウトまたは -1 | テストリクエストが完了していない | ログを確認し、1回の結果だけで削除しない |
操作のポイント
1回のタイムアウトだけで設定が無効だとは判断できません。テスト先が一時的に到達不能、DNS名前解決の異常、ノードによるテスト先の制限、コアの起動直後なども失敗の原因になります。10秒ほど間隔を空けて再試行し、ログでtimeout、connection refused、TLSエラー、DNSエラーのどれかを確認してください。一覧に表示された赤い数値1つより、具体的なエラーの種類のほうが診断には重要です。
ノードとシステムプロキシを起動する
操作のポイント
実接続遅延テストが終わったら、候補ノードをダブルクリックするか、右クリックメニューからアクティブサーバーに設定します。メイン画面では通常、選択状態で現在のノードが示されます。続いてシステムトレイのv2rayNメニューからシステムプロキシモードを選択します。初回検証では、対象リクエストを確実にカバーできるモードを使うのがおすすめです。ルール分岐でテストサイトが直接接続と判定され、「ノードは起動しているのに出口IPが変わらない」と誤認するのを防げます。
操作のポイント
コアの起動とシステムプロキシは別々の状態です。コアを起動すると、127.0.0.1:10808などのローカルポートがプロキシリクエストを受け付けます。システムプロキシを有効にすると、システム設定に従うブラウザーやアプリが自動的にそのポートへ通信を渡します。前者だけを完了した場合、コマンドラインで明示的にプロキシを指定すれば成功しても、ブラウザーは直接接続することがあります。
アクティブに設定
実接続遅延が低いノードをダブルクリックし、現在のアクティブサーバーになったことを確認します。行が選択されているだけでは不十分です。アクティブサーバーが実際に切り替わっている必要があります。
コアを起動
メインウィンドウ下部のステータスとログパネルを確認します。正常に起動すると、ローカルポートの待受に関する情報が表示されます。起動失敗やポート使用中のエラーが連続して出ていないことも確認してください。
プロキシを有効化
トレイメニューを開き、システムプロキシモードを選択します。初回検証中は、ブラウザーに個別設定した古いプロキシを無効にし、リクエストが別のポートへ転送されないようにします。
接続を更新
ブラウザーを完全に終了して再起動するか、プライベートウィンドウを新しく開きます。長時間起動しているプログラムは古い接続を再利用することがあり、ページを更新するだけでは新しいプロキシがすぐに使われない場合があります。
3ステップでプロキシの有効性を確認
操作のポイント
ステータスバーに「実行中」と表示されても、コアプロセスが起動したことしか分からず、対象の通信がノード経由になった証拠にはなりません。信頼できる検証には、ローカルの入口、プロキシの出口、アプリの実際のリクエストをすべて確認する必要があります。次の3ステップでログ、ブラウザー、コマンドラインを照合すれば、「コアが起動していない」「システムプロキシが通信を受け取っていない」「ルーティングルールで直接接続になっている」という3種類の問題を切り分けられます。
コアのログを確認
v2rayNのログパネルを開いた状態で、新しいWebページにアクセスします。新しい接続記録が表示され、リクエストがプロキシの出方向に入ったことを確認できるはずです。timeout、failed to dial、TLS handshake errorが繰り返し表示されていないことも確認してください。
ブラウザーの出口を比較
システムプロキシを無効にした状態で一度パブリック出口IPを記録し、プロキシを有効にして新しいウィンドウから再度確認します。テストドメインがルールどおりプロキシ経由になっていれば、出口IPと通信事業者の所属が変わるはずです。
明示的なプロキシを実行
コマンドラインで127.0.0.1:10808を直接指定し、システムプロキシ設定を介さずにリクエストを送信します。コマンドは成功するのにブラウザー側が変わらない場合は、システムプロキシの適用とブラウザー独自のネットワーク設定を重点的に確認してください。
操作のポイント
WindowsではPowerShellまたはコマンドプロンプトでcurl.exeを使用すると、PowerShellの古い環境にあるコマンドエイリアスによる引数解析の影響を避けられます。macOSとLinuxのターミナルでは通常、そのままcurlを使用します。以下のコマンドではDNS問い合わせもSOCKSプロキシ経由にします。socks5h末尾のhは、接続先ドメインの名前解決をプロキシ側で行うことを示します。
curl.exe --proxy socks5h://127.0.0.1:10808 https://api.ipify.org
curl --proxy socks5h://127.0.0.1:10808 https://api.ipify.org操作のポイント
コマンドがパブリックIPを返せば、ローカルのSOCKS入口がリクエストを受け取り、応答を取得できたことを示します。続いて--proxyを付けない同じリクエストを実行して比較します。2つの結果が異なれば、通常は明示的なプロキシ経路が確立しています。結果が同じ場合は、ノードの出口、ルーティングルール、ログも確認してください。IP文字列だけで結論を出すことはできません。
curl.exe https://api.ipify.org
curl https://api.ipify.org操作のポイント
分流ルールを使用している場合、パブリックIP確認用のテストドメインが直接接続と判定されることがあります。その場合は、ログの出方向タグを確認するほうが正確です。リクエストがdirectやfreedomではなく、プロキシの出方向にマッチしている必要があります。プロキシ経由に明示的に設定した別のテストドメインを選び、ログでドメイン、宛先ポート443、出方向タグが対応しているか確認することもできます。
初回接続に失敗したときの簡易チェック
操作のポイント
トラブルシューティングでは、ノード、コア、ポート、ルーティング、DNSを同時に変更しないでください。一度に1つの変数だけを変更し、変更のたびにコアを再起動して再テストします。最短の手順は、まずローカルポートが待受状態か確認し、次にノードがリモートハンドシェイクを完了できるか確認し、最後にシステムプロキシと分流ルールを調べることです。
実接続遅延がすべてタイムアウトになる場合は？
まずサブスクリプションの更新日時とシステム時刻を確認し、「設定」→「パラメーター設定」→「Coreの種類」でコアを確認します。コアを再起動した後、1つのノードだけをテストし、ログでDNS失敗、接続拒否、ハンドシェイクタイムアウトを切り分けます。
ログにポートが使用中と表示された場合は？
他のプロキシクライアントと古いv2rayNプロセスを終了し、10808がまだ使用中か確認します。パラメーター設定で未使用のポート、たとえば10818に変更することもできます。保存して再起動した後、コマンドラインの引数も同じ番号に変更してください。
コマンドラインは成功するのにブラウザーの出口が変わらない場合は？
明示的なプロキシ指定が成功していれば、ノードとローカルSOCKS入口は基本的に正常です。次にトレイのシステムプロキシモードを確認し、ブラウザー独自のプロキシ設定を無効にしてブラウザーを再起動します。テストドメインがルーティングルールで直接接続になっていないことも確認してください。
1つのノードだけ失敗し、他のノードは正常な場合は？
ローカル環境全体に問題がある可能性は低いでしょう。現在のサブスクリプションを再更新し、失敗したノードのアドレス、ポート、通信方式、TLS、SNI、フロー制御が揃っているか確認します。正常なノードから一部の項目だけをコピーして上書きしないでください。
接続して数分後に突然切断される場合は？
ログパネルを開いたままにし、切断時のエラーと時刻を記録します。複数のノードが同時に失敗する場合は、ローカルネットワークの切り替え、スリープからの復帰、DNSを確認します。現在のノードだけが失敗する場合は、同じサブスクリプション内で実接続遅延が正常な予備ノードに切り替えて比較してください。
| 現象 | 優先して確認する層 | 重要な証拠 |
|---|---|---|
| コアを起動できない | ローカルプロセスとポート | ログに表示される待受失敗、設定解析エラー |
| 明示的なプロキシでもタイムアウトする | ノードとリモートハンドシェイク | DNS、接続、TLS、プロトコルのエラー |
| 明示的なプロキシは成功するがブラウザーは失敗する | システムプロキシとアプリ設定 | ブラウザーのリクエストがコアのログに入っていない |
| 一部のWebサイトだけ直接接続になる | ルーティング分流 | ログに表示されるdirectまたはfreedomの出方向 |
初回接続成功後の設定整理
操作のポイント
3ステップの検証が完了したら、通常のルーティングモードに戻し、もう一度比較テストを行います。中国本土のドメインは直接接続し、それ以外はプロキシ経由にする構成は一般的ですが、実際の動作はルールの順序と出方向タグによって決まります。ルールは通常、上から順に照合されるため、広告ブロック、プライベートアドレス、指定ドメインなど、より具体的なルールを大まかなルールより前に配置してください。
操作のポイント
実接続テストに合格したノードを少なくとも2つ残し、1つをメイン、もう1つを予備にします。ノードを切り替えたら、出口IPとログをもう一度確認してください。同じサブスクリプション内のすべてのノードがまったく同じ通信パラメーターを使っているとは限りません。サブスクリプションを更新するとサーバーから配布されたノード内容で上書きされるため、サブスクリプションのノードを手動変更する前に、本当に必要か確認してください。
- 現在のローカル待受ポート、たとえばSOCKSポート10808を記録しておくと、後で明示的なプロキシテストを実行するときに便利です。
- 実接続テストを3回連続で成功し、遅延が300 ms以内の予備ノードを1つ残します。
- サブスクリプションを更新したら、実接続遅延を再測定します。数日前の速度テスト結果をそのまま使わないでください。
- geosite、geoip、カスタムドメインのルールを変更した後は、ログで実際の出方向タグを確認します。
- 障害が発生したら、まずエラー発生時刻、ノード名、ログの種類を保存してから、層ごとに切り分けます。