v2rayN
v2rayNはWindows、macOS、Linux向けのGUIクライアントで、サブスクリプションのインポート、ノード選択、システムプロキシ、TUN、ルーティング、ログ確認などに対応します。クライアント自体は主に設定管理と操作画面を担い、実際のプロトコル接続は選択したコアが処理します。問題を調べる際は、画面設定、生成された設定、コアの実行状態を分けて確認してください。
クライアント画面、サブスクリプション、詳細設定で頻出する技術用語をまとめて解説します。各項目では概念の範囲、設定場所、実際の役割を説明し、チュートリアルの読解や接続トラブルの切り分けに役立つ情報を提供します。
クライアントはGUI、サブスクリプション、システム設定を担当し、コアは設定の解析、接続の確立、ルーティングの実行を担います。両者を区別すると、バージョン選びやトラブルの切り分けが明確になります。
v2rayNはWindows、macOS、Linux向けのGUIクライアントで、サブスクリプションのインポート、ノード選択、システムプロキシ、TUN、ルーティング、ログ確認などに対応します。クライアント自体は主に設定管理と操作画面を担い、実際のプロトコル接続は選択したコアが処理します。問題を調べる際は、画面設定、生成された設定、コアの実行状態を分けて確認してください。
v2rayNGはAndroid向けのGUIクライアントで、通常はXrayコアを使って接続を処理します。サブスクリプションや単一の共有リンクをインポートでき、現在の接続に対するルーティング、DNS、対象アプリの範囲も設定できます。端末の省電力設定、バックグラウンド制限、VPN権限も継続動作に影響します。
v2flyNGもAndroidで使われますが、主にV2Flyコアを採用しています。対応するコア実装や、既存のV2Fly設定を必要とする環境に適しています。v2rayNGとv2flyNGの選択は、画面の名称だけでなく、ノードのプロトコル、設定項目、コアの互換性に基づいて判断してください。
XrayはProject Vエコシステムに属するコアの一つで、プロトコルのハンドシェイク、トランスポート層、セキュリティ層、DNS、ルーティング規則を処理します。クライアントは画面上の設定をコアが読み取れる形式へ変換し、対応するプロセスを起動します。利用できるプロトコル項目は、クライアントとコアの両方のバージョンが対応しているかで決まることが多いです。
V2Flyはコミュニティによって継続的に保守されているProject Vのコア実装で、設定の読み込み、インバウンドとアウトバウンドの確立、ルーティングを処理します。Xrayと一部の概念や設定構造を共有しますが、機能、項目、デフォルト動作は異なる場合があります。設定をインポートする前に、クライアントが使うコアの系統を確認し、別のコア専用パラメーターをそのまま流用しないようにしてください。
プロトコルはクライアントとサーバーが接続情報を交換する方法を定め、トランスポート層とセキュリティ層はデータの運搬方法と保護方法を定めます。3者は異なる設定階層にあるため、同じ名称として扱わないことが重要です。
VMessは識別情報と時刻検証の仕組みを備えたプロキシプロトコルで、サーバーアドレス、ポート、ユーザー識別子、トランスポート方式などを設定します。クライアントとサーバーの主要パラメーターを一致させる必要があり、端末の時刻が大きくずれていると認証に失敗することもあります。VMessはプロトコル層の名称で、実際の接続にはTCPやWebSocketなどのトランスポート設定も必要です。
VLESSは比較的軽量な構造のプロキシプロトコルで、トランスポートの安全性をTLSやREALITYなどの独立した機構に任せることが多いです。アドレス、ポート、ユーザー識別子に加え、フロー制御、トランスポートの種類、セキュリティ層の項目も確認する必要があります。VLESSという名称だけでは互換性を判断できず、組み合わせ全体を項目ごとに一致させなければなりません。
TrojanはTLSの利用方法を前提に設計されたプロキシプロトコルで、サーバーアドレス、ポート、認証情報、証明書に対応するドメイン名などを設定します。接続できない場合は、プロトコル認証の失敗、TLSハンドシェイクの失敗、ドメイン解決の失敗を分けて確認してください。症状は似ていても、ログに現れるエラー段階は通常異なります。
REALITYはXrayエコシステムで使われるトランスポートセキュリティ機構で、VLESSと組み合わせることが多いです。クライアント側では通常、サーバー名、公開鍵、ショートID、フィンガープリントなどを設定し、サーバー側の値と対応させます。REALITYはノード名でも単独のGUIクライアントでもなく、接続のセキュリティ層で機能します。
トランスポート層は、プロキシプロトコルのデータをどの接続方式で運ぶかを示します。一般的な方式にはTCP、WebSocket、gRPC、HTTP系トランスポートがあります。方式によってパス、ホスト名、サービス名など必要な項目が異なります。ノードをインポートした後に方式の認識を誤ると、アドレスと認証情報が正しくても接続できません。
サブスクリプションは一括更新に使われ、ノードは1件の接続設定を表します。速度測定の結果は、特定のテスト条件における値にすぎません。データの出所を理解して初めて、更新、絞り込み、切り替えが反映されたか判断できます。
サブスクリプションは、サーバーが提供しクライアントが定期的に読み込むノード一覧の入口です。更新すると通常は内容を再取得し、クライアントの規則に従ってノードを追加、上書き、整理します。サブスクリプションURL自体は接続可能なノードではなく、クライアントが具体的な設定へ解析して初めて選択して使えるようになります。
ノードはクライアント内の1件のサーバー接続設定で、通常はサーバーアドレス、ポート、プロトコル、認証パラメーター、トランスポート方式、セキュリティ設定を含みます。ノード名は識別用であり、接続品質を決めるものではありません。利用できるかどうかは、ログ、実接続テスト、実際のアクセス結果を組み合わせて判断してください。
共有リンクは、単一ノードの主要パラメーターを特定のリンク形式にエンコードしたもので、1件の設定をすばやくインポートするために使われます。プロトコルごとにリンク構造は異なり、複雑なルーティングやDNS設定は単一リンクに含まれない場合があります。インポート後は、アドレス、ポート、トランスポート、セキュリティ項目が正しく認識されているか確認してください。
遅延は1回の検査リクエストが往復するまでの時間です。ただし、クライアントによってTCP検査、プロトコルハンドシェイク、対象へのアクセスなど方法が異なります。検査値が低くてもダウンロード速度が高いとは限らず、回線の安定性だけで判断することもできません。比較する際は検査方法と対象をそろえてください。
実接続遅延は、実際にプロトコル接続を確立するかテスト対象へアクセスして所要時間を記録するため、単なるポート確認よりクライアントの実利用に近い指標です。DNS、ハンドシェイク、トランスポート層、対象からの応答の影響を受けます。ポート検査は正常なのに実接続に失敗する場合は、認証とトランスポートのパラメーターを確認してください。
ルーティング規則はマッチングを担当し、アウトバウンドは処理を実行します。規則の順序、ドメインの解決方法、データファイルの状態によって最終的な判定結果は変わります。
ルーティング規則は、ドメイン、IP、ポート、ネットワーク種別、プロトコル、プロセスなどの条件に基づき、トラフィックをどのアウトバウンドへ渡すか決めます。複数の規則がある場合、通常は設定順に判定し、最初に一致した規則を実行します。規則を変更したら設定を保存し、対応するコアを再起動して古い実行設定が残らないようにしてください。
ルーティング分岐は、異なる宛先やアプリのトラフィックを直接接続、プロキシ、ブロック、カスタムアウトバウンドへ振り分ける処理です。単独のプロトコルではなく、複数のルーティング規則で構成される処理方針です。設計時はまずデフォルトの出口を決め、範囲の明確な例外規則を追加して、規則同士の重複を減らします。
GeoIPはIPアドレスの地域や用途別に整理されたマッチングデータで、ルーティング規則からカテゴリを参照できます。ユーザーが入力したドメインではなく、接続先のIPを対象に照合します。ドメインを先に解決してIPを判定する規則では、DNSの結果とドメイン方針も最終判定に影響します。
GeoSiteはカテゴリ別に整理されたドメイン集合で、クライアントやコアがルーティング規則から該当カテゴリを参照できます。ドメインを1件ずつ管理する手間を減らせますが、カテゴリの内容はデータのバージョンによって変わります。想定と異なるドメイン判定になった場合は、カテゴリ名、データファイル、規則の順序を確認してください。
アウトバウンドは、トラフィックがコアを離れる際に使う処理の出口を示します。一般的にはプロキシ接続、直接接続、ブロックなどがあります。ルーティング規則は出口を選ぶだけで、実際にサーバー接続を確立するのは対応するアウトバウンド設定です。詳細設定では複数のプロキシアウトバウンドを作成し、規則ごとに呼び出すこともできます。
DNSはドメイン解決の経路を決め、システムプロキシとTUNはトラフィックがクライアントへ入る方法を決めます。接続は正常なのにルーティングだけが不安定な場合は、この層を個別に確認してください。
DNSはドメインをIPアドレスへ変換する基礎ネットワークサービスです。V2Rayクライアントはシステムリゾルバーを使うことも、コアに設定したリモートまたはローカルのリゾルバーへ問い合わせを渡すこともできます。解決結果は実際の接続先だけでなく、GeoIP、ドメイン規則、FakeDNSの判定にも関わります。
DNSリークは、ドメイン問い合わせが想定した経路で処理されず、設定外のリゾルバーへ渡る状態です。アプリが独自に暗号化DNSを使う、システムプロキシがDNSを取り込まない、TUNの規則範囲が不足している、DNS設定の優先順位が競合していることなどが原因になります。確認時は、アプリ、OS、クライアントのコアがそれぞれどの経路を使っているかを分けて調べてください。
TUNモードは仮想ネットワークインターフェースで広範囲のシステムトラフィックを受け取り、クライアントのコアへ渡してルーティングを実行します。システムプロキシ設定を自動的に読み取らないアプリに適していますが、OSの許可と正しいルーティング・DNS設定が必要です。有効化後にLANアクセスや名前解決に問題が出た場合は、まず除外範囲とDNSの取り込み設定を確認してください。
FakeDNSはアプリにマッピングアドレスを返し、コア内にそのアドレスと元のドメインの対応関係を保存します。アプリが後からマッピングアドレスへ接続しても、コアは元のドメインに基づいてルーティング判定を行えます。TUNモードと組み合わせることが多い一方、アドレスプールの範囲や除外規則を誤るとLANや特定アプリに影響する場合があります。
システムプロキシは、プロキシサーバーのアドレスをOS設定に登録し、その設定に従うアプリが自発的にリクエストをクライアントへ渡す方式です。設定は簡単で、ブラウザーやシステムのネットワークインターフェースを使う多くのソフトに適していますが、すべてのアプリの通信を自動的に対象にできるわけではありません。特定のプログラムがシステムプロキシを使わない場合は、アプリ側の設定を確認するか、必要に応じてTUNモードを検討してください。