V2Rayプロトコルとコアガイド

プロトコルの階層と設定項目

プロキシプロトコルが定めるリクエストの伝え方

VMess、VLESS、Trojan、Shadowsocksはいずれも、クライアントからサーバーへ宛先を伝え、双方の取り決めに従って認証やデータの処理を行うプロトコルです。これらの名称だけでネットワーク環境全体を表すわけではありません。接続には、名前解決、通信方式、安全なハンドシェイク、出口のルーティングも関わります。v2rayNのサーバー設定に並ぶ項目も、実際にはそれぞれ異なる階層に属します。設定の可否を判断するときは、各階層を分けて考え、特定の項目だけですべてが決まると思わないことが大切です。

VLESSは複数の通信方式や安全レイヤーと組み合わせられるため、VLESSを使うという情報だけでは設定を完了できません。サーバーアドレス、ポート、ユーザーIDに加え、通信方式と安全方式、および組み合わせに必要な追加項目を確認してください。Trojanは通常TLSで通信を保護し、Shadowsocksでは暗号化方式が重要な設定項目です。サブスクリプションをインポートすれば項目を自動入力できますが、各項目の整合性が必要なことに変わりはありません。

通信方式が決めるデータの運び方

TCP、WebSocket、gRPCなどは、それぞれ異なる通信の運び方を表すもので、アカウントの違いではありません。WebSocketはリバースプロキシを経由する構成でよく使われ、パスやリクエストのHostが転送先の判定に使われる場合があります。gRPCではサービス名などの確認が必要です。通常のTCP設定には同じパスの意味はありません。WebSocketのパスを別の通信方式にコピーしても互換性は高まらず、設定が完了したと誤解するおそれがあります。クライアントに入力欄が表示されていても、現在の組み合わせでその値が使われるとは限りません。

TLSとREALITYは安全設定のレイヤーに属し、VMessやVLESSと同じ階層で置き換えられるものではありません。「VLESS + REALITY」はプロキシプロトコルと安全方式の組み合わせを表します。TCPは通信方式、Xrayは設定を実行するコア、v2rayNは設定を管理するGUIクライアントです。これらの名称が同時に使われても矛盾はありません。選び方を検討するときは、個別の名称ではなく、組み合わせ全体を明確にしてください。

トラフィックの取り込みと接続先プロトコルを別々に確認

システムプロキシ、TUN、AndroidのVPNモードはアプリの通信をクライアントに渡すための仕組みです。接続先のプロトコルは、受け取ったリクエストをサーバーへ送ります。前者が正しく設定されていても、後者のハンドシェイクが成功したとは限りません。接続先へのテストに成功しても、すべてのアプリが通信を取り込まれているとは限りません。v2rayNでシステムプロキシだけを有効にした場合、システムプロキシ設定を参照しないアプリは直接接続する可能性があります。v2rayNGでVPNモードを有効にした場合も、アプリごとの振り分けやLANのバイパス設定を確認してください。

ルーティングルールは、通信を取り込んだ後にドメイン、アドレスなどの条件で出口を選びます。DNSは宛先名をアドレスに変換する方法や、ルーティングでドメイン情報を利用できるかどうかに影響します。サーバーのアドレス解決と最終的な宛先の名前解決は別の処理です。前者に失敗すると接続を確立できず、後者に失敗するとクライアントが起動しているのにサイトを開けないことがあります。ログでそれぞれの段階を確認し、すべてをプロトコルの非互換として扱わないでください。

設定項目は階層ごとに記録しておくと便利です。まずアドレスと認証、次に通信方式、最後に安全レイヤーとルーティングの例外を記録します。変更は一度に1つの階層だけに行い、直前に動作していた設定も残しておきましょう。こうすれば、問題が起きたときに取り込み方法、プロトコルのハンドシェイク、名前解決のどこに原因があるかを判断しやすくなります。複数のクライアント間で移行するときに、目立たない追加項目を見落とすことも防げます。

プロキシプロトコルの設計上の違い

VMessとVLESS：認証と暗号化の役割

VMessはProject Vのエコシステムで初期から使われてきた主要なプロキシプロトコルです。ユーザー認証とデータ保護の仕組みを備え、宛先の指定だけでなく、安全性に関する役割も一部担います。そのため、ユーザーID、暗号化オプション、時刻に関わる認証条件などを設定します。VMessを扱う際は、現在の実装と過去の設定を区別してください。古いガイドにある互換性のための項目を、新規設定にそのまま推奨できるとは限りません。インポート後に認証エラーが出た場合は、暗号化方式を手当たり次第に切り替えるのではなく、ユーザーID、クライアントの時刻、サーバー側の要件を確認します。

VLESSは役割を絞ったシンプルな設計で、データ暗号化を外部の安全レイヤーに委ねます。ここでいう「シンプル」はプロトコルの役割を指し、どのネットワークでも遅延が小さくなるという意味ではありません。VLESSはTLSやREALITYとの組み合わせが一般的で、通信全体の安全性と接続コストは組み合わせて判断する必要があります。ユーザーIDが正しくても安全レイヤーの設定が誤っていれば接続できません。外部の安全レイヤーを無効にしても、同等の安全性が得られるわけではありません。

VMessは、すでに利用している互換性のある構成が適切に保守されている場合に、引き続き使う選択肢になります。VLESSはXrayの機能を活用する新しい構成でよく使われます。どちらを選ぶかは、クライアントの一覧でどちらの名称が新しいかではなく、サーバー側が何を提供しているかで決まります。サーバー側に該当する待ち受け設定がなければ、クライアントのプロトコルを切り替えても変換はできません。移行にはサーバーとクライアント双方の対応が必要で、アドレスとポートだけでなく、認証、通信方式、安全設定を再確認します。

Trojan：TLSを基盤とする安全な接続

TrojanはTLSで安全な接続を確立し、その中でプロキシ認証とリクエスト転送を行う設計です。通常、パスワード、サーバー名、証明書の検証に関する項目を設定します。認証と暗号化をプロトコル内部にまとめる方式とは異なり、成熟したTLS基盤を活用します。安全レイヤーの役割が明確になる一方、証明書、ドメイン名、ハンドシェイクを正しく設定する必要があります。パスワードが正しくても証明書の名前が違えば接続できず、証明書が有効でもプロキシのパスワードが正しいとは限りません。

Trojanを単に「パスワード付きTLS」と捉えるのも不十分です。通信の拡張機能や追加オプションへの対応はコアによって異なり、共有リンクですべての構成情報を表せるとは限りません。v2rayNやv2rayNGにインポートした後は、安全方式、サーバー名、通信方式、パスワードが保持されているか確認してください。ハンドシェイクエラーならまずTLSレイヤーを確認します。ハンドシェイクが成功して認証に失敗した場合は、パスワードとサーバー設定を確認すると、無駄な試行を減らせます。

Shadowsocks：設定は簡潔、方式の一致が重要

Shadowsocksは比較的早くから使われている、シンプルな暗号化プロキシ方式です。一般的な設定項目はアドレス、ポート、暗号化方式、パスワードです。現在利用する際は、具体的な方式と実装の対応範囲を確認してください。「Shadowsocks対応」というだけで、すべての派生方式が互換性を持つとは限りません。世代によって認証方法や鍵の要件が異なり、特定の方式では定められた形式の鍵が必要です。通常のパスワードに置き換えられるとは限りません。クライアントに方式名を保存できても、現在のコアが実装しているとは限りません。

Shadowsocksは設定項目が少なく、固定の接続先を直接管理したい場合に適しています。ただし簡潔だからといって、サーバー情報を省略できるわけではありません。TCPとUDPへの対応はサーバー、クライアント、現在の接続モードを合わせて確認してください。プラグインや追加のカプセル化も、すべてのコアで使える機能ではありません。古い共有リンクが追加コンポーネントに依存している場合は、3つのクライアントが現在どのように対応しているかを確認します。用途が分からない拡張項目は削除して使い続けるのではなく、設定の提供元に確認してください。

プロトコル選びでは、最終的に保守性を重視してください。現在のサービスが安定しているか、クライアントが継続して対応するか、設定を完全に移行できるか、問題発生時にログを読み解けるかが重要です。正常に動作している組み合わせを、名称が違うという理由だけで移行する必要はありません。新しい機能が必要になった場合に、移行コストとサーバー側の対応状況を検討するほうが、プロトコルの新旧だけを追うより有効です。

TLS、REALITY、認証の役割

TLSではサーバー名と信頼チェーンを確認

TLSは接続を暗号化し、サーバーの身元を確認します。クライアントに入力する接続先アドレスはドメイン名でもIPアドレスでも構いませんが、安全性の検証に使うサーバー名には独立した意味があります。あるアドレスに接続できても、そのアドレスに対応する任意の証明書を受け入れてよいわけではありません。証明書の有効期間、名前の一致、信頼チェーンを確認してください。システム時刻が大幅にずれていると、有効な証明書でも有効期間外と判断される場合があるため、安全なハンドシェイクの問題を調べる際は時刻の同期が基本です。

サーバー名は通常、クライアント画面のSNIまたはServerNameにあたる項目です。接続に使うアドレスとは異なる場合があります。接続アドレスはサーバーを探すためのもので、サーバー名はハンドシェイクと検証に使われます。WebSocketリクエストのHostはさらに別のレイヤーに属し、リバースプロキシでサイトを振り分けるために使われる場合があります。構成によってこれらの名前が同じことはありますが、同じ設定項目だと決めつけず、構成の説明に従って個別に変更してください。

TLSのアプリケーション層プロトコルネゴシエーションは、接続で使用するアプリケーションプロトコルを決める機能で、HTTP関連の通信方式が必要な構成でよく使われます。自由に有効化できる高速化オプションではなく、クライアントとサーバーの双方で互換性のある結果を得る必要があります。独自の項目を設定する前に、現在の通信方式で何が必要か確認してください。サーバー名、ネゴシエーションの一覧、通信方式を一度に変更すると、ログに記録された1つのハンドシェイクエラーから原因を特定しにくくなります。

REALITYは安全方式であり、単独のプロキシタイプではない

REALITYはXrayが対応する通信の安全方式で、VLESSと組み合わせて使われることがよくあります。独自の認証とハンドシェイクの要件があり、通常、サーバーから提供された公開鍵情報、許可されたサーバー名、Short IDなどが必要です。公開鍵情報はサーバーの身元とハンドシェイク設定に関わるもので、VLESSのユーザーIDの代わりにはなりません。ユーザーID、Short ID、公開鍵はそれぞれ役割が異なり、どれか1つを正しく入力しても、ほかの項目の不一致は補えません。

REALITYのクライアントフィンガープリント設定は、ハンドシェイクの特徴に影響しますが、認証条件の代わりにはなりません。見覚えのある名前を一覧から選んでも、公開鍵の誤りやShort IDの不一致は解消されません。フィンガープリント設定は現在のコアの実装にも依存するため、移行時は設定ファイルに文字列があるかだけでなく、認識されているかを確認してください。画面上に未知の項目が残っていても、起動時に未対応の値としてエラーになる場合があります。実行ログを確認してください。

VLESSのフロー制御項目も、通信方式と安全方式の組み合わせに照らして判断します。一般的なVision設定は特定の実装が提供するトラフィック処理機能で、すべてのVLESS接続で必須ではありません。サーバーが特定のフロー制御を要求する場合は、クライアントでも同じ設定を使い、対応状況を確認します。サーバー側に該当する設定がないのに、速度向上を狙って追加する必要はありません。インポート後にフロー制御項目が空でも、ただちにリンクが不完全とは判断せず、その構成で必要かどうかを確認してください。

ハンドシェイクエラーを段階的に確認

v2rayNで安全な接続の問題を調べるときは、まずサーバーアドレスを名前解決できるか確認します。次に、接続が接続先ポートまで届いているかを確認し、安全なハンドシェイクとプロキシ認証がそれぞれ完了したかをログで調べます。ポートに到達できても、認証が成功したとは限りません。反対に、接続がタイムアウトしても安全レイヤーが原因とは限りません。名前解決の失敗、パスの異常、サーバーが待ち受けていないなどの問題は、ハンドシェイク前に起きる場合があります。「接続できない」という概要だけでなく、ログに記録された段階を確認してください。

v2rayNGでREALITY設定を移行する際は、インポート機能がサーバー名、フィンガープリント、Short ID、公開鍵情報、フロー制御を保持しているか確認してください。クライアントの更新で画面上の項目名が変わることはありますが、パラメーターの意味はサーバー側の説明と一致している必要があります。元の設定で接続できて移行後に失敗する場合は、ネットワークの違いを疑う前にこれらの項目を比較します。ユーザーIDや認証情報が含まれるため、問題の確認目的でも共有リンク全体を公開しないでください。

TLSとREALITYは、エンドユーザーアプリ自体の安全対策に代わるものではありません。クライアントとサーバー間の安全な接続と、Webサイトで使われるHTTPSは異なる通信レイヤーです。サーバーの先にあるアクセス経路も別途考慮する必要があります。方式を選ぶ際は、信頼する対象、認証情報の保管方法、更新手順を確認してください。設定項目が少なく内容を把握しやすい組み合わせは、正体の分からない項目を多数追加するより長期的に管理しやすいことが多いです。

接続速度とリソース消費

初回リクエストと継続ダウンロードを分けて測定

VMess、VLESS、Trojan、Shadowsocksの性能は、接続全体を考慮せずに比較できません。最初にページを開くまでの時間には、名前解決、接続の確立、安全なハンドシェイク、プロキシ認証、Webサイトからの応答が含まれます。継続ダウンロードの速度は、帯域、混雑、サーバー負荷、取得先の制限に左右されます。同じ組み合わせでも初回の表示は少し遅い一方、転送速度を安定して維持できる場合があります。別の組み合わせはハンドシェイクが速くても、長時間接続ではパケットロスや速度制限の影響を受けることがあります。

v2rayNの接続テストで確認できるのは、そのテストリクエストが通る経路だけで、すべてのアプリの性能を示すものではありません。テスト先、接続の再利用状況、キャッシュが結果に影響します。ある接続先がテスト先にすばやく応答しても、動画、ソフトウェアリポジトリ、業務システムでも同じように速いとは限りません。比較する際は、クライアント、ネットワーク、取得先、接続モードをそろえ、初回リクエスト、継続アクセス、大容量ファイルの転送を別々に記録してください。複数の条件の変化をプロトコルだけの差と見なさないようにします。

TLSなどの安全なハンドシェイクには通信の往復と暗号処理が必要なため、往復遅延の大きいネットワークほど接続確立のコストが目立ちます。すでに確立され、アプリで再利用されている接続では、リクエストごとにすべてのコストが発生するわけではありません。実際の影響は、ブラウザーのコネクションプール、コアによる接続再利用、サーバーのアイドルタイムアウトによって変わります。比較では新規接続と確立済み接続を分けてください。そうしないと、先に測定した構成と後から測定した構成で、同じハンドシェイクを経験していない可能性があります。

暗号化、カプセル化、接続の多重化にはそれぞれコストがある

暗号処理の負荷は、プロセッサー、OSの実装、ハードウェアアクセラレーションに左右されます。同じ方式でもデスクトップ端末と省電力端末では結果が異なるため、デスクトップでの測定からスマートフォンのバッテリー消費を推測できません。VLESSが暗号化を外部の安全レイヤーに任せていても、接続全体で暗号処理の負荷がなくなるわけではありません。TrojanもTLSを利用するため、TLSの処理コストを考慮する必要があります。プロキシ層だけでなく、接続全体を観察してください。

WebSocketやgRPCなどの通信方式には、それぞれのフレーム構造、状態管理、導入経路があります。カプセル化を追加すると処理負荷が増える場合がある一方、リバースプロキシ設備、接続の再利用、ネットワーク経路によって実際の利点が得られることもあります。特定の環境で安定する通信方式が、生来的に速いとは限りません。まずサーバー側の要件を満たし、そのうえで追加のカプセル化が必要かを判断します。名称を増やすために、現在のアプリで不要なレイヤーを重ねないでください。

多重化を使うと複数の論理リクエストを既存の接続で処理でき、接続を繰り返し確立するコストを減らせます。一方で、基盤となる接続の混雑や障害の影響も共有します。基盤の接続でパケットロスが発生すると、ほかのリクエストも待たされることがあります。サーバーや中継機器のタイムアウト設定も多重化の効果に影響します。ブラウザーがすでにアプリケーション層で接続を再利用している場合、さらに多重化を追加しても明確な効果が得られるとは限りません。有効化するかどうかは、同じ条件での反復テストに基づいて判断してください。多いほどよいとは限りません。

リソースを比較する際はテスト条件をそろえる

v2rayNのリソース消費を比較する際は、2つの設定で同じタスクを行い、アイドル時、継続的な転送中、多数の短いリクエストを処理する段階に分けて観察します。メモリの常駐量には設定のキャッシュ、ルールデータ、実行時の管理処理が含まれ、現在の接続が同じ規模のネットワークリソースを使っていることを意味しません。GUIプロセスとコアのプロセスも分けて計測し、画面更新の負荷をプロトコル処理のコストに含めないようにしてください。ログを詳細にしすぎると、ディスクやプロセッサーへの負荷が増える場合もあります。

UDPを使うアプリは個別に確認してください。リアルタイム音声、ゲームなどのデータグラム通信では、ジッター、パケットロス、継続的な到達性が重要で、Webページのテストでは代用できません。組み合わせによっては、UDP転送に特定のカプセル化方式や実装が必要です。サーバーとクライアントの双方が対応している必要があります。テストに失敗した場合は、まず該当する通信経路が有効になっているかを確認し、その後で遅延を検討します。TCP通信だけに対応する接続が使えても、あらゆる種類の通信が正しく転送されるとは限りません。

性能を調整する際は基準となる設定を残し、一度に1項目だけ変更して、同じタスクを複数の時間帯に繰り返してください。効果が1回のテストでしか見られない場合は、すぐに恒久的な変更をしないようにします。一時的な最高値より、再現性のある安定した改善のほうが参考になります。接続方式とルーティングの影響を詳しく分けて確認するには、システムプロキシとルーティングモードの違いを参照してください。

Androidのバッテリー消費とバックグラウンド動作

VPNが常時有効でも、高負荷が続くとは限らない

v2rayNGとv2flyNGはAndroidのシステムVPNインターフェースを使ってアプリの通信を取り込めます。システムにVPN接続中と表示されるのは、通信を取り込むサービスが動作しているという意味で、プロセッサーが常に高負荷ということではありません。バッテリー消費には、通信量、接続によるスリープ解除の頻度、無線ネットワークの状態、暗号処理、DNSリクエスト、ほかのアプリのバックグラウンド動作などが影響します。通知アイコンが表示され続けることだけを根拠にクライアントの異常な電力消費と判断すると、実際に通信を発生させているアプリを見落とすおそれがあります。

Androidのバッテリー使用量では、元のリクエストがほかのアプリからのものでも、ネットワーク処理の一部がVPNクライアントに計上されることがあります。使用時間、フォアグラウンドとバックグラウンドの通信量、同じタスクでの比較も合わせて確認し、1つの割合だけで判断しないでください。動画の連続再生、大量のクラウド同期、短いプッシュ通知では負荷の構成が異なり、転送量、接続回数、端末のスリープ解除にそれぞれ影響します。同じプロトコルでも、タスクによるバッテリー消費の違いが、プロトコル自体を変更した場合の差を上回ることがあります。

モバイルネットワークでは、無線モジュールがスリープから動作状態に移る際にも電力を消費します。短い接続の頻発、保活の間隔が短すぎる設定、失敗後の繰り返し再試行は、動作状態の時間を長引かせる場合があります。設定の誤りでハンドシェイクを繰り返すときの消費電力増加は、通常動作でプロトコルの負荷が高すぎるのではなく、失敗を繰り返していることが原因かもしれません。まずログでタイムアウト、認証失敗、接続の再確立が繰り返されていないか確認してから、設定の簡素化やバックグラウンド動作を検討してください。

省電力設定は安定性と合わせて評価する

v2rayNGのバックグラウンド動作がシステムに制限されると、画面ロック後にサービスが中断することがあります。アプリが再び通信すると、接続を再確立する場合もあります。バッテリー制限を解除すると連続動作を維持しやすくなりますが、クライアントが動作する時間も長くなります。単純な省電力設定ではありません。まず利用目的を決めましょう。常時安定した接続が必要なら必要なバックグラウンド動作を許可し、特定のタスクでのみ使う場合は、終了後に接続を手動で切って不要な常駐を減らせます。

v2flyNGのバックグラウンド動作も、Androidのスケジューリングや端末メーカー独自の制御に左右されます。コア系列を変えてもシステムの制限を自動的に回避できるわけではなく、バッテリー消費が減る保証もありません。2つのクライアントを比較するときは、一方だけを起動し、ネットワーク、アプリのタスク、測定時間帯をそろえてください。一方がVPNサービスを維持し、もう一方がシステムに停止されている状態では、消費電力を公平に比較できません。異なるのはバックグラウンドでの稼働時間ではなく、同じタスクを完了するための消費電力です。

VPNモードとプロキシのみのモードでは、通信を取り込む範囲が異なります。プロキシのみのモードでは、通常、アプリ側でローカルプロキシを使う設定が必要で、端末全体の通信が処理されるわけではありません。省電力に見える場合も、処理する通信量が少ないだけかもしれません。アプリごとのプロキシ設定やLANのバイパスルールで不要な転送を減らせますが、通信経路も変わります。変更前に、どのアプリの通信をプロキシ経由にする必要があるかを確認し、バッテリー使用量を下げるためだけに想定した接続方法を損なわないようにしてください。

モバイルネットワークの切り替えとDNSは個別に確認

Wi-Fiとモバイルデータを切り替えると、アドレス、経路、システムのネットワーク状態が変わり、既存の接続をそのまま使い続けられない場合があります。v2rayNGが接続先に再接続する必要が生じたり、アプリが無効になったコネクションプールを保持したりすることもあります。切り替え直後に一時的に回復しないだけで、すぐにプロトコルの問題と決めつけないでください。長時間回復しない場合は、クライアントが再接続できるか、DNSが利用できなくなった経路を使っていないか、アプリが接続を再確立した後に正常動作するかを確認します。

DNSリクエストが失敗を繰り返したり、誤ったルートへ送られたりすると、バックグラウンドの動作が増える場合もあります。リモートDNSと直接接続で使うDNSには、それぞれ到達可能な出口が必要です。また、まだ確立されていないプロキシに依存してサーバー自身を名前解決する循環状態を避けてください。FakeDNSはドメインとアドレスの対応方法を変えるもので、省電力機能ではありません。有効にする前に、ルーティング、アプリのキャッシュ、VPNによる通信の取り込みとの関係を理解してください。詳しくはFakeDNSの仕組みと利用場面を参照してください。

バッテリー消費の調査は3段階で行えます。まず通常の設定で決めたタスクを実行し、次に画面ロック中のアイドル状態で異常な通信が続いていないかを確認し、最後にネットワークの切り替えを再現します。各段階でクライアントの状態、タスクの時間、エラーの種類を記録すると、バッテリー残量の割合だけを記録するより有効です。いずれかの段階で認証エラーが繰り返される場合は、消費電力を比較する前に設定を修正してください。そうしないと、誤った設定での再試行コストを測ることになります。

v2rayNGのバックグラウンド設定は、Androidのバッテリー消費とバックグラウンド動作のトラブル対処も参考にしてください。長期利用で目指すのは、タスクを安定して完了し、異常なスリープ解除を減らすことです。システムの使用量表示をゼロに近づけることではありません。プロトコル選びだけでなく、バックグラウンド設定、通信の発生元、ネットワーク品質も同じように重要です。

XrayとV2Flyのコア系列

共通のルーツがあっても設定が常に互換とは限らない

V2FlyはProject Vに関連する実装とコミュニティによる保守を引き継ぎ、Xrayは同じ技術エコシステムから独自の機能方針で発展しました。共通の概念や似た設定構造はありますが、機能、項目、動作はそれぞれ異なります。系列の関係を理解すると、プロトコル名や設定用語を把握しやすくなります。しかし「設定ファイルを自由に相互利用できる」と考えると、実際の移行で問題が起きます。互換性はプロジェクトの由来だけでなく、具体的な機能と項目ごとに確認してください。

REALITYや関連するVLESSのフロー制御に対応していることは、Xrayを選ぶ主な理由の1つです。一方、V2Flyには独自のプロトコル、通信方式、ルーティングの対応範囲があります。対応状況を調べる際は、古い記事やクライアントの過去の画面ではなく、現在インストールしているコアの機能を基準にしてください。機能は追加・変更され、設定項目も変わることがあります。本ページの機能一覧は、特定時点の情報を恒久的に保証するものではありません。移行前にクライアントのログと該当する設定ガイドを確認してください。

v2rayNはデスクトップ向けのGUIクライアントで、サーバー管理、サブスクリプションの解析、システムプロキシ、コアの起動などを担います。画面に設定項目があることは、その設定を入力できるという意味にすぎません。最終的には選択したコアが設定を実行します。コアを切り替えると、以前使えていた項目が対応しなくなる場合や、一部のサーバー設定が新しいコアに適さない場合があります。切り替える前に、対象の接続に必要なプロトコル、安全レイヤー、フロー制御を確認し、コア名だけで比較しないでください。

必要な機能に合わせてAndroidクライアントを選ぶ

v2rayNGは主にXrayコアの機能を活用したい場合に適したAndroidクライアントです。v2flyNGはV2Fly系列の実装範囲に合う設定を使うための選択肢です。両クライアントの画面や設定のインポート方法が似ていても、同じ共有リンクを取り込んだときに同じ動作をするとは限りません。特定の安全方式や拡張項目を含むリンクは、画面上の表示だけでなく、コアの対応状況を確認してください。

クライアントの更新とコアの更新は同じではありません。GUIはサブスクリプションを解析して実行用の設定を生成し、コアは実際の通信を処理します。どちらか一方が古いと、新しい項目を使えないことがあります。コアを交換しても古い画面から正しい項目が生成されるとは限らず、画面を更新しても実行ファイルが必要な機能に対応するとは限りません。「設定項目があるのに動作しない」ときは、設定の生成経路と実際に起動しているコアの両方を確認してください。

設定移行は実際の項目単位で確認

XrayとV2Flyの設定移行は、最小限の接続から始めてください。まずリモート出口を1つだけ設定し、認証と安全なハンドシェイクを確認します。その後でルーティング、DNS、追加設定を順に移行します。多数のルールを含む設定全体を一度にコピーすると、起動に成功しても、どの項目が無視されたのか、既定の動作がどう異なるのかを特定しにくくなります。プログラムがすぐ終了しなかったとしても、起動時の一部の確認を通過しただけで、すべての通信が期待どおりに動作する証明にはなりません。

ルーティング用のデータとコアの設定も分けて考える必要があります。ルールによってはドメイン分類やIPアドレス分類のデータを参照し、該当ファイルが使えるか、分類名が存在するか、読み込み先が正しいかが結果に影響します。必要なデータがないまま元のクライアントのルーティング設定をコピーすると、読み込みに失敗したり、期待どおりに一致しなかったりする場合があります。こうした問題は通常、接続先のプロキシプロトコルが機能しないこととは別です。起動ログとルールのマッチ状況を個別に確認してください。

カスタム設定は、誰が管理するかを明確にしてください。GUIクライアントは再読み込み、サブスクリプションの更新、設定変更後に実行用ファイルを再生成する場合があり、生成済みのファイルを直接編集しても変更が保持されるとは限りません。独自の項目が必要な場合は、まずクライアントが用意する設定画面を使い、保存場所と上書きのルールを確認してください。設定を書き出して比較するときは、認証情報が含まれる可能性に注意してください。問題を報告する前に、アドレス、ユーザーID、パスワードなどの機密情報を削除します。

コアを選ぶときは、必要な機能を満たすことを最優先し、その後に安定性と保守の手間を検討します。既存のV2Fly設定が正常に動作していて追加機能も不要なら、対応するクライアントをそのまま使えます。REALITYなど特定の組み合わせが必要なら、その設定を完全に入力・実行できるXrayの構成を選んでください。OSとチップに合ったインストーラーはクライアントのダウンロードページから選べます。プロトコル名ごとに別のクライアントを探す必要はありません。

共有リンクとサブスクリプション形式の互換性

インポートできても、一部の情報を読み取れただけの場合がある

サブスクリプションは設定を配布する方法であり、新しいプロキシプロトコルではありません。サブスクリプションのURLが返す内容は、複数の共有リンクの場合も、構造化された設定の場合もあります。クライアントはまず形式を識別し、内部の設定項目に変換します。インポート後にサーバー名が表示されても、解析できたのは一部の情報だけかもしれません。認証、安全レイヤー、通信方式がすべて保持されているか、編集画面で確認してください。名前が正しいこと、件数が合うこと、接続できることは、それぞれ別の確認事項です。

VMessの共有リンクは、エンコードした構造化情報を含む形式が一般的です。VLESSやTrojanのリンクは、アドレスとクエリパラメーターで設定を表すことが多く、Shadowsocksのリンクでは認証情報のエンコード方式や拡張パラメーターにも注意が必要です。生成ツールによって項目名やエンコードの詳細が異なる場合があるため、リンクのプレフィックスだけで互換性を判断しないでください。新しい項目を旧式のパーサーがエラーを出さず無視することもあるため、「エラーが表示されない」だけでは完全な互換性を証明できません。

サブスクリプションの応答に含まれるBase64エンコードは、内容を包むための形式であり、暗号化ではありません。サブスクリプションのURLを知る人が、サーバーや認証情報を閲覧できることが多いため、URL自体を機密情報として扱ってください。公開のスクリーンショット、ログ、質問文に完全なURLを載せたり、内容を不明な変換サービスに渡したりしないでください。形式を比べる必要がある場合は、必要な項目をローカルで確認し、機密情報を削除したコピーで問題を説明します。

再インポートより、設定項目を1つずつ比較

v2rayNとv2rayNGで同じ接続先を比較する場合は、アドレス、ポート、認証、通信方式、安全レイヤー、サーバー名、追加項目の順に確認してください。REALITYの組み合わせでは、公開鍵情報、Short ID、フィンガープリント、フロー制御も確認します。WebSocketではパスとリクエストのHost、gRPCではサービス名が必要です。項目が空欄なら、正当な既定値なのかインポートで欠落したのかを先に確認し、別の接続先の値を流用しないでください。

特殊文字が含まれると、インポート結果に差が出る場合があります。パスワード、メモ、パスに予約文字が含まれるときは、共有リンクの形式に従って正しくエンコードしてください。二重にエンコードすると、クライアントが元の値ではなく、エンコード済みの文字列を読み取る場合があります。手動でコピーする際は、改行、前後の空白、チャットツールによる途中切れにも注意してください。同じリンクが一方のクライアントでは動作し、もう一方では失敗する場合、サブスクリプションを何度も更新する前に、解析後の項目を比べてください。

構造化された設定と共有リンクは、同じ情報を入れられる形式ではありません。完全な設定には複数の出口、ルーティングルール、DNS、インバウンド、ポリシーが含まれる場合があります。一方、単一の共有リンクで表せるのは通常、1つの接続先と限られた追加情報です。完全な設定をリンクの一覧に変換すると、サーバー情報は残っても、通信の振り分けや名前解決の設定が失われることがあります。逆方向にインポートしても元の全体的な動作は自動で復元されません。移行時はサーバー設定とクライアント全体の設定を分けて処理してください。

設定例：ルールの参照先にも依存関係がある

以下はXrayまたはV2Flyの設定でよく使われるルーティング記述の例です。ルールから出口タグを参照する方法を示しています。実行可能な設定ファイル全体ではなく、既存の設定に組み込む必要があります。また、directという名前の直接接続用出口が定義されていることを確認してください。ルールではプライベートアドレス範囲を指定しているため、追加の分類データには依存しません。ただし対象はこの種のアドレスだけで、ドメインによる振り分け、DNS、すべてのLAN内検出通信を網羅するものではありません。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "fc00::/7"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

この設定例からも、JSONの構文確認だけでは不十分なことが分かります。括弧や引用符が正しくても、出口タグが存在しない場合や、GUIクライアントが別のルーティング構造を生成する場合は、期待どおりに動作しません。ルールの順序も重要で、先に一致したルールが出口を決める場合があります。GUIクライアントを使うときは、ルーティング設定画面で目的を表現し、例の内容を生成済みの設定ファイル全体に上書きしないでください。

サブスクリプションの更新後に一部の接続先が消えた場合は、サービス側で削除されたと判断する前に、応答形式、グループのフィルター、解析時の通知を確認してください。更新に失敗した場合は、URLへのアクセス、認証応答、内容の解析という3つの段階に分けて調べます。確認済みの接続設定を基準として残しておくと、配布形式と接続そのもののどちらに問題があるか判断しやすくなります。よくある操作上の疑問はヘルプセンターをご覧ください。

用途に合わせた選び方と検証

条件を整理してから組み合わせを選ぶ

デスクトップでv2rayNを使う場合は、まずサーバーが提供する組み合わせと端末側の接続要件を確認します。普段のブラウジングでシステムプロキシだけを使うなら、まずは単純な接続方法にしてください。システムプロキシを参照しないアプリも通信させる必要がある場合に、TUNを検討します。プロトコルは現在の接続先に合わせて選びます。正常に保守されているVMess構成は継続して利用でき、TrojanではTLSの条件、VLESSでは対応する安全レイヤー、Shadowsocksでは具体的な方式と鍵の要件を確認します。クライアントに多くの機能があっても、毎回すべてを有効にする必要はありません。

モバイルでv2rayNGを使う場合は、安定した再接続とバックグラウンドでの消費電力を合わせて評価してください。REALITYなどXrayの機能が必要なら、該当するパラメーターをすべて取り込める設定を選びます。V2Flyの実装に合った接続先を使う場合は、v2flyNGも選択肢になります。2つのクライアントで同じシステムVPN接続を同時に処理しないでください。比較する前にもう一方のサービスを停止し、システムの接続先切り替えによる中断を、接続先プロトコルの問題と誤認しないようにします。

開発やオフィス業務では、ブラウザー、コマンドラインツール、社内アドレス、依存パッケージのリポジトリなどを同時に使うことがあります。システムプロキシがすべてのツールに適用されるとは限らず、独自のプロキシ設定を使うプログラムもあります。その場合は接続を取り込む範囲とルーティングの例外を先に確認し、すぐに接続先のプロトコルを変えないでください。社内アドレスには明確な直接接続経路が必要なことが多く、DNSで該当する名前を解決できる必要もあります。特定のツールだけ失敗する場合は、そのツールが実際に使っているプロキシ設定から調べてください。

一度の判断ではなく段階を分けて検証

第1段階ではクライアントとコアが正常に起動するかを確認します。起動に失敗した場合は、システムプロキシを変更する前に、設定項目の形式、機能への対応、ファイルの依存関係を調べてください。第2段階ではリモート接続を1つだけ確認し、名前解決、安全なハンドシェイク、認証が完了するかを観察します。第3段階では実際のアプリを接続し、そのリクエストがクライアントに届くかを確かめます。第4段階でルーティング、DNS、特殊な通信種別を検証します。各段階の結果を明確にすれば、次に変更すべきレイヤーを判断できます。

接続できるのにWebサイトを開けない場合は、宛先の名前解決、誤った出口の選択、接続先サービスの異常を分けて確認します。テスト用アドレスに到達できても、成功したのはその通信経路だけです。ブラウザーが名前解決結果をキャッシュしていたり、アプリが古い接続を保持していたりすることがあるため、設定を変えた後はリクエストを新たに実行してください。必要に応じて影響を受けたアプリを再起動します。すべての設定を同時に初期化すると一時的に復旧しても、どの条件が改善に寄与したか分からなくなります。

DNSの検証では、アドレスが取得できたかだけでなく、想定する通信経路を確認する必要があります。直接接続のDNS、リモートDNS、サーバーのアドレス解決にはそれぞれ異なる役割があり、ルーティングルールがDNSリクエスト自体に影響することもあります。ブラウザーのセキュアDNSやキャッシュによって検査結果が変わる場合もあるため、1つのページで一度確認しただけで結論を出さないでください。詳しい手順はv2rayN・v2rayNGのDNS経路を確認する方法を参照し、目的を明確にしてからリクエストの実際の経路を確かめてください。

基準となる設定を残し、必要な機能から移行

設定を移行する際は、現在使えている接続先を残し、新しい組み合わせを別途インポートして個別にテストしてから、グループ設定と既定の接続先を移してください。新しい設定で別のコアが必要な場合は、ほかのよく使う接続先との互換性も確認し、1つを直すことでグループ全体に影響しないようにします。サブスクリプションの更新後も、安全レイヤー、フロー制御、通信方式などの重要項目を抜き取り確認してください。長く使う設定では、区別しにくいコピーを大量に保存するより、変更理由を記録しておくほうが役立ちます。

トラブル対処の記録は簡潔にまとめられます。クライアント、コア系列、プロトコルの組み合わせ、接続モード、失敗した段階、直近の変更を記録してください。パスワード、ユーザーID、サブスクリプションURLの全文は記録・公開しないでください。再現した時刻を中心にログを絞り込み、無関係な出力で実際のエラーが埋もれないようにします。設定の提供元に問い合わせる際は、「安全なハンドシェイクに失敗する」「インポート後にフロー制御の項目がない」などと伝えると、「速度が遅い」とだけ説明するより具体的な対応を得やすくなります。

選び方の基準は、必要な機能を満たし、日常のタスクを繰り返し安定して実行でき、問題が起きたときに原因のレイヤーを特定できることです。端末やネットワークの条件を問わない恒久的な速度ランキングはなく、プロトコル名を変えるだけですべての問題が解決するわけでもありません。まずサーバーに合った設定全体を使い、そのうえで条件をそろえて安定性、リソース消費、バッテリーを比較すると、信頼できる結論を得られます。設定を始める場合は入門ガイドへ、インストーラーが必要な場合はクライアントのダウンロードページへ進んでください。設定項目の意味は、本ページの各項目で確認できます。