V2Fly公式サイト
v2rayN クライアント

Project Vから並行して保守されるコアファミリーへ

Project VはV2Ray設定体系の基本構造を築きました。インバウンドは本機の通信を受け取り、アウトバウンドは転送先を定義し、routingはその間で照合を行い、dnsとlogは名前解決と実行記録を提供します。V2FlyコミュニティはV2Ray Coreと関連仕様を継続的に保守し、Xrayは同じ技術的系譜から独立したコアとして発展しました。共通する設定概念は多いものの、具体的なフィールド、プロトコル拡張、リリースのペースには違いがあります。

したがって、「クライアントが特定の共有リンクに対応していること」と「現在のコアが対応するパラメータを完全に処理できること」は別の判断です。GUIクライアントはサブスクリプションを解析して設定を生成し、プロセスを管理できますが、実際にプロトコルのハンドシェイク、ルーティング、転送を行うのはコアです。サーバー側のパラメータが変わった場合は、画面にサーバー名が表示されるかだけでなく、クライアントの解析能力とコアの対応範囲を同時に確認してください。

オープンソースライセンスと公開協業

v2rayN、v2rayNG、v2flyNG、および関連するコアは、いずれもオープンソース方式で保守されています。ソースコード、設定形式、変更履歴は各プロジェクトで公開管理され、機能の議論、修正、互換性の調整はメンテナーとコミュニティ参加者によって継続的に進められています。オープンソースであるため、開発者は設定の生成方法を理解しやすく、上級ユーザーもログやフィールド定義から挙動の違いを特定できます。

コンポーネントごとに採用するオープンソースライセンスが異なる場合があります。ライセンスが定めるのはコードの複製、変更、再配布の方法であり、すべてのクライアントを同じチームが保守していることを意味しません。ドキュメントを読む際は対象を明確にしてください。v2rayNのメニュー手順をモバイルクライアントにそのまま適用したり、Xrayの拡張フィールドがすべてのV2Fly設定で使えると仮定したりしないようにします。コンポーネントごとの説明を参照すると、概念の混同を減らせます。

更新の仕組みと互換性の判断

クライアントの更新には、通常、UIの変更、サブスクリプション解析、設定生成の修正、コア管理機能が含まれます。一方、コアの更新はプロトコル実装、転送動作、ルーティング、DNSに重点が置かれます。「更新前は使えたのに更新後に異常が出た」場合は、まず変わったのがクライアント、コア、サブスクリプションのどれかを記録し、その後ログを段階的に確認します。複数のコンポーネントを同時に置き換えると、結果に影響した変数を特定しにくくなります。

日常の保守には一定の順序を設けると便利です。まずサブスクリプションを更新してノード一覧を確認し、次に既知の設定を起動し、最後にプロキシモードとルーティングを調整します。長期利用するルールについては、目的、条件、出口タグを記録しておきます。そうすればUIのメニューが変わっても、特定のボタンの位置に頼らず設定の意味から従来の動作を再現できます。