V2Rayプロトコル・コア・クライアント選定ガイド

01 / DECISION MODEL

まずプロトコル選定の判断モデルを作る

プロトコル、転送方式、セキュリティ層、クライアントは別の層

ノード情報を見たら、まず4つの層に分けて考えます。第1層はVMess、VLESS、Trojan、Shadowsocksなどのプロキシプロトコルで、クライアントの認証方法、接続の構成、サーバー側でのリクエスト識別方法を定めます。第2層はTCP、WebSocket、gRPCなどの転送方式で、ネットワーク接続上でデータを運ぶ方法を決めます。第3層はTLSやREALITYなどのセキュリティ層で、ハンドシェイク時の識別、暗号化された通信路、特定の接続検証を担います。第4層がクライアントとコアです。v2rayN、v2rayNG、v2flyNGが画面を提供し、V2FlyまたはXrayが実際に設定を解析して接続を確立します。

この4層は組み合わせられますが、自由に入れ替えることはできません。VLESSはプロトコル、REALITYはXray系で実装され特定の転送方式と組み合わせるセキュリティ方式なので、「VLESS」と「REALITY」は完全に同列の選択肢ではありません。同様に、WebSocketはプロキシプロトコルではなく、TLSもノードの種類ではありません。クライアントのサブスクでよく見る「VLESS + TCP + REALITY」は、実際には3層の組み合わせです。インポート後に項目が多い場合は、パラメータを一つずつ推測するより、層ごとに確認する方が確実です。

選定は互換性の確認から始める

プロトコル選びで最初に見るべきなのは理論上の速度ではなく、サーバーとクライアントのコアが共通して対応しているかどうかです。サーバーがVMessしか提供していないなら、クライアント側でVLESSの処理負荷を議論しても意味がありません。サブスクにREALITYのパラメータが含まれる場合は、現在のクライアントのコアが関連フィールドを認識できるか確認します。互換性を確認した後で、ネットワーク環境、端末のリソース、接続数、管理のしやすさを比較します。最後に最大スループットを見ます。日常の差は多くの場合、プロトコル名そのものより回線品質、ハンドシェイクの再試行、名前解決、転送層の設定に左右されます。

安全な確認手順は、まずリンクの方式名を特定し、次にクライアントのコアを確認します。その後、転送とセキュリティのフィールドを確認し、最後にアドレス、ポート、認証情報を調べます。ノードの表示名だけでプロトコルを判断しないでください。表示名はサブスク提供元が設定するラベルで、任意の文字列を含められます。実際の解析方式を決めるのはリンクの方式と、設定内のprotocol、network、securityなどのフィールドです。

安定性は接続全体の結果

同じプロトコルでも、設定が違えば挙動は大きく変わります。TCPの直接接続は構造がシンプルで追加処理が少なく、WebSocketは一般的なWebサービスの構成と組み合わせやすい一方、フレームのカプセル化コストがあります。gRPCはHTTP/2を基盤とし、接続管理に優れますが、パラメータの関係はより複雑です。TLSでは証明書名、システム時刻、SNIが一致している必要があり、プロトコル設定が正しくてもハンドシェイクを完了できません。REALITYでは、短い識別子、公開鍵、サーバー名などのフィールドをクライアントとサーバーで一致させる必要があります。

そのため、選定時は「プロトコル + 転送 + セキュリティ層 + コア」の完全な組み合わせを記録し、省略形だけを残さないでください。トラブル対処でも同じ順序で確認します。インポートには成功したのに接続できない場合は、まずクライアントがプロトコルを認識しているか確認し、次に転送フィールドが揃っているかを確認します。最後にセキュリティ層のパラメータを確認します。すべて一致している場合は、DNS、システムプロキシ、ローカルポートを調べます。具体的な症状はトラブル対処で順に確認できます。

02 / VMESS

VMess：充実した認証体系と成熟した互換性

設計背景とプロトコルの役割

VMessはProject Vの初期エコシステムを代表するプロトコルです。ユーザー識別子、リクエスト情報、時刻に関係する認証処理をプロトコル設計に組み込み、クライアントとサーバーはUUIDなどの情報でユーザーを識別します。特徴は「特定の暗号アルゴリズム」ではなく、認証、リクエストのカプセル化、接続ネゴシエーションを含む一連の仕組みにあります。登場が早かったため、多くのV2Ray設定、サブスク生成ツール、GUIクライアントがVMessを認識でき、歴史的に幅広い互換性があります。

VMessの設定には通常、サーバーアドレス、ポート、ユーザーUUID、alterId、転送方式、セキュリティ層が含まれます。現在の設定でよく見るalterIdはゼロであることが多いものの、古いサブスクには別の値が残っている場合があります。クライアントへのインポート時にこのフィールドを勝手に変更しないでください。サーバーとクライアントの設定は一致している必要があります。暗号化オプションはautoが一般的で、実際の動作は設定に従ってコアが処理します。サブスクは正常に更新できるのにVMessノードだけすべて接続できない場合は、まずシステム時刻を確認します。時刻のずれが認証段階に直接影響することがあります。

VMessのメリットとコスト

VMessのメリットは、資料が豊富で設定ツールの対応範囲が広く、V2FlyとXrayの通常の組み合わせで処理できることです。複数のクライアント間で移行する必要がある場合、サーバーが従来のV2Ray設定を使っている場合、サブスク形式が安定して運用されている場合は、積極的にプロトコルを変更するよりVMessを継続する方が手間を抑えられます。TCPやWebSocketなどの転送方式と組み合わせ、TLSを重ねることもできます。既存の環境が安定しているなら、新しいプロトコルが登場したという理由だけで移行する必要はありません。

コストの主因は、プロトコル処理が比較的複雑で、認証やカプセル化の手順が軽量設計より多いことです。十分な処理能力を持つデスクトップでは通常目立ちませんが、省電力端末、多数の同時接続、頻繁にスリープから復帰するモバイル環境では差が現れやすくなります。ただし、実際の消費電力と速度は依然としてネットワーク品質の影響が大きいです。接続失敗による繰り返しの再試行は、1回のプロトコル処理より多くのリソースを消費しがちです。そのため、理論上の負荷より「設定どおり安定してハンドシェイクを完了できること」が重要です。

主なフィールドの確認方法

まずアドレスとポートが完全にインポートされているか確認し、次にUUIDが元のままか確認します。UUIDは標準的な区切り形式である必要があり、コピー時に余分な空白を入れないでください。その後、転送層を確認します。サーバーがWebSocketを使用している場合、クライアントのパスとHostが一致している必要があります。TLSを重ねる場合は、SNIまたはserverNameが証明書の対象名と一致している必要があります。クライアントに表示されるメモは接続に使われないため自由に変更できますが、その他のフィールドは「見た目を簡潔にする」ために削除しないでください。

{
  "protocol": "vmess",
  "settings": {
    "vnext": [
      {
        "address": "server.example.com",
        "port": 443,
        "users": [
          {
            "id": "11111111-2222-4333-8444-555555555555",
            "alterId": 0,
            "security": "auto"
          }
        ]
      }
    ]
  }
}

上の断片はVMessのアウトバウンドにおける主要な階層だけを示しています。完全な設定には、インバウンド、転送パラメータ、ルーティングも必要です。手動入力では、画面上の項目名とJSONの名称が異なることがあります。たとえば「ユーザーID」はid、「追加ID」はalterIdに対応します。意味が一致していればよく、画面の文言と内部フィールド名を一字一句合わせる必要はありません。

VMessを維持するケース

サーバーが安定稼働し、複数の端末でサブスクを使い、クライアントにV2FlyとXrayの両コアが存在する場合、VMessは堅実な互換性重視の選択肢です。従来のWebSocket + TLS構成を含み、移行に伴う変数を減らしたい場合は、現状維持を優先するのが適切です。新規設定でクライアントとサーバーが明確にVLESSへ対応しているなら、認証処理の負荷やセキュリティ層を比較できますが、それはVMessに価値がなくなったという意味ではありません。

VMessのトラブル対処では、まず「インポート失敗」と「ハンドシェイク失敗」を分けて考えます。インポート失敗はリンクのエンコード、サブスク内容、クライアントの解析に関係することが多く、ハンドシェイク失敗は時刻、UUID、転送パス、TLS名、ポートに関係することが多いです。2つの段階で全パラメータを何度も変更しないでください。一度に1項目だけ変更し、変更前後の結果を記録することで、原因を特定できます。

03 / VLESS + REALITY

VLESSとREALITY：軽量プロトコルとセキュリティ層の組み合わせ

VLESSが軽量設計を採用する理由

VLESSは、プロトコル認証と転送セキュリティをより明確に分離します。UUIDでユーザーを識別しますが、VMessと同じ暗号化の役割をプロトコル内部では担わず、通信路の安全性をTLSやREALITYなど外側の方式に委ねます。この分離によりプロトコル本体が簡潔になり、コアが転送方式とセキュリティ層の組み合わせに応じて機能を提供しやすくなります。ただし「プロトコル自体が軽い」ことは、セキュリティ層を省略できるという意味ではありません。TLSやREALITYが必要かどうかは、完全な構成全体で判断します。

クライアントのVLESSノードには、アドレス、ポート、UUID、フロー制御、転送ネットワーク、セキュリティ種別、サーバー名、フィンガープリントなどが含まれることがあります。これらの項目には組み合わせ上の制約があります。たとえば、一部のフロー制御値は特定の転送方式とセキュリティ層でしか使えません。REALITYでは公開鍵、短い識別子、serverNameなども必要です。サブスクでどれか1項目が欠けていると、クライアントはノードを作成できてもハンドシェイクで失敗することがあります。ノードが一覧に表示されるだけで、インポートが完全だと判断しないでください。

REALITYの位置付けとパラメータの関係

REALITYは独立したプロキシプロトコルではなく、Xray系におけるセキュリティおよびハンドシェイクの仕組みで、VLESSと組み合わせて使われることが多い方式です。クライアントには、対応フィールドを解析できるXrayコアが必要です。設定のpublicKeyはクライアント側の検証に使われ、shortIdはサーバー設定との照合に使われます。serverNameはハンドシェイク先の選択に関わり、fingerprintはクライアントのハンドシェイク指紋ポリシーを指定します。これらは相互に置き換えられる別名ではなく、それぞれサーバー設定に対応させる必要があります。

REALITYでよくある問題は、フィールドは存在するのに値がずれていることです。たとえばサーバーアドレスをserverNameに入力したり、ノードのUUIDを公開鍵として扱ったり、短い識別子をコピーする際に文字を落としたりします。サブスクにパラメータが含まれていても、古いコアが認識できないフィールドを無視し、画面上はインポート成功に見えて実際の設定が不完全になる場合があります。この場合は、まず現在のクライアントのコア種別を確認してから再インポートしてください。元のノードでシステムプロキシを何度も切り替えるだけでは解決しません。

性能への期待は具体的に持つ

VLESSはプロトコル処理が軽く、高スループット、多数の同時接続、省電力端末で理論上のメリットがあります。ただし、実際の接続速度は複数の要因で決まります。往復遅延はハンドシェイク時間に、パケットロスは再送に、サーバーのCPUと帯域は継続通信に、転送方式は追加のカプセル化に、DNSは初回アクセスに影響します。回線自体が不安定なら、VMessとVLESSを入れ替えても、安定して体感できる差が出るとは限りません。

REALITYはハンドシェイクのパラメータが多いため、初回設定では通常のVLESS + TLSよりフィールド不足で失敗しやすくなります。正しく設定できれば、日常利用で頻繁に調整する必要はありません。管理ではコアの対応状況とサブスクフィールドの完全性を重視します。クライアントを更新した後も古いノードが正常なら、作り直す必要はありません。サブスク更新後に突然失敗した場合は、更新前後のserverName、公開鍵、短い識別子、フロー制御を比較する方が、クライアントを全面的に再インストールするより有効です。

この組み合わせに適した条件

新規ノードで、サーバーがVLESS + REALITYを明確に提供し、デスクトップでv2rayN、AndroidでXrayコア搭載のv2rayNGを使う場合、この組み合わせは対応経路が明確です。Androidでv2flyNGを使う場合は、サブスクのプロトコルとセキュリティ層がV2Flyの対応範囲に含まれるかを先に確認してください。名前が似ているから互換性があるとは限りません。複数のコアで同じサブスクを共有する必要があるなら、通常のVLESS + TLSや成熟したVMessの方が揃えやすい場合があります。

最終的な判断基準は「より先進的か」ではなく、サーバー、コア、サブスクの3者が同じパラメータを安定して表現できるかどうかです。選択後は3点を確認します。クライアントにセキュリティフィールドが完全に表示されること、接続ログに未知の設定項目がないこと、切断と再接続を繰り返しても復旧できることです。3点を満たしてから、常用設定にします。

04 / TROJAN + SHADOWSOCKS

TrojanとShadowsocks：異なる2つの簡略化アプローチ

Trojanの設計方針

Trojanはパスワードでユーザー認証を行い、TLSに依存して安全な接続を確立します。設定の考え方は比較的明快で、サーバーアドレス、ポート、パスワード、SNI、証明書検証、転送設定が主要項目です。時刻に関係する認証を使うVMessと比べると、TrojanはTLS層が正しく設定されているかに大きく左右されます。VLESSとは異なり、通常はUUIDではなくパスワードフィールドを使います。クライアント画面に「パスワード」と「ユーザーID」が同時に表示される場合は、現在のノード種別を確認し、認証情報を誤った場所に入力しないでください。

Trojanの接続問題はTLSに集中しがちです。システム時刻のずれ、SNIと証明書名の不一致、ポートの誤り、証明書チェーンの異常により、プロキシリクエスト開始前に接続が終了することがあります。設定のallowInsecureは証明書検証の動作を制御するもので、万能な修復スイッチではありません。通常の証明書設定では厳格な検証を優先してください。サーバー証明書の構成を理解したうえで短時間の診断を行う場合に限り変更を検討し、診断後は想定される設定に戻します。

Shadowsocksの基本構造

ShadowsocksはSSと略されることが多く、基本設定はサーバー、ポート、パスワード、暗号化方式で構成されます。VMessやVLESSのUUIDモデルは使わず、サーバーとクライアントでまったく同じ暗号化方式を選ぶ必要があります。設定項目が少なく処理も直接的なため、リソースに余裕のない端末や単純な接続では管理負担を抑えやすい方式です。一方で機能範囲も明確です。複雑な転送方式を必要とする場合は、使用するコアとサーバーが追加機能で対応しているか確認し、他プロトコルのフィールドをそのままSSへ移さないでください。

暗号化方式は名称だけで推測しないでください。サブスクが指定する値を、クライアントでもそのまま使います。インポート後に方式が空欄になったり、見覚えのない値に置き換わったりする場合は、クライアントのコアがその方式に対応していないか、サブスク変換時にフィールドが失われた可能性があります。まずクライアントログの「unknown method」などの解析メッセージを確認し、その後でコアの変更や互換形式での出力を検討します。パスワードを何度変更しても、暗号化方式の不一致は解決しません。

接続速度とリソース使用量の見方

SSは通常、処理経路が短く、設定の複雑さや計算負荷を抑えたい場面に向いています。TrojanはTLSハンドシェイクが必要なため初回接続にコストがかかりますが、接続の再利用と安定した維持により、繰り返しのハンドシェイクを減らせます。アプリが短時間の接続を頻繁に作る場合は、DNS、TLSセッション再開、転送の多重化が体感に大きく影響します。継続的な通信が中心なら、回線帯域とサーバー負荷の方が重要です。

1回のWebページ表示速度だけでプロトコルを評価しないでください。より確実な方法は、同じサーバー、同じ時間帯、同じアプリに固定し、初回接続、継続通信、待機からの復帰、ネットワーク切り替え後の再接続をそれぞれ観察することです。複数回繰り返し、失敗時の再試行も結果に含めます。あるプロトコルが一時的に高いピーク値を出しても、モバイル回線や弱い電波で安定するとは限りません。

2つから選ぶ方法

サーバーが標準的なTrojan設定を提供し、証明書とドメインの関係が明確で、クライアントのコアが完全に対応しているなら、Trojanは明確なTLSモデルを使いたいユーザーに適しています。サーバーがSSを提供し、端末のリソースが限られ、フィールド数と管理手順を減らしたいならSSが直接的です。どちらもVMessやVLESSの「簡易版」ではなく、認証モデルとセキュリティ境界が異なります。移行する場合はサーバー側から対応プロトコルを提供する必要があり、クライアントのプルダウンで種類だけ変更してはいけません。

1つのサブスクが複数のプロトコルを提供している場合は、検証済みの安定ノードを基準として残し、新しいプロトコルの組み合わせをテストすることをおすすめします。基準ノードがあれば、ローカルネットワークの問題と新設定の問題を切り分けやすくなります。すべてのノードが同時に失敗する場合は、まずシステムプロキシ、DNS、ネットワーク接続を確認します。特定の種類だけ失敗する場合は、そのプロトコルの認証とセキュリティフィールドを確認します。

05 / PERFORMANCE

接続速度、リソース使用量、モバイル端末の消費電力

速度は4つの段階に分けて観察する

「速度」には少なくとも、名前解決、ハンドシェイク、最初のパケット、継続通信の4段階があります。DNSはクライアントが接続先アドレスを取得するまでの時間を決めます。プロトコルとセキュリティ層のハンドシェイクは接続が利用可能になる時点を決めます。最初のパケットはアプリのリクエストから遠隔側の応答までを示し、継続通信が一般にいう帯域に近い指標です。VMess、VLESS、Trojan、SSにはプロトコル処理の差がありますが、DNSが遅かったり回線のパケットロスが深刻だったりすると、より大きなネットワーク要因に埋もれます。

テストではまずノードアドレス、転送方式、セキュリティ層を固定し、1つの変数だけを変更します。VMess + WebSocket + TLSとVLESS + TCP + REALITYを直接比較すると、プロトコル、転送、セキュリティ層の差が同時に含まれ、どれか1項目だけの影響とはいえません。サーバーが提供する比較可能な組み合わせを使い、同じネットワークで繰り返しテストするのが適切です。最高スループットだけでなく、接続成功率と復旧能力も記録してください。

CPUとメモリの負荷はどこから生じるか

CPUは主に暗号化、プロトコルのカプセル化、TLSハンドシェイク、データコピー、圧縮、追加の転送処理で消費されます。メモリは接続数、バッファ、ルーティング規則、DNSキャッシュ、ログレベルに左右されます。プロトコル本体が軽くても、クライアント全体の使用量が低いとは限りません。GUI、コアプロセス、ルールセット、TUNモードが主な負荷になることもあります。デスクトップのv2rayNは通常、GUIプロセスからコアプロセスを管理します。リソースを確認する際は、関連プロセスを合算して見てください。

ログレベルも負荷に影響します。トラブル対処中は一時的に詳細度を上げても構いませんが、通常利用に戻ったら標準レベルに戻し、大量のディスク書き込みを避けます。ルーティング規則が多いほど照合処理とメモリ使用量は増えますが、適切に分類された規則が最初のボトルネックになることは通常ありません。重視すべきなのは、重複した規則、過大なドメインリスト、繰り返し失敗するDNSクエリ、継続的な再接続です。

モバイル端末の電池を左右する主な要因

Androidでv2rayNGまたはv2flyNGを使う場合、消費電力はプロトコルだけで決まりません。バックグラウンド接続の維持、Wi-Fiとモバイル通信の切り替え、省電力機能によるプロセス終了、頻繁なDNSリクエスト、再接続の失敗、多数の同時接続が電池に影響します。理論上の負荷が低くても頻繁に切断される設定は、多少複雑でも安定した設定より電力を使うことがあります。再接続のたびに名前解決、ハンドシェイク、アプリ接続の復旧が必要になるためです。

電池消費を確認する際は、まずクライアントが継続動作に必要なシステム権限を取得していることを確認し、端末設定に応じて適切な省電力対象外リストへ追加します。その後、待機中に接続ログが頻繁に出ていないか観察します。画面オフ後に接続が途切れ続ける場合は、すぐにプロトコルを変更せず、システムのバックグラウンド制限を確認してください。AndroidのVpnService権限、省電力対象外設定、アプリごとのプロキシについては、v2rayNG Android利用のポイントも参照してください。

TUNモードでリソースの基準値が変わる

デスクトップでTUNモードを有効にすると、通常のシステムプロキシよりクライアントが処理する通信範囲が広くなることが多く、コアはより多くの接続を引き受け、追加のDNSやルーティング判定を行う場合があります。そのため、通常のシステムプロキシとTUNモードでプロトコル負荷を比較しても直接的な意味はありません。まずプロキシモードを固定してから、プロトコルの差を観察します。TUNへ切り替えてリソースが明らかに増えた場合は、まずルーティング範囲、DNS設定、通信ループがないかを確認してください。

v2rayNのTUNモードは、システムプロキシ設定に従わないアプリも一括して制御したい場合に適しています。ただし、接続失敗時の最初の修復手段にするべきではありません。通常のシステムプロキシで接続できないノードをTUNへ切り替えても、変数が増えるだけです。正しい順序は、まずクライアント内蔵テストでノードを確認し、次にシステムプロキシを有効にしてブラウザーで検証し、最後にアプリの要件に応じてTUNを使うか決めることです。

再現可能なテスト記録を作る

候補となる各組み合わせについて、プロトコル、転送、セキュリティ層、コア、プロキシモード、テストネットワークを記録することをおすすめします。一度に1項目だけ変更し、初回接続、10分間の継続利用、待機からの復帰、ネットワーク切り替えを連続して観察します。ピーク値が少し高くても再接続失敗が多い組み合わせより、成功率が安定した組み合わせを優先してください。日常の体感は、1回の最高記録ではなく、多くの時間で使えるかどうかで決まります。

リソースに異常がある場合は、変数を順番に減らします。詳細ログを無効にし、単純なルーティングに戻し、TUNを終了し、ノードを1つだけ残してからコアプロセスを観察します。使用量が正常に戻ったら、機能を1つずつ再び有効にします。これにより、プロトコル、ルール、プロキシモードのどこに負荷があるかを切り分けられ、問題をすべてノード種別のせいにせずに済みます。

06 / CORE FAMILY

V2FlyとXrayのコアファミリーおよび設定互換性

共通の起源と異なる発展方向

V2FlyとXrayはいずれもProject Vのエコシステムにある設定思想を受け継いでおり、一般的なインバウンド、アウトバウンド、ルーティング、DNS、転送層の構造には多くの共通点があります。これらはGUIクライアントではなく、設定の解析と接続処理を担うコアプログラムです。v2rayNはデスクトップGUIクライアントで、対応するコアを管理できます。v2rayNGは主にXrayコアを使い、v2flyNGはV2Flyコアを対象とします。クライアント選びでは、実質的にデフォルトのコア能力も選んでいることになります。

共通の基盤があるため、多くのVMess、Shadowsocks、Trojan、通常のVLESS、一般的なルーティング規則は似た形式で表現できます。しかし「似ている」ことは、すべてのフィールドが双方向に互換であることを意味しません。XrayはVLESS、XTLS、REALITYなどの方向で独自機能を追加しており、V2Flyは従来の設定体系に沿って発展しています。ある設定ファイルを一方のコアが受け入れても、もう一方が拡張フィールドをすべて理解できるとは限りません。

機能差はフィールド単位で確認する

互換性を判断するとき、「VLESSに対応しているか」だけで終わらせず、セキュリティ層、フロー制御、転送方式、拡張パラメータまで確認します。たとえば通常のVLESS + TLSとVLESS + REALITYではコアに求められる対応が異なります。同じTCP転送でも、特定のフロー制御を有効にするかどうかで対応範囲が変わります。サブスク名にはVLESSとしか書かれていなくても、コア選びに影響するパラメータはクエリ文字列や内部JSONに隠れています。

Xray固有のフィールドをV2Flyで使うと、インポート時に無視される、起動時に未知のフィールドとして報告される、ノードは保存できても接続できない、といった結果がよく起こります。逆方向の移行でも、デフォルト値の違いやフィールド名の変更に遭遇することがあります。エラー項目を手動で削除するのではなく、まずその項目が担う機能を確認するのが安全です。セキュリティ層に必須のパラメータなら、削除後に設定が起動しても同等の接続にはなりません。

設定移行の確認手順

コアを切り替える前に、現在のノード種別、転送方式、セキュリティ層、ルーティング設定をエクスポートまたは記録します。次に、設定に移行先コアが認識できない拡張フィールドがないか確認します。3番目に、移行先クライアントへノードを1つだけインポートし、コアが起動できることを確認します。4番目にDNSとルーティングのログを確認し、リクエストが想定したアウトバウンドへ実際に流れているか確かめます。最後に完全なサブスクを移行します。一度に全ノードを移行すると、原因を特定しにくくなります。

GUIだけを更新し、コアファミリーが変わらない場合は、通常設定を書き直す必要はありません。コア切り替え後に通常のVMessは使えるのにREALITYだけ失敗するなら、確認範囲をXrayの拡張機能とセキュリティフィールドに絞り、ネットワークドライバーを再インストールしないでください。逆に、すべてのノードが起動できない場合は、まずクライアントがコアファイルを正しく呼び出しているか、ローカルの待受ポートが使用中でないか、設定構文が通るかを確認します。

ルーティングとDNSにも互換性の境界がある

プロキシプロトコルが使えても、設定ファイル全体が完全に互換とは限りません。ルーティング規則のドメイン分類、ルールセット参照、DNSクエリポリシー、アウトバウンドのタグにも差がある場合があります。移行後、ノードテストは成功するのに一部サイトの挙動が異常なら、ルールが存在しないタグを参照していないか、DNSアウトバウンドが正しい対象を指しているか、規則の順番が変わっていないか確認します。内部設定は通常上から順に照合されるため、前の広い規則が後の具体的な規則を上書きすることがあります。

設定を簡略化することは互換性を検証する有効な方法です。ローカル入口を1つ、プロキシアウトバウンドを1つ、最小限のDNS設定だけ残し、基本接続を確認してから分流を追加します。最小構成のテストで複雑なルール、TUN、複数の予備アウトバウンドを同時に有効にしないでください。機能を1層追加するたびに接続を確認すれば、どの層で差が生じたかを明確にできます。

デフォルトコアの選び方

サブスクがVMess、通常のVLESS、Trojan、SSを中心とし、既存のV2Fly設定が安定しているなら、従来のコアを維持できます。REALITY、特定のフロー制御、Xray拡張フィールドが明確に含まれる場合は、Xray対応の経路を選びます。デスクトップではまずv2rayNを使い、ノード要件に応じてコアを設定します。Androidではサブスクの機能に応じてv2rayNGとv2flyNGを選択します。

コア選びは永久に固定されるものではありませんが、切り替えるたびに明確な理由が必要です。名前が見慣れているというだけでコアを変えると、設定の解釈差が増えます。より詳しい機能比較はXrayコアとV2Flyコアの違いで確認できます。プロトコル対応、性能、設定移行の境界をさらに分解して解説しています。

07 / SUBSCRIPTION

サブスク形式、共有リンク、クライアントの互換性

サブスクは設定の入れ物であり、プロトコルではない

サブスクURLはクライアントに1つ以上のノード設定を提供するもので、それ自体がVMess、VLESS、Trojan、SSのどれを使うかを決めるわけではありません。クライアントはサブスクを更新するとテキストまたは構造化データを取得し、共有リンク、フィールド、メモを内部設定へ変換します。つまり「サブスク更新成功」は内容を取得できたことを示すだけで、すべてのノードが完全に解析されたことや、接続できることを保証しません。

共有リンクでは、vmess://、vless://、trojan://、ss://などの方式名でプロトコルを区別します。VMessの共有内容はJSONをエンコードして含めることが多く、VLESSとTrojanはURIのユーザー情報やクエリパラメータで転送方式、セキュリティ層、追加フィールドを表します。SSリンクには暗号化方式、パスワード、アドレス、ポートが含まれます。クライアントは方式とリンク内のパラメータ形式を認識できなければなりません。

同じサブスクでもクライアントによって件数が違う理由

ノード数が異なる理由は主に4つあります。第1に、クライアントがサブスク内のプロトコルや拡張フィールドに対応しておらず、該当項目をスキップする場合です。第2に、サブスク内容に形式エラーがあり、一部のリンクを解析できない場合です。第3に、クライアントで重複排除、絞り込み、キーワード除外が有効になっている場合です。第4に、サブスク変換側がクライアント種別に応じて異なる内容を出力している場合です。トラブル対処では、総数だけでなく、まずプロトコルの種類ごとの分布を比較します。

v2rayNGではREALITYノードが表示されるのにv2flyNGでは表示されない場合は、まずコアの対応範囲を確認します。両方で同じVMessノード群が欠けているなら、サブスクのエンコードやリンクの完全性に問題がある可能性が高いです。デスクトップのv2rayNで一部しかインポートできない場合は、更新ログに「スキップ」「未知の方式」「フィールド解析失敗」などの情報がないか確認します。実際の設定はノード名に含まれていないため、名前を手動でコピーして補わないでください。

URIエンコードで起こる見落としやすい問題

パスワード、メモ、パス、クエリパラメータに特殊文字が含まれる場合は、URIの規則に従ってエンコードする必要があります。サブスク変換で二重にエンコードされると、クライアント側の値にパーセント記号の並びが余分に現れます。まったくエンコードされていない場合は、シャープ、疑問符、スラッシュなどがリンク構造として解釈されることがあります。TrojanとSSのパスワードは特に注意が必要です。インポート後にパスワードの長さが明らかに変わった場合は、クライアント上で推測せず、元のサブスクを確認してください。

リンク末尾のシャープ以降は通常ノードのメモとして扱われ、認証には使われません。メモが文字化けしても接続失敗に直結しないことが多いですが、サブスクのエンコード処理に問題がある兆候です。メモと重要パラメータが同時に異常なら、サブスク内容を完全に再取得してください。リンクをコピーするときは自動改行や文字置換を行うエディターを避け、表示上で省略された部分だけをコピーしないでください。

サブスク更新後の安全な操作手順

更新前に、検証済みで利用可能なノードを1つ残しておき、古い設定をすぐ削除しないでください。更新後はノードの種類と数を確認し、新しいノードを1つ選んでクライアント内蔵テストを実行します。テストに成功したらシステムプロキシを有効にして実際のアクセスを確認し、最後にルーティングやTUN設定を更新します。これでサブスク解析、ノード接続、システムによる通信制御を3段階に分けられます。どの段階で失敗しても、直前の有効な状態へ戻せます。

サブスク更新で元のノードが上書きされた場合は、ローカル変更の保持、メモによる統合、サブスクグループの分離といった機能がクライアントにないか確認します。サブスクノードを手動で変更しても次回更新で上書きされることが多いため、恒久的な修正はサブスク側で行う必要があります。一時的なテストノードは独立した設定として複製し、分かりやすいメモを付けると自動更新項目と区別しやすくなります。

クライアントをサブスクの種類に合わせて選ぶ

Windows、macOS、Linuxのデスクトップではv2rayNを優先します。サブスクの一元管理、コアの切り替え、ログ確認に便利です。AndroidでXray拡張機能を中心とするサブスクを使う場合はv2rayNG、V2Flyコアとの互換性が明確に必要な場合はv2flyNGを選びます。インストールパッケージはクライアントを入手ページでプラットフォームとアーキテクチャに合わせて選び、共有リンク名からパッケージ種別を推測しないでください。

サブスクURLは設定への入口なので、公開ページやスクリーンショットに完全な内容をそのまま表示しないでください。トラブル対処では、プロトコル種別、エラーメッセージ、機密でないフィールドを記録できますが、認証情報は秘密に保ちます。他人に問題を説明する場合は、「プロトコル + 転送 + セキュリティ層 + コア + エラー段階」の形式で伝えると、原因の方向を特定しやすくなります。

08 / SCENARIO GUIDE

利用シーンに合わせてプロトコル、コア、クライアントを選ぶ

デスクトップの日常利用：管理上の変数を減らす

Windows、macOS、Linuxのデスクトップ環境ではv2rayNを優先します。最初に、サブスクにあるプロトコルを基準に選び、サーバーが提供するノード種別を勝手に変更しません。次にREALITYや特定のXray拡張が含まれるか確認し、含まれる場合は対応するXrayコアの経路を使います。3番目に、通常のシステムプロキシモードで単一ノードの接続を確認します。アプリがシステムプロキシに従わない場合や、通信を一括管理する明確な必要がある場合に限り、TUNモードを検討します。

プロトコルについては、既存のVMess + TLS設定が安定しているなら継続使用できます。新しい設定でVLESS + REALITYが明確に提供されている場合は、全フィールドをインポートしてコアを確認します。サーバーがTrojanを提供している場合はTLSとSNIを重点的に確認し、SSでは暗号化方式を一致させます。デスクトップ端末には通常これらのプロトコルを処理する十分なリソースがあるため、選定では理論上の小さな負荷差より、互換性、復旧能力、管理コストを重視します。

Androidの長時間バックグラウンド利用：まず再接続を抑える

AndroidのサブスクにVLESS + REALITYなどのXray機能が含まれる場合はv2rayNGを優先し、設定が明確にV2Flyコア向けならv2flyNGを選びます。インポート後は、まずVpnServiceの接続権限を許可し、端末のバックグラウンド管理に応じて省電力対象外リストを設定します。画面オフ後の接続維持を観察し、ログに切断と再ハンドシェイクが続く場合は、まずシステムのバックグラウンド制限を解決します。

モバイル端末でプロトコルを選ぶ際は、安定した接続と待機からの復帰を重視します。SSは設定が簡潔で、VLESS本体は軽量ですが、どのプロトコルでも失敗と再試行を繰り返せば電池を消費します。同じノードを半日以上使い、待機、ネットワーク切り替え、アプリ復帰を観察してください。短時間の速度測定だけで判断しないことが重要です。アプリごとのプロキシを使えば、プロキシを必要としないアプリの接続数を減らし、不要な通信処理の削減にも役立ちます。

複数端末でサブスクを共有：共通機能を選ぶ

同じサブスクをデスクトップとAndroidで使う場合は、対象となるすべてのクライアントが共通して対応するプロトコルの組み合わせを基準にします。VMess、Trojan、SS、通常のVLESSは幅広いクライアントで使えることが多いものの、具体的な対応は転送方式とセキュリティフィールドにも左右されます。サブスクにREALITYが含まれる場合は、対応クライアントで該当ノードを使いながら、互換範囲の広い予備ノードも残しておくと安心です。「名称を統一する」ために異なるセキュリティ構成を無理に同じリンクへ変換しないでください。

共有サブスクでは、フィールドの一致とグループの整理を重視します。プロトコルやコア要件に応じて、「VLESS-REALITY-Xray」や「VMess-TLS-共通」のように明確なメモを付けられますが、メモは識別用であり、実際のパラメータの代わりにはなりません。更新のたびに両方の端末でノードを1つずつテストし、変換処理でクエリパラメータが削除されていないか確認します。

低リソース・高同時接続環境：接続全体を先に測る

リソースに制約がある端末では、SSやVLESSのように処理が直接的な方式を優先的に比較できますが、サーバー対応とセキュリティ層が完全であることが前提です。高同時接続環境では、接続の再利用、転送方式、コアのバッファ、サーバー側の制限も同時に確認します。プロトコルのカプセル化が軽くても、回線のパケットロス、サーバー負荷、誤ったDNSポリシーを補うことはできません。

テストではCPU、メモリ、接続成功率、継続スループットを記録します。プロトコル負荷を下げてCPUが改善しても、失敗率が上がれば全体として悪化する可能性があります。対象の負荷で安定して連続稼働できる設定を選び、戻せる構成も残してください。転送、コア、セキュリティ層を調整するときは一度に1項目だけ変更し、結果の原因を明確にします。

最終確認リスト

選定後は8項目を順番に確認します。プロトコル名がサーバーと一致していること、クライアントのコアがすべてのフィールドに対応していること、アドレスとポートが完全であること、認証情報に空白や欠落がないこと、転送方式とパスが一致していること、TLSまたはREALITYのパラメータが完全であること、クライアントの単一ノードテストに成功すること、システムプロキシまたはVpnServiceで実際のアクセスが正常なことです。どれか1つでも未確認なら、その段階で止め、ルーティングやTUNを重ねて設定しないでください。

接続に成功した後は、切断からの再接続、待機からの復帰、ネットワーク切り替えを観察します。しばらく安定して動作したら、プロトコル、転送、セキュリティ層、コア、クライアント名を含む有効な組み合わせを文章で保存します。以後問題が起きたときは、この記録を基準に変更されたフィールドだけを比較します。サブスク全体を再インポートするより、原因を特定しやすくなります。

1ページで分かる選定結論

既存の成熟した設定を使い、複数コア間の互換性を重視するなら、まずVMessを維持できます。新規設定でXray系が完全なVLESS + REALITYパラメータを提供するなら、その組み合わせに対応するコアとクライアントを使います。明確なTLS認証モデルを採用し、証明書設定が完全ならTrojanを選べます。設定をシンプルにし、サーバーがSSを明確に提供し、暗号化方式に互換性があるならShadowsocksを使えます。プロトコルに用途を離れた絶対的な順位はありません。

デスクトップではv2rayNを第一候補とし、Androidではコア要件に応じてv2rayNGまたはv2flyNGを選びます。選定後は使い方ガイドに戻り、サブスクのインポート、プロキシの有効化、接続確認の順に進めてください。クライアントの起動直後のクラッシュ、ポートの競合、証明書ハンドシェイクのエラーが続く場合は、トラブル対処とTLS証明書エラー対処チェックリストを参照してください。