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

設定のレイヤー：プロトコルだけでは接続を説明できない

設定を4つのレイヤーに分けて考える

クライアントに表示されるプロトコル名が示すのは、接続経路の一部にすぎません。アプリからローカルのプロキシ入口にリクエストが届くと、コアがルーティングに従って接続先を決めます。次にプロキシプロトコルが宛先と認証情報を包み、選択した伝送方式でリモートサーバーに接続します。セキュリティ層は、その通信を保護します。そのため、VLESS・TCP・TLSが1つの設定に含まれていても矛盾はありません。それぞれ別のレイヤーを担当し、相互に置き換えるものでもありません。互換性を判断するには、一覧のプロトコル名だけでなく、各レイヤーの組み合わせを確認してください。

ローカルの入口とリモート側のプロトコルも区別が必要です。ブラウザーがPC上のHTTPまたはSOCKSポートに接続していても、リモートサーバーが同じプロトコルを使うとは限りません。システムプロキシは、システム設定に従うアプリにローカルの入口へリクエストを送るよう指示する仕組みで、すべてのプログラムを自動的に経由させるものではありません。仮想NICモードはネットワーク層に近い位置で通信を受け取るため、対象範囲や権限、DNSの扱いが異なります。アプリが接続できない場合は、まずリクエストがコアに届いているかを確認し、その後でリモート側のプロトコルを調べると効率的です。

伝送方式とセキュリティ層の役割

TCPは信頼性のあるバイトストリームを提供します。WebSocketは接続確立時にHTTP Upgradeを行い、gRPCはHTTP/2の仕組みを使って通信を構成します。これらは接続の確立方法や中継設備との適合性を左右しますが、ユーザー認証用のプロトコルを置き換えるものではありません。パス、サービス名、リクエストヘッダーは通常、伝送設定に属し、パスワードではありません。クライアントがWebSocketを選択しているのにサーバーが通常のTCPとして待ち受けている場合、アドレス・ポート・ユーザーIDが正しくても、再試行を繰り返すだけでは解決しません。まず両端の伝送方式を一致させてください。

TLSはサーバーを認証し、通信を保護します。その際、証明書の名前、SNI、証明書の信頼チェーンが関係します。REALITYは別のセキュリティ層の仕組みで、対応状況はコアによって異なります。あらゆる項目をそのまま相互に置き換えられるわけではありません。サービス名にTLSと書かれていても、正しいセキュリティ層が有効とは限りません。画面上の設定、実際に出力された項目、実行ログを確認してください。接続先にIPアドレスを使い、検証にはドメイン名を使う場合があります。これらは役割が異なるため、見た目を揃える目的で同じ値にする必要はありません。

レイヤーごとに問題を切り分ける

設定を確認するときは、接続先アドレスとポート、プロトコルと認証、伝送方式、セキュリティ層、追加のフロー制御設定の順で記録するのがおすすめです。その後、ルーティング、DNS、ローカルのプロキシモードを確認します。前半の項目はリモート接続の確立に関わり、後半はどのリクエストがその接続を使うか、ドメイン名をどこで解決するかを決めます。すべての項目を一度に変えると、たまたま接続できても、どの変更が効いたのか分からなくなります。次のサブスクリプション更新後に問題が再発する可能性もあります。元の設定を保存し、一度に1つのレイヤーだけ変更すれば、結果を再現しやすくなります。

ログもレイヤーごとに読み解けます。接続拒否なら、まずアドレス、ポート、サーバーの待ち受け状態を確認します。ハンドシェイク失敗なら、セキュリティ層と伝送方式を確認し、認証失敗ならユーザー情報を照合します。ただし、これはあくまで確認の優先順位であり、原因を断定するものではありません。サーバー側から接続を切られた場合も、接続中断として記録されることがあります。同じ時刻のエラーと現在の設定を照らし合わせ、別のバックグラウンド通信のエラーを対象の接続と混同しないようにしてください。エラーの意味を詳しく知りたい場合は、Xrayコアの実行ログを読み解くメモも参照してください。

VMessとVLESS：認証と暗号化の違い

VMessが多くの機能をプロトコルに含める理由

VMessはProject V初期の主要プロトコルで、ユーザー認証やデータ保護などをプロトコル設計に組み込み、さまざまな伝送環境でプロキシ接続を確立できるようにしています。単に元のリクエストへパスワード項目を追加する仕組みではなく、ハンドシェイクとデータのカプセル化にも独自のルールがあります。そのため、クライアントとサーバーの両方が同じプロトコル仕様を理解している必要があります。実際の負荷は、暗号化の実装、CPU性能、外側の伝送方式、接続の多重化などによって変わります。「古くからあるプロトコル」というだけで遅いと判断したり、プロトコル名から回線の帯域を推測したりすることはできません。

現在のVMess設定では、通常AEAD認証方式が使われます。古い解説に頻出する追加IDは、過去との互換性に関わるもので、現在のチューニング項目として扱うものではありません。古いリンクをインポートして形式が古い、または認証に失敗すると表示されたら、追加IDを手当たり次第に試すのではなく、設定の提供元に現在の形式を確認してください。VMessでは時刻の同期も重要です。端末の表示日時やタイムゾーンと、実際のシステム時刻は分けて考え、認証に影響する時刻が正確かを確認します。暗号化方式を変えるより、まずシステム時刻を修正してログを確認するほうが有効です。

VLESSが外側のレイヤーに任せる処理

VLESSはプロトコル構造を軽量にする設計で、VMessと同じデータ暗号化の役割をプロトコル内では担わず、外側のセキュリティ層と組み合わせて使います。ユーザーIDは認証に使いますが、それだけで通信内容を保護できるわけではありません。そのため、一般的な設定ではVLESSとTLSまたはREALITYを組み合わせます。VLESSを選んだからといって、セキュリティ設定を省略できるわけではありません。クライアントのプロトコル項目に「暗号化なし」と表示される場合、それはそのレイヤーの説明であり、信頼できないネットワーク上を通信全体が平文で流れるべきという意味ではありません。

UUIDは一般的なユーザーIDの形式です。インポート時は、空白、改行、全角文字を混ぜず、元の値をそのまま保ってください。クライアントで新しいIDを生成することはできますが、ローカルで生成しただけではサーバー側の設定は変わりません。認証情報はサーバーに登録された値と一致する必要があります。もう1つ混同しやすいのがフロー制御です。全体を高速化するスイッチでも、すべてのVLESS設定に必要な項目でもありません。サーバー側で対応する設定が指定され、利用するコアと伝送方式の組み合わせがサポートされている場合に限り、指定値を使ってください。不明な場合はインポートした値を維持し、フロー制御の名前を自己判断で追加しないでください。

実際にどちらを選ぶか

安定して使えているVMess設定を移行するなら、明確な互換性要件、サーバー側の運用方針、実測で確認された問題など、具体的な理由が必要です。別のプロトコルがよく話題になるというだけで移行する必要はありません。クライアントがあるプロトコルに対応していることは、その種類の設定を扱えるという意味であり、設定の提供元が対応サーバーを運用しているとは限りません。VLESS設定を受け取った場合も、VMessにある項目をすべて探す必要はありません。プロトコルごとに認証とデータのカプセル化方法が異なるため、項目がないからといってインポートに失敗したとは限りません。別のプロトコルの項目を補うのではなく、同じプロトコルの説明と照らし合わせてください。

v2rayNで確認する場合は、サーバーの編集画面を開き、まずプロトコルの種類を確認してから、伝送方式、セキュリティ層、フロー制御を見ます。v2rayNGでも同じ順番で確認してください。クライアントの更新で画面上の項目名が変わることがあるため、判断基準は項目の意味です。コアを切り替えた直後に接続できなくなった場合は、変更前後のコア名とエラーを記録してください。UUIDを削除して作り直す必要はありません。元に戻す場合は、正常に使えていた設定全体を復元してください。同じ設定を続けて変更するより、比較対象を明確にしたほうが差分を特定しやすくなります。

リソース使用量を比較するのは、セキュリティ層と伝送方式が正しく設定されてからです。短いWebアクセスでは、DNS解決やハンドシェイクに時間がかかることがあります。連続ダウンロードでは、帯域、輻輳、暗号化の処理速度がより重要です。負荷の違いによって結論が変わることもあります。一般ユーザーは、提供元が継続的に保守し、クライアントが正しく認識し、手動で項目を補う必要のない組み合わせを優先してください。プロトコルを選ぶ目的は設定の曖昧さを減らすことであり、各設定に最も短い名前や最新の名前を当てることではありません。

TrojanとSS：パスワード以外に確認すべきこと

TrojanではTLS設定全体が重要

Trojanは一般に、TLS接続の内側で認証とプロキシリクエストを処理し、成熟したTLS実装で通信を保護します。クライアントでは通常、サーバーアドレス、ポート、パスワード、サーバー名を設定しますが、項目が少ないからといって検証が簡単とは限りません。証明書が対象の名前をカバーしているか、有効期限内か、サーバーが証明書チェーン全体を提供しているかが接続に影響します。パスワードが正しくても証明書検証に失敗する場合、問題はパスワードのレイヤーにはありません。まず安全な接続を確立できていないのか、接続後に認証が拒否されているのかを切り分けてから、確認箇所を決めてください。

サーバーアドレスとSNIは異なる値を使う場合があります。前者は接続先を決め、後者はTLSハンドシェイクと証明書名の検証に使われます。設定の提供元からIPアドレスとドメイン名を受け取った場合、ブラウザーでIPアドレスを開いて見慣れたページが表示されないからといって、プロキシ設定が間違っているとは限りません。プロキシの待ち受けサービスは、通常のWebサイトと同じ応答を返すとは限りません。元の項目を維持し、クライアントのログでハンドシェイク結果を確認したうえで、サーバー側が必要とする名前を提供元に問い合わせてください。よくあるドメイン名を適当に入力するのは避けましょう。

証明書検証の無効化を、通常の解決策として使うことはおすすめしません。サーバーの正当性を確認する機能が弱まり、システム時刻の誤り、名前の設定ミス、サーバー証明書の不備を見逃すおそれがあります。特定の端末だけで失敗する場合は、まずシステム時刻と証明書の信頼環境を比較してください。すべての端末で失敗する場合は、サーバー設定を優先して確認します。ハンドシェイクではアプリケーション層プロトコルのネゴシエーションが行われることもあります。クライアントとサーバーで明確な指定がある場合は、その値を設定してください。「選択肢が多いほど互換性が高い」と考えて、すべての値を追加するのは適切ではありません。

Shadowsocksの暗号化方式と鍵はセットで確認

Shadowsocksはクライアント画面でSSと略されることがあり、比較的コンパクトな暗号化プロキシ方式で通信を処理します。実際の互換性はパスワードだけでなく、暗号化方式やプロトコルの世代にも左右されます。従来のAEAD方式と新しい方式では、鍵の形式、認証の扱い、コアの対応状況が異なる場合があります。同じ名前の方式を選び、任意の文字列を入力しても、有効な設定になるとは限りません。提供元が指定した暗号化方式と鍵は1組のパラメーターとして扱い、パスワードだけをコピーして好みの方式に変更しないでください。

新しい方式の中には、通常のパスワードではなく、長さとエンコード形式が決まった鍵を要求するものがあります。クライアント上で「パスワード」と表示されても、どんな文字列でも使えるとは限りません。インポートに失敗した場合は、チャットツールによる文字列の欠落、特殊文字のエスケープ、現在のコアがその方式を実装しているかを確認してください。末尾の記号を削除したり、文字を置き換えたり、再エンコードしたりすると、正しい鍵を壊すおそれがあります。クライアントに設定を保存できても、コアが受け付けるとは限りません。起動時の設定チェック結果も確認してください。

プラグイン・伝送方式・プロトコル機能は別々に確認

SSの共有リンクにプラグインのパラメーターが含まれている場合は、現在のクライアントがそのプラグイン機構を認識して実行できるかも確認してください。コアが暗号化方式をネイティブサポートしていることと、クライアントから外部プラグインを呼び出せることは別の話です。プラグインを次々に変えて試すことはおすすめしません。提供元に、ネイティブのプロトコル接続が必要なのか、特定のカプセル化を組み合わせるのかを確認してください。クライアントが必要な機能に対応していない場合は、伝送パスの項目にプラグイン名を入れるのではなく、双方が対応する設定を選びましょう。項目名が似ていても、役割が同じとは限りません。

両者の実用上の範囲も異なります。TCPでWebページを開けても、UDPを使うアプリも動くとは限りません。UDP転送はサーバーの機能、ルーティング、ローカルの入口にも左右されます。まず一般的なWebアクセスで基本接続を確認し、その後、必要なアプリごとにテストしてください。日常的なサービスへの安定したアクセスが目的なら、パラメーターの出どころが明確な設定を優先します。特定アプリの通信動作も必要なら、UDP、名前解決、システムによる通信の取り込み範囲を確認項目に加え、あらゆる差をプロトコルの速度に結びつけないようにしましょう。

REALITY：セキュリティ層と設定項目の対応

REALITYは別のプロキシプロトコルではない

REALITYはVLESSと組み合わせて使われることが多いものの、両者の役割は異なります。VLESSはプロキシ認証とリクエストを扱い、REALITYはその外側のセキュリティハンドシェイクを処理します。TLSに関連する仕組みをもとに設計され、独自の認証とハンドシェイク処理を備えていますが、一般的なWebサイトの証明書設定と同じものではありません。この違いを理解すれば、「サーバーの種類：VLESS」と「セキュリティ層：REALITY」を重複した設定だと誤解せずに済みます。また、別のプロトコル設定でセキュリティ項目だけをREALITYに変更しても、サーバーが自動的に受け入れるわけではありません。組み合わせ全体がクライアントとサーバーの両方でサポートされている必要があります。

REALITYのクライアント設定には、接続先アドレス、サーバー名、公開鍵パラメーター、ショートID、クライアントフィンガープリントなどが含まれます。フロー制御の指定が必要な場合もあります。各項目はサーバー側の設定と対応しています。公開鍵パラメーターはクライアント側の認証計算に使うもので、サーバーの秘密鍵を入力する項目ではありません。サーバーの秘密鍵をサブスクリプションや共有リンクに含めてはいけません。バージョンによって画面上の項目名が変わることがあるため、項目の用途と提供元の説明を確認してください。「鍵」という名前だけを頼りに、同じ値を関連する入力欄すべてに貼り付けるのは避けましょう。

サーバー名・公開鍵・ショートID

サーバー名はハンドシェイクに使われるため、サーバー側で許可された値と一致している必要があります。自由に付けるメモではなく、実際の接続先アドレスと同じとも限りません。サーバー側ではハンドシェイク先なども設定されますが、クライアントから変更できるものではありません。完全な設定を受け取ったら、クライアントに必要な項目が正しく保持されているか確認してください。名前から接続先のWebサイトを推測し、別のドメイン名に置き換えるのは避けましょう。変更後のドメインを開けたとしても、現在のREALITYサーバー設定と一致するとは限りません。

ショートIDは通常、16進数の文字列で表され、サーバーと実装の形式要件を満たす必要があります。空欄が許されるかはサーバー側の設定によるため、空だから必ず設定漏れとは限りません。手入力では使用可能な文字と長さを確認し、空白や全角文字を混ぜないようにしてください。公開鍵も元の値をそのままインポートし、エディターが自動挿入した改行を含めて保存しないよう注意が必要です。サブスクリプションの更新前は使えて更新後に失敗した場合は、まずこれらの認証項目に変更がないか確認し、古い手動上書き設定が残っていないかを調べてください。

フィンガープリント・フロー制御と切り分け手順

クライアントフィンガープリントは通常、コアが提供するハンドシェイク実装の選択肢として機能します。画面に多数の名前が表示されていても、実際に呼び出されるコアがすべてに対応しているとは限りません。「未対応のフィンガープリント」や初期化エラーが出たら、まず実際に使われているコアと設定の提供元を確認してください。フロー制御もREALITYとは別の項目です。REALITYを有効にしただけで任意の値を設定してよいわけではありません。一般的な組み合わせにも適用範囲があります。特に伝送方式を変更した場合は、フロー制御が引き続き有効かを確認し、以前の設定の上級項目をまとめてコピーしないようにしてください。

問題の切り分けは3段階で進められます。第1段階では、指定されたアドレスとポートに接続できるか確認します。第2段階では、安全なハンドシェイクが完了するかを見て、サーバー名、公開鍵、ショートID、フィンガープリントを照合します。第3段階で、ユーザー認証、フロー制御、実際のプロキシリクエストを確認します。同じハンドシェイクエラーにも複数の原因があり、ログの一文だけで公開鍵の誤りと断定してはいけません。まず別のサブスクリプショングループにある同名の設定を使っていないか確認し、変更後にコアが設定を再読み込みしたことを確かめてから、エラーの時刻と接続試行を照合してください。

REALITYを使うには、設定の提供元がその構成を保守しており、現在のクライアントが設定を正しくインポートできることが前提です。一般的なTLSの証明書設定をすべてそのまま適用する必要はなく、設定の出どころを確認しなくてよいという意味でもありません。v2rayNまたはv2rayNGでは、正常に解析された元の値を維持してください。インポート機能がセキュリティ層を認識しない場合、画面の項目を埋めるために通常のTLSへ切り替えるのは避けましょう。まずクライアントとコアの互換性を確認し、その後、双方が対応する別の設定に切り替えるかを検討してください。

V2FlyとXray：クライアントが実行する範囲

GUIクライアントとプロキシコアは別のプロジェクト

このエコシステムを理解するにはProject Vから始めるとよいでしょう。V2FlyコミュニティはV2Rayコアの開発と保守を引き継ぎ、Xrayは関連するコードベースから派生して独自の機能や設定を発展させてきました。共通のルーツがあるため、基本概念や設定構造の多くは似ていますが、新機能が常に同期されるとは限りません。ダウンロード先が違うだけで機能は完全に同じファイル、と考えるのは誤りです。また、画面に「V2Ray」と表示されているだけで、実際にどのコアが動いているかを判断することもできません。実行状態やログに表示されるコア名を確認してください。

v2rayNはデスクトップ向けの主要なGUIクライアントで、サーバー設定、サブスクリプション管理、プロキシモード、コアの起動などを担当します。実際のプロトコル接続は、呼び出されたコアが処理します。v2rayNGはAndroidでよく使われるXrayコア対応クライアントで、v2flyNGはV2Flyコアを使う場合に向いています。この3つは異なるプロキシプロトコルではありません。モバイル端末では、デスクトップのように別のコアファイルをアプリへ自由に追加して同じ機能を得られるとは限りません。各クライアントのビルドと対応範囲に合わせて選んでください。

設定構造が似ていても自由に移行できるわけではない

どちらのコアにも、インバウンド、アウトバウンド、ルーティング、DNSなどの概念があり、基本項目の一部も似ています。そのため、単純な設定は移行できる場合があります。しかし、REALITY、特定のフロー制御、新しい伝送方式、拡張パラメーターを使う場合は、現在のコアが対応しているか確認してください。「JSONを読み込める」ことは、「JSON内のすべての項目を理解できる」ことを意味しません。起動時にエラーが出る場合もあれば、クライアント側で変換されたり、接続開始時に初めて問題が分かったりすることもあります。保存できたことは最初の段階にすぎず、互換性が確認されたわけではありません。

クライアント側で行われる変換にも注意が必要です。GUIクライアントは内部形式で設定を保存し、起動時にコア用の設定ファイルを生成することがあります。そのため、サブスクリプションの項目がそのまま最終ファイルに反映されるとは限りません。カスタム設定モードでは、GUIの一部のルーティングやDNS生成処理を経由しないこともあります。画面の設定を変えても動作が変わらない場合は、その設定がカスタム設定を使っているか、そのモードが全体設定を適用するかを確認してください。同じ種類のスイッチを追加し続けても、反映されない設定が増えるだけです。

比較できる基準を保って移行する

コアを切り替える前に、動作が確認できているクライアント設定を保存し、プロトコル、伝送方式、セキュリティ層、DNS、ルーティングモードを記録してください。新しいコアを初めて起動するときは、双方が対応しているシンプルな設定を使い、基本接続を確認してからカスタムルーティングを戻します。複雑なルール、実験的な伝送方式、複数の上級項目を一度に移行すると、失敗時に原因を特定しにくくなります。コアの起動失敗をリモートサーバーの障害と混同しないでください。設定構文の誤りや未対応の項目が原因で、コアが待ち受けを開始できていないこともあります。

対応バージョンは実際のインストール環境に基づいて確認してください。ただし、比較のためにいつまでも有効な対応一覧を作る必要はありません。クライアント、コア、サブスクリプション形式は、それぞれ別のタイミングで更新されます。新しいコアに項目があっても、現在のクライアントがインポートに対応しているとは限りません。逆に、クライアントに項目が表示されても、実際に使う実行ファイルが実装しているとは限りません。対応範囲の違いを報告する際は、「最新版で使えない」とだけ伝えるより、クライアント名、実際のコア名、プロトコルの組み合わせ、エラーの概要を示すと原因を特定しやすくなります。

日常的な選び方はシンプルにできます。デスクトップではまずv2rayNを使い、Androidでは設定に応じてv2rayNGかv2flyNGを選びます。名前が似ているからといって、上級設定を別のコアへそのまま移さないでください。オープンソースであることは、コードや開発・保守の過程を調べられるという意味であり、すべての派生版が同じ動作を保つという意味ではありません。プロジェクトの関係を詳しく知りたい場合は、Project V・V2Fly・Xrayのエコシステム解説をご覧ください。プラットフォームごとの操作の違いを比べるには、3つのクライアントの比較を参照してください。

接続速度・リソース使用量・Androidの電池消費

「速さ」を段階ごとに分けて考える

接続速度には、DNSの名前解決、サーバーへの接続確立、安全なハンドシェイク、最初の応答までの時間、継続転送時のスループットなど、複数の指標があります。プロトコルが影響するのはその一部で、回線やサーバーの影響のほうが大きい場合もあります。Webページがすぐ開いても、連続ダウンロードが速いとは限りません。ダウンロードのスループットが高くても、短い接続の応答が常に速いとは限りません。プロトコルを比較する際は、まずどの段階を測るのか明確にしてください。異なる指標を一つの「遅延」にまとめ、単純な結論を出すのは避けましょう。

説明可能な測定結果を得るには、端末、ネットワーク、サーバーの場所、アクセス先、測定時間帯をできるだけ揃えてください。測定前にサブスクリプションの自動更新、バックグラウンドの大容量通信、頻繁なヘルスチェックを停止し、ルーティングモードとDNSの方針も同じにします。その後、一方を午前、もう一方を夜に測るのではなく、2つの設定を交互にテストします。接続の再利用、DNSキャッシュ、TLSセッション再開で後続の通信が変わることがあるため、最初のリクエストとその後のリクエストを分けて記録してください。再現できない小数値にこだわらず、傾向を確認すれば十分です。

CPU・メモリ・接続の再利用は低ければよいとは限らない

暗号化処理、データのコピー、伝送のカプセル化、接続数はいずれもリソースを消費します。特定のハードウェアアクセラレーションにCPUが対応しているかどうかは、プロトコルヘッダーのサイズより重要なことがあります。外側でTLSを使う場合、内側に追加の暗号化があるかどうかも処理量に影響しますが、プロトコルが要求する保護を安易に無効化してはいけません。メモリ使用量は、アクティブな接続、バッファー、DNSキャッシュ、ルールセットに応じて増えることがあります。短時間の使用量増加を見たら、接続終了後に戻るか確認してください。通常のキャッシュをメモリリークと決めつけたり、アイドル時の画面だけでコアの優劣を比較したりしないようにしましょう。

接続の再利用は、接続確立を繰り返す負荷を減らせる一方、複数のリクエストが同じ接続を共有することで、輻輳や障害の影響を受ける場合もあります。有効にすると速くなるかどうかは、実装、伝送方式、アプリの負荷によって異なり、どの設定にも当てはまる最適なスイッチはありません。フロー制御や伝送方式の組み合わせによっては、再利用の方法が制限されることもあります。安定している設定は、まずデフォルト値のまま使うことをおすすめします。短時間の接続で再現性のある問題がある場合に限り、項目を1つずつ比較してください。再利用、並列数、バッファーを同時に増やして、短時間の変化を特定の項目の効果だと決めつけないでください。

Androidの電池消費はプロトコルだけでは決まらない

モバイル通信の電池消費は、無線通信がアクティブな時間に大きく左右されます。頻繁なキープアライブ、再接続の繰り返し、常時の接続確認、バックグラウンドアプリからの小さなリクエストが続くと、通信量が少なくてもネットワークが何度も起動し、電池を消費します。画面消灯後にシステムのバックグラウンド制限でプロセスが休止し、復帰時に再接続が発生することもあります。そのため、長時間のダウンロードで消費電力が低かったプロトコルでも、一晩の待機で省電力とは限りません。画面点灯中の使用と消灯中の待機を分けて観察し、アプリの使い方やネットワークの種類をできるだけ揃えてください。場面の違いをプロトコルのせいにしないようにしましょう。

仮想NICが通信を取り込む範囲、アプリごとの振り分け、DNSクエリもモバイル端末の負荷を左右します。全通信を取り込む設定では、より多くのバックグラウンド通信がコアを経由する可能性があります。アプリ単位やルール単位で振り分けると、経路やDNSクエリの数も変わります。ルーティングルールが広すぎたり、DNSの失敗が繰り返されたりすると、余分なリクエストや再試行が発生することがあります。電池消費が増えた場合は、まず連続エラー、頻繁なネットワーク切り替え、過剰な接続確認がないか調べてから、プロトコルを確認してください。バックグラウンド消費を抑えるためにクライアントのバックグラウンド動作をすべて禁止すると、プロキシの入口だけがシステムに残り、接続は停止している状態になるおそれがあります。

設定を安定させてから、不要な高頻度テストを停止し、バックグラウンド動作の権限を確認します。その後で異なるプロトコルの組み合わせを比較してください。通常の使用時間と待機時間の両方を含め、切断と再試行が起きていないか観察します。特定のアプリだけ電池を多く消費する場合は、すぐにコアを変更するのではなく、アプリ自体のバックグラウンド動作を確認してください。接続済みなのにWebページが開けない場合は、接続済みなのに閲覧できない場合のチェックリストに沿って確認します。接続不能による再試行が続くと、電池消費の測定結果も歪む可能性があります。

サブスクリプション形式：インポート後に確認すること

共有リンク・サブスクリプション・完全な設定ファイル

サーバーの共有リンクは通常、1つの接続設定を表します。サブスクリプションURLは複数の設定や、クライアントが認識できる形式のデータを返します。コアの完全な設定ファイルは別の形式で、ローカルのインバウンド、複数のアウトバウンド、DNS、ルーティングなどをまとめて定義できます。3つは拡張子を変えれば相互に使える同じファイルではありません。クライアントの「クリップボードからインポート」と「サブスクリプションURLを追加」も、処理するデータが異なります。サブスクリプションURLを単体のサーバーリンクとして読み込むと認識できない場合があり、コアのJSON全体をURL欄に貼ってもオンラインサブスクリプションにはなりません。

共有リンクの項目のエンコード方法はプロトコルごとに異なり、古い形式との差が残っている場合もあります。メモ欄の日本語、特殊記号、空白は適切なエンコードが必要です。Base64形式が使われることもありますが、これはサブスクリプションの内容を秘匿するための暗号化ではありません。リンクをコピーできても、チャットツールで転送した後に完全なままとは限りません。インポート件数がおかしい場合は、元の配布元から改めてコピーし、説明文、改行、末尾の句読点が混ざっていないか確認してから、クライアントの解析結果を見てください。すぐに見知らぬ変換ツールへ内容を渡すのは避けましょう。

件数が同じでも項目がすべて取り込まれたとは限らない

新しいセキュリティ層、フロー制御、伝送パラメーターが古いインポート処理で無視されることがあります。その場合、サーバー名、アドレス、ポートは表示されていても、重要な項目が保存されていない可能性があります。REALITYなどを使う設定では、インポート後に少なくとも1件を開いて、プロトコル、セキュリティ層、サーバー名、公開鍵パラメーター、ショートID、フロー制御が元の説明どおりか確認してください。WebSocketやgRPCでは、パス、リクエストヘッダー、サービス名を重点的に見ます。一覧に表示された件数だけで、サブスクリプション形式との互換性を判断しないでください。

サブスクリプションの更新、重複した設定、手動変更の扱いはクライアントごとに異なります。次回更新時に手動変更が上書きされる場合もあれば、上書き設定が新しい設定にも適用され続ける場合もあります。管理しやすくするには、サブスクリプションのグループとローカルのテスト用設定を分け、試すときは設定を複製してから項目を1つずつ変更してください。同じサブスクリプション設定を長期的に手書き編集しないようにしましょう。提供元がサーバーの設定を更新した後、ローカルの上書き設定と新しいデータが混ざると、各項目の出どころが分かりにくくなります。

ルーティング設定はサーバー設定と一緒に移行されない

別のクライアントへ移行してサーバー設定をインポートできても、DNS、ルーティング、アプリごとの振り分け、プロキシモードまで移行されるとは限りません。基本接続を確認した後、デフォルトのアウトバウンドとドメインの処理方法も確認してください。次のコードは、一般的なコア設定にあるルーティング構造の例です。ループバックアドレスだけをdirectというアウトバウンドへ送ります。これは完全な設定ではなく、単独では起動できません。実際の設定ファイルには、対応するアウトバウンドのタグが定義されている必要があります。このような短い例は項目の関係を説明するためのものであり、クライアントが生成した設定ファイル全体を置き換える用途ではありません。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "::1/128"],
        "outboundTag": "direct"
      }
    ]
  }
}

AsIsは、そのルーティング方針によってドメイン名をIPアドレスへ変換しないことを意味します。クライアント全体でDNSを使わなくなるわけでも、リクエストが絶対に名前解決されないわけでもありません。ほかのドメイン解決方針が、条件に応じて名前解決やIPルールの判定に関わることがあります。実際の動作は、コアとDNSの設定をあわせて確認してください。移行後にルーティング結果が変わった場合は、まずリクエストがコアに届いた時点でドメイン名とIPアドレスのどちらを使っているか確認し、その後にドメインルール、IPルール、最終的なデフォルトアウトバウンドを調べます。項目名だけで実際の経路を推測しないようにしましょう。

サブスクリプションの更新失敗とサーバーの接続障害は分けて考えてください。前者は設定の取得・解析段階、後者は実際の接続段階で発生します。以前の設定がまだ使えるなら、更新に一度失敗しただけでグループ全体を削除する必要はありません。まず更新リクエストが成功したか、応答内容が有効なサブスクリプション形式かを確認し、その後で形式を調べます。リストが空になるなどのよくある問題はFAQをご覧ください。解析と振り分けの設定を確認する場合は、V2RayのDNS振り分け設定も参照してください。設定の出どころに起因する問題を、プロトコルを適当に変更して回避しようとしないでください。

用途に合わせて選ぶ：必要な設定を見極める

デスクトップとモバイルで共通して使える機能を確認

デスクトップではまずv2rayNを選び、OSとCPUアーキテクチャに合ったダウンロード項目を選択します。インストール後は、設定の提供元が明示的にサポートしているプロトコルの組み合わせを使い、「機能をすべて使う」ために上級設定を有効にする必要はありません。安定しているVMess・Trojan・SSの設定があるなら、そのまま使い続けてもかまいません。VLESSとREALITYの組み合わせを受け取った場合は、実際に使うコアとインポートされる項目を確認してください。まずクライアント、コア、サーバーのすべてが対応する設定を選び、その後で用途に応じたリソース使用量を調整します。

Androidでは、設定がXrayの機能に依存する場合はv2rayNGを優先して確認してください。V2Flyの設定と保守方針を明確に使う場合は、v2flyNGも選択肢になります。2つのアプリを同時に有効にして比較するのは避けましょう。システムのVPN機能による通信の取り込みが干渉し、アプリの切り替えや接続の再確立が測定結果に混ざるおそれがあります。バックグラウンド利用では、想定する動作に必要なシステム権限と電池設定を先に確認してから、プロトコルを比較してください。アプリごとに通信を振り分ける場合は対象アプリの選択範囲も確認し、ブラウザーと目的のアプリが同じ経路を通っているか確かめます。

名前ではなく実際の通信内容で比較する

日常的なWeb閲覧やメッセージアプリでは短いリクエストが中心となるため、名前解決、接続確立、休止状態からの復帰を確認します。連続ダウンロードでは安定したスループット、端末の発熱、長時間接続の維持が重要です。UDPが必要なアプリは、その経路を個別に検証してください。どの用途でも、まず動作が確認できている基本設定で基準を作ってから、別の組み合わせと比較します。異なるサーバーの設定を比べた場合、分かるのはサーバーを含めた総合的な差であり、特定のプロトコルが本質的に優れているとは言えません。サーバー条件を揃えられない場合は、速度の順位より互換性と保守状況を優先しましょう。

複数端末での設定同期は、通常、各クライアントで同じサブスクリプションを利用することであり、デスクトップの設定全体をスマートフォンへコピーすることではありません。ローカルポート、システムによる通信の取り込み方法、アプリごとの振り分け、バックグラウンド権限は端末ごとに設定する必要があります。サーバーの取得元やグループ名は揃えても、その端末に合わないシステムプロキシ設定まで同期しないでください。移行後は、各端末でWebアクセス、必要なUDPアプリ、DNSの動作を確認します。同じサブスクリプションを使っていても、すべての端末でネットワーク動作が同じになるとは限りません。

元に戻せる確認手順を用意する

実際の作業は4段階に分けられます。第1段階では、設定の出どころと項目を確認し、リンクが完全で、認証情報が一致し、伝送方式とセキュリティ層が適合していることを確かめます。第2段階では、クライアントが正しいコアを使っているか、コアが正常に起動するか、ローカルの入口が動作するかを確認します。第3段階では、ルーティングをシンプルに保ち、DNSやプロキシモードを同時に変更せず、基本的なアクセスをテストします。第4段階で、アプリごとの振り分け、カスタムルール、任意の最適化を戻します。各段階で動作が確認できた状態を保存し、問題が起きたら1つ前に戻してください。こうすれば、後の最適化で生じた差をプロトコルそのものの問題と誤解せずに済みます。

失敗した場合は、問題がローカルとリモートのどちらで起きているかも判断します。コアの起動エラー、ポートの競合、システムプロキシ設定の残存は、ローカル環境の問題です。接続タイムアウト、ハンドシェイク失敗、認証拒否なら、ネットワークやサーバー側を調べます。Webページが開いても、名前解決の経路が想定と異なる場合は、プロトコル認証ではなくDNSやルーティングが原因かもしれません。DNSリークの確認と設定方法を参考に、問い合わせ経路を確認できます。測定結果は現在のネットワークとクライアントモードに照らして解釈してください。1つのページに表示された結果だけで全体を判断することはできません。

最後に、保守用の簡潔な記録を残しておきましょう。クライアント名とコア名、プロトコルと伝送方式の組み合わせ、必要なセキュリティ項目が揃っているか、ルーティングモード、最後に動作を確認した環境を記録します。問題を報告する際は認証情報を隠し、特定に必要な設定の構成とエラー概要だけを残してください。設定の提供元がパラメーターを変更したら、まずサブスクリプションを更新して内容を確認し、その後でローカルの上書き設定を調整します。このガイドでは判断の根拠を解説しています。インポートと接続の手順を最初から確認する場合は、クイックスタートガイドに戻り、基本の手順に沿って進めてください。上級設定を手当たり次第に試す必要はありません。