V2Rayプロトコルとコアの選び方ガイド

01 / MODEL

プロトコルを選ぶ前に、プロトコル・トランスポート・安全性の層を分けて考える

クライアントのノード1行は、実際には複数のパラメータ層で構成されています

クライアント画面では「プロトコル」が広い分類として使われがちですが、接続に必要なのはプロトコル名だけではありません。一般的なVLESSノードを例にすると、VLESSはクライアントとサーバー間で認証情報を交換し、データを転送する基本方式を定義します。TCP、WebSocket、gRPCなどはデータをどのように運ぶかを示す下位層の項目です。TLSやREALITYはハンドシェイクと安全性を担い、XTLS Visionはフロー制御としてデータ処理に関わる場合があります。アドレス、ポート、ユーザー識別子、サーバー名は接続パラメータです。どれか1つでも一致しなければ、タイムアウト、ハンドシェイク失敗、接続後に通信できないといった症状になります。

そのため、選択時に「VLESS」と「VLESS + TCP + REALITY + Vision」を同じ粒度の名称として扱うことはできません。前者はプロトコルの骨格だけを示し、後者は完全な構成に近い情報を含みます。サブスクリプションをインポートすると、クライアントは識別しやすい一部だけを種類ラベルとして表示することがあります。完全なパラメータはノード編集画面で確認してください。特にテキスト形式のサブスクリプションから別のクライアントへ移行する場合、同じ名前が表示されても拡張項目がすべて保持されているとは限りません。

固定的な順位より信頼できる4つの判断軸

1つ目はサーバーとの互換性です。クライアント側だけでVMessをVLESSに変更することはできず、REALITYを選ぶだけで通常のTLSノードに同じ機能を追加することもできません。プロトコル、トランスポート、安全性の各パラメータをサーバー設定と1項目ずつ一致させる必要があります。2つ目はコアの機能です。v2rayNはデスクトップで一般的な設定を扱え、v2rayNGは主にXrayコアを、v2flyNGはV2Flyコアを使用します。同じ基本ノードでも、これらのクライアントで対応範囲が異なる場合があります。REALITY、Vision、特定のトランスポート拡張を使う場合は、差がより明確になります。

3つ目は端末環境です。デスクトップは処理時間とメモリに余裕があるため、互換性、ルーティング機能、管理のしやすさを優先できます。Androidではバックグラウンド動作、Wi-Fiとモバイルデータの切り替え、継続的なハンドシェイク、再接続による消費電力も考慮します。4つ目は設定の入手元です。ノードがサブスクリプション由来なら、サブスクリプションに明記され、クライアントが完全に認識できる種類を優先してください。名称だけを求めて、不足パラメータを推測して手入力するのは避けます。

まず完全性を確認し、その後で性能を比較する

接続速度の前提は、パラメータが正しいことです。アドレスの名前解決、ポートへの到達性、正確なシステム時刻、ユーザー識別子の一致、同一のトランスポート経路は、プロトコル名より初回接続の成功率に直接影響します。インポート後にサーバー名、WebSocketパス、REALITY公開鍵、短い識別子が欠けている場合、ノードの種類を切り替えるだけでは解決しません。ノード情報またはサブスクリプションの提供元に戻って確認し、クライアント上で項目を当てずっぽうに試すのは避けてください。

実用的な手順は、まずクライアントがノードの種類を認識しているか確認し、次にアドレス、ポート、認証項目を照合します。その後、トランスポート方式と関連パラメータを確認し、最後に安全性とフロー制御を確認します。ここまで終えてから、接続確立時間、継続的なスループット、メモリ使用量、バッテリー消費を比較します。この順序なら「設定ミス」と「プロトコルの選択」を切り分けられ、1回のハンドシェイク失敗をプロトコル自体の速度不足と誤認せずに済みます。

02 / VMESS

VMess：既存設定との互換性とパラメータの境界

設計背景と現在の位置づけ

VMessは、Project Vのエコシステムで早くから広く使われてきたプロトコルの1つです。ユーザー識別子、認証情報、データ転送ルールを統一された構造にまとめ、クライアントとサーバー間で時刻を基準にした認証処理を行います。この設計により、VMessは単なる「アドレスとパスワード」の組み合わせではなく、システム時刻のずれが接続に影響する理由も説明できます。以前から運用されているサーバー、サブスクリプション変換ツール、クライアント設定の多くがVMessを基盤としているため、既存ノードとの互換性という点で今も実用的な価値があります。

VMessを選ぶ主な理由は、処理を最小限にすることではなく、既存設定が安定して動作し、関連するサブスクリプション項目をクライアントが完全に解析できることです。サーバーがVMessのみを提供しているなら、クライアントも同じプロトコルにしてください。ノードの種類をVLESSに変更し、元のUUIDを残しても、同等の接続にはなりません。2つのプロトコルは認証方式とデータ構造が異なるためです。移行にはサーバーとクライアント双方の変更が必要で、ローカルのラベルだけを変えても解決しません。

alterId、暗号化オプション、旧設定の見分け方

古い資料にはalterIdがよく登場します。これは初期のVMess設定体系に属する項目で、現在の設定では通常ゼロ値を使います。過去のサブスクリプションをインポートした際にこの項目が表示されても、資料の年代を根拠に別の数字へ変更せず、実際のサーバー設定を基準にしてください。クライアントによっては、現在あまり使われない項目を隠したり、インポート時に初期値を自動入力したりします。こうした画面上の違いは、プロトコルの内容が変更されたことを意味しません。

VMessノードにはsecurityまたは「暗号化方式」が表示されることもあります。この項目はVMessのデータ層で使う処理方式を示し、外側のTLSとは別の設定です。外側のTLSを有効にするかどうかは、トランスポートの安全性に関する項目で決まります。securityに値が入っているからTLSも設定済みだと考えるのは、よくある誤解です。実際には別の階層にあるため、トラブル時はそれぞれを個別に確認してください。

{
  "protocol": "vmess",
  "settings": {
    "vnext": [{
      "address": "example.com",
      "port": 443,
      "users": [{
        "id": "11111111-1111-4111-8111-111111111111",
        "alterId": 0,
        "security": "auto"
      }]
    }]
  }
}

上の断片はVMessアウトバウンドの主要な階層だけを示したものです。実際の接続には、サーバーと一致するトランスポートと安全性の設定も必要です。例にあるアドレスとユーザー識別子は項目構造を説明するためのもので、ノードとして使用するものではありません。手入力する場合は、ノード情報の各値を対応する欄に入力し、例の内容をそのままコピーしないでください。

トランスポート構成と性能の考え方

VMessはTCPやWebSocketなどのトランスポートと組み合わせられ、TLSを重ねることもできます。構成による違いは、VMessプロトコル自体の違いより大きい場合があります。たとえば直接TCPはカプセル化の経路が比較的短く、WebSocketは追加のフレーム処理が必要で、パスやHostなどの項目も一致させなければなりません。TLSを使えばハンドシェイクと暗号計算も増えます。「VMessは速いか」を議論するなら、比較対象が同じトランスポート、同じ安全性、同じサーバー、同じネットワーク条件かを明示する必要があります。

リソース使用量では、VMessの認証とデータ処理は、より簡潔な構造のVLESSより手順が多くなることがあります。ただし現代のデスクトップでは、これが主なボトルネックになるとは限りません。実際に目立つ遅延は、DNS名前解決、サーバーまでの距離、無線ネットワークの揺らぎ、接続の再確立、トランスポート層の再試行から生じることが多いです。モバイル端末で継続利用する場合は、クライアントログに定期的な切断と再接続がないか確認してください。ハンドシェイクの繰り返しは待ち時間とバッテリー消費を同時に増やします。

使い続けるべきケースと移行を検討するケース

VMessノードのパラメータが揃い、接続が安定し、サブスクリプションも正常に更新され、現在のクライアントがトランスポート設定を正しく認識できているなら、そのまま使うのが合理的です。新しい名称が登場するたびに移行する必要はありません。一方、新しいサーバーを構築していて、クライアントとコアがVLESSおよび必要な安全構成を明確にサポートしているなら、より簡潔なプロトコル基盤から評価を始めてもよいでしょう。移行時は元のノードを比較用に残し、新しい設定を追加して検証してから旧設定を削除してください。パラメータ確認前に、使える基準を失わないことが重要です。

v2rayN、v2rayNG、v2flyNGの間でVMessノードを移行する場合、基本項目は幅広く互換しますが、一部のトランスポート拡張はコアに依存します。インポート後は、プロトコル、アドレス、ポート、UUID、トランスポート方式、TLSの有効・無効、サーバー名、パスを最低限確認してください。サブスクリプションにvmess://項目が1つだけ含まれている場合、通常はクライアントがデコードします。空のノードや項目のずれが表示されたら、手入力で推測する前にサブスクリプションの内容が完全か確認します。

03 / VLESS · REALITY

VLESS、REALITY、XTLS Vision：3つの階層の役割

VLESSは軽量なプロトコル基盤

VLESSは、プロトコル自身が担う処理を簡潔にすることを重視して設計されています。ユーザー識別子で認証を行いますが、VLESSのデータ層に完全な暗号化機構を重ねて持たせず、安全性をTLSやREALITYなどの外側の方式に委ねます。この分担により構造が明確になり、重複処理も減らせます。ただし「VLESS自体が軽い」からといって、どのVLESS構成も必ず速いとは限りません。実際の負荷は、トランスポート、安全性のハンドシェイク、フロー制御、サーバー実装、ネットワーク経路によって決まります。

クライアントの編集画面でVLESSに表示される主な項目は、アドレス、ポート、UUID、暗号化値、トランスポート方式、安全性の種類、フロー制御です。画面によっては暗号化項目にnoneを指定しますが、これはプロトコル構造の一部であり、接続全体に安全性がないという意味ではありません。ノードがTLSまたはREALITYを使う場合、安全性の処理は外側の層にあります。「トランスポートの安全性」などの項目を確認し、VLESSの暗号化値だけで判断しないでください。

REALITYは安全なハンドシェイク方式であり、VLESSの別名ではありません

REALITYはVLESSと組み合わせて提供されることが多く、多くのクライアントでは組み合わせた名称が続けて表示されます。厳密には、VLESSがアプリケーションプロトコルを、REALITYが安全性とハンドシェイク関連の機能を担います。REALITYの設定には通常、サーバー名、公開鍵、短い識別子、クライアントフィンガープリントなどが含まれ、これらは一組で一致しなければなりません。アドレス、ポート、UUIDだけでは完全な接続を確立できません。サブスクリプション変換で拡張項目が1つでも欠けると、クライアントにVLESSと表示されてもハンドシェイクで失敗する可能性があります。

公開鍵は、クライアントが検証しハンドシェイクに参加するための重要な項目です。短い識別子はサーバー設定との照合に使われ、サーバー名はハンドシェイクの意味づけに関わります。クライアントの「フィンガープリント」は、ハンドシェイク時の見え方に使うプリセットを示します。バージョンによって「Public Key」「公開鍵」など表記が異なる場合がありますが、役割は変わりません。ノードを移行する際は、画面上の位置ではなく項目の意味に沿って対応づけてください。

XTLS Visionはフロー制御とデータ処理の方式です

XTLS VisionはVLESS + REALITY構成でよく使われます。新しい認証プロトコルでも、サーバーアドレスの追加形式でもなく、フロー制御の選択肢です。Visionは、特定の状況で重複処理を減らし、安全性の意味を持つデータに適した経路で処理することを目指します。クライアントとサーバーの双方が対応し、設定も一致している必要があります。サーバー側で対応するフロー制御を有効にしていない場合、クライアントだけでVisionを選ぶと接続異常につながる可能性があります。

画面でよく表示される値はxtls-rprx-visionです。選択時はノード情報を基準にしてください。空欄とこの値の入力は、自由に入れ替えられる性能モードではなく、サーバー設定の一部です。サブスクリプション形式によってはflowパラメータをそのまま含められますが、古い変換処理では失われる場合があります。インポート後にREALITYの公開鍵と短い識別子が揃っているのに通信できない場合は、サーバー名だけを繰り返し変更せず、flowも確認してください。

この構成が良好な応答性能を示しやすい理由

VLESSのプロトコル基盤は簡潔で、REALITYは通常のTLS証明書を自分で用意する手順の一部を省き、Visionはデータ処理経路を最適化します。3つを組み合わせると、重複するカプセル化が減り、適切なフロー制御によって処理負荷が下がる可能性があります。ただし実際の体感は、往復遅延、サーバー負荷、混雑、DNS名前解決、端末性能にも左右されます。プロトコルが決めるのは一部にすぎず、1回の速度測定から一般的な結論を導かないでください。

モバイル端末では、継続接続が安定し、再計算が少ない場合にメリットが現れやすくなります。Wi-Fiとモバイルデータが頻繁に切り替わる環境では、どのプロトコルでも接続を再確立します。その場合、バックグラウンド設定やネットワーク品質がプロトコル差よりバッテリーに大きく影響することがあります。ハンドシェイクとデータ経路を詳しく知りたい場合は、REALITYとXTLS Visionの技術解説を参照してください。実際に設定する前に、使用するクライアントとコアが必要な項目をすべてサポートしていることも確認します。v2rayNGはXray関連の拡張を扱うのに適しています。

04 / TROJAN · SS

TrojanとShadowsocks：構造は簡潔でも、選択のポイントは異なる

Trojan：認証とTLSの組み合わせが明確

Trojanは通常、パスワードを認証情報としてTLSと組み合わせて使います。設定の考え方は比較的わかりやすく、クライアントは指定したアドレスとポートへ接続し、パスワードでプロトコル認証を行い、TLSが安全性を担います。一般的なノード情報には、サーバー名や証明書検証に関する項目も含まれます。サーバー名はサーバー側の証明書設定と一致させる必要があり、アドレス欄だけから判断することはできません。

Trojanの利点はパラメータの階層が理解しやすく、多くのクライアントで標準的な共有リンクを安定して解析できることです。ただし「パスワードとポートだけ」で動くわけではなく、TLSハンドシェイク、サーバー名、トランスポート方式も一致させる必要があります。WebSocketやgRPCを使う場合は、パスやサービス名などの関連項目も接続に関わります。トラブル時はTLSハンドシェイク段階とTrojan認証段階に分け、前者ではシステム時刻、サーバー名、安全性を、後者ではパスワードとサーバー側のプロトコル設定を確認します。

Shadowsocks：簡潔な暗号化転送構造

ShadowsocksはSSと略されることが多く、主な項目はサーバーアドレス、ポート、暗号化方式、パスワードです。VMessや複数の拡張層を持つVLESS構成より構造が短く、手入力しやすく、クライアント間でも受け渡しやすいのが特徴です。一方、暗号化方式はクライアントとサーバーの双方が対応している必要があり、名称も完全に一致させなければなりません。似た名前の方式に置き換えても、自動的に利用可能な値へ調整されることはありません。

コアによってShadowsocksの暗号化方式への対応範囲が異なる場合があります。新しい方式には対応するコアの機能が必要で、古いクライアントはss://リンクを読み取れても接続時に未対応と表示することがあります。この場合はパスワードを変更する前に、クライアントのコアを確認してください。v2rayNはデスクトップで複数プロトコルを一元管理するのに適し、v2rayNGとv2flyNGはそれぞれ使用するコアの対応範囲に左右されます。クライアントを選ぶ際は、実際の暗号化方式を互換性確認に含めてください。

{
  "protocol": "shadowsocks",
  "settings": {
    "servers": [{
      "address": "example.com",
      "port": 8388,
      "method": "aes-128-gcm",
      "password": "your-password"
    }]
  }
}

この断片は標準的なアウトバウンド項目の関係を示しています。アドレス、ポート、方式、パスワードはサーバーから提供された実際の値に置き換えてください。暗号化方式はローカルの好みで選ぶ項目ではなく、リソース削減を理由に一方的に変更できません。インポート後に方式が空欄なら、共有リンクまたはサブスクリプションの変換結果を再確認します。

両者の性能差は項目数だけでは判断できません

Shadowsocksはパラメータが少ないからといって、あらゆるネットワーク環境でTrojanより速いとは限りません。Trojanは通常TLSハンドシェイクのコストを伴いますが、長時間接続ではそのコストが後続の通信に分散されます。Shadowsocksの実際の負荷は、暗号化方式、端末のハードウェアアクセラレーション、パケットサイズ、コアの実装に左右されます。短時間の接続が多い場合は接続の再利用やクライアントの挙動が体感を左右し、継続的なダウンロードではサーバー帯域と回線品質のほうが重要になることが多いです。

モバイル端末では、継続的な暗号化処理と頻繁な再接続がバッテリーに影響します。現代のプロセッサは一般的な暗号処理に十分対応しているため、アルゴリズム名だけで消費電力を正確に予測するのは困難です。同じネットワーク、同じサーバー地域、近い負荷条件を保ち、一定時間の接続安定性、スリープ解除回数、クライアントのバックグラウンド状態を記録するほうが有効です。数秒の速度測定だけでは、長期的なバッテリー性能は判断できません。

適用範囲と選び方

ノード情報が標準的なTrojanパラメータだけを提供し、クライアントがTLS関連項目を正しく認識できるなら、Trojanを使い続けるのが最も確実です。Shadowsocksが提供されている場合は、暗号化方式が現在のコアでサポートされているかを重点的に確認します。どちらも他のノードと「種類を統一する」ために変換する必要はありません。サブスクリプションに複数のプロトコルが含まれている場合は、種類を分けたままノード単位で管理できます。システムプロキシやルーティング規則が、すべてのアウトバウンドに同じプロトコルを要求するわけではありません。

保守の面では、項目が少ないほど手作業で確認しやすくなりますが、更新が不要になるわけではありません。サーバーアドレス、パスワード、証明書名、暗号化方式が変われば、古いノードは使えなくなります。サブスクリプションを利用している場合は、クライアントのサブスクリプション更新機能で変更を受け取り、手動コピーを複数長期間管理しないようにしてください。デスクトップとAndroidのサブスクリプション追加画面については、V2Rayサブスクリプションリンクのインポート方法を参照してください。

05 / PERFORMANCE

接続速度、リソース使用量、モバイル端末のバッテリーを比較する方法

「速さ」を4つの観測可能な段階に分ける

プロトコル比較でいう「速度」には、少なくとも4つの異なる指標があります。1つ目は接続確立時間で、クライアントが接続を開始してからハンドシェイクが完了するまでの時間です。2つ目は最初のデータが届くまでの時間で、リクエスト後に有効なデータを受け取るまでの待ち時間を示します。3つ目は継続的なスループットで、長時間の転送における安定速度を表します。4つ目は揺らぎと再接続で、Webページの連続読み込み、動画再生、バックグラウンド処理の安定性を左右します。ある構成の接続確立が少し遅くても、継続的なスループットが低いとは限りません。逆に初回接続が速くても、弱いネットワークで安定するとは限りません。

比較する際は、サーバー、ネットワーク、接続先、ルーティング規則、測定時間帯を固定してください。2つのノードが異なる地域にある場合、差の主因はプロトコルではなくネットワーク経路です。DNS名前解決や初回接続のキャッシュによる影響を減らすため、事前に1回ウォームアップすることも推奨します。クライアントの「遅延テスト」は、TCP接続や特定の探査先だけを測定し、実際のプロトコルハンドシェイクを完了しない場合があります。利用できるか判断するには、実際に接続してから目的のサイトへアクセスしてください。

プロトコル処理が唯一のボトルネックとは限りません

VMessには独自の認証とデータ処理があります。VLESSは安全性を外側の層に委ね、TrojanはTLSと組み合わせることが多く、Shadowsocksの負荷は暗号化方式に左右されます。VLESS + REALITY + Visionでは、さらにハンドシェイクとフロー制御が連携します。理論上の処理手順は違いを説明する手がかりになりますが、一般的なクライアント利用ではネットワーク往復、サーバーの処理能力、パケットロス、混雑がより大きな割合を占めることがよくあります。サーバーと回線の条件が近いときに初めて、プロトコル層の差を観測しやすくなります。

トランスポート方式も結果を変えます。TCP構成は経路が直接的で、WebSocketはフレームのカプセル化を追加し、gRPCはHTTP/2の仕組みを利用して多重化できる場合があります。多重化は接続数が多いほどよいわけではなく、過度に集約すると1本の下位接続の揺らぎが複数のリクエストに影響します。クライアントの同時接続、接続再利用、muxの項目は慎重に調整し、一度に1項目だけ変更して、初期値を比較基準として残してください。

メモリ、プロセッサ、バックグラウンド復帰

リソース使用量は、クライアント画面、コア、ルールセット、接続数、ログレベルによって決まります。プロトコルはその一部にすぎません。大規模なルーティング規則、詳細ログの常時出力、大量の同時接続は、単一のプロトコル項目よりメモリとプロセッサ使用率を大きく増やすことがあります。デスクトップのv2rayNはシステムプロキシ、トレイ状態、設定一覧も管理します。Androidクライアントはシステムのネットワークインターフェースで通信を処理し、バックグラウンド制御の影響も受けます。比較時は2回のテストでルールとログレベルを揃えてください。

ログレベルは長期観測を乱しやすい項目です。トラブル解決時は詳細ログが役立ちますが、確認が終わったら通常レベルに戻し、継続的な書き込みと整形処理を減らせます。ノードが多いだけでプロセッサを常時大量消費することは通常ありませんが、全件テストを頻繁に行うと多数の接続が同時に作られます。モバイル端末では自動テスト間隔を短くしすぎず、候補ノードだけを必要に応じてテストするほうが、結果を解釈しやすくなります。

モバイル端末のバッテリーは安定性と再接続頻度で決まる

モバイル端末の消費電力をVMess、VLESS、Trojanの順番だけで決めることはできません。無線モジュールの復帰、画面使用、電波強度、バックグラウンド維持、接続数、再試行方針が結果に影響します。理論上の処理が軽くても、数十秒ごとに切断と再接続を繰り返すノードは、長時間接続を安定して維持するノードより多くの電力を使うことがあります。まず安定した経路を選び、その後でプロトコル処理の差を比較してください。

v2rayNGまたはv2flyNGでノードを比較する場合は、ルーティングモードと対象アプリを揃え、不要な連続速度測定を停止し、通常利用の時間帯でシステムのバッテリー統計を確認します。テスト中はネットワークを頻繁に切り替えず、大規模なシステム更新も同時に行わないでください。スリープ後に接続がいつもシステムに回収されるなら、クライアントのバックグラウンド実行設定を確認します。これは端末のスケジューリングの問題であり、プロトコルを変更しても解決しない場合があります。

06 / CORES

V2FlyとXray：コアの系統、機能範囲、設定互換性

クライアント画面とプロキシコアは別々の構成要素です

v2rayN、v2rayNG、v2flyNGはいずれもグラフィカルな画面を提供しますが、実際のプロトコル解析、接続確立、ルーティング処理は通常コアが担います。画面はサブスクリプション管理、ノード編集、システムプロキシ、ログ表示、起動制御を担当し、コアは設定を読み込んでネットワーク処理を実行します。この分担を理解すると、互換性の問題を切り分けやすくなります。画面に項目が表示されるのはデータを保存できたことを示すだけで、コアが実行できるかどうかは対応機能に左右されます。

v2rayNはデスクトップ向けの第一候補で、Windows、macOS、Linuxに対応し、複数のノードとルーティング設定を管理できます。v2rayNGはAndroidでよく使われるクライアントで、主にXrayコアの機能を利用します。v2flyNGもAndroid向けですが、V2Flyコアの方針を採用しており、そのコアとの互換性が必要な場合の選択肢になります。3つのクライアントの導入先はダウンロードセンターにまとめています。端末のプラットフォームとノードの種類で選び、名前が似ていることだけを基準にしないでください。

V2FlyはProject Vの設定体系を引き継いでいます

V2FlyはV2Ray関連のコア機能を維持し、inbounds、outbounds、routing、dnsなどの一般的な階層構造を引き継いでいます。VMess、Shadowsocks、Trojanと、それらに対応するトランスポート機能を、サポート範囲内で構成できます。既存のV2Fly設定を使っている場合、固有の動作に依存している場合、同じコア体系を保ちたい場合は、v2flyNGがAndroid向けの直接的なグラフィカル入口になります。

「設定構造が似ている」からといって、すべての拡張項目が完全に共通するわけではありません。特定のコアにしか存在しない項目や、同じ名前でも利用できる値の範囲が異なる項目があります。完全なJSONを別のコアへコピーする前に、プロトコルとトランスポートの対応を確認し、その後でルーティング規則とDNS構造を確認してください。基本的なアウトバウンドは移行しやすい一方、実験的機能、専用フロー制御、拡張トランスポートは1項目ずつ検証する必要があります。

XrayはVLESS、REALITY、Visionなどの機能を拡張しています

XrayとV2Rayの設定体系には深い構造的なつながりがあり、多くの基本設定は似ています。XrayはVLESS、XTLS Vision、REALITYなどに対応する機能を提供しており、これらのノードがv2rayNGや、デスクトップで対応するコア環境に適している理由でもあります。ノード情報にREALITYの公開鍵、短い識別子、Visionのフロー制御が明記されている場合は、画面にVLESS種類があるかだけでなく、現在クライアントが実際に呼び出すコアが対応しているかを優先して確認してください。

コアの選択は、共有リンクを解析した後にどの項目が保持されるかにも影響します。クライアントはインポート時にURIパラメータを認識しても、コアの起動時に設定変換や検証を行うことがあります。ログに未知の項目、無効な値、未対応のフロー制御が出る場合、問題は通常、アドレスの到達性ではなく機能範囲にあります。この場合はノードの種類とコアの対応関係に戻って対処し、設定を通すために項目を無作為に削除しないでください。削除した項目が接続に必須の場合があります。

互換しやすい設定と、慎重な確認が必要な設定

アドレス、ポート、基本ユーザー識別子、標準的なVMess項目、一部の一般的なトランスポート、基本的なルーティング規則は、近い設定体系間で比較的移行しやすい項目です。DNSとroutingの基本階層にも共通概念があります。一方、REALITY、XTLS Vision、特定のトランスポート拡張、プロトコル専用設定、コアごとに追加された項目は、個別に確認が必要です。クライアントが生成する完全な設定には、ローカルの待受ポート、ログパス、プラットフォーム固有の設定が含まれることもあり、別の端末へそのままコピーするのは適切ではありません。

安全な移行方法は、ノードの共有情報を入力として、移行先クライアントにローカル設定を生成させることです。これにより、元のクライアントのローカルポート、キャッシュパス、プラットフォーム設定まで持ち込まずに済みます。その後、ルーティング規則を移行して1項目ずつ検証します。JSONを扱う必要がある場合は、最小限のアウトバウンドと必要なトランスポート項目を残し、接続を確認してからDNS、ルーティング、高度な設定を追加してください。1層追加するたびにテストすれば、直近の変更箇所を特定できます。

v2ray test -c config.json
xray run -test -c config.json

上記のコマンドは、対象コアの実行ファイルが正しくインストールされ、現在のコマンド環境から実行できる場合に設定構文を確認するためのものです。コマンドテストに合格しても、サーバーへ到達できるとは限りません。グラフィカルなクライアントでは、通常、クライアントを離れずに起動ログを確認できます。

07 / SUBSCRIPTION

サブスクリプション、共有リンク、クライアント互換性：項目がツール間でどう渡るか

サブスクリプションリンクは設定の集合を取得する入口であり、プロトコルそのものではありません

サブスクリプションリンクは通常、複数のノードデータを返し、クライアントが取得後にローカル設定へ解析します。VMess、VLESS、Trojan、Shadowsocksなど複数の種類を含められ、Base64でエンコードされた複数行の共有リンクを返すこともあります。サブスクリプションアドレスだけでは内部ノードのプロトコルは分からず、更新して解析した後に初めて具体的な種類を確認できます。サブスクリプションアドレスを単一ノードの編集欄へ直接貼り付けても、通常は正しく処理されません。

v2rayNでは、サブスクリプショングループまたはサブスクリプション管理画面にアドレスを保存し、その後に更新を実行します。v2rayNGとv2flyNGにも、対応するサブスクリプション設定と更新操作があります。更新後はまずノード数と種類を確認し、その後でノードを選んでテストしてください。一覧が空の場合は、アドレスが完全か、ネットワーク要求が成功したか、返された形式がクライアントに対応しているかを確認します。詳しい手順はv2rayNとv2rayNGのサブスクリプション導入ガイドをご覧ください。

主なURI形式に含まれる情報

vmess://は、JSON情報をエンコードしてリンクに埋め込む形式が一般的です。アドレス、ポート、UUID、トランスポート、Host、パス、TLSなどを含められます。生成ツールによって項目名に少し違いがあるため、古いリンクを新しいクライアントで解析した場合は手動で確認してください。vless://、trojan://、一部のss://リンクは標準URIに近く、認証情報はユーザー情報部分、アドレスとポートはホスト部分、その他のパラメータはクエリ文字列に入ります。

URIのパラメータ名には明確な意味があります。securityはTLSまたはREALITY、typeはトランスポート方式、flowはフロー制御、sniまたは同等の項目はサーバー名を示す場合があります。pbkとsidはREALITYの公開鍵と短い識別子に使われることが多い項目です。クライアントはこれらを認識し、コア設定へ正しく対応づける必要があります。共有リンクが長くても、情報が完全とは限りません。生成ツールが必要な項目を書き込んでいなければ、リンクが長くても不足情報を復元できません。

Base64は表現形式であり、特定のプロトコルを意味しません

多くのサブスクリプションでは、複数行の共有リンク全体をBase64でエンコードし、1つのテキストとして転送します。デコード後もvmess://、vless://、trojan://、ss://などの項目が複数残ります。Base64はノード情報を暗号化せず、クライアントの互換性も決めません。互換性は、デコード後のプロトコルリンク、拡張パラメータ、移行先クライアントの解析能力によって決まります。

あるクライアントではインポートできるのに、別のクライアントでは空になる場合、最初からサブスクリプションが無効だと判断しないでください。移行先クライアントが返却された種類に対応しているか、含まれるプロトコルを認識できるか、リンクの拡張パラメータをサポートしているかを順に確認します。v2flyNGとv2rayNGは異なるコア方針を採用しているため、REALITYやVisionを含むノードでは特に差に注意してください。複数種類のノードを含むサブスクリプションで一部だけ成功する場合は、サブスクリプション全体の取得失敗ではなく、プロトコルやパラメータの対応範囲が異なる可能性が高いです。

更新、重複排除、ローカル変更の扱い

サブスクリプションを更新すると、サブスクリプション管理対象のノードが上書きされることがあります。クライアント上でサブスクリプションノードを直接変更した場合、次回更新時に変更が失われる可能性があります。長期的に残したいローカル検証用の設定は、独立したノードとして複製して名前を変え、サブスクリプションの項目と混同しないようにしてください。ノード名が同じでも重複とは限らないため、削除前にアドレス、ポート、プロトコル、認証項目、トランスポート、安全性を比較します。

サブスクリプション更新後に突然接続できなくなった場合は、まずノードパラメータが変わっていないか確認し、その後でローカルプロキシ設定を判断します。サーバー側でアドレス、ポート、安全性の項目が変更されたり、クライアントの解析規則によって表示が変わったりすることがあります。更新前の設定を独立した比較用ノードとして残しておくと、どの層で変化したかを判断しやすくなります。すべてのサブスクリプションノードが同時にタイムアウトする場合は、ノードのタイムアウト対処手順に沿って、システム時刻、ローカルポート、ノードパラメータ、サブスクリプション状態を確認してください。

08 / DECISION

用途に合わせてプロトコルを選び、安全に移行する

既存の安定したノード：名称より互換性を優先

現在使っているVMess、Trojan、Shadowsocksのノードが安定して動作し、サブスクリプションも正常に更新され、クライアントがパラメータを完全に認識できているなら、新しいプロトコル名を見ただけで急いで移行する必要はありません。プロトコルの選択はまずサーバーの対応状況に制約され、ローカルの好みはその次です。安定した接続には、検証済みのサーバー設定、ネットワーク経路、クライアント構成が含まれており、理論上の比較より価値があります。

クライアントを変更する場合、デスクトップではv2rayNを優先し、AndroidではXray拡張を含む設定にv2rayNG、V2Flyコアが必要ならv2flyNGを選びます。移行前に、元のクライアントのプロトコル、トランスポート、安全性、サーバー名、パス、フロー制御、認証項目を記録してください。共有リンクまたはサブスクリプションからインポートした後、1項目ずつ照合します。名前とアドレスが一致するだけでは不十分で、拡張項目が欠けるとハンドシェイクで失敗することがあります。

新しい設定：まずコアを決め、次に構成を決める

新しいノードを作成する場合は、対象端末とクライアントから必要なコアの機能を逆算するとよいでしょう。デスクトップとAndroidの両方で使い、REALITYとVisionを含む設定にするなら、両方に適切なXray実行環境があることを確認してからVLESS + REALITY + Visionを採用します。V2Fly設定との一貫性を重視する環境なら、V2Flyの対応範囲からプロトコルとトランスポートを選びます。先にコアを決めれば、サーバー構築後に片方の端末で重要な項目を解析できない事態を避けられます。

パラメータを簡潔にし、手入力しやすくしたい場合で、サーバーとクライアントが同じ暗号化方式をサポートしているなら、Shadowsocksは明確な選択肢です。標準的なTLS設定を使い、パスワード認証と明確なTLS階層を求めるなら、Trojanは理解しやすく保守もしやすいでしょう。VMessは既存設定や過去のサブスクリプションとの互換性を維持するのに適しています。環境から切り離した絶対的な順位はありません。互換性、保守性、安定性、リソースの4項目を同じチェック表で比較してください。

不安定なネットワークとモバイル端末：まず再接続を減らす

ネットワークの変動が大きい場合は、理論上のカプセル化の少なさより、安定したサーバーと適切なトランスポートを選ぶことが重要です。ログで接続リセット、ハンドシェイクのタイムアウト、名前解決の繰り返しを確認します。ノードが頻繁に切断されるなら、無線信号、サーバー負荷、トランスポート設定、プロトコルパラメータのどれが原因かを先に切り分けてください。プロトコルを直接変更するとサーバーや経路も変わり、比較の前提が崩れることがあります。

Android端末では、連続した一括速度測定や頻繁すぎるサブスクリプション更新を減らし、ルーティング規則の規模を適切に保ち、必要に応じてクライアントがバックグラウンドで動作できるようにします。VLESS + REALITY + Visionは、完全な対応と正しいパラメータ一致を前提に、優れた処理経路になる可能性があります。ただし、安定したTrojanやShadowsocksノードのほうが実際の端末で良い結果を出すこともあります。通常利用の一周期における安定性、バッテリー、実際の接続結果で判断してください。

複数端末の同期：サブスクリプションを共有元にし、クライアント設定をローカル層にする

デスクトップとAndroidを併用する場合は、ノードサブスクリプションを共有元にし、システムプロキシ、対象アプリ、ルーティングモード、ローカル待受ポートは各端末で管理するのが適切です。プラットフォーム固有の項目が含まれるため、クライアント設定ファイル全体を直接コピーしないでください。サブスクリプション更新後は、両端でノード種類と拡張パラメータを確認します。ある種類のノードが片方にしか表示されない場合は、すぐにサブスクリプションから削除せず、その端末の解析機能とコア対応を確認してください。

ルーティング規則もプロトコルの選択と混同してはいけません。同じVLESSまたはVMessアウトバウンドを異なる規則から参照でき、ルーティングモードを切り替えてもノードのプロトコルは変わりません。「一部のサイトだけ開けない」場合は、まずリクエストが想定したルーティングに入っているか確認し、その後でノードを確認します。すべてのリクエストが失敗する場合に、プロトコルと接続パラメータへ戻ってください。2つの層を分けることで、効果のない変更を減らせます。

移行手順：追加、照合、検証、最後に整理

安全な移行は4段階に分けられます。1段階目は旧ノードを残し、現在使える項目を上書きせず、移行先のプロトコル設定を追加します。2段階目はアドレス、ポート、認証、トランスポート、安全性、フロー制御を1項目ずつ照合し、サーバー側も対応済みであることを確認します。3段階目は実際に接続し、ログを確認して目的のサイトへアクセスし、接続確立とシステムプロキシの反映を個別に検証します。4段階目は一定期間安定して使えた後、不要になった旧設定を削除します。

新しい設定に失敗した場合は、直近の利用可能な状態へ戻し、階層ごとに確認します。認証エラーならUUIDまたはパスワード、ハンドシェイクエラーならシステム時刻、サーバー名、公開鍵、短い識別子、タイムアウトならアドレス、ポート、トランスポート、起動時の未知の項目ならコアの互換性を確認します。プロトコル、トランスポート、ルーティング、DNSを同時に変更すると、ログから原因を特定しにくくなります。初回接続の詳しい検証手順はv2rayNGの初回接続完全ガイドを参照してください。