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

1. プロトコル・伝送方式・セキュリティ層を区別する

クライアントの3つの設定項目は、それぞれ別のもの

プロキシ設定には、少なくともサーバーアドレス、ポート、認証情報、通信方式が含まれます。プロトコルはリクエストの宛先の表し方、ユーザー認証、データのカプセル化を定めます。伝送方式は、そのデータをどのような接続で届けるかを決めます。セキュリティ層は通信内容を保護し、接続先を検証します。VMess、VLESS、Trojan、Shadowsocksはプロトコル名、TCP、WebSocket、gRPCは伝送方式の設定に使われる名称です。TLSとREALITYはセキュリティ機構にあたります。異なるレイヤーの名称を同じ速度ランキングで比べても、意味のある結論にはなりません。

たとえばVLESSは、さまざまな伝送方式やセキュリティ層と組み合わせられるため、「VLESS」の一言だけでは実際の性能を判断できません。TCPは通常、接続をそのまま運びます。WebSocketはアップグレード時のハンドシェイクとフレームのカプセル化を加え、gRPCはHTTP/2の仕組みを使ってデータを運びます。組み合わせによってサーバー、リバースプロキシ、クライアントに求められる条件も異なります。画面で項目を選べるのは、クライアントがその選択肢を用意しているというだけです。サーバー側に対応する接続口が設定済みとは限らず、任意のプロトコルと伝送方式を自由に組み合わせられるわけでもありません。

設定内容を正確に説明するには

2つの接続を比較するときは、速度を論じる前にプロトコル、伝送方式、セキュリティ層、フロー制御、コアを明記しましょう。サーバーの設置場所、端末の種類、テストに使ったアプリも記録してください。プロトコル名だけを変えながらサーバーやネットワークも同時に変更しては、差がどのレイヤーから生じたのか判断できません。サブスクリプションに表示されるメモは通常、提供元が入力した説明であり、機能の検証結果ではありません。REALITYやVisionと書かれていても、実際の設定項目や起動ログの確認に代わるものではありません。

サーバー側の対応状況に合わせて選ぶ

すでにサブスクリプションを利用している場合は、そこで提供される一式の設定を優先しましょう。VMessノードを「アップグレード」するためにVLESSへ変更するのは避けてください。プロトコルを変えるには、サーバー側のインバウンドとクライアント側のアウトバウンドの両方を調整する必要があります。片方だけ変更すると、通信の内容を双方で解釈できません。サーバーを自分で管理している場合も、対応するプロトコルと伝送方式を確認してからクライアントを選びます。既存サービスを使いたいだけなら、ドロップダウンメニューから設定を推測し直すより、サブスクリプションのパラメーターをそのまま使う方が確実です。

トラブルシューティングもレイヤーに沿って進めましょう。アドレスを解決できない場合はドメイン名とネットワーク、ポートに接続できない場合は待ち受け状態と到達性を確認します。セキュリティハンドシェイクに失敗したら、サーバー名、時刻、認証パラメーターを確認してください。接続済みなのに目的のサイトへアクセスできない場合は、ルーティング、DNS、アプリのプロキシ設定を調べます。関連する項目だけを一つずつ変更すれば、正しい設定まで壊してしまうのを防げます。接続の具体的な問題については接続できないときの対処法もご覧ください。

2. VMess：認証・暗号化・旧式の設定項目

設計の目的と既存設定との関係

VMessはProject Vのエコシステムで早くから使われてきたプロキシプロトコルで、認証とデータ保護を重要な設計要素としています。一般的な接続にパスワードを加えるだけではなく、リクエスト情報やデータの流れをどのように構成するかも定めています。長く使われてきたため、多くのクライアント、サブスクリプション、解説記事で採用されていますが、過去の設定項目も残っています。古い記事を読むときは、当時の設定方法と現在のコアが受け付ける項目を区別してください。画面上の名称が同じだからといって、そのまま流用できるとは限りません。

VMessのユーザーIDには通常UUIDを使います。UUIDはサーバーアドレスではなく、別のノードのユーザーIDと使い回すこともできません。アドレス、ポート、IDが一致していても、伝送方式とセキュリティ層も一致させる必要があります。「UUIDさえ正しければ接続できる」と考えがちですが、サーバーがWebSocketを受け付ける一方でクライアントが直接TCPリクエストを送る設定では、期待どおりに通信できません。プロトコル認証が正しいだけでは、接続全体の一部しか確認できていません。

時刻や古い設定項目が問題を起こす理由

VMessの認証には時刻が関係するため、端末のシステム時刻が大きくずれていると認証に失敗することがあります。インポートはできても認証エラーが続く場合は、ユーザーIDを何度も入れ替えるのではなく、まず自動時刻合わせを有効にし、タイムゾーン表示と実際の時刻を確認してください。タイムゾーンは主に時刻の表示に影響し、重要なのはシステム時計が正確かどうかです。サーバー側の時刻も正常である必要があります。クライアントだけ時刻を合わせても、サーバー側にずれが残っていれば解決しません。

古い資料では、追加のIDに関する設定としてalterIdがよく登場します。現在の設定では通常ゼロを使い、対応するAEAD認証方式を採用します。古い解説との互換性を保つために値をむやみに大きくしたり、異なるコアでサブスクリプションの旧式パラメーターを機械的に流用したりしないでください。インポート時に非対応と表示された場合は、設定提供元に現在有効なVMessのパラメーターを確認し、クライアントとコアがどのように解析したかを調べましょう。古い項目を認識できないからといって、サーバーが必ず使えないとは限りません。

プロトコル内の暗号化と外側のTLSは分けて考える

VMessの暗号化オプションと外側のTLSは別のレイヤーです。画面の「自動」は通常、コアが対応状況に応じて暗号化方式を選ぶ設定であり、ノード全体を自動設定するものではありません。暗号化方式を手動で指定する場合は、接続の両端で同じ実装に対応している必要があります。処理コストはプロセッサーごとのハードウェアアクセラレーションの性能にも左右されるため、特定の方式があらゆる端末で最速とは限りません。外側のTLSには独自のハンドシェイク、サーバー認証、証明書チェーンの要件があります。プロトコル内の暗号化でこれらの確認を代用することはできません。

WebSocketではパスとHost、gRPCではサービス名などの伝送パラメーターも確認します。これらは伝送方式の項目であり、UUIDや暗号化オプションに入力するものではありません。パスは通常、末尾を含めて厳密に照合されます。先頭のスラッシュ、大文字と小文字、余分な文字も一致判定に影響することがあります。リバースプロキシが特定のパスだけを転送する構成では、アドレスとポートに接続できても、リクエストが通常のWebページ用の入口に送られ、ハンドシェイク異常や即時切断が起こる場合があります。

VMessを使い続けるケース

VMessのサービスが安定して稼働し、クライアントが必要な機能に対応していて、新機能を使う明確な理由がないなら、そのまま利用できます。プロトコルの移行では、インバウンド、サブスクリプションの生成方法、クライアントとの互換性を改めて確認する必要があります。ドロップダウンの項目を一つ変えるだけではありません。比べるべきなのは、現在の構成の安定性、保守の手間、端末への負荷です。名前がいつ登場したかではありません。サービス提供元から別の設定一式を受け取った場合は、元の設定を比較用に残し、グループを分けてテストしましょう。Web閲覧、ファイル転送、必要なUDP通信を確認してから移行します。

3. VLESS：軽量なプロトコルだけでは安全な設定にならない

プロトコルの役割を絞る設計上の選択

VLESSはプロキシリクエストの表現と外部のセキュリティ機構を分け、プロトコル自体を軽量にする設計です。VMessと異なり、同じ内蔵データ暗号化の仕組みを採用していません。基本的な設定では、通信の保護にTLSやREALITYなどの外部機構を使います。そのため、「プロトコル自体のオーバーヘッドが少ない」ことと「接続全体が暗号化されていない」ことは同じではありません。実際にどのように保護されるかは、ノード種別だけでなく設定全体を確認してください。名前に「軽量」の意味があるからといって、外側のセキュリティ設定を省略してはいけません。

ユーザーIDには通常UUIDを使いますが、VMessとVLESSではリクエスト形式が異なります。どちらにもユーザーIDがあるからといって、プロトコルを置き換えられるわけではありません。一般的な基本設定では、VLESSの共有リンクに含まれるencryptionパラメーターはnoneです。これはプロトコル内蔵の暗号化を使わないことを表し、TLSやREALITYを無効にする指定ではありません。クライアントに追加機能がある場合も、利用できるかどうかは具体的なコアとサーバー側の実装で確認してください。基本項目だけから対応状況を推測することはできません。

セキュリティ層とフロー制御をそれぞれ確認する

TLSを使う場合は、サーバー名が証明書の名前と一致し、端末が証明書チェーンを信頼できることを確認します。接続先にはドメイン名もIPアドレスも使えますが、認証に使う名前はサーバー側の案内に従ってください。「このIPに接続できる」ことは、「このIPが正しい証明書名である」ことを意味しません。サーバー名を別途入力するよう指定される構成もあります。クライアントが接続先から自動取得した名前が、その構成に合うとは限らないため、接続先と認証する名前の役割を分けて考えましょう。

flowも個別に理解しておきたい設定項目です。一般的なxtls-rprx-visionは伝送方式ではなく、すべてのVLESS接続で使える速度向上スイッチでもありません。対応するコア、サーバー設定、利用可能な伝送方式が揃っている必要があります。この機能を使っていないノードにflowを無理に追加すると、認証やデータ処理に失敗する場合があります。反対に、サーバー側でflowが必要なのにインポート時に抜けていれば、ノードが正常に動作しない可能性があります。

クライアント画面で設定項目を確認する

v2rayNでノードの編集画面を開いたら、「アドレスとID、伝送方式、セキュリティ層、フロー制御」の順に確認します。v2rayNGでも同じ順序で見れば、設定画面を行き来して推測する必要がありません。変更前に元の設定を保存し、一度に一項目ずつ変更してください。サブスクリプションから追加したノードを手動編集すると、次回の更新で変更が上書きされることがあります。テスト用のコピーを別の場所に作り、変更理由も記録して、サブスクリプションの基準設定を直接上書きしないようにしましょう。

インポート後に画面で見える項目が、コアに渡される最終設定と同じとは限りません。クライアントが既定値を補完したり、画面上の項目を別の内部形式に変換したりすることがあります。正しく設定されたかどうかは、設定生成時のメッセージと起動ログも合わせて確認してください。不明な項目やフロー制御に非対応というエラーが出た場合は、すぐに項目を削除せず、まずコアの選択と設定の組み合わせを確認します。エラーメッセージが示すのは現在の解析段階です。原因は項目の入力ミスではなく、コアとの不一致かもしれません。

利用できる条件と移行の判断

VLESSは、対応するサーバーがすでにあり、外側のセキュリティ層とフロー制御の組み合わせを明確に指定したい場合に向いています。他のプロトコルより遅延が必ず小さくなるわけではなく、サーバーの経路が異なれば、ネットワーク経路の違いの方が大きく影響することもあります。短時間の接続を大量に行うアプリでは、外側のハンドシェイクや接続の再利用が使い勝手を左右します。大容量ファイルを長時間転送する場合は、継続的なスループット、CPU使用率、サーバー負荷に注目しましょう。用途ごとに確認する必要があります。

VMessからVLESSへ移行する場合は、まず新しい設定一式を入手し、名前解決、通常のWeb閲覧、長時間接続、必要なUDPアプリをテストします。Webページが一度開いただけで、元のグループを削除しないでください。新しい設定にREALITYやVisionが含まれる場合は、サブスクリプション形式で必要な項目がすべて保持されているかも確認します。2つのプロトコルの背景と違いはプロキシプロトコルの比較も参考になりますが、実際の接続ではサーバー提供元のパラメーターに従ってください。

4. REALITYとVision：ハンドシェイクとデータ処理の役割

REALITYは独立したプロキシプロトコルではない

REALITYはセキュリティ機構で、VLESSと組み合わせて使われることがよくあります。Visionは関連するデータ処理機構です。クライアントのメモに「REALITYプロトコル」とまとめて書かれることは珍しくありませんが、設定時は役割を分けて理解する必要があります。プロキシリクエストはVLESSなどのプロトコルで表現し、REALITYは関連するセキュリティハンドシェイクと認証を担い、Visionは条件に合うデータの流れを処理します。それぞれ役割が異なるため、プロキシプロトコルの種類にREALITYを入力しただけで、他の項目が自動的に決まるわけではありません。

REALITYはTLS関連の仕組みを利用し、独自の認証パラメーターを使います。一般的な構成では、通常のWebサイトのTLSと同じ公開証明書の手順をプロキシサービスに設定する必要はありませんが、クライアント側で認証を省略できるという意味ではありません。クライアントには正しい公開鍵、サーバー名、shortIdなどが必要です。サーバー側で選ぶ接続先やその動作にも制約があります。アクセスできるWebサイトを適当に選べば安全な構成になるわけではありません。クライアントを選ぶときは、設定済みのパラメーター一式を使ってください。

間違って入力しやすい認証項目

サーバー名はserverNameまたは共有リンク内のsniで指定されることが多く、サーバー側で許可された名前と一致させる必要があります。公開鍵は、サーバーが保持する秘密鍵に対応するものです。クライアントにサーバーの秘密鍵を求めたり、入力したりしてはいけません。shortIdはサーバーが許可する識別子と一致させます。通常は16進数の文字列で、長さと内容の両方にコアの制約があります。任意のメモではなく、UUIDの一部を切り出して代用することもできません。特定の構成で空欄が許される場合はありますが、サーバー側でそのように設定されている場合に限ります。

フィンガープリントは、関連するハンドシェイクでクライアントがどのように振る舞うかを示す設定です。現在のコアが対応する項目を選んでください。任意に変更できる端末名ではなく、珍しいものほど有効というわけでもありません。共有リンクではfp、pbk、sidなどの略称が使われ、クライアント画面では日本語の名称で表示される場合があります。インポート後は意味を確認して項目を対応づけましょう。同じ略称が画面にないからといって、設定が失われたとは限りません。コアの更新で項目名が変わることもあるため、古い解説の記述より現在のコアの仕様を確認してください。

Visionが軽減するオーバーヘッド

通常のHTTPSアプリのデータはすでにTLSで保護されています。そのデータをプロキシのセキュリティ層でさらに運ぶと、処理が入れ子になります。Visionは、対象となるデータの流れを識別して処理する方法を最適化し、条件が合う場合に重複するカプセル化やコピーのコストを一部減らします。アプリ自身のHTTPSを取り除く機能ではなく、すべての通信が同じ最適化経路を通る保証もありません。リクエストの種類、接続段階、コアの実装、サーバー構成によって効果は異なります。理論上の利点を一定の速度倍率に置き換えることはできません。

小さなリクエストでは、DNS名前解決、接続の確立、ネットワークの往復に時間の大半がかかり、データ処理を減らしてもページの初回表示はほとんど変わらない場合があります。大容量データを継続して転送し、もともとCPUがボトルネックなら、最適化の効果が表れやすくなります。端末に余裕があり、サーバー回線が混雑している場合は、フロー制御を変更しても帯域幅の制限は回避できません。評価では、アプリの処理完了時間、CPU負荷、接続の安定性を合わせて見ましょう。クライアントが表示する遅延の数値だけで判断しないでください。

ハンドシェイクに失敗したときの確認順

まず、この組み合わせに対応するXrayコアを使っているか確認し、アドレス、ポート、UUID、セキュリティの種類、公開鍵、shortId、サーバー名、flowを順に確認します。一度に一項目だけ元に戻すか修正し、ログに記録されたエラーの種類を残してください。タイムアウトならまず到達性、認証失敗ならパラメーター一式、非対応項目ならコアとインポート形式を確認します。詳しい仕組みはREALITYとXTLS Visionの解説をご覧ください。サーバー側に対応する接続口がなければ、クライアントだけでこの構成を有効にすることはできません。

5. TrojanとShadowsocks：異なる2つのシンプルな方式

TrojanはTLSを使って接続を保護する

TrojanはTLSで接続を保護し、その中でプロキシ認証とリクエストの転送を行います。一般的に入力するのはパスワードで、VMessやVLESSでよく使われるUUIDではありません。このパスワードはプロキシサービスの認証情報であり、OSへのログインやWebサイトのアカウントに使うパスワードとは別のものです。クライアントとサーバーで伝送方式やセキュリティのパラメーターも一致させる必要があります。パスワード認証だからといって、サーバー名や証明書の検証を省略できるわけではありません。

Trojanの接続品質はTLSの設定に大きく左右されます。証明書の期限切れ、名前の不一致、システム時刻のずれ、証明書チェーンの不足などがあると接続を確立できない場合があります。こうした問題が起きたら、まずサーバー情報と端末の時刻を確認してください。「安全でない接続を許可する」を恒常的に設定すると、サーバー認証が弱まり、設定不備も見えにくくなります。証明書の問題を切り分けるために一時的なテストを行った場合も、最後は名前や証明書チェーンを修正し、テスト時の設定をそのまま使い続けないでください。

Shadowsocksは暗号化転送が中心

Shadowsocksは通常SSと略され、暗号化プロキシ転送を比較的シンプルな設定で行います。よく使われる項目はサーバー、ポート、パスワード、暗号化方式です。TLSを使う構成とはカプセル化や認証の設計が異なるため、TLSのサーバー名をそのまま設定してはいけません。追加の伝送機能が不要な構成では、項目が少ない分、入力ミスを減らせます。ただし、目的に合うかどうかは、クライアント、コア、サーバーが対応する具体的な方式によって決まります。

旧式の方式、AEAD方式、新しいプロトコルの派生方式には、それぞれ互換性の範囲があります。特に新しい方式では、鍵の形式や長さが明確に定められており、任意の文字列をパスワード欄に入力するだけでは使えないことがあります。「SS」と書いてあるからといって、すべての実装が完全に互換とは限りません。インポート時に暗号化方式が非対応と表示されたら、方式の正式名称と現在のコアの対応状況を確認してください。名前が似ている方式を自己判断で代用しないでください。両端で異なる方式を使うと、通常は通信を復号できません。

パスワード、エンコード、拡張パラメーターの注意点

共有リンクでは、区切り文字や特殊文字による誤解釈を防ぐため、パスワードや他の項目がエンコードされていることがあります。手動でコピーする際にエンコードされた文字列を途中で切ったり、余分な空白を加えたり、二重にデコードしたりすると、実際の認証情報が変わる可能性があります。まずクライアントの標準機能でインポートし、その後に画面上の項目を確認してください。サーバーで追加の伝送機能が必要な場合、サーバーとパスワードだけでは足りません。現在のコアがその機能を実装しているかも確認しましょう。ノードのメモにある名前だけから対応状況を推測することはできません。

TrojanとShadowsocksはUDPを扱う場合がありますが、プロトコルがUDPに対応しているだけでは、アプリのUDP通信がクライアントに取り込まれるとは限りません。ローカルのインバウンド、TUNやシステムの通信制御方法、サーバー側の転送許可も確認が必要です。Web閲覧はできてもリアルタイム音声が不安定な場合、まずパスワードを変更するのは避けてください。アプリが使う通信方式、クライアントが該当する通信を取り込んでいるか、ルーティングで想定したアウトバウンドへ送られているかを調べてから、サーバー側と戻り経路を確認します。

名前の順ではなく、既存の構成に合わせて選ぶ

TLSサービスを正常に運用していて、Trojanの設定一式が揃っているなら、明確な証明書管理の流れを活かしてTrojanを使えます。端末のリソースが限られ、サーバーが互換性のあるShadowsocks方式を提供している場合は、実際の動作を優先して確認する方法もあります。どちらが優れているかは、サーバーの回線、暗号化の実装、アプリの用途を踏まえて判断してください。一般の利用者にとっては、高機能に見える名前より、必要な設定が揃い、コアが対応し、目的の作業を安定して行えることが重要です。

6. 接続速度・リソース消費・スマートフォンの電池持ち

接続の確立と継続的な通信を分けて考える

体感速度には、少なくとも名前解決、接続確立、最初のデータが届くまでの時間、継続的なスループットが含まれます。クライアントの遅延テストがどこまで測定するかは、テスト方式によって異なります。ポートの応答が速くても、目的のWebページの応答が速いとは限りません。ページがすぐ表示されても、大容量ファイルを高速で転送し続けられるとは限りません。プロトコルを比較する前に、ページ表示の待ち時間を減らしたいのか、継続的な転送効率を上げたいのか、バックグラウンド接続による電池消費を抑えたいのか、目的を明確にしましょう。

TCP、TLS、追加の伝送ハンドシェイクは、接続確立時のやり取りを増やすことがあります。接続の再利用やセッション再開によって、繰り返し発生するコストを減らせる場合もありますが、効果は実装と接続の利用期間によって異なります。WebSocketやgRPCも単純に速い・遅いとは言えません。構造が増える一方で、特定のサーバー構成や接続管理の要件を満たすことがあります。往復遅延の大きなネットワークでは、暗号化方式のわずかな差より、通信が1往復増える影響の方が目立つことがあります。低遅延のネットワークでは、CPUやサーバーの帯域がボトルネックになる場合もあります。

リソース消費は接続全体の処理で決まる

CPU負荷は暗号化方式、ハードウェアアクセラレーション、カプセル化の層数、接続数、通信量に左右されます。メモリ使用量にはクライアント画面、サブスクリプションの記録、DNSキャッシュ、接続バッファ、ログも含まれるため、すべてをプロトコルの処理に帰属させることはできません。1接続あたりのオーバーヘッドが小さくても、多数の接続を同時に使えばリソース消費が必ず少なくなるとは限りません。比較では同じクライアントを使い、バックグラウンドの作業とテスト内容をできるだけ揃えましょう。画面描画や他のアプリが結果に影響することがあります。

多重化では複数の論理接続を一つの接続で共有できますが、輻輳制御、エラー復旧、接続のライフサイクルも変わります。条件が合えば接続を繰り返し確立するコストを減らせる一方、パケットロスや接続断が起きると複数のリクエストに影響する可能性があります。多重化を万能の高速化スイッチと考えたり、ある多重化設定をVisionなど別の構成にそのまま適用したりしないでください。まず既定の設定を使い、コアの対応状況とアプリの要件を理解してから、条件を揃えて比較テストを行いましょう。

スマートフォンの電池消費はプロトコルだけでは決まらない

モバイル端末の消費電力には、無線通信の起動、電波が弱いときの再送、頻繁な接続確認、バックグラウンド更新、アプリの動作が影響します。少量の通信を絶えず続けるだけでも、無線モジュールが低消費電力状態に移行しにくくなることがあります。一方、システムが接続を繰り返し終了させ、何度も再接続する場合も余分な処理が発生します。「バックグラウンドで接続を維持する」ことと「消費電力を最小限にする」ことにはトレードオフがあります。OSの電池管理、利用頻度、常時接続が本当に必要なアプリかどうかを踏まえて判断してください。

v2rayNGでは、システムのVPNインターフェースがアプリの通信を取り込みますが、すべてのアプリが同じ量の通信を行うわけではありません。全通信を取り込む設定、アプリごとの除外、バックグラウンドでのアプリの動作が消費電力に影響します。電池の減りが気になる場合は、まずOSの電池使用量を確認し、再接続の繰り返し、自動テスト、高頻度のログ出力がないか調べてください。省電力のためにバックグラウンド権限をすべて無効にすると、画面消灯後に接続が切れることがあります。画面消灯中の待機、前面での閲覧、ネットワーク切り替えを分けてテストしましょう。

再現できる方法で比較する

設定一式を2つ用意し、同じ端末とネットワークで同じ作業を交互にテストします。コールドスタートかどうか、接続を再利用したか、テスト時のネットワーク状態も記録してください。まず短いWebリクエストを試し、次に継続的なダウンロードを行い、最後に普段使うアプリのバックグラウンド動作をしばらく観察します。更新、クラウド同期、他の大容量通信を避け、各テストを数回繰り返してください。比較のためにTUNを2つ同時に動かすのは避けましょう。ルーティングが競合して結果に影響したり、一方のクライアントの通信がもう一方を経由したりする可能性があります。

7. V2FlyとXray：設定が似ていてもそのまま置き換えられるとは限らない

クライアントの画面と実行コアの役割

Project Vはこのエコシステムを理解するうえでの背景です。V2FlyとXrayは、関連するコアの異なる開発系統です。クライアントはサブスクリプションの管理、GUI設定、システムプロキシ、起動制御を担い、コアは設定を読み込んで実際の通信を処理します。この2つを混同してはいけません。v2rayNという画面名でも、特定のコアだけを実行するとは限りません。画面にプロトコルの一覧があっても、選択中のコアがすべての項目に対応しているとは限りません。最終的な機能は、実際に起動するコアと生成された設定によって決まります。

2種類のコアには、インバウンド、アウトバウンド、ルーティングなど共通する設定概念がありますが、機能の進化や各項目の制約は完全には一致しません。Xray系のREALITYやVisionなどの機能は、設定ファイルがJSONだからといって、そのままV2Flyに渡せるものではありません。反対に、一部のV2Flyの設定方法も、Xrayで同じ意味になるか確認する必要があります。互換性は「どちらもV2Rayのエコシステムに属する」という大まかな分類ではなく、プロトコル、伝送方式、セキュリティ層、個々の設定項目まで確認してください。

3種類のクライアントの選び方

Windows、macOS、Linuxのデスクトップでは、サブスクリプションの一元管理、ログ確認、ルーティング調整に便利なv2rayNがおすすめです。Androidでは通常、Xray系のv2rayNGをまず選びます。V2Fly固有の動作に依存する設定がある場合は、代替としてv2flyNGを検討してください。名前が似ている2つのモバイルクライアントは、画面だけが異なる同一の実行環境ではありません。ダウンロード先はプラットフォーム別ダウンロード、機能の違いは3つのクライアントの比較をご覧ください。

コアの切り替えは、実行ファイルを入れ替えるだけではありません。クライアントはコアごとに異なる設定項目を生成したり、一部のプロトコル選択肢を制限したりすることがあります。起動できない場合は、まず現在のコア名とエラーログを確認し、ノードに必要な機能が揃っているか調べてください。画面だけが更新され、実行コアが別の環境のままだと、インポートと設定生成は成功しても、起動時に初めてエラーが発生することがあります。クライアントが提供する管理方法に沿って変更してください。パスや呼び出し方法を把握せず、ファイルを手作業で混在させるのは避けましょう。

共通の基本構造で設定を理解する

以下は、ローカル端末からのみアクセスできるSOCKSインバウンドと、直接接続するアウトバウンドの例です。インバウンドとアウトバウンドの基本的な関係を示しています。リモートのプロキシサーバーには接続せず、ノードの認証情報も含みません。設定ファイルとして保存する前に、使用するコアがこれらの項目を受け付けるか確認してください。この最小構成では、インバウンドがアプリのリクエストを受け取り、アウトバウンドが外部への送信方法を決めることがわかります。リモートプロキシを使うには、該当するアウトバウンドをサーバー設定に合った完全なものへ置き換える必要があります。

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

ここではループバックアドレスを使い、待ち受ける範囲をローカル端末に制限しています。LANからアクセスできるアドレスに変更する場合は、アクセス制御とOSのファイアウォールも考慮してください。認証なしで公開範囲を広げてはいけません。ポートは実行中のクライアントと重ならないようにしてください。重複するとアドレスが使用中というエラーが発生します。設定ファイルの構造とクライアント画面の項目の対応関係は、inbounds・outbounds・routingの解説もご覧ください。

2段階に分けて移行を検証する

第1段階ではノードを1つと最もシンプルなルーティングだけで検証し、コアが起動してアプリからアクセスできることを確認します。第2段階でDNS、分割ルーティング、多重化、その他のカスタム設定を戻します。こうすれば、プロトコルの対応問題と追加ルールの問題を切り分けられます。不明な項目が出ても、起動するまで次々に削除しないでください。削除した項目がセキュリティやルーティングに必要な役割を担っている場合があります。まず対象のコアと機能を確認してから、そのコアで対応する形式に変換します。同等の機能に置き換えられない場合は、元の環境で使い続けることを明確にしてください。

8. サブスクリプション形式の互換性と用途別の選び方

共有リンク・サブスクリプション・実行設定の違い

単一ノードの共有リンクは1つの接続を記述します。サブスクリプションURLからは、更新されることのある接続情報の一覧を取得します。コアの実行設定には、さらにインバウンド、ルーティング、DNSなどの設定が含まれます。この3つは同じ形式ではありません。サブスクリプションURLを単一ノードの解析欄に貼り付けたり、実行設定全体を共有リンクとして読み込ませたりすると、失敗することがあります。トラブルシューティングの前に、手元のデータがどの種類かを確認し、クライアントの対応するインポート方法を選んでください。基本の手順はサブスクリプションのインポート方法をご覧ください。

よく使われる共有リンクの形式には、vmess://、vless://、trojan://、ss://があります。形式によってエンコード方法、パラメーター名、拡張項目の表し方は異なります。同じプロトコルでも、過去の共有形式が複数残っていることがあります。そのため、ブラウザーで開けることや、テキストが一見そろっていることだけでは、クライアントが解析できるとは限りません。サブスクリプションはリクエスト元に応じて異なる内容を返す場合もあります。URLが有効でも現在のクライアントに適さない形式なら、ファイルの拡張子を変えるのではなく、提供元に対応形式を確認してください。

変換で失われる情報

サブスクリプション変換では、通常、認識した項目を別の形式に割り当て直します。サーバーが実際に使えるかどうかを検証する機能ではありません。変換ツールが認識しない新しい伝送方式、セキュリティ機構、フロー制御、拡張パラメーターは、無視されたり既定値に置き換わったりすることがあります。ノードが一覧に残っていても、すべての機能が維持されたとは限りません。変換後は、REALITYの認証パラメーター、Visionのflow、WebSocketのパス、gRPCのサービス名などを特に確認してください。

不要な中間変換を減らすため、提供元が直接生成した対象クライアント向けの形式を優先してください。変換が必要な場合は、元のサブスクリプションを比較用に残し、まずノードを1つ選んで全項目を確認します。サブスクリプションURLはアクセス認証情報にあたる場合があるため、出所のわからないオンラインツールへ安易に入力しないでください。更新後にノード数が変わっても、プラン、グループのフィルター、サーバー側の変更が原因かもしれません。プロトコルの互換性だけに原因を求めないでください。共有リンクとサブスクリプションの違いはリンクのインポート方法もご覧ください。

目的に合わせて選ぶ順序

日常的なWeb閲覧では、現在のサービスの安定性と接続確立の速さを優先し、クライアントが設定全体を正しく読み込めるものを選びます。大容量ファイルの転送では、継続的なスループット、CPU使用率、途中で切断したときの復旧を確認してください。データ処理がボトルネックと判明した場合に限り、フロー制御や暗号化の実装を比較する価値があります。モバイル端末を長時間使う場合は、ネットワーク切り替え、画面消灯後の復帰、電池管理を含めてテストしましょう。低スペックの端末では不要なカプセル化やバックグラウンドの接続確認を減らしつつ、サーバー側で必須のセキュリティ機構は省略しないでください。

リアルタイム音声などUDPを使うアプリでは、まず端末側での通信の取り込みとサーバーまでの転送経路を確認してからプロトコルを比較します。複数の端末で同じサブスクリプションを使う場合は、各端末のコアが対応する構成を選ぶか、提供元に端末ごとの形式を用意してもらいましょう。同じサブスクリプションURLを使えるからといって、設定フォルダー全体をそのまま同期できるわけではありません。デスクトップのポート設定、モバイルのアプリ別ルール、システムプロキシ設定にはプラットフォームごとの差があります。端末ごとに管理し、別の端末の設定で上書きしないでください。

問題を再現できる基準設定を残す

最終的に設定を決めたら、クライアント、実際に使用するコア、プロトコルの組み合わせ、テストした用途を記録します。判断に関係のない宣伝上の名称を記録する必要はありません。サブスクリプションの更新やコアの切り替え前に、元に戻せる設定を保存してください。変更後はノードを1つテストしてから、すべてのルールを戻します。問題が起きたら最後に使えた基準設定に戻し、アドレス、認証、セキュリティ層、伝送方式、ルーティングの順に確認しましょう。適切なプロトコル選びとは、メニューに項目が多いことではありません。端末が設定を正しく実行し、必要なアプリを安定して使えることです。