サブスクリプションを追加したものの、接続方法がわからないデスクトップユーザー向けです。まず候補ノードを絞り込み、実接続テストで利用できない経路を除外します。その後、ローカルプロキシポート、システムプロキシ、リクエストの出口をそれぞれ確認します。Windows版v2rayNを例に、ノード一覧の数値だけに頼らず、繰り返し使える確認手順を紹介します。
1. インポート後の確認：ノード・コア・ローカルポート
サブスクリプションの更新に成功しても、クライアントがノード設定を取得できたことを示すだけです。アカウントの有効性、サーバーへの接続、ブラウザーのプロキシ利用までは保証されません。まず一覧に実際のサーバー項目があり、サブスクリプショングループ名だけではないことを確認します。次にノードを選択し、対応する設定を読み込みます。接続結果はノードのアドレス、認証情報、トランスポート方式、TLS設定によって決まるため、表示名だけで判断しないでください。
以下では、Windowsデスクトップ版で一般的なメニュー名を使って説明します。バージョンによって項目名が多少異なる場合があります。たとえば「サーバーの実接続遅延をテスト」が「実接続遅延をテスト」と表示されることもあります。既存の設定を変更してメニュー名に合わせるのではなく、機能を基準に操作してください。
-
サブスクリプションを確認
「サブスクリプショングループ」→「サブスクリプショングループの設定」でグループが有効になっていることを確認し、「サブスクリプショングループ」メニューから「すべてのサブスクリプションを更新（プロキシを使用しない）」を実行します。更新ログとノード一覧を確認してください。現在のネットワークからサブスクリプションURLに接続できない場合は、まず取得の問題を解決します。
-
設定値を確認
ノードを選択して右クリックし、「サーバーを編集」を開きます。アドレス、ポート、プロトコル、トランスポートの各設定が同じ設定情報に基づいていることを確認してください。VLESSとREALITYを組み合わせる場合は、公開鍵、サーバー名、shortIdなどもサーバー側の値と一致させ、推測で補わないでください。
-
ポートを確認
「設定」→「パラメーター設定」を開き、ローカルのリスニングポートと関連するインバウンド設定を確認します。HTTPプロキシまたは混合プロキシの実際のポートを控えてください。以下のコマンドではHTTPプロキシに対応する
127.0.0.1:10808を例にしています。実行前に画面に表示された値に置き換えてください。 -
アクティブに設定
ノード一覧を右クリックし、「アクティブサーバーに設定」を選択します。アクティブ表示が対象ノードに移動したことを確認し、設定の読み込み失敗、コアの終了、ポートの競合などがログに出ていないか確認してください。行を選択しただけでは、アクティブノードが切り替わっていない場合があります。
2. ノードの選び方：地域・プロトコル・安定性
まず同じ地域から候補を2〜3台選び、地域やサービス経路を同時に変えることによる影響を抑えます。地理的な近さは候補を絞る目安になりますが、テストの代わりにはなりません。通信事業者間の接続、夜間の混雑、サーバー負荷、中継経路も結果に影響します。ノード名に記載された地域が、実際の出口の所在地とは限りません。
同じ地域の候補ノード
おすすめ対象サイトが求める地域のノードから2〜3台を選び、実接続テストを繰り返します。一度だけ低遅延になるノードより、連続して接続でき、遅延の変動が少ない経路を優先してください。
用途：初回接続、日常の閲覧、基準値の確認
地域指定のノード
利用するサービスが特定の地域を要求する場合は、実際の出口とサイト側の判定を基準にします。遅延が大きくても、設定ミスとは限りません。地域をまたぐ通信経路で通常発生する遅延の可能性もあります。
用途：特定地域からのアクセスが必要なサービス
別プロトコルの候補
メインの経路で接続できない場合は、設定が揃っていてコアが対応する別のノードを比較します。プロトコル名だけで低遅延が保証されるわけではありません。アドレス、経路、トランスポートの組み合わせによって結果は変わります。
用途：特定の経路の問題とローカル環境の問題を切り分ける
サブスクリプションにVLESS + REALITYのノードがある場合、使用中のコアが対応する設定をサポートしているか確認してください。v2rayNでは「設定」→「パラメーター設定」でコアの種類に関する項目を探し、起動ログも確認して実際に読み込まれたコアを特定できます。コアの名前で経路の品質を判断したり、サーバーが指定するセキュリティ設定を別の組み合わせに変更したりしないでください。
- Web閲覧：まず実接続テストが安定して成功するか確認し、ページの初回表示や画像・スクリプトの読み込みもチェックします。
- 継続的なダウンロード：転送を継続したときの速度を別途確認します。低遅延でも転送量が多いとは限りません。サブスクリプションの通信量とテストでの消費に注意してください。
- 地域限定サービス：実際の出口と対象サイト側の地域判定を確認します。ノード名の地域表示は目安にとどめてください。
3. TCPingと実接続テストでわかること
TCPingは通常、ノードのアドレスとポートへのTCP接続にかかる時間を測定します。プロキシ認証、トランスポートのハンドシェイク、対象サイトへのアクセスまでは検証しません。ポートに接続できても、その先のプロキシサービスが利用できるとは限りません。サーバー上の別サービスや前段の接続レイヤーが接続を受け付けている可能性もあります。
実接続テストでは、ノード経由で設定されたテストURLへのアクセスを試みるため、プロキシ経路のより多くの部分を確認できます。「このノード経由でリクエストを接続できるか」に近いテストですが、結果はテストURL、DNS、タイムアウト設定、経路の状態にも左右されます。すべてのサイトにアクセスできることを保証するものではありません。
| テストの種類 | 主な確認内容 | 判断できないこと |
|---|---|---|
| TCPing | ノードのTCPポートへの到達性、接続にかかる時間 | 認証の成否、プロキシ経由のリクエスト完了 |
| 実接続遅延 | ノード経由でテストURLにアクセスした結果と所要時間 | すべてのサービスサイトへの接続可否、継続的なダウンロード速度 |
| ダウンロード速度テスト | 指定されたファイルとテスト時間帯における転送状況 | 長期的な安定性、他の接続先への通信品質 |
おすすめのテスト手順
- 候補ノードを少数選択し、右クリックメニューの「サーバーの実接続遅延をテスト」、または「サーバー」メニューにある同名の機能を実行します。
- 同じテストURLを使い、3回繰り返して成功の有無と遅延の変動を記録します。多数のノードでダウンロードテストを同時に実行しないでください。
- すべて失敗する場合は、「設定」→「パラメーター設定」で実接続テストのURLに関する設定を確認し、テスト先にアクセスできることを確かめてからログを確認します。
- 連続して成功したノードをアクティブサーバーに設定し、実際のアプリで動作を確認します。テスト機能を使うだけなら、システムプロキシを有効にする必要がない場合があります。
一覧に負の値、タイムアウト、空欄が表示された場合は、まず使用中のバージョンの結果説明とログを確認してください。負の値を「遅延が非常に低い」と解釈してはいけません。TCPingは成功するのに実接続が失敗する場合は、認証、TLS、トランスポート設定、テスト先を優先して確認します。両方失敗する場合は、ノードのアドレスとポート、ローカルネットワーク、ファイアウォールを調べてください。
4. システムプロキシの確認：リクエストをローカルポートへ送る
アクティブノードを設定した後は、アプリのリクエストをv2rayNに渡す必要があります。Windowsの「システムプロキシ」は、この設定に従うアプリにプロキシの接続先を提供するもので、すべてのプログラムを自動的に経由させるわけではありません。ターミナルツール、一部のブラウザー拡張機能、単体アプリは独自のプロキシ設定を使うことがあります。
-
システムプロキシを有効にする
v2rayNの下部ステータスバーまたはトレイメニューから「システムプロキシ」→「システムプロキシを自動設定」を選択します。「システムプロキシを解除」になっていないことを確認してください。初回の切り分けでは、システムプロキシを変更する他のプログラムを同時に実行しないようにします。
-
システム設定を確認
Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシがローカルアドレスと正しいポートを指しているか確認します。スクリプト方式を使う場合は、「セットアップスクリプトを使う」の項目も確認してください。手動プロキシのスイッチだけでは判断できません。
-
ポートを個別にテスト
PowerShellで以下のコマンドを実行し、プロキシを明示的に指定します。これにより、ターミナルがシステムプロキシを参照するかどうかに左右されずに確認できます。ローカルポートへの接続に失敗した場合は、まずリスニングポートとコアの状態を確認してください。
-
ブラウザーを確認
ブラウザーがシステムプロキシを使う設定になっていることを確認し、プロキシを上書きする拡張機能を一時的に無効にして、新しいページで対象サイトにアクセスします。コマンドラインでは成功してブラウザーで失敗する場合、サブスクリプションをすぐに変更するのではなく、ブラウザー独自のプロキシルールを確認してください。
curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 15 --head https://example.com/ここでは curl.exe を使用し、PowerShellが curl を別のコマンドとして解釈するのを避けています。--noproxy "" は、このコマンドでプロキシを使わない対象のリストを空にします。この例では、ポートがHTTPプロキシに対応している必要があります。SOCKS専用のインバウンド設定の場合は、--proxy socks5h://127.0.0.1:10808 を使ってください。socks5h は接続先のドメイン名をプロキシ側で名前解決します。
5. 出口IPの確認：システムプロキシとルーティングを切り分ける
システムプロキシはリクエストをクライアントに渡すかどうかを決め、ルールはその後どのアウトバウンドを通るかを決めます。システムプロキシが有効でも、日本国内のサイトなどがルールにより直接接続されることがあります。そのため、直接接続に設定されたサイトを使ってプロキシの故障を判断したり、ページが開けるだけで出口が変わったと判断したりしないでください。
以下では同じHTTPSアドレスを使い、直接接続とプロキシ経由のリクエストを比較します。このAPIはリクエスト元のグローバルIPを返します。確認用の接続先ですが、アクセス可否はネットワーク到達性やサービスの稼働状況にも左右されます。利用できない場合は、信頼できる別の出口IP確認サービスを使い、前後で同じ接続先を指定してください。
# プロキシを使わずに直接リクエスト
curl.exe --noproxy "*" --connect-timeout 10 --max-time 15 https://api.ipify.org
Write-Output ""
# ローカルのHTTPまたは混合プロキシポートを明示してリクエスト
curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 15 https://api.ipify.org
Write-Output ""- プロキシ経由と直接接続で出口が異なる：2回のリクエストでグローバルIPが変わっています。クライアントのログも確認し、プロキシリクエストが想定したアウトバウンドを通ったことを確かめてください。
- 2回とも出口が同じ：対象ドメインが直接接続にルーティングされていないか、別のネットワークプロキシが動作していないか、アクティブノードの切り替えが完了しているかを確認します。この結果だけでノードの故障とは判断できません。
- 直接接続は失敗し、プロキシ経由は成功：プロキシ経路に到達できることは確認できますが、直接接続の出口を比較できていません。ログと対象サイトの結果もあわせて判断してください。
- コマンドは成功するが、ブラウザーの出口が異なる：ブラウザー拡張機能や独自のプロキシ設定を確認し、ブラウザーが同じ確認用ドメインにアクセスしているかも確かめてください。
ルーティングの影響を切り分けるには、まず現在のルーティングモードを記録します。次にv2rayNの「ルーティング」で、通常の宛先リクエストをプロキシのアウトバウンドに送るグローバルルールを一時的に選択し、再度確認します。項目名はバージョンやカスタムルールによって異なるため、ルールの内容とログに表示されるアウトバウンドのタグを基準にしてください。確認が終わったら、元のルーティングルールに戻します。
6. 初回接続でよくある問題と確認手順
TCPingでは数値が出るのに、実接続がタイムアウトするのはなぜ？
まず同じノードの認証情報、トランスポート方式、TLSサーバー名、コアの対応状況を確認し、テストURLにアクセスできるか確かめます。TCP接続を受け付けるのは確認の前半にすぎず、プロキシのハンドシェイクに失敗すると実接続はタイムアウトします。
実接続は成功したのに、Webページが開けないのはなぜ？
まずプロキシを明示したコマンドを実行し、次に「システムプロキシ」→「システムプロキシを自動設定」とブラウザーの設定を確認します。特定のサイトだけ失敗する場合は、そのドメインのルーティング、DNS、サイト側の応答を確認してください。すべてのノードが使えないと決めつけないようにします。
ログにローカルポートの競合が表示された場合は？
netstat -ano | findstr :10808 で使用状況を確認し、タスクマネージャーで該当PIDのプログラムを特定します。クライアントを二重に起動していないか確認してください。ポートを変更する場合は「設定」→「パラメーター設定」で変更し、システムプロキシとテスト用コマンドも同じ値に更新します。
遅延は低いのにダウンロードが遅いのは、速度テストが不正確だから？
遅延は1回のリクエストにかかる時間を示し、スループットは回線帯域、混雑、サーバー、ダウンロード先によって決まります。同じ時間帯、同じ接続先で2つのノードを比較し、複数の速度テストを同時に実行しないでください。サブスクリプションの通信量にも注意します。
ノードを切り替えても出口IPが同じなのは、切り替えに失敗したから？
異なる入口が同じ出口を共有している場合があります。まずアクティブサーバーの表示と新しいリクエストのログを確認し、新規リクエストでテストしてください。ブラウザーの既存の長時間接続はすぐに切り替わるとは限りません。ルールが直接接続に一致している場合は、ノードを変更してもそのリクエストの出口は変わりません。
再利用できる接続記録を残す
初回接続後、ノード名、プロトコルとトランスポートの組み合わせ、ローカルのリスニングポート、テスト先、ルーティングモード、テスト日時を記録します。後から問題が発生したときに同じ手順で再テストすれば、ノードの変化、ローカル設定の変更、対象サイトの障害を切り分けやすくなります。
- まずローカル環境：コアが動作しているか、ポートが待ち受けているか、アクティブサーバーが正しいかを確認します。
- 次に通信経路：実接続テストが成功するか、プロキシを明示したリクエストに応答があるかを確認します。
- 最後にアプリ：システムプロキシ、ブラウザー設定、ルーティングの適用先、実際の出口が想定どおりか確認します。
- ログを共有する前に：サブスクリプションURLや認証情報などの機密設定を隠し、問題の特定に必要なエラー部分だけを残してください。