03 / PROJECT V · V2FLY · XRAY
V2Rayエコシステム:クライアントとコアの役割
オープンソースはコードとライセンスの公開方法を示すものです。プロトコル対応、設定の互換性、接続結果はそれぞれ個別に確認してください。
「V2Rayクライアント」はGUIツールの総称として使われることがありますが、画面を表示するプログラム、接続を処理するコア、サーバーはそれぞれ別のコンポーネントです。画面側は選択内容を設定に変換し、コアはその設定に従って通信を処理します。サーバー側にも互換性のある設定が必要です。この流れを理解すると、ダウンロード、設定、トラブル対処の確認先を分けられ、あらゆる問題をクライアント自体のせいにせずに済みます。
Project V
プロジェクト名から設定体系へ
Project Vはネットワークプロキシ機能を中心に発展したオープンソースプロジェクト群で、V2Rayはその中でも広く使われているコア実装です。インバウンド、アウトバウンド、ルーティング、DNSなどの設定概念は、エコシステムのツールを理解するための共通語になっています。これらは通信処理の流れを示すもので、特定のサービス事業者を指すわけでも、そのまま使えるサブスクリプションと同じものでもありません。このガイドでは、画面上の項目と設定の意味を結び付けられるよう、これらの構造に沿って解説しています。
接続の流れに沿って読むと理解しやすくなります。まずアプリからローカルのインバウンドへ接続し、コアが接続先の情報を取得します。ルーティングルールがアウトバウンドを選び、そこからリモートへ接続します。DNSは接続先の解決やルール判定に関わり、ログには実行結果が記録されます。すべての設定項目を一つずつ暗記するより、この順序を押さえるほうが実用的です。また、「ローカルポートが開いている」だけではリモートとのハンドシェイク成功を確認できない理由も説明できます。
V2Fly / Xray
共通概念があっても設定項目の互換性は保証されない
V2FlyコミュニティはV2Rayの開発を引き継ぎ、Xrayは関連コードを基盤に分岐して、独自の機能とリリース方針を持つようになりました。設定概念には共通点が多い一方、新しいプロトコル機能、トランスポートのオプション、既定の動作、項目の制約は異なる場合があります。REALITYやXTLSなどの機能を使うときは、利用するコアが実際に対応しているか確認してください。ファイル名がどちらもconfig.jsonというだけで、設定を互換利用できるとは限りません。
クライアントに表示されるプロトコル名は確認の第一歩にすぎません。トランスポート方式、TLSの設定、サーバー名、サーバー側の要件も照合してください。別のコア系統に存在する項目でも、現在のコアが受け付けるとは限りません。設定の読み込みに失敗した場合は、まずログに示された項目と階層を確認します。読み込めても接続できない場合は、双方の設定とネットワーク経路を調べ、構文エラーとハンドシェイクエラーを混同しないようにしましょう。
コアの違いを確認する →
v2rayN / v2rayNG / v2flyNG
3つのオープンソースクライアント、それぞれ異なる画面
v2rayNはデスクトップ向けで、サーバー一覧、サブスクリプショングループ、システムプロキシ、設定管理の機能を備えています。v2rayNGはAndroid向けでXrayコアを使用し、v2flyNGはV2FlyベースのAndroid向けクライアントです。いずれもオープンソースですが、同じプログラムの別スキンではありません。メニューの場所、既定値、インポートできる形式、コアの管理方法は、それぞれのクライアントに合わせて確認してください。
GUIクライアントを使えば、JSONを直接入力する手間は減りますが、サーバーが要求する認証やトランスポートの条件は変わりません。共有リンクをコピーするときは、内容をすべて保持してください。インポート後もプロトコル、アドレス、ポート、トランスポートの設定を確認します。クライアントを切り替える前に、必要な情報をエクスポートしておくと安心です。画面上の既定値をサーバー指定の値と取り違えないようにしましょう。デスクトップとAndroidの間で移行する場合は、システムプロキシとVPNによる通信の取り込み方の違いも確認してください。
LICENSE / SOURCE
ライセンスはコンポーネントごとに確認
オープンソースライセンスは、コードの使用、改変、再配布に関する条件を定めます。クライアント、コア、すべての依存コンポーネントを一つのライセンス名でまとめることはできません。V2RayコアはMITライセンス、XrayコアはMPL 2.0ライセンスです。GUIクライアントや同梱コンポーネントにもそれぞれライセンスがあります。再配布やコードの改変を行う場合は、該当する条件を個別に確認し、必要な表示を残してください。「無料で使える」ことは、条件が一切ないことを意味しません。
ソースコードが公開されていれば、実装を読んで議論できます。しかし、サブスクリプションの入手元、サーバーの動作、端末の設定まで確認できるわけではありません。使用時にはサブスクリプションURLや認証情報を保護し、信頼できる設定だけをインポートしたうえで、スクリプト、証明書、ネットワーク権限の役割を理解してください。このサイトではダウンロード先と設定ガイドをまとめていますが、各コンポーネントのライセンスに代わるものではなく、オープンソースであることを接続結果の保証とするものでもありません。
UPDATE / BACKUP
ソフトウェアの更新とサブスクリプションの更新は別
ソフトウェアの更新ではクライアントや付属コアが変わり、サブスクリプションの更新ではサーバー一覧やグループ情報が変わります。前者は画面の項目、既定値、設定の互換性に影響することがあり、後者はアドレスや接続情報を置き換えることがあります。更新後に問題が起きたら、まずどの層を更新したか記録し、更新前後の差を比較してください。サブスクリプションを取得し直しても、ローカルポートの競合は解決せず、未対応機能がコアに追加されるわけでもありません。
更新前にクライアント設定と必要なカスタムルールを保存し、更新後は以前に使えた個別の設定で接続を確認してください。コアが起動し、基本的な接続ができたら、ルーティング、DNS、TUNなどの組み合わせを試します。クライアントとコアのリリース時期は一致するとは限りません。コアを変更するかどうかは、組み合わせの互換性と実際に必要な機能で判断しましょう。互換性がわからないまま、すべてのコンポーネントを置き換えないでください。
インポートと接続の手順を見る →
DIAGNOSIS / REFERENCE
接続できないときは失敗した段階を特定
まずサブスクリプションを取得できるか確認し、サーバー情報が正しく解析されたかを調べます。次にコアが起動するか、ローカルの待ち受けが確立するかを確認し、最後に接続先へのリクエストを試します。一部のドメインだけ接続できない場合は、名前解決の結果とルーティングの適用先を確認してください。すべてのリクエストが失敗する場合は、選択中のサーバーとハンドシェイクのログを優先して調べます。レイテンシーテストと実際のアプリ通信は同じではありません。テスト結果は特定の方法による一度の測定にすぎず、接続全体の確認に代わるものではありません。
問題を報告するときは、エラー文、操作手順、プロキシモード、使用中のコア名を残し、サブスクリプションURL、認証情報、特定につながるサーバー情報は削除してください。用語がわからない場合は、まずインバウンド、アウトバウンド、サブスクリプション、ルーティングの定義を確認し、実際の設定と照らし合わせましょう。再現に必要な情報がそろいやすくなり、「ブラウザーがプロキシ設定を参照していない」問題を「プロトコル非対応」と誤認することも減らせます。JSONの例を統合する前に、括弧、カンマ、配列の階層、アウトバウンドの参照先も確認してください。
設定と接続に関する用語を見る →