設定の階層ごとに用語を確認できます。まずクライアントとコアを区別し、通信の入口、転送ルール、ドメインの名前解決先を順に見ていきましょう。
プロトコルは通信方式と認証方式を定め、トランスポートとセキュリティ層は接続の運び方と保護方法を決めます。同じプロトコルでも異なるトランスポートを組み合わせられるため、名称が同じでも各パラメーターの確認が必要です。
Project Vのエコシステムで使われるプロキシプロトコルで、ユーザー認証とデータ暗号化の仕組みを備えています。クライアントとサーバーでユーザーIDや接続パラメーターを一致させる必要があり、端末の時刻が大きくずれていると認証に影響することもあります。問題の切り分けでは、プロトコルのパラメーター、トランスポート方式、セキュリティ層を個別に確認してください。特定のトランスポート方式をVMessそのものと混同しないようにしましょう。
軽量なプロキシプロトコルで、アプリケーションデータ自体は暗号化しません。通常はTLSやREALITYなどのセキュリティ層と組み合わせます。設定時はユーザーID、トランスポート方式、セキュリティ層のパラメーターを確認してください。プロトコル名だけでは互換性を判断できません。一部のフロー制御オプションには、特定のコアやトランスポートが必要です。サーバー側の説明がないまま追加しないでください。
通常はTLSで安全な接続を確立し、パスワードで認証するプロキシプロトコルです。パスワードが正しくても接続できるとは限りません。サーバーアドレス、ポート、サーバー名、証明書の信頼設定も一致させる必要があります。証明書関連のエラーが発生したら、検証を無効にするのではなく、まずドメイン名と端末の時刻を確認してください。
所定の暗号方式と鍵情報を使ってプロキシ通信を行うプロトコルです。クライアントとサーバーが同じ暗号方式に対応している必要があります。世代の異なる方式は、同じパスワードを設定しても相互接続できません。読み込み後に方式がサポートされていないと表示された場合は、ルーティングモードを何度も切り替えるのではなく、選択中のコアの対応範囲と元の設定を確認してください。
Xrayエコシステムのセキュアなトランスポート方式です。単独のノードサブスクリプション形式ではなく、VLESSと同じものでもありません。接続時は通常、公開鍵、サーバー名、short IDなどを確認します。必要な項目はサーバーの設定によって異なります。インポート用リンクをクライアントが認識できても、現在選択中のコアが対応機能を備えているとは限りません。
Project Vはエコシステムの背景、V2FlyとXrayはコアの系統、v2rayNなどは操作画面を指します。それぞれの階層を把握すると、変更すべき場所を判断しやすくなります。
V2Rayなどのネットワークツールを取り巻くオープンソースプロジェクトや技術エコシステムを指す呼称です。特定のGUIクライアントや、ノード・サブスクリプションを提供するアカウントサービスを指すものではありません。情報を読む際は、エコシステムの歴史、コアの機能、個々のクライアントの機能を分けて理解し、ある一つの説明をすべてのプログラムに当てはめないようにしましょう。
V2Rayの開発を引き継ぐコミュニティプロジェクトで、代表的なプロキシコアの系統の一つです。コアはインバウンド、アウトバウンド、ルーティング、DNSなどを処理し、GUIはクライアントが提供します。v2flyNGはV2Flyコアをベースにしています。使用前に、読み込むプロトコルとパラメーターがそのコアの対応範囲内か確認してください。
V2Rayの技術体系から派生したオープンソースのコアで、複数のプロキシプロトコルと関連トランスポートに対応しています。XrayとV2Flyには共通する概念もありますが、追加機能、設定項目、対応範囲は完全には一致しません。v2rayNGはXrayコアを使用します。特定のプロトコルに関する問題を調べる際は、クライアント名だけでなく、実際に動作しているコアを確認してください。
クライアントはサブスクリプションの追加、ノードの選択、設定変更を行う操作画面で、コアは実際のネットワーク接続を処理するプログラムです。v2rayN、v2rayNG、v2flyNGはGUIクライアントの名称であり、3種類のプロキシプロトコルではありません。画面上では起動していても接続できない場合は、コアのログも確認してください。選び方の違いはクライアント比較をご覧ください。
サブスクリプションは設定を配布し、ノードは接続パラメーターを保持します。テスト結果は特定の時点でのリクエストの状態を示します。それぞれ、提供元、設定内容、測定結果に対応します。
サーバー設定をまとめて取得・更新するためのURLやデータです。通常は利用中のサービス提供元から案内されます。サブスクリプションを更新すると設定内容は変わりますが、自動更新や回線の修復、サーバー側の状態変更が行われるわけではありません。サブスクリプションURLにはアカウントを特定できる情報が含まれる場合があります。機密情報として扱い、スクリーンショットやログを共有する前に認証情報を削除してください。
GUIクライアントで、サーバーへの接続設定一式を指すときによく使われる呼称です。通常はアドレス、ポート、認証情報、トランスポートのパラメーターを含みます。ノード項目が必ず独立した物理サーバーを表すとは限らず、表示名だけで実際の出口の場所を特定することもできません。項目を変更する前に設定の提供元を記録しておきましょう。同じ項目への変更は、サブスクリプションの更新で上書きされる場合があります。
設定の提供元や用途ごとにサーバー項目を整理する、クライアントの管理方法です。サブスクリプションの個別更新、一覧の絞り込み、提供元の確認に役立ちますが、負荷分散やフェイルオーバーの設定が自動で作成されるとは限りません。重複する項目がある場合は、削除する前に所属グループとサブスクリプションの提供元を確認し、手動で保存した設定を誤って消さないようにしてください。
特定のテストにかかった時間で、意味はテスト方法によって異なります。TCP接続テスト、リクエストテスト、プロキシ経路全体のテストでは、それぞれ測定する段階が異なるため、目的を考慮せずに結果を比較することはできません。数値が小さくてもダウンロード速度が速いとは限りません。タイムアウトが発生した場合は、宛先、ネットワーク状況、ログもあわせて確認してください。
一部のクライアントで、プロキシ経由で指定のテスト先へアクセスするのにかかった時間を指します。サーバーのポート確認だけの場合より実際のリクエスト経路に近い測定ですが、テスト先、DNS、ハンドシェイク、測定時のネットワーク状況にも左右されます。同じテスト条件でノードを選ぶ際の参考にはなりますが、動画の読み込み速度やファイルのダウンロード帯域を直接推測することはできません。
接続の特徴を照合してから、対応するアウトバウンドを選びます。ルールが参照するデータ、照合順序、アウトバウンドタグがすべて必要です。ここでの説明は概念を示すもので、そのまま読み込める設定ではありません。
ドメイン、IP、ポート、インバウンドタグなどの条件に基づいて、接続先のアウトバウンドを選ぶ設定です。一般的なフィールドルールは上から順に評価され、最初に一致したルールで通信の行き先が決まります。そのため、ルールの順序とアウトバウンドタグが重要です。ルールを追加する前に照合対象と出口を決め、より広い条件が上にあって接続を先に拾わないか確認してください。
条件に応じて接続ごとに異なるアウトバウンドを使うことです。たとえば、直接接続、プロキシ経由、ブロックに振り分けます。振り分けは通信がコアに入った後に行われるため、アプリの通信をローカルプロキシに取り込む入口の設定を代替するものではありません。「全般」や「中国本土を回避」などのモード名は、通常、あらかじめ設定されたルーティングポリシーを示します。具体的な動作は、クライアントが現在生成しているルールで確認してください。
ルーティングルールでの照合に使う、カテゴリ別のIPアドレス一覧です。geoip:privateはプライベートネットワークなどのアドレス範囲を照合する際によく使われます。収録内容は使用するルールデータによって異なります。地理カテゴリはデータ上の分類であり、実際のサービス提供場所を保証するものではありません。ドメインの接続でIP照合が行われるタイミングは、ドメイン解決の方針にも左右されます。
ルーティングルールでドメインを照合するための、カテゴリ別ドメイン一覧です。geosite:cnなどはデータ内のカテゴリを参照する記述であり、リアルタイムの地理情報検索やDNSの結果ではありません。使用前に、対応するデータが存在し、参照先のカテゴリが含まれていることを確認してください。カテゴリデータの更新によって、その後の照合結果が変わる場合もあります。
コアが接続を宛先へ送るために使う出口設定です。プロキシプロトコル、直接接続、ブロックなどを指定できます。ルーティングでは通常、アウトバウンドタグを使って行き先を選びます。タグは設定上の識別子であり、変更できないプロトコル名ではありません。ルールにproxyと指定した場合は、対応するアウトバウンド定義が必要です。タグだけを変更しても、新しい接続機能は作成されません。
アプリの通信がプロキシに入るか、ドメインをどこで名前解決するか、接続が最終的にどこから出るかは、それぞれ別の問題です。異常が起きたときは複数の設定を同時に切り替えるより、各層を順に確認すると原因を特定しやすくなります。
ドメインをIPアドレスなどのレコードに変換するネットワークの名前解決システムです。OS、アプリ、プロキシコアがそれぞれ名前解決を行う場合があり、どれか一つの設定を変更しても、すべてのリクエストが同じ経路で名前解決されるとは限りません。問題の切り分けでは、まずクエリを送信するプログラム、リゾルバーのアドレス、クエリのアウトバウンドを確認してから、キャッシュや暗号化DNSなどの設定を調べてください。
仮想ネットワークインターフェースで通信を受け取り、適切なネットワーク処理コンポーネントに転送する方式です。通常、システムプロキシより多くのアプリをカバーできますが、対象範囲はルーティング、権限、実装方法、アプリの動作によって異なります。有効にする際はDNSの制御やローカルネットワークへのアクセスも確認してください。グローバルプロキシと同じ意味のスイッチではありません。
アプリに内部マッピング用の合成IPアドレスを返し、後続の接続時に対応するドメインへ復元する仕組みです。ドメイン情報の保持に役立ちますが、DNSの制御、マッピング用アドレス範囲、通信の入口を連携させる必要があります。合成アドレスはWebサイトの実サーバーのアドレスではありません。マッピングを復元するコンポーネントを経由せずに接続すると、アクセスできない場合があります。
DNSクエリが想定した名前解決経路を外れ、別のリゾルバーに処理される状態です。リークに該当するかどうかは想定するポリシーに基づいて判断します。直接接続による名前解決をすべて異常とみなすことはできません。確認時は、ブラウザー独自の名前解決、システムDNS、コアのDNS、クエリのアウトバウンド経路をあわせて調べてください。テストページに表示されるリゾルバー名だけでは原因を特定できません。
OSにローカルプロキシのアドレスとポートを登録し、その設定に従うアプリで利用する方式です。すべてのプログラムの通信がプロキシに送られるわけではなく、コアに入った後の接続を直接接続にするかプロキシ経由にするかも自動では決まりません。クライアントを終了した後もブラウザーが停止中のローカルポートを参照していると、ネットワークに接続できない場合があります。システムプロキシが元の設定に戻っているか確認してください。