VMess、VLESS、Trojan、SS、REALITYの選び方

1. プロトコル選定の基本：設定を階層に分けて考える

プロトコル名だけでは接続構成全体を表せない

クライアント一覧に表示されるVMess、VLESS、Trojan、Shadowsocksは、まずアプリケーション層のプロキシプロトコルを示します。実際の接続には、アドレスとポート、ユーザー認証情報、トランスポート方式、セキュリティ層、ドメイン名、必要に応じたパスなども含まれます。プロトコル名だけを比較しても、2つの設定を置き換えられるか、接続速度が速いかは判断できません。たとえばVLESSは通常のTCP上でも動作し、TLS、WebSocket、gRPC、REALITYと組み合わせることもできます。これらはハンドシェイク、証明書要件、データのカプセル化、クライアント対応範囲がそれぞれ異なります。

選定時は、1つの設定を4つの層に分けて考えます。第1層はプロトコルと認証で、VLESSのUUID、Trojanのパスワード、Shadowsocksの暗号化方式とパスワードなどです。第2層はデータを運ぶトランスポート方式で、TCP、WebSocket、gRPCなどが該当します。第3層はセキュリティと本人確認で、標準TLSやREALITYなどです。第4層はクライアントとコアで、v2rayN、v2rayNG、v2flyNGが画面上の項目をXrayやV2Flyが読み取れる設定へ変換します。どこか1つでも一致しなければ、接続直後の切断、ハンドシェイクのタイムアウト、インポート後の項目欠落として現れることがあります。

好みではなく、既存の設定から始める

クライアント利用者が受け取るのは、通常すでにパラメータが決まった共有リンクやサブスクリプションです。この場合、最初に新しそうなプロトコルを選んで元の設定を書き換えるのではなく、まずサーバー側のプロトコルとトランスポートの組み合わせを確認し、それを完全に認識できるクライアントとコアを選びます。サーバーがVMessならクライアントもVMessとしてインポートします。サーバーがVLESSとREALITYなら、VLESSに対応するだけでなく、公開鍵、短い識別子、フィンガープリント、サーバー名などのREALITY項目を保存できなければなりません。クライアントのプルダウンだけを変更しても、サーバー側の機能は変わりません。

サーバーとクライアントの両方を選べる場合は、互換性の範囲、設定の複雑さ、端末性能、保守コストの順に検討します。複数のクライアントで共有するなら、各環境で安定して解析できる組み合わせを優先します。Xray専用機能を使う場合は、すべての端末が対応するXrayコアを実行していることを確認してください。性能の低い端末では、不要な多重カプセル化を避けます。ここでいう「シンプル」とは、項目や経路の階層が少なく、切り分けの境界が明確であることを指し、どのネットワークでも必ず速いという意味ではありません。

2. VMess、VLESS、Trojan、Shadowsocksの設計上の違い

VMess：完全な認証構造と時刻の一致が必要

VMessはProject V初期のプロトコル体系から生まれ、1つのプロトコルでユーザー認証、リクエスト情報の伝達、データ保護を行うことを目指しました。設定では通常UUIDをユーザー識別子として使い、追加のプロトコルハンドシェイク構造も含みます。VMessはV2FlyとXrayの両方で長年にわたる互換性の基盤があるため、古いサブスクリプションや既存環境で今も広く使われています。古い設定を維持したい場合、サーバー側をすぐに変更できない場合、複数端末ですでに動作確認済みの場合は、新しい名前だけを理由に移行するよりVMessを使い続ける方が安全です。

VMessの認証では、クライアントとサーバーの時刻が許容範囲内で一致している必要があります。端末の時刻、タイムゾーン、自動時刻合わせに問題があると、アドレスとポートが正しくても認証に失敗することがあります。切り分けでは、まずシステムの自動時刻設定を戻し、UUID、alterIdの互換項目、トランスポートパラメータを確認します。現在の設定では通常、古いalterId設計に依存する必要はありませんが、過去のサブスクリプションをインポートすると項目が残っている場合があります。クライアントに項目が表示されることは、サーバーが同じ古い方式で動作していることを意味しません。移行時はサーバーの現行設定を基準にしてください。

VLESS：プロトコルの役割を絞り、機能を組み合わせで実現

VLESSはXrayエコシステムの主要プロトコルの1つで、プロトコル自身が担うデータ暗号化の役割を減らし、通信の安全性をTLS、REALITYなど明確なセキュリティ層に委ねる設計です。VLESSはUUIDなどでユーザーを識別しますが、単独ですべての安全性を担う閉じた方式とは考えないでください。実際の構成では、トランスポート方式とセキュリティ層を合わせて記述します。たとえばVLESS over TCP with TLS、VLESS over TCP with REALITYなどです。

この役割分担により、VLESSはXrayのflowなどの機能と組み合わせやすく、重複処理も減らせます。一方で、項目間には明確な制約があります。サーバーにflowが設定されていなければ、クライアント側で勝手に追加できません。REALITYを使う場合は公開鍵、短い識別子、サーバー名を同時に指定する必要があります。標準TLSでは、証明書の本人情報に基づいてドメインを確認します。VLESSの強みはXrayの機能構成と明確な階層設計にあり、「VLESSを選ぶ」だけですべての経路が改善するわけではありません。

Trojan：パスワード認証と標準TLSの組み合わせ

Trojanは通常、パスワードをユーザー認証情報として使い、TLSで安全な接続を確立します。仕組みは比較的明快で、クライアントがTLSサーバーへ接続し、その後プロトコル層で認証情報と宛先情報を送ります。設定で重要なのはパスワードだけではありません。ドメイン名、サーバー名、証明書の検証、ポートが一貫している必要があります。アドレスだけを別のホストに置き換えたり、元のサーバー名を残したり、必要なセキュリティ項目を無効にしたりすると、元の本人確認ロジックが崩れることがあります。

Trojanは複数のコアエコシステムで対応基盤があり、標準TLSの既存設定を使い、パラメータ構造を分かりやすく保ちたい場面に適しています。ただし、任意のTLSサービスと同じ意味ではなく、通常のHTTPSアドレスをそのままTrojanノードとして使うこともできません。インポート後は、セキュリティ項目がTLSのままか、SNIが欠落していないか、パスワードが途中で切れていないかを確認してください。サブスクリプション変換ツールが「アドレス、ポート、パスワード」だけを残してトランスポート項目を落とした場合、一覧に表示されても元の設定を再現していません。

Shadowsocks：軽量な構造と暗号化方式の一致

ShadowsocksはSSと略されることが多く、主要項目はサーバー、ポート、暗号化方式、パスワードです。VLESSやVMessのように階層の多い構成と比べ、基本的なShadowsocks項目は少なく、設定を理解しやすい傾向があります。性能は暗号化方式、実装、プロセッサの命令セット、経路品質によって変わります。新しいAEAD暗号化方式はデータの機密性と完全性を明確に提供しますが、クライアントとサーバーで方式名とパスワードを完全に一致させる必要があります。

Shadowsocksエコシステムには、さまざまな拡張やプラグインの組み合わせがあります。基本的なSS対応だけで特定の拡張まで使えるとは限らず、サブスクリプションのインポートに成功しても拡張項目が保持されるとは限りません。v2rayNやAndroidクライアントでは、項目の編集画面で暗号化方式、プラグインパラメータ、トランスポートの追加項目を確認してください。3つのクライアント間で設定を移行するなら、基本項目の方が一致しやすく、特定プラグイン付きの項目は端末ごとに検証が必要です。「プロトコル互換」と「拡張互換」は分けて記録しましょう。

3. トランスポート方式、TLS、REALITY：組み合わせと項目の境界

TCP、WebSocket、gRPCはどのようにデータを運ぶか

トランスポート方式は、プロトコルデータを下位の接続にどう載せるかを決めます。TCPは追加のカプセル化が少なく、パラメータも比較的限定されます。WebSocketはHTTPアップグレードの上で双方向データを運び、設定ではパスやHostがよく使われます。gRPCはHTTP/2の仕組みに基づき、サービス名や多重化に関する設定が主な項目です。これらはクライアントの好みだけで切り替えられる「速度モード」ではなく、サーバーも同じトランスポートとパラメータで待ち受ける必要があります。WebSocketの設定をTCPに変えても、通常は同等の構成にはなりません。

トランスポート層が性能に与える影響は、ハンドシェイク回数、カプセル化の負荷、接続の再利用方式、中継ネットワーク機器の動作から生じます。短時間の接続を大量に行う場面では接続確立のコストが目立ち、長時間の大容量通信では経路品質、輻輳制御、サーバー負荷の方が重要になることがあります。WebSocketのパスは1文字単位で一致させ、gRPCのサービス名も省略できません。クライアントのHost、SNI、アドレスは似て見えても役割が異なります。アドレスはサーバーの所在、Hostはアプリケーション層のリクエスト情報、SNIはTLSハンドシェイクで使うサーバー名です。

標準TLS：証明書の本人情報とサーバー名

TLSは上位プロトコルに暗号化された通信路とサーバー認証を提供します。設定内のサーバー名は通常、証明書で検証できる名前と一致させます。一方、接続先アドレスはドメイン名を使うことも、特定の設定では別のアドレスを使うこともあります。クライアントが証明書検証を行う場合、有効期限、信頼チェーン、名前の一致を確認します。証明書エラーが出たら、まずシステム時刻、SNI、ドメイン名の綴り、サーバー証明書を確認してください。検証を無効にするのは通常の解決策ではありません。元の本人確認条件が変わってしまうためです。

ALPNはTLSハンドシェイク時にHTTP/2やHTTP/1.1など上位プロトコルを交渉するために使われます。手動入力が必要かどうかは、トランスポートの組み合わせとサーバー設定によって決まります。サブスクリプションにALPNが含まれている場合は元の値を保持してください。明確な指定がないのに「項目が多い方がよい」と考えて追加するのは避けます。クライアントで複数選択できても、サーバーがすべて受け入れるとは限りません。同様に、フィンガープリントはTLSクライアントのハンドシェイク特性を示す実装項目であり、使用するコアとサーバー構成に適合させる必要があります。

REALITY：Xrayのセキュリティ層と必須パラメータ

REALITYはXray体系のセキュリティ層機能で、通常はVLESSなどと組み合わせます。独立したプロキシプロトコルではないため、クライアントで項目を作成するときもプロトコル種別はVLESS、セキュリティ項目はREALITYと表示されることがあります。主なパラメータはサーバー名、公開鍵、短い識別子、クライアントフィンガープリントで、組み合わせによってはflowも使います。公開鍵はクライアントがREALITYサーバーの本人性を検証するため、短い識別子はサーバー側設定との照合のため、サーバー名はハンドシェイクの意味付けに使われます。サブスクリプション変換でどれか1項目でも欠落すると、ハンドシェイクが完了しないことがあります。

公開鍵とUUIDは異なる役割を担います。UUIDはVLESSのユーザー認証、REALITYの公開鍵はセキュリティ層での本人確認に使われ、互いに置き換えられません。短い識別子は通常、指定形式の16進文字列で、長さと使用可能な値はサーバーが決めます。クライアントではそのまま保存し、勝手にゼロを補ったり、大文字・小文字の構成を変えたりしないでください。サーバー名もメモ欄の名前ではなく、サーバー設定に適合する必要があります。v2rayNでREALITY項目を編集するときは、プロトコル、アドレス、ポート、ユーザーID、security、SNI、publicKey、shortId、fingerprint、flowの順に確認します。

{
  "protocol": "vless",
  "address": "server.example.com",
  "port": 443,
  "id": "00000000-0000-4000-8000-000000000001",
  "network": "tcp",
  "security": "reality",
  "serverName": "www.example.com",
  "publicKey": "サーバーから提供された値に置き換えてください",
  "shortId": "1a2b3c4d",
  "fingerprint": "chrome",
  "flow": "xtls-rprx-vision"
}

上の断片は項目間の階層を示すためのもので、直接接続できるノードではありません。実際の値は対応するサーバー設定から取得してください。クライアント画面では日本語の項目名になっている場合も、「トランスポート設定」「TLS設定」「REALITY設定」など複数のパネルに分かれている場合もありますが、項目の意味は変わりません。共有リンクのパラメータ名は省略形になっていることもあります。たとえばpbkは公開鍵、sidは短い識別子、fpはフィンガープリントに対応します。手動で比較するときは、まず項目の対応関係を整理してから欠落を確認してください。

4. 接続速度、リソース消費、モバイル端末のバッテリー

プロトコルのオーバーヘッドは総所要時間の一部にすぎない

体感速度は、名前解決、ネットワークの往復時間、ハンドシェイク、サーバー負荷、回線の混雑、トランスポートのカプセル化、端末側の処理によって決まります。プロトコルが影響するのはその一部だけです。2つの設定でプロトコルだけでなくサーバーの場所、出口負荷、経路品質も異なる場合、速度測定だけでプロトコルの優劣を証明することはできません。信頼できる比較には、サーバー、ポート経路、測定時刻、対象リソース、クライアントバージョンをできるだけ揃え、接続確立時間、継続転送、失敗時の再試行を繰り返し観察します。

基本的なTCP通信はアプリケーション層のカプセル化が少ない傾向にありますが、すべての環境で最低遅延になるとは限りません。WebSocketとgRPCは対応するプロトコル処理を追加し、接続の再利用や中継経路の動作も変えます。TLSとREALITYにはハンドシェイクと暗号計算がありますが、現代のデスクトップCPUなら通常は素早く処理できます。低消費電力のモバイル端末では、安定した接続を維持するよりも、切断と再接続を頻繁に繰り返す方が消費電力を増やしやすい傾向があります。不要な再試行を減らし、システム時刻を正しく保ち、誤った名前解決を避ける方が、1回の暗号処理の差を議論するより実用的です。

CPU、メモリ、接続数

リソース消費はプロトコル名だけで順位付けできません。コアは接続状態、ルーティングルール、DNSキャッシュ、ログ、必要に応じてTUNネットワークスタックを管理します。クライアント画面では、サブスクリプション更新、一覧表示、統計表示も実行されます。大量の同時接続、複雑な正規表現ルール、詳細すぎるログ、頻繁なヘルスチェックは、CPUのウェイクアップ回数とメモリ使用量を増やします。基本的なShadowsocksは項目が少なく処理経路を理解しやすい構成です。VLESSもシンプルなトランスポートと組み合わせれば追加負荷を抑えられますが、多重トランスポートや複雑なルーティングではより多くの状態管理が必要です。

デスクトップでリソース消費を確認するときは、v2rayNのGUIプロセスとCoreプロセスを分けて考えます。画面側のメモリ増加が必ずしもプロトコルコアの問題を示すわけではなく、その逆も同様です。まず自動更新と追加チェックを停止し、同じ設定で再測定すると、バックグラウンド処理の影響を判断できます。ログレベルは通常利用時には必要な情報に絞り、切り分け時だけ一時的に詳細化して、終了後に戻してください。アクセスログを常時完全に記録すると、ディスク書き込みと処理負荷が増え、本当のエラー行も見つけにくくなります。

Android端末のバッテリー消費を判断する

Androidのv2rayNGやv2flyNGは、通常システムVPNインターフェースを通じて通信を処理します。バッテリー消費は暗号化だけでなく、ネットワーク接続の維持、アプリの通信量、無線ネットワークの切り替え、DNSリクエスト、バックグラウンド起動からも発生します。画面を消すと再接続が頻発する場合は、まずクライアントのバックグラウンド実行制限、ネットワーク切り替え、サブスクリプション自動更新の頻度を確認してください。不安定な経路を残したままプロトコルだけを変えても、再接続による消費電力は通常解決しません。

TUNまたはVPNが通信を処理する範囲も処理量に影響します。端末上のすべてのアプリ通信をクライアントに通すと、コアが処理する接続数が増えます。システムの機能と実際の用途に応じて、不要なバックグラウンドアプリの通信を減らせば総処理量を抑えられます。ルーティングルールが過度に大きかったり、名前解決を必要とするルールが大量に含まれたりすると判定コストも増えますが、通常規模では最初に疑うべき要因ではありません。切り分けは、接続が安定して継続するか、再試行ループがないか、ログレベル、自動更新、DNS、ルーティングの順に確認し、最後にプロトコル構成を比較するのが効果的です。

プロトコルの選択では、安定性、互換性、保守コストを優先し、性能データは条件を揃えた場合の補助材料として扱います。既存のVMess設定が長期間安定しているなら、VLESSへの移行は緊急ではありません。REALITYや特定のXray flowが必要なら、コアの更新と全端末の互換性確認を移行計画に含めてください。異常なリソース消費は、ヘルプセンターの障害分類も参考に切り分け、プロトコル、DNS、ルーティング、システムプロキシを同時に変更して比較基準を失わないようにします。

5. V2FlyとXrayコアファミリーの関係

共通の起源と独自の発展

V2FlyとXrayはいずれもProject Vエコシステムの設定思想とマルチプロトコルのプロキシ機能を受け継いでいるため、VMess、一部のVLESS、Shadowsocks、ルーティングルール、アウトバウンド構造には似た概念が見られます。その後は別々の開発方針を歩んでおり、機能追加、項目の意味、実装の細部が常に同期しているわけではありません。共通の起源は基本設定の構造が似ている理由を説明しますが、すべての拡張機能を2つのコア間で完全に置き換えられることまでは意味しません。

XrayはREALITY、XTLS Visionなどの機能をより集中的に発展させ、Xrayクライアントエコシステムで対応する項目を形成しています。V2Flyは独自のリリース、プロトコル実装、機能方針を維持しています。一般ユーザーにとって重要なのは、基本的なVMess、Shadowsocks、標準トランスポート設定はコアをまたいで移行しやすい場合がある一方、Xray専用のセキュリティ層、flow、特定の拡張項目を含む設定ではXray Coreを明示的に選ぶべきという点です。設定ファイルを解析できても、構文上成立するだけで、実行時の意味まで一致するとは限りません。

3つのクライアントとコアの位置付け

v2rayNは当サイトがデスクトップ向けに第一に推奨するクライアントで、Windows、macOS、Linuxに対応し、サーバー一覧、サブスクリプショングループ、ルーティング設定、システムプロキシ、Coreの種類を管理するGUIを提供します。REALITYを含むVLESS設定では、v2rayNで対応するXray Coreを選び、インポート後のセキュリティ項目が揃っていることを確認してください。複数のサブスクリプション、細かなルーティング、システムプロキシをデスクトップで一元管理する場合、v2rayNの集中管理型の設定が適しています。

v2rayNGはAndroidでXrayの機能路線を採用するクライアントで、デスクトップのv2rayNとVLESS、REALITYなどのXray設定を共有するのに適しています。v2flyNGはV2Flyコアファミリーを主な位置付けとし、対応するVMess、Shadowsocks、その他の互換設定に向いています。名前は似ていますが、画面上の項目が似ているだけで機能が同じとは判断できません。サーバー項目がXray専用項目に依存する場合はv2rayNGを優先し、V2Flyの動作や既存のV2Fly設定を基準にする場合はv2flyNGを選びます。

設定互換性を判断する3つの層

互換性は、構文、機能、動作の3層に分けて判断します。構文互換は、JSON項目や共有リンクを認識できることです。機能互換は、コアが対応するプロトコル、トランスポート、セキュリティ層を実際に実装していることです。動作互換は、同じ設定でDNS、ルーティング、接続再利用、エラー処理が期待どおりになることを意味します。移行問題の多くは、第1層を第3層と誤認することで起きます。たとえばインポートツールが項目を生成できても、未対応項目を見落とし、接続時になって初めて問題が表面化することがあります。

設定ファイルを移行するときは、アウトバウンドのタグ、ルーティング参照、DNS構造にも注意が必要です。プロトコルノードが使えても、元のルーティングルールをそのままコピーできるとは限りません。ルール内のoutboundTagは実際に存在するアウトバウンドタグを指す必要があります。DNSの問い合わせ方針やドメイン解決モードも、振り分けの判定に影響します。GUIクライアントでは、まずクライアント画面から設定を作成またはインポートし、現在のCoreに合う構造を生成させてください。特定の項目を確認する必要がある場合だけ、設定を書き出して読み取り専用で比較します。

xray run -test -config ./config.json

上のテストコマンドは、インストール済みのXray Coreに設定構文を確認させるためのもので、実際の接続テストの代わりにはなりません。コマンドが成功しても、アドレスに到達できる、認証情報が正しい、安全層のハンドシェイクが成功するとは限りません。v2rayNでは通常、ログからCoreの起動結果を確認できます。手動コマンドは未知の項目、JSON構造、タグ参照の誤りを特定するのに適しています。テストにはクライアントが実際に生成した一時設定のコピーを使い、稼働中の設定ファイルを変更しないでください。

6. サブスクリプション形式、共有リンク、項目の互換性

サブスクリプションは設定の容器であり、プロトコルではない

サブスクリプションURLは複数のノードやクライアント設定を返すためのもので、サブスクリプション自体がVMessやVLESSなどのプロキシプロトコルというわけではありません。1つのサブスクリプションに複数のプロトコル項目を含めることも、特定のクライアントが認識できる構造を使うこともできます。「サブスクリプション更新成功」と表示されても、クライアントがリクエストと基本解析を完了しただけです。項目数、プロトコル種別、メモ、トランスポート、セキュリティ項目が揃っているかも確認してください。一覧が空の場合は、URLへのアクセス失敗、返却内容が空、非対応形式、グループの絞り込みミスを分けて確認します。

よくある共有リンクは、vmess://、vless://、trojan://、ss://などプロトコル方式で始まります。方式ごとにパラメータの構成は異なります。VLESSとTrojanのリンクは、クエリパラメータにトランスポート、セキュリティ層、SNI、フィンガープリントなどを含めることがあります。VMessの古い形式では、JSON項目群をエンコードしてリンクに埋め込むことが多く、Shadowsocksリンクでは暗号化方式、パスワード、アドレス、ポートが中心で、プラグイン項目が追加される場合もあります。コピー時の切り詰め、エスケープの変化、QRコードの読み取り欠落は、項目の欠落につながります。

汎用サブスクリプションとクライアント専用形式

いわゆる汎用サブスクリプションは、複数行の共有リンクやエンコードされたリンクの集合です。構造が分かりやすく、複数のクライアント間で渡しやすい一方、複雑なルーティング、DNS、クライアント専用のポリシーを完全に表現するのは困難です。クライアント専用設定にはグループ、ルール、画面オプションを含められますが、別のクライアントへ移行するとノード本体しか保持できないことがあります。形式を選ぶ前に、サーバー項目だけを同期するのか、ルーティングとDNSの方針まで移行するのかを決めてください。

v2rayN、v2rayNG、v2flyNGで端末間の設定を共有する場合は、各クライアントが対応するノード項目をサブスクリプションに含め、ルーティングは各クライアントで個別に管理するのが最も安全です。デスクトップのシステムプロキシ、AndroidのシステムVPN、アプリ単位の振り分けは仕組みが異なります。クライアント設定一式を1つのサブスクリプションに無理にまとめると、意味のずれが生じやすくなります。ノードサブスクリプションはアドレス、プロトコル、トランスポートを担当し、端末側でプロキシ接続、DNS、ルーティングを管理する方が切り分けやすい構成です。

サブスクリプション変換の利点と情報損失

サブスクリプション変換では、ある容器形式を別の形式に整理したり、名前変更、絞り込み、グループ化を行ったりできます。ただし、変換先が元の項目を表現できる場合に限って無損失になります。VLESS REALITY項目ではsecurity、SNI、publicKey、shortId、fingerprint、flowを保持する必要があります。WebSocketではpathとHost、gRPCではserviceNameが必要です。変換先のテンプレートに対応項目がない場合、ツールはエラーを報告せず項目を無視することがあります。

変換結果を確認するときは、ノードのメモだけを比較しないでください。各プロトコルから少なくとも1つずつ無作為に選び、編集画面を開いてプロトコル、アドレス、ポート、認証項目、トランスポート、セキュリティ層、拡張項目を確認してから接続テストを行います。元のサブスクリプションと変換後のサブスクリプションは別グループに入れ、同名ノードで上書きされないようにします。すべてのプロトコルが正しく動作すると確認してから、普段使うグループを切り替えてください。変換後にVLESSはインポートできるのにREALITYだけ失敗する場合は、何度も更新するのではなく、まずセキュリティ層の追加項目を確認します。

更新、上書き、ローカル変更

サブスクリプションのノードは通常、リモートの内容で管理されます。クライアント内でサブスクリプション項目を直接変更しても、次回更新時に元の値へ戻ることがあります。長期的に保持したいカスタム設定は、独立したローカル項目やクライアントが対応する上書きルールに保存してください。変更前に項目を複製してメモを変えておくと、比較用の基準を残せます。システムプロキシ、ルーティングモード、アクティブグループを調整するだけなら、通常はクライアントのローカル状態なので、ノードのプロトコル項目を変更する必要はありません。

サブスクリプションの更新に失敗したら、まずURLが完全か、対象グループが有効かを確認し、次にクライアントログのHTTPステータス、解析エラー、証明書エラーを確認します。サブスクリプションURLを「サーバーを手動追加」のアドレス欄に貼り付けたり、単一の共有リンクを定期更新できるサブスクリプションだと誤認したりしないでください。詳しい手順ははじめにのサブスクリプションインポート手順を参照してください。一覧が空になる問題やグループ選択については、ヘルプセンターも確認できます。

7. v2rayN、v2rayNG、v2flyNGでプロトコル選択を設定に反映する

v2rayN：まずCore、次にノード編集画面を確認

v2rayNはデスクトップ向けの主要な選択肢です。ノードをインポートしたら、まず設定でCoreの種類を確認し、その後サーバー編集画面で項目を確認します。VMessではユーザーID、トランスポート方式、セキュリティ項目を重点的に確認します。VLESSではencryption、flow、REALITYまたはTLSの画面まで確認します。Trojanではパスワード、TLS、サーバー名、Shadowsocksでは暗号化方式とパスワードを確認します。クライアント一覧のメモは識別用で、プロトコル認証には使われません。メモが正常に表示されても、設定全体が正しいとは限りません。

接続を有効にする前に、ノード設定とシステムプロキシ設定を分けて考えます。アクティブサーバーの選択はCoreが使うアウトバウンド設定を決め、システムプロキシは対応アプリのリクエストをクライアントへ渡すかどうかを決めます。ルーティングルールは、プロキシ、直接接続、その他の設定済み出口のどれを使うかを決めます。3つは連続するものの、それぞれ別の段階です。ノードテストに失敗したらまずプロトコルログを見ます。ノードは接続済みなのにアプリが通信を引き継がない場合はシステムプロキシを確認し、一部のドメインや経路だけが想定外の場合にルーティングを確認します。

v2rayNG：共有リンクの全パラメータを確認

v2rayNGでVLESS REALITYリンクをインポートしたら、設定詳細を開き、セキュリティ種別、SNI、公開鍵、短い識別子、フィンガープリント、flowがすべて存在することを確認します。QRコードやクリップボードから取り込んだ後に空の項目があれば、元の共有内容に戻って確認し、別のノードから勝手にコピーしないでください。公開鍵と短い識別子は各サーバーに紐づいているため、見た目が似ていても使い回せません。VMessでは端末時刻とトランスポート項目、Shadowsocksでは暗号化方式を重点的に確認します。

Androidの接続ボタンはシステムVPNによる通信処理を開始するだけで、ノードのプロトコルを変更するものではありません。接続後にすべてのアプリが通信できない場合は、まずログでCoreが起動したか、設定解析を通過したか、ハンドシェイクが完了したかを確認します。特定のアプリだけ挙動が異なる場合は、システム制限とアプリ単位の振り分けを確認してください。複数のプロトコル項目を頻繁に切り替えるとログが混ざります。切り分け時は確認済みのノードを1つに固定し、現在のログ時刻を記録または消去してから、明確な接続操作を1回行います。

v2flyNG：V2Flyの対応範囲に合わせて項目を選ぶ

v2flyNGはAndroid向けのV2Flyコアクライアントとして適しています。インポート前に、設定がXray専用機能に依存していないか確認してください。基本的なVMess、対応するShadowsocks、V2Flyが実装するプロトコルとトランスポートは、実際の設定に従って確認できます。REALITYや特定のXray flowを含むVLESS項目は、プロトコル名が表示されるだけで互換と判断しないでください。同じサブスクリプションに複数種類の項目がある場合は、独立したグループを作り、互換性を確認したノードだけをv2flyNGで使います。

2つのAndroidクライアントを比較するときは、同じ基本互換設定を使い、DNS、ルーティング、ネットワーク条件をできるだけ揃えます。一方でインポート後に項目が欠落した場合、その結果はネットワークではなく形式または機能の非互換として記録します。クライアント選択の目的は、各端末に同じアプリを強制することではなく、コアの能力を一致させることです。Xray設定はv2rayNG、V2Fly設定はv2flyNGを優先する方が、何度も変換するより保守しやすくなります。

ログから設定の階層を特定する

ログのエラーは段階ごとに分類できます。設定解析では未知の項目、形式エラー、存在しないアウトバウンドタグなどが出ます。DNSと接続の段階では名前解決失敗、接続拒否、タイムアウトが出ます。TLSとREALITYでは証明書名、鍵、ハンドシェイクの問題が出ます。プロトコル認証ではUUID、パスワード、サーバー側ユーザー設定が関係します。まず失敗した段階を特定してから該当項目へ戻る方が、項目を無作為に切り替えるより効率的です。

切り分け中は、一度に1つの変数だけ変更します。たとえば最初はプロトコルとトランスポートを固定してSNIだけ修正し、再テスト後に公開鍵を確認します。Core、ノード、DNS、ルーティングモードを同時に変えると、成功しても原因を特定できず、失敗時には範囲が広がります。他者へ問題を伝えるときは、クライアント名、Coreファミリー、プロトコル、トランスポート、セキュリティ層、失敗段階、ログの主要なエラー分類を記録し、認証情報は隠してください。

対応するクライアントをまだインストールしていない場合は、クライアントページでWindows、macOS、Android、Linuxからソフトウェアパッケージを選びます。デスクトップではv2rayNを優先し、AndroidではXrayとV2Flyのコア要件に応じてv2rayNGまたはv2flyNGを選択します。インストール後のサブスクリプションインポート、システムプロキシ、接続確認ははじめにの範囲であり、本章ではプロトコルの選定結果をクライアント設定へ反映する方法だけを扱います。

8. 用途別の選定、移行、障害時の切り戻し

既存設定が安定しているなら、プロトコルを維持し変更を減らす

すでに安定して使えているVMess、Trojan、Shadowsocksの設定を、プロトコル名が変わったという理由だけで急いで移行する必要はありません。まず現在のクライアント、Core、トランスポート、セキュリティ層、DNS、ルーティングを基準として記録し、移行によって何を解決したいのかを評価します。端末を替えるだけなら、新しい端末に同じ設定をインポートして項目を確認します。REALITYやVisionを使いたい場合は、サーバーとクライアントの双方を変更する作業なので、元のノードを上書きせず、独立したテスト項目を用意してください。

安定した設定には比較の基準としての価値があります。新しい項目のテストに失敗したら、古い項目へ戻して、ローカルネットワーク、システムプロキシ、クライアント全体がまだ動作しているか確認できます。古い項目も同時に失敗するなら、原因は新しいプロトコル以外にある可能性があります。移行中は元のサブスクリプショングループ、元のCore設定の記録、主要項目の一覧を残すと、どの層で変化が起きたかをすぐ判断できます。新しい設定をすべての対象端末で検証してから、段階的に古い項目の使用を停止します。

デスクトップのマルチプラットフォーム：v2rayNと共通機能を中心にする

Windows、macOS、Linuxでデスクトップ操作を統一したい場合は、v2rayNでサブスクリプションとルーティングを管理する方法が適しています。プロトコルは、まず3つのデスクトップ環境で安定して動くCoreとトランスポートの組み合わせを選び、その後にプラットフォーム差を考慮します。標準セキュリティ層を組み合わせた基本的なVLESS、既存のVMess、Trojan、基本的なShadowsocksは、サーバー項目に沿って1つずつ確認します。REALITYを使う場合は、各プラットフォームのv2rayNが対応するXray Coreを呼び出し、すべての項目を保存できることを確認してください。

プラットフォーム間の同期は、クライアントのディレクトリ全体をコピーすることではありません。システムプロキシの実装、証明書ストレージ、ネットワークインターフェース、自動起動方式にはプラットフォーム差があるため、それぞれ個別に設定する方が適切です。サブスクリプションでノードを同期し、ルーティングルールは用途に合わせて読みやすいルールセットとして管理し、システム設定は各端末に残します。Linuxデスクトップの導入と自動起動は技術ノートv2rayN Linuxデスクトップインストールを参照し、プロトコル項目は本ページの階層的な方法で確認してください。

Androidとデスクトップで共有する：まずコアの共通部分を確認

デスクトップのv2rayNとAndroidのv2rayNGで設定を共有する場合、Xrayの共通機能が最も明確で、VLESS REALITYが必要な用途に適しています。Android側でv2flyNGを使う場合は、V2Flyが明確に対応するプロトコルとトランスポートを選び、Xray専用パラメータを共通設定に持ち込まないでください。1つのサブスクリプションに複数種類のノードを含めることはできますが、「Xray設定」「V2Fly互換設定」のようにメモやグループでコア要件を示し、プロトコル名だけで誤選択しないようにします。

モバイル端末では、安定した接続とバックグラウンド動作をより重視します。デスクトップでは正常でAndroidでは失敗する場合、まずインポート後の項目を比較し、その後にシステムVPNの起動と端末ネットワークを確認してください。すぐにサーバー異常と判断しないでください。Androidで接続できても消費電力が大きい場合は、前述の順序に従って再接続、ネットワーク切り替え、自動更新、ログを確認し、最初から暗号化プロトコルを変更しないようにします。端末間の選定では、パラメータの一致、コアの適合、障害範囲の明確さを目標にします。

複雑なサブスクリプション：プロトコルごとに抽出して検証

サブスクリプションにVMess、VLESS、Trojan、Shadowsocksが混在している場合、一覧の先頭だけをテストしないでください。まずプロトコルごとに分類し、各種類から項目が揃ったノードを1つ選びます。次にトランスポートごとに分類し、TCP、WebSocket、または実際に提供される別の方式を少なくとも確認します。最後にTLSとREALITYを個別に確認します。これにより、障害が特定ノード、特定プロトコル、特定トランスポート、サブスクリプション形式全体のどこにあるか判断できます。テスト結果はグループやメモに記録し、短期的な記憶に頼らないでください。

同じプロトコルでREALITYだけが失敗するなら、Xray CoreとREALITYパラメータを確認します。WebSocketだけがすべて失敗し、TCPが正常なら、パス、Host、TLSを比較します。すべてのプロトコルで解析できないなら、サブスクリプションのレスポンスと形式に戻ります。階層ごとに分類すると、無関係な変更を減らせます。プロトコルとクライアントの違いを横断的に比較するには、v2rayN、v2rayNG、v2flyNGの選び方も参照してください。

移行の実行チェックリストと切り戻し条件

正式な移行は、準備、並行検証、切り替え、観察の4段階に分けられます。準備段階では旧設定を記録し、使えるグループを削除しません。並行検証では新しい項目を追加し、同じネットワーク条件で解析、ハンドシェイク、継続接続、よく使うアプリをテストします。切り替え段階ではアクティブノードだけを変更し、DNSとルーティングは固定します。観察段階で新しいルーティングやシステム設定を少しずつ適用します。各段階に明確な切り戻し地点を設ければ、異常時に旧アクティブノードへ戻すだけで済み、設定全体を作り直す必要がありません。

切り戻し条件には、対象クライアントが必要な項目を保存できない、Coreが必要な機能を実装していない、サブスクリプション更新がローカル修正を繰り返し上書きする、モバイル端末で再接続が頻発する、複数プラットフォームの重要端末のいずれかで安定動作しない、といった場合があります。切り戻しはプロトコルの優劣を判断するものではなく、現在の組み合わせが互換性要件を満たしていないという意味です。旧構成を残したまま、サーバー、サブスクリプション形式、クライアント設定を個別に修正し、次の検証を始められます。

プロトコルの判断が終わったら、はじめにでサブスクリプションのインポート、ノード選択、システムプロキシ、接続確認を実行します。接続失敗、一覧が空、ルーティングが反映されないといった場合は、ヘルプセンターでエラー段階に応じた対処を確認してください。中国本土と海外の振り分けルールをさらに設計する場合は、v2rayNで中国本土と海外を分ける実践設定を参照し、ノードのプロトコルとルーティング方針を分けて管理します。