サブスクリプションの更新が完了した後のノード一覧から始め、通常の遅延テストと実接続遅延テストの違いを整理します。そのうえで一括の実接続テストで使えるノードを絞り込み、最後にアプリの状態・出口 IP・目的のサイトという 3 段階でプロキシが有効かを確認します。v2rayNG をインストールし、サブスクリプションは読み込んだもののまだページを開けていない方向けの内容です。
サブスクリプション読み込み後、ノード一覧の読み方
サブスクリプションの更新が完了すると、メイン画面の一覧の各行が 1 つのノード設定になります。左側が備考、右側がテスト結果の欄で、初期状態では空か前回のテスト値が表示されます。備考はサーバー側から配信され、一般的には地域名と連番の組み合わせです。これはあくまで名前であり回線品質を示すものではないため、重複や文字化けがあっても異常ではありません。
ノード項目の右側のメニューを開くと「編集」「共有」「実接続遅延をテスト」が表示されます。上部メニューにはグループ全体を対象にした一括テストもあります。初回接続では 1 つずつ開いて当たりを引くようなことはせず、まず一括テストを 1 回行い、実際に使える数件まで絞り込みましょう。
- 名前:回線の識別用。重複や文字化けがある場合は備考を優先
- プロトコル:VMess、VLESS、Trojan、SS の 4 種類が一般的
- 転送方式:TCP、WebSocket、gRPC など。CDN 経由かどうかを左右する
- テスト結果:遅延のミリ秒数、または「タイムアウト」「失敗」の表示
一覧が空の場合や、サブスクリプションを更新しても項目数が変わらない場合は、まず「サブスクリプション」に戻って購読 URL が有効か、更新時にエラーが出ていないかを確認してください。サブスクリプション自体が失効していると、テストはすべてタイムアウトになります。
実接続遅延テスト:不通のノードを除外する
v2rayNG には 2 種類のテストがあります。通常の遅延テストはサーバーのアドレスとポートに対して TCP の往復を 1 回行うだけで、数値が良くてもハンドシェイクできるとは限りません。実接続遅延テストはプロトコルのハンドシェイクを完了させ、さらに検出用アドレスへリクエストを送り、ハンドシェイクと初回バイトまでの所要時間を一覧に書き戻します。初回接続では実接続の結果を基準にしてください。
一括実行の入口は上部メニューの「すべての設定の実接続をテスト」、個別のノードは項目メニューの「実接続遅延をテスト」です。テスト中はネットワークを安定させ、同時にノードを切り替えないでください。テスト中の項目が中断され、無効な値になります。
結果の読み取りは次の表に沿って行います。タイムアウトと失敗では対処が異なるため、一律に再テストしないでください。
| 一覧の表示 | 意味 | 対処 |
|---|---|---|
| 2 桁から 3 桁のミリ秒 | ハンドシェイクが完了し、検出リクエストに応答あり | そのまま使用 |
| タイムアウト timeout | ハンドシェイクまたは検出リクエストに応答なし | 同じグループの別ノードに切り替え、ローカルネットワークの問題も切り分ける |
| 失敗 failed | ハンドシェイク段階で拒否された | サブスクリプションを再更新し、パラメータをサーバー配信の値に戻す |
| 数値が普段より明らかに高い | 回線の混雑、またはローカルネットワークの変動 | 数分おいて再テストしてから判断する |
一通り終わったら、遅延が低くタイムアウトしていないノードを選び、そのうち 1 つを有効にします。残りの使用可能なノードは予備として一覧に残しておけばよく、すべて有効にする必要はありません。クライアントは同時に 1 つの設定しか使わないため、複数を有効にしても意味がありません。
プロキシ反映の確認:状態・出口 IP・目的のサイト
ノードを選んだら、次の 5 ステップを順に確認します。各ステップには明確な確認ポイントがあるので、感覚に頼る必要はありません。
ノードを有効化
一覧でテストに合格したノードをタップします。通知バーに接続状態が表示されればコアは起動しています。
コアのログを確認
「設定」→「パラメータ設定」でログレベルを「情報」に変更し、再接続して起動行を確認します。
出口 IP を比較
まずプロキシをオフにし、出口 IP 確認ページで直通の IP を控えます。次にプロキシをオンにして同じページを再読み込みします。
目的のサイトを開く
普段プロキシがないとアクセスできないサイトを使い、経路が本当に通っているか確認します。
使える組み合わせを記録
ノード名、ルーティングモード、アプリ別プロキシの状態を記録しておき、ネットワーク環境を変えたときに優先的に再利用します。
ログに次の 2 行が出ていれば、コアが起動しローカルポートも確保されています。この 2 行がない場合は、コアが起動していないかポートが使用中の可能性が高いので、まず「設定」→「パラメータ設定」でローカルポートを変更してから再接続してください。
[Info] transport/internet/tcp: listening TCP on 127.0.0.1:10808
[Info] transport/internet/tcp: listening TCP on 127.0.0.1:10809出口 IP の比較ではルーティングモードに注意してください。ルーティングモードで「LAN と中国本土をバイパス」を選んでいる場合、中国本土のサイトへのアクセスはもともとプロキシを通らないため、出口 IP が変わらないのは想定どおりの動作です。確認には海外のサイト、または海外の IP 確認ページを使ってください。ルーティングモードは「設定」→「ルーティングモード」で切り替えます。
目的のサイトでの確認は最後に行います。出口 IP は変わったのに目的のサイトが開けない場合は、多くの場合 DNS 解決かルーティングの問題です。まず「設定」→「アプリ別プロキシ」でブラウザが除外されていないか確認し、次に「ドメイン解決ポリシー」が現在のネットワークと競合していないか確認してください。
ノードパラメータの確認:プロトコルと転送方式のフィールド
サブスクリプションで読み込むノードのパラメータはサーバー側から配信されるため、通常は手動で変更する必要はありません。失敗したノードを調べるときは、ノードの編集画面を開き、配信されたフィールドと照らし合わせて読み込みに誤りがないか確認できます。
VLESS + Reality
- 転送方式
- TCP
- Flow
- xtls-rprx-vision
- フィンガープリント
- chrome
- 公開鍵とショート ID
- サブスクリプションから配信
サブスクリプションの読み込みで自動入力されます。いずれかのフィールドを手で変更するとハンドシェイクに失敗します。
VMess + WebSocket + TLS
- 転送方式
- WebSocket
- パス
- /ws
- 暗号化
- auto
- Host と SNI
- 証明書のドメインと一致
CDN 経由の場合、Host と SNI は証明書のドメインと一致している必要があります。
フィールドがサブスクリプションと一致していない場合、たとえばパスや SNI を手動で変更していると、実接続はそのまま失敗します。対処は、このノードを削除してサブスクリプションを再更新し、パラメータをサーバー配信の値に戻すことです。項目ごとに推測しないでください。
パラメータを手動で入力する必要があるのは 1 つのケースだけです。サーバーが共有リンクのみを提供し、サブスクリプションがない場合です。このときは「クリップボードから読み込み」を使い、共有リンクをそのまま貼り付けるとクライアントがフィールドを解析します。
初回接続のよくある質問
以下は初回接続の段階で最も多く見られる問題です。いずれも考え方は同じで、まずどの層が通っていないかを特定し、それから設定を触ります。
実接続テストがすべてタイムアウトする場合は?
まず端末のネットワークで普通にページが開けるか確認し、次にサブスクリプションが有効期限内か確認します。特定のグループだけがすべてタイムアウトする場合は、別のグループでテストし、必要なら別の回線に切り替えてサブスクリプションを更新してください。
速度テストの遅延は低いのにページが開けない?
実接続が通ったのは、ハンドシェイクと検出リクエストが成功したことだけを示します。「設定」→「アプリ別プロキシ」でブラウザが除外されていないか、ルーティングモードで目的のドメインが直通になっていないかを確認してください。
接続しても出口 IP が変わらない?
まず通知バーの接続状態が正常か確認します。ルーティングモードが「LAN と中国本土をバイパス」の場合、中国本土のサイトへのアクセスがプロキシを通らないのは想定どおりなので、海外のサイトや海外の IP 確認ページで再確認してください。
ノードを切り替えるたびに速度テストが必要?
サブスクリプションを更新するとノード項目はリセットされるため、もう一度一括テストを行うことをおすすめします。日常的にノードを切り替えるときは、テスト済みの項目をタップするだけでよく、繰り返しテストする必要はありません。
通常の遅延と実接続遅延が大きく違うのは正常?
正常です。CDN 経由のノードでは、通常の遅延はエッジノードまでしか測れませんが、実接続はオリジンまでの経路を通ります。両者に数十ミリ秒の差が出るのはよくあることです。