V2Rayのプロトコル・コア解説

設定の階層：各項目の役割を理解する

クライアントの「サーバータイプ」だけでは、接続全体を表せません。プロキシ接続は通常、アプリからの接続方法、プロキシプロトコル、伝送方式、セキュリティ設定、ルーティング先などで構成されます。アドレスとポートは接続先、UUIDやパスワードは認証方法、TCPやWebSocketはデータの運び方を示します。TLSやREALITYは別のセキュリティ設定です。項目ごとの役割を理解すれば、組み合わせ名を丸暗記するより設定を把握しやすくなり、サーバー側が指定するセキュリティ方式をプロトコルの選択欄に誤って入力することも防げます。

プロトコル・伝送方式・セキュリティ設定の違い

VMess、VLESS、Trojan、Shadowsocksは、このページで扱うプロキシプロトコルです。接続先の指定方法や認証、プロキシデータの扱いを定めますが、機能やセキュリティモデルはそれぞれ異なります。TCP、WebSocket、gRPCなどはデータの伝送方式です。TLSは広く使われている通信のセキュリティ機構で、REALITYはXrayエコシステムのセキュリティ機能です。通常はVLESSと組み合わせて使いますが、VLESSと同じ階層にある、単独でサーバータイプを置き換える選択肢ではありません。

VLESSの設定を確認するときは、まずサーバータイプ、次に伝送方式、最後にセキュリティ設定を確認します。たとえばサーバー側がTCPとREALITYを指定している場合、UUIDが同じだからといって、WebSocketと通常のTLSに変更してはいけません。同じVMessの設定でも、パスやホスト名、伝送方式が異なれば互換性がないことがあります。使えるかどうかは、一覧に表示されたプロトコル名ではなく、設定全体が一致しているかで決まります。

アドレス・名前・パスは別々の設定項目

サーバーアドレスは接続先、TLSのサーバー名は名前の検証とネゴシエーション、WebSocketのHostはアプリケーション層のリクエスト情報に使われます。値が同じ場合もありますが、常に一致するとは限りません。サーバー側から異なる値が指定されている場合に限り、それぞれ入力してください。経験だけを頼りに同じ値をすべての欄へコピーするのは避けましょう。ポートはサーバーの待ち受け口にすぎません。よく使われるポート番号だからといって、TLSが有効とは限らず、伝送方式が正しいことの証明にもなりません。

WebSocketのパスはサーバーとリバースプロキシの設定に合わせる必要があります。先頭のスラッシュ、大文字・小文字、クエリ部分が一致条件になる場合もあります。gRPCのサービス名は、一般的なWebページのパスとは別のものです。インポート後に空欄があっても、必ずしも設定漏れとは限りません。プロトコルによっては項目自体が不要で、クライアントが既定値を使うこともあります。別のチュートリアルにあるパスをそのまま追加せず、まずプロトコルと伝送方式の組み合わせを確認してください。

端末側の接続方法とサーバー側のプロトコルを分けて確認

デスクトップアプリがローカルのSOCKSまたはHTTPポートに接続すると、コアがルーティングに応じて直接接続するか、プロキシ経由で接続するかを判断します。ローカルポートとリモートサーバーのポートは別のものです。一方を変更しても、もう一方は変わりません。システムプロキシもプロトコルの一部ではなく、システムプロキシ設定を参照するアプリにのみ影響します。特定のアプリがプロキシを経由しない場合、すぐにリモート側のプロトコルを変更せず、まずそのアプリがどの接続方式を使っているか確認してください。

AndroidのVPNモードでは、システムの仮想ネットワークインターフェースが対象の通信を受け取り、コアに渡して処理します。デスクトップのシステムプロキシとは、適用される範囲が異なります。接続アイコンが表示されても、端末側の接続が確立したことを示すだけで、リモート認証や名前解決、ルーティングが正しいとは限りません。「端末でリクエストを受け取ったか」「どの経路に振り分けられたか」「リモート接続ができたか」の順にログを確認すると、問題を切り分けやすくなります。

VMessとVLESSの設計上の違い

VMessとVLESSは、どちらもProject V関連のクライアントでよく使われますが、設計の考え方は異なります。VMessはV2Rayの初期プロトコル群に由来し、認証やリクエストの処理、データ保護などをプロトコル設計に取り込んでいます。VLESSはXrayエコシステムで広く使われる軽量なプロトコルで、セキュリティ保護の多くを外側の仕組みに委ねます。サーバーの条件を無視した優劣はありません。サーバーが提供する設定と、利用中のコアが組み合わせ全体をサポートするかを基準に選びましょう。

VMess：現行の認証方式と旧設定を区別する

VMessのUUIDは認証情報であり、サーバーアドレスでも、自由に生成して差し替えられるメモでもありません。現在のVMess設定ではAEAD認証方式を使います。古い資料にある追加IDやalterIdは過去の互換性に関する情報で、古いチュートリアルを参考に適当なゼロ以外の値を入力してはいけません。旧方式への対応状況はサーバーやコアによって異なるため、古いサブスクリプションをインポートした場合は、提供元の最新の設定要件を確認してください。

VMessの認証では時刻が関係するため、端末の時計が大きくずれていると認証に失敗する場合があります。サーバーに到達できるのにハンドシェイクに失敗するときは、システムの日付、タイムゾーン、自動時刻設定を確認してから、UUIDとサーバーの状態を確認してください。ただし、VMessの失敗が必ず時刻のずれによるものとは限りません。伝送パス、外側のTLS、リモートポートの誤りでも接続に失敗します。単なるタイムアウト表示より、ログに記録されたエラーの段階を確認するほうが原因を絞り込めます。

VMessは複数の伝送方式と組み合わせられるため、プロトコル名だけでリソース負荷を判断できません。VMessとWebSocket、TLSを組み合わせた設定と、直接接続する設定では、ハンドシェイク、カプセル化、接続の再利用に違いが生じる場合があります。現在のVMess設定が安定して動作し、サブスクリプションも正常に更新でき、用途にも合っているなら、別の名称がよく見かけるという理由だけで変更する必要はありません。コアの対応を統一したい、不要な伝送レイヤーを減らしたいなど、明確な目的がある場合に移行を検討してください。

VLESS：ヘッダーが軽量でも安全性は別途必要

VLESSは主にプロキシリクエストと認証情報を扱い、VMessと同等のペイロード暗号化機能は備えていません。クライアントのencryption欄にnoneと表示されるのは、プロトコル上の正常な設定です。接続全体が平文で送信されることを意味するわけではありません。通信が保護されているかどうかは、外側のTLSやREALITY、ほかのセキュリティ対策も確認する必要があります。noneという一つの項目だけで接続全体の安全性を判断しないでください。

UUIDが複雑に見えるからといって、VLESSで外側の保護を省略できるわけでもありません。認証情報と通信の暗号化は、それぞれ異なる役割を担います。一般の利用者は、サーバー側から提供されたセキュリティ設定を含む組み合わせをそのままインポートしてください。設定項目を減らすためにセキュリティ層を無効化するのは避けましょう。セキュリティに関する説明がない設定しか提供されていない場合は、汎用のインターネット向け設定として使うのではなく、利用目的と導入環境を確認してください。

flow、伝送方式、サーバーの対応状況

VLESSのflowは、どの設定でも使える高速化スイッチではありません。一部のXray設定ではxtls-rprx-visionを使いますが、サーバー、クライアントのコア、伝送方式がそれぞれ対応している必要があります。この値を任意のVLESS設定にコピーすると、設定が拒否されたり、ハンドシェイクに失敗したりすることがあります。特に、サーバー側の根拠がないまま、直接接続の設定とWebSocketやgRPCの項目を混在させないでください。設定名は正しく見えても、組み合わせが無効になるおそれがあります。

クライアントの編集画面に項目が表示されていても、現在選択しているコアがその機能を実装しているとは限りません。VLESSの設定は、UUID、伝送方式、セキュリティタイプ、サーバー名、flowの順に確認し、REALITYの公開鍵とショートIDは別途照合してください。すべて一致しているのに接続できない場合は、コアのログに記録された具体的なエラーを確認し、認証・ハンドシェイク・名前解決の観点からヘルプセンターで原因を調べてください。

実際の選び方はシンプルです。現在も運用されているVMessサーバーは、提供された設定のまま使い続けます。サーバー側がVLESSとTLSまたはREALITYの設定を明示している場合は、その組み合わせに対応したXrayクライアントを選びます。プロトコルの移行は、タイプ選択を一つ変更するだけでは完了しません。認証方式とセキュリティ設定が異なるため、サーバー側から新しい設定一式を入手し、比較確認用に旧設定も残してください。

Trojan、SS、REALITY

Trojan、Shadowsocks、REALITYはサブスクリプションの一覧で並んで表示されることがありますが、同じ階層の代替項目ではありません。前の二つはプロキシプロトコル、REALITYはセキュリティ機能です。比較するときは、TrojanとTLS、VLESSとREALITY、Shadowsocksとその暗号化方式のように、組み合わせ全体を確認しましょう。「REALITYを使っている」という情報だけでは、必要なクライアントや設定項目を判断できません。

Trojan：TLSを前提に設定する

TrojanはTLSによるセキュアな接続を前提とし、クライアントは通常パスワードでプロキシリクエストを認証します。設定時はパスワードだけでなく、サーバー名と証明書の検証条件も確認してください。サーバーアドレスにはドメイン名やIPアドレスを指定できますが、TLSで使う名前はサーバーの証明書と設定に合っている必要があります。アドレスに接続できても名前が一致しなければ、プロキシリクエストを送る前に失敗することがあります。この場合、パスワードを変更しても解決しません。

証明書エラーが発生しても、証明書検証の無効化を通常の対処法にしてはいけません。検証を無効にすると接続のセキュリティが低下し、名前の入力ミスや端末時刻のずれ、サーバー証明書の異常を見過ごすおそれがあります。まずサーバー名、時刻、証明書の有効性を確認してから、サービス提供元に設定を問い合わせてください。自己署名証明書を使う専用のテスト環境では、その環境の信頼設定に従い、テスト時の方法を日常の設定に広げないようにしましょう。

Shadowsocks：暗号化方式も設定条件

ShadowsocksはSSとも略され、軽量なプロキシと暗号化通信を中心とする独自のプロトコル群です。クライアントでは通常、アドレス、ポート、パスワード、暗号化方式を設定します。暗号化方式は好みで選べる項目ではなく、サーバー側と一致させる必要があります。旧式のストリーム暗号、一般的なAEAD方式、新しいプロトコルの派生形では互換性が異なります。クライアントの選択欄に似た名前があるからといって、相互に接続できるとは限りません。

暗号化方式によって、パスワードの形式も異なる場合があります。テキスト形式のパスワードを受け付ける方式がある一方、新しい方式では所定の長さにエンコードされた鍵が必要です。テキストのパスワードをそのまま入力すると、ローカルでの解析時点でエラーになることがあります。インポート後にアドレスとパスワードしか表示されず、暗号化方式やプラグイン、追加パラメーターが保持されていない場合は、設定が不完全です。プラグインの要否はサーバーの説明とコアの対応状況に従って判断し、削除しても問題ないと決めつけないでください。

SSは設定がシンプルで、カプセル化レイヤーが少ない点がメリットになる場合があります。ただし、あらゆる端末で省電力になったり、通信速度が上がったりするわけではありません。暗号化の実装、プロセッサーの性能、通信品質、アプリのリクエストパターンによって結果は変わります。UDPを使うアプリでは、サーバーとローカルの接続口の両方がUDP転送に対応しているか確認してください。Webページを一度開けただけでは、UDP通信やすべてのアプリが使えることは確認できません。

REALITY：公開鍵・ショートID・サーバー名を確認

REALITYは一般的な証明書を使う構成とは異なる認証方式です。利用者が設定する主な項目には、サーバー名、公開鍵、ショートID、クライアントフィンガープリントがあります。公開鍵はサーバー側の設定に対応している必要があり、通常の証明書から適当に抜き出してはいけません。ショートIDも表示用のメモではないため、そのまま正確に入力してください。空欄が許可されるかどうかはサーバー側の設定によります。ほかの設定にある値を流用して埋めるのは避けましょう。

クライアントフィンガープリントはハンドシェイクの特徴に関する設定であり、端末の認証パスワードではありません。利用中のコアが対応し、サーバーの要件にも合う値を使ってください。むやみに変更しても性能が上がるわけではありません。サーバー名も任意のWebサイト名ではなく、サーバー側が許可した名前を指定します。接続できない場合は、ポートを何度も切り替えるより、サーバー名、公開鍵、ショートID、フィンガープリント、時刻、flowの順に確認するほうが効果的です。

最終的な選択は、サーバーの対応状況に基づいて判断します。標準的な証明書検証を使う場合は、設定が明確なTrojanを検討できます。既存のSSサーバーを使う場合は、まず暗号化方式の互換性を確認してください。REALITYを使う場合は、その組み合わせに明確に対応したXrayコアを選びます。プロトコル名を変更するだけで移行できる方法はありません。サブスクリプションの設定全体が、クライアントの接続条件になります。

接続速度とリソース負荷

「接続が速い」には、少なくとも三つの異なる指標があります。初回リクエストが成功するまでの時間、連続ダウンロードのスループット、ページ内の多数の小さなリクエストが完了するまでの時間です。プロトコルのヘッダーが短ければ処理負荷が少し軽くなる可能性はありますが、ネットワーク上の往復回数が減るとは限りません。連続通信のスループットが高くても、ページを初めて開く速度が上がるとは限りません。選択前に、主な用途が短いリクエスト、長時間の接続、動画転送、頻繁なスリープ復帰のどれかを確認し、一つのテスト結果ですべてを判断しないようにしましょう。

ハンドシェイクの流れを分けて考える

初回のリクエストでは、名前解決、基盤となる接続、セキュリティネゴシエーション、プロキシ認証、接続先サイトへの接続が順に行われることがあります。伝送方式によっては、アプリケーション層の接続処理がさらに加わります。各段階の所要時間が初回応答に影響するため、サーバーとの距離、名前解決の状態、パケットロスは、プロトコルヘッダーの小さな差よりも大きく影響する場合があります。名前解決がタイムアウトしているなら、認証プロトコルを変えても待ち時間は解消しません。

WebSocketやgRPCなどの伝送方式は、特定のサーバー構成に適していますが、独自のカプセル化や接続管理も伴います。直接接続する方式は構造がシンプルな傾向にある一方、サーバー側の接続条件に合っている必要があります。「レイヤーを減らしたい」という理由だけで伝送設定を削除しないでください。接続先の正しいサービスへリクエストが届かなくなり、同等のまま高速化されるわけではありません。サーバーが実際に提供する組み合わせで比較してください。

CPU・メモリ・スループットの関係

暗号化処理、ユーザー空間でのデータ転送、バッファーのコピー、ルール照合はいずれもリソースを消費します。端末のハードウェアアクセラレーション、コアの実装効率、アプリが同時に確立する接続数も結果に影響します。低性能な端末ではCPUが先にボトルネックになり、デスクトップではリモート側の帯域が主な制限になることがあります。プロトコル名だけでリソース負荷の順位を決めると、実際のボトルネックを見落とし、調整できる項目も特定しにくくなります。

メモリ使用量はプロトコルの負荷と同じではありません。ルールデータベース、名前解決キャッシュ、接続数、クライアント画面、ログキャッシュもメモリを使います。長時間の利用後に起動直後よりメモリ使用量が増えていても、プロトコルのメモリリークとは限りません。確認するときはクライアントとコアのプロセスを区別し、同じ負荷条件を保ってください。増加が続いて戻らないかを確認してから、問題を報告するか判断しましょう。

接続の再利用とキープアライブは用途に応じて検証

接続を再利用すると、接続確立を繰り返すコストを減らせますが、複数の通信が伝送状態の一部を共有することにもなります。ネットワーク上のパケットロス、サーバーの実装、接続を閉じる条件によって効果は変わります。すでに成熟した多重化方式を使う構成では、別の再利用オプションを追加しても効果がないことがあります。一部のサイトだけが応答しない、大きなファイルは正常なのに小さなリクエストは不安定といった場合は、設定のコピーで追加の再利用を無効にし、問題が解消するか比較してください。

キープアライブにもトレードオフがあります。頻繁に通信を維持すれば、アイドル後の再接続を減らせる一方、モバイル通信の無線モジュールが起動する回数が増える可能性があります。間隔を長めに設定すればバックグラウンド通信を減らせますが、最初のリクエストで接続を確立し直すことがあります。常時給電するデスクトップと、待機状態になるAndroid端末に同じ「性能最適化」設定を適用しないでください。具体的な問題が見つかるまでは、既定値を検証の基準にするのが適切です。

再現できる比較方法

バックグラウンドのダウンロードを止め、同じルーティング設定を使って、二つの設定が同じ通信経路に接続することを確認します。その後、初回接続と一定時間の連続通信をそれぞれ複数回行い、一度の結果だけで判断しないでください。失敗率、初回応答、連続通信の安定性、端末の発熱を記録します。クライアントの遅延テストは、特定のテスト先やハンドシェイクの一部だけを測る場合があります。Webページ全体やUDP通信の使い勝手を自動的に表すわけではありません。

二つの設定でサーバーが異なる場合に分かるのは、「現在の条件ではこの二つの設定の結果が異なる」ということだけです。特定のプロトコルが必ず速いとは結論づけられません。プロトコルの影響だけを比較するには、サーバーの場所、帯域、負荷をできるだけ揃える必要があります。条件を揃えられない場合は、一度のテストで見えた小さな差をもとに頻繁に切り替えるより、互換性、管理のしやすさ、安定して使えるかを優先しましょう。

V2FlyとXrayのコア

このエコシステムを理解するうえで、Project Vの歩みが参考になります。初期のV2Rayは、インバウンド、アウトバウンド、ルーティング、伝送方式を組み合わせるアーキテクチャを確立しました。V2FlyはV2Ray関連コアの開発を引き継ぎ、Xrayはこの技術を基盤に独自の分岐として発展し、プロトコルや伝送機能を追加しています。共通する用語や設定の考え方はありますが、名前の異なる二つのファイルを無条件で置き換えられるわけではありません。共通の由来だけで互換性を判断せず、必要な機能に対応しているか確認してください。

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

v2rayNは、デスクトップ上でサーバーの管理、サブスクリプションの更新、設定編集、コアの実行を操作するクライアントです。実際のデータ処理は選択したコアが行います。v2rayNGはAndroidでよく使われるXrayクライアントで、v2flyNGはV2Flyコアを使う選択肢です。クライアント画面にボタンがあることと、コアが関連プロトコルに対応していることは別の問題です。見た目が似た設定でも、コアが異なれば生成される設定内容が異なる場合があります。

デスクトップではv2rayNを使うと、サブスクリプションのグループ分け、ログ、システムプロキシの操作を一つの画面にまとめられます。コアタイプを設定する場合は、必要なプロトコルの実装を確認してからコアを切り替えてください。Androidでは、使用するコアの種類に合わせてクライアントを選ぶのが適切です。デスクトップでのコア切り替え手順をAndroidのメニューにそのまま当てはめず、実際にインストールしたバージョンの画面を確認してください。

共通項目があっても設定全体の互換性は保証されない

どちらのコアでも、アドレス、ポート、ユーザー、ルーティングルールといった基本概念を扱える場合があります。しかし、対応する伝送方式の名称、プロトコル拡張、設定構造、既定の動作は異なることがあります。REALITYやVisionなどの機能は、Xrayの対応状況を確認してください。V2FlyがVLESSタイプを読み込めるからといって、すべてのXray向けVLESS設定を処理できるとは限りません。逆方向に移行する場合も、元の設定に含まれる固有機能を確認する必要があります。

サブスクリプションはクライアントで解析され、通常は現在のコア向けの設定に変換されます。JSON全体を手動で貼り付けると、一部の変換処理を通さないため、別のコア専用の項目が混入しやすくなります。起動に失敗した場合は、まずログに表示された未知の項目、未対応のプロトコル、無効なパラメーターなどのメッセージを確認し、設定の出所を調べてください。起動させるためにエラー項目をまとめて削除すると、接続に必要な認証情報やセキュリティ設定まで失うおそれがあります。

ルーティング：ルールの意味とリソースを確認

ルーティング設定は、アウトバウンドのタグとルールデータベースを参照します。ルールの記述を解析できても、指定先のアウトバウンドタグが存在しない、または参照先のgeosite分類がローカルのデータに含まれていない場合、起動に失敗したり、意図しない振り分けが起きたりすることがあります。以下は、プライベートアドレスを優先して直接接続する意味を示す、Xrayルーティングオブジェクトの一部の例です。単独で起動できる完全な設定ではありません。組み込む前に、directという名前の直接接続用アウトバウンドが存在し、必要なルールデータが用意されていることを確認してください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

このルールは、IPアドレスの条件で照合できるリクエストだけを処理します。AsIsはIPルールのためにすべてのドメイン名を自動で名前解決しないため、ローカルネットワークのドメインと名前解決を完全に扱う設定の代わりにはなりません。実際のルールには、ローカルサービスへのアクセス方法に応じた設定を追加してください。データの入手先や更新方法、参照方法についてはgeoip.dat・geosite.datルールデータの解説をご覧ください。データベースがない問題をプロトコルの非互換と誤認しないために役立ちます。

アップグレードや切り替え時のロールバック

コアのアップグレードで問題が修正され、新機能が追加されることもあれば、古い設定の検証が厳しくなることもあります。アップグレード前にクライアント設定と重要なカスタム項目を保存してください。アップグレード後は、動作が確認できている設定で基本接続をテストしてから、サブスクリプション、ルーティング、特殊な伝送設定を確認します。コアを切り替えるときは、古いプロセスの状態と新しい設定が混在しないよう、現在の接続を停止してください。画面上の名称より、ログで新しいコアが実際に起動したことを確認するほうが確実です。

オープンソースライセンスも一括りにして説明できません。V2Flyのコアプロジェクトは通常MITライセンス、XrayのコアプロジェクトはMPL 2.0を採用しています。クライアントや依存コンポーネント、付属データにはそれぞれ異なるライセンスが適用される場合があるため、配布物のライセンス表記を確認してください。一般の利用者にとって、オープンソースであることは実装やライセンスを確認できることを意味しますが、設定の照合や証明書の検証、サービス提供元の信頼性を自分で判断する必要がなくなるわけではありません。

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

サブスクリプションは設定を配布する方法であり、プロキシプロトコルではありません。サブスクリプションURLから返される内容は、共有リンクの一覧、Base64でエンコードされたテキスト、または特定のクライアント向けの構造化設定などさまざまです。クライアントは外側の形式を読み取り、各設定を自分のサーバーモデルに変換してから、コア向けの設定を生成します。そのため、「URLにアクセスできる」「一覧をインポートできる」「サーバーに接続できる」はそれぞれ別の段階です。一つの段階に成功しても、次の確認が不要になるわけではありません。

共有リンクに含められる設定情報

一般的な共有リンクでは、プロトコルごとに異なるプレフィックスが使われますが、プロトコルや過去の実装によって項目のエンコード方法は異なります。VMessのリンクではエンコードされた構造化データがよく使われます。VLESSやTrojanのリンクでは、アドレスとクエリパラメーターで伝送方式やセキュリティ設定を表すことが多く、SSにも複数のエンコード形式があります。通常、備考は画面表示用で認証には使われません。一方、クエリパラメーター内のパス、名前、セキュリティ項目は接続の成否に直接影響する場合があります。

インポート機能がプロトコルのプレフィックスを認識していても、リンクに含まれる拡張項目に対応していないことがあります。画面にサーバーが表示されていても、flow、公開鍵、ショートID、サービス名、プラグインの設定が完全に保持されているとは限りません。インポート後は編集画面を開き、プロトコル、セキュリティ、伝送方式の各項目を確認してください。複雑な設定では、項目が空欄になっていないか、古い既定値が使われていないか、未対応の情報が無視されていないかに特に注意しましょう。

Base64はエンコード方式であり、アクセス制限ではない

リンク一覧をBase64にエンコードするとテキストで配布しやすくなりますが、含まれるアカウント情報は保護されません。サブスクリプションURL自体にアクセス用トークンが含まれている場合もあり、URLを共有すると更新権限まで渡すことになります。サブスクリプションURL全体、QRコード、サーバーの詳細情報を公開ログに貼り付けないでください。サポートを求めるときは、プロトコルの種類、エラーが発生した段階、値を伏せた項目名を共有すれば、多くの互換性を確認できます。

更新後に一覧が空になっても、ノードがすべて削除されたとは限りません。ログイン画面やエラーメッセージ、未対応の形式が返された可能性があります。まずURLが有効か、サブスクリプション形式に対応しているかを確認し、更新時に既存のプロキシが必要かどうかも調べてください。現在のプロキシが使えず、更新にもそのプロキシが必要だと、接続が循環して更新できないことがあります。詳しい確認手順はサブスクリプションの更新失敗・解析結果が空の場合の確認リストをご覧ください。グループを何度も削除して再インポートするのは避けましょう。

クライアント間で設定を移行する方法

v2rayN、v2rayNG、v2flyNGに移行する際は、複数の変換ツールを経由させず、移行先のクライアントが対応する元のサブスクリプションを使ってください。変換のたびに、変換先の形式で表現できない項目が失われる可能性があります。提供元が複数の形式を用意している場合は、現在のクライアントとコア向けであることが明示された形式を選びます。ほかの設定形式をダウンロードできても、これらのクライアントが直接読み込めるとは限りません。

ローカルでエクスポートした個別の共有リンクは、少数の設定を移行するのに便利ですが、ルーティング、DNS、アプリの対象範囲、画面の設定などがすべて含まれるとは限りません。サーバーをインポートした後も、新しい端末でローカル設定を確認してください。Androidのアプリ別振り分け設定が、デスクトップのシステムプロキシ設定に自動で反映されることはありません。デスクトップのカスタムルーティングも、サーバーの共有リンクだけでは移行できない場合があります。アカウント設定と端末ごとの設定を分けてバックアップすると、移行時に不足を確認しやすくなります。

更新後の設定と手動変更

サブスクリプション内の設定は更新時に再生成される場合があるため、購読中のノードのポート、名前、セキュリティ項目を直接変更しても、次回以降ずっと維持されるとは限りません。調整を試す場合は、まず設定を複製して独立させ、入手元と変更の目的を明記してください。更新でテスト条件が上書きされるのを防ぎ、提供元が設定を変更したと誤解することもなくなります。元に戻すときは複製を削除すればよく、グループ全体を作り直す必要はありません。

複数のサブスクリプションを管理するときは、プロトコルだけで分類するより、用途や入手元でグループ分けするほうが管理しやすくなります。一つのサブスクリプションに複数のプロトコルが含まれることもあり、設定が変更される時期もそれぞれ異なります。更新後は、普段使う設定が残っているか、選択中の項目が変わっていないか確認してから実際にアクセスしてください。問題が見つかった場合に、更新前の動作するコピーを残しておけば、サーバー側の変更、解析の違い、ローカルコアの問題を切り分けやすくなります。

Androidの電池消費とバックグラウンド動作

モバイル端末の電池消費は、プロトコル名だけでは判断できません。Androidでプロキシを動かす際の消費電力には、無線通信、CPU処理、システムの仮想ネットワークインターフェース、バックグラウンドアプリの通信、接続維持など複数の要因が関係します。小さなリクエストが頻繁に発生すると、連続ダウンロードより携帯ネットワークの無線機能が何度も起動し、待機中の電池消費が増えることがあります。電波が弱い場合は再送やネットワーク検索の影響が大きくなり、プロトコル間の差が見えにくくなります。「利用中に消費が多い」のか、「画面消灯中も通信が続いている」のかを分けて確認しましょう。

v2rayNGとv2flyNGを選ぶ基準

Xray固有の機能を組み合わせる必要がある場合は、Androidではv2rayNGを優先して検討してください。サーバー設定がV2Flyの機能に明確に依存している場合や、対応するコアを使い続けたい場合は、v2flyNGを検討します。二つのクライアントを同時にVPNとして動かすことはできません。システムのVPNサービスには利用上の制約があります。比較テストでは、一方を停止してからもう一方を起動し、対象アプリとルーティングを揃えてください。条件が異なると、コアの違いではなく異なる通信負荷を比較することになります。

VPNサービスの初回起動時に表示されるシステムの許可確認は、端末側で通信を受け付けるための手順であり、サーバーへの接続成功を示すものではありません。VPN確立後は実際の接続先にアクセスし、ログに有効なリクエストと正しい出口が記録されているか確認してください。一部のアプリだけ接続できない場合は、アプリ別の対象範囲や除外設定を確認します。アプリをVPNの対象外にすると、そのアプリの通信ではプロキシサーバーの状態を検証できません。テスト中にどの経路を使っているかを把握してください。

バックグラウンド制限と接続安定性のバランス

システムの省電力設定によって、バックグラウンドサービス、ネットワーク通信、自動起動が制限されることがあります。画面消灯後に接続が切れ、クライアントに戻るとすぐ復旧する場合は、まずシステムがアプリのバックグラウンド動作を制限していないか確認し、用途に合わせて調整してください。設定画面の名称は端末によって異なるため、システムのバッテリー管理画面を確認します。バックグラウンド動作を許可すると接続を維持しやすくなりますが、関連するすべてのアプリの制限を解除する必要はありません。範囲を絞って変更し、元に戻せるようにしておきましょう。

接続が維持されているのに発熱が続く場合は、バックグラウンド同期、失敗したリトライ、異常なDNSリクエストがないか確認してください。リクエストの失敗が繰り返されると接続が何度も再確立され、プロキシプロセスの電池消費に見えても、実際の原因はアプリのリトライである場合があります。対象アプリを一時的に絞るか、動作確認済みのルーティング設定を使うと原因を切り分けやすくなります。詳しいログは調査中に限って有効にし、大量のログを継続的に出力して処理やストレージの負荷を増やさないようにしましょう。

DNS、UDP、アプリの対象範囲

名前解決の設定は、接続までの待ち時間やリクエスト数に影響します。DNSサーバーに到達できない、名前解決の通信が誤った出口に振り分けられる、ローカルとリモートで異なる名前解決結果が返るといった場合、リトライが繰り返されることがあります。「高速化」のために問い合わせ方式を理解せず、多数のDNSサーバーを追加するのは避けてください。まずは仕組みを把握しやすい一つの名前解決経路を使い、通常のドメイン、ローカルネットワークのサービス、プロキシの接続先がそれぞれ想定どおりに処理されることを確認してから、設定を一つずつ広げましょう。

リアルタイム通信や一部のインタラクティブなサービスでは、UDPが必要になる場合があります。プロトコル、サーバー、接続経路がすべて対応していないと、アプリが別の方式に切り替えたり、リトライを繰り返したりして、使い勝手や電池消費に影響することがあります。Webページが開けてもUDPが使えるとは限りません。必要なアプリで実際にテストし、通信が途切れ続けないか、接続に時間がかからないか、再接続が繰り返されないかを確認してから、コアのログを調べてください。すべての問題をAndroidのバックグラウンド制限のせいにしないようにしましょう。

待機状態を含めて電池消費を比較する

電池消費を比較するときは、電波状況と利用時間をできるだけ揃え、画面の明るさ、対象アプリ、バックグラウンド同期も同じ条件にします。一方では通常の利用中、もう一方では画面消灯中を観察し、システムのバッテリー使用状況に表示されるアプリの動作を記録してください。システムの残量表示は推定値です。短時間のわずかな差だけでは結論を出せません。一度の測定で1パーセント少なかったかより、待機中の起動、発熱、接続の再確立が繰り返し起きているかを確認するほうが重要です。

ローカルネットワーク機器へのアクセスに問題がある場合は、すべての通信をプロキシ経由にする前に、プライベートアドレスとローカルドメインのルーティングを確認してください。地域や用途に応じたルールの組み合わせは、v2rayNGのルーティング設定実践ガイドを参考にできます。実際の用途に合ったルールを使うほど、不要なリモート経由を減らせます。効果を説明できる安定した設定は、省電力をうたう項目を増やすより長期的に管理しやすくなります。

用途に合わせた選択と接続確認

選択肢を絞るときは、制約を順番に確認します。まず端末の種類、次にサーバー側が提供するプロトコルの組み合わせ、続いて対応するコア、最後に用途に応じたルーティングと通信対象を決めます。プロトコルは単独で購入する性能オプションではなく、クライアントとサーバーが共に従う通信条件です。サブスクリプションに保守可能な設定が一種類だけ含まれている場合は、まずその設定の動作を十分に確認しましょう。名称が新しいという理由だけで、管理コストを増やして別の組み合わせを求める必要はありません。

デスクトップ、Android、既存サーバーの選び方

Windows、macOS、Linuxのデスクトップではv2rayNを選び、CPUアーキテクチャとOSのパッケージ形式に応じてダウンロードページから入手してください。Web閲覧や開発用アプリで共用する場合は、分かりやすいシステムプロキシとローカル接続先の設定から始め、どのアプリがシステム設定を参照するか確認します。アプリ側でSOCKSの指定が必要な場合は、そのアプリに接続先を設定してください。「全トラフィックをルーティングする」モードがすべてのアプリを自動的に制御するとは限りません。

Androidでは、サーバーが提供する組み合わせに応じてv2rayNGまたはv2flyNGを選び、必要に応じてすべてのアプリまたは特定のアプリを対象に設定します。モバイル回線とWi-Fiを切り替えると、基盤の接続が再確立されることがあります。一時的に接続が切れただけで、プロトコルが不安定だと判断しないでください。再接続に失敗し続ける場合は、名前解決の変化、リモートサーバーへの到達性、バックグラウンド制限を確認します。ローカルネットワークの機器をよく利用する場合は、LAN内のアドレスと関連ドメインも個別にテストしてください。

VMess、Trojan、SSを安定して使えている場合は、正確な設定とサブスクリプションの更新を優先してください。サーバー側がVLESSとREALITYを提供する場合は、セキュリティ項目とflowに明確に対応したXray環境を選びます。端末の負荷を減らしたいときは、プロトコル名だけを変えるのではなく、不要な転送レイヤー、異常なリトライ、多数のバックグラウンド処理を先に見直してください。低性能な端末では、複雑な設定を重ねるより、シンプルで対応が明確な組み合わせのほうが検証しやすくなります。

手順に沿って接続を確認する

最初に、ローカル設定からコアを起動できるか確認します。コアがすぐ終了する場合は、無効な項目、ポートの競合、ルールデータの不足を先に解決してください。この段階では、リクエストはまだ正常にリモートへ送られていません。次にアドレスが名前解決できるか、サーバーの接続口に到達できるかを確認します。その後、セキュリティネゴシエーションとプロトコル認証を確認します。最初の三段階が完了してから、接続先サイト、DNS、ルーティングの問題を調べてください。段階を追って確認すれば、ローカルの設定エラーをサーバーの不安定さと取り違えずに済みます。

四つ目に、実際の用途を確認します。一般的なWebサイトを開く、必要な業務サービスにアクセスする、LAN内のアドレスに接続するほか、必要な場合はUDPアプリもテストしてください。五つ目に、アイドル状態からの復帰とネットワーク切り替えを確認します。使用したクライアント、コアの種類、プロトコルの組み合わせ、結果を記録します。アカウント情報を公開する必要はありません。途中で失敗した場合は、サーバーを次々と切り替えてログを混在させるより、その時点の短いログを残しておくとサポートを受けやすくなります。

ルールの順序と確認対象

ルーティングルールは通常、記述された順に照合されます。前方にある広い条件のルールが、後方の詳細な条件より先に適用されることがあります。プロトコルを変更した後に一部のサイトの動作が変わった場合は、編集画面のサーバータイプだけを比べず、実際に生成されたルーティングと既定の出口を確認してください。ドメインやアドレスの条件をカスタマイズする場合は、Xrayカスタムルーティングルールと照合順序をご覧ください。ルールは具体的な用途に合わせて作り、内容を説明できない例外を一度に大量に追加しないようにしましょう。

接続確認が完了したら、動作が分かっている設定を基準として一つ保存してください。今後、サブスクリプションの更新、コアの切り替え、システムのアップグレードを行うたびに、まずこの設定で最小限の確認をしてから、複雑なルーティングや特殊なオプションを戻します。基準の設定を永久に更新しないという意味ではありません。変更のたびに比較できる出発点を残すためのものです。設定が決まった後の普段の操作はクイックスタートガイドをご覧ください。このハンドブックはプロトコルの境界、互換性のある項目、トラブルの発生段階を確認するための資料です。接続のたびにすべての設定を見直す必要はありません。