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

設定のレイヤー：プロトコル、トランスポート、セキュリティ

クライアントに表示されるノード名は通常1行ですが、実際の接続は複数のレイヤーで決まります。プロキシプロトコルは認証とリクエストの形式を定め、トランスポートはデータを運ぶ仕組みを定めます。セキュリティ層は接続の暗号化と相手の認証を担い、アドレスとポートは接続先の入口を指定します。各項目をまとめて理解すれば、同じVLESSのノードでも設定をそのまま流用できない理由や、画面上の選択肢がプロトコル全体を表すとは限らないことが分かります。

ノード設定で確認するレイヤー

VMess、VLESS、Trojan、Shadowsocksはプロキシプロトコル、TCP、WebSocket、gRPCなどはトランスポート、TLSとREALITYはセキュリティ設定にあたります。REALITYはVLESSと同列のプロキシプロトコルではありません。よく使われる組み合わせを入力しやすくするため、クライアントが独立した項目として表示する場合があります。その場合も、一覧のラベルだけで接続方式を判断せず、基盤となるプロトコルを確認してください。

入力時はまずアドレス、ポート、プロキシプロトコル、認証情報を設定し、その後にトランスポートとセキュリティを確認します。UUIDはVMessやVLESSでよく使われるユーザー識別子、Trojanではパスワード、Shadowsocksでは暗号方式とその方式に合ったキーが必要です。どれも文字列に見えますが意味は異なるため、あるプロトコルのパスワードを別のプロトコルのユーザー識別子欄にコピーしてはいけません。編集画面で保存できても、入力値が画面上の検査を通っただけで、サーバーが受け入れるとは限りません。

接続先アドレスとサーバー名は別

アドレスはクライアントが実際に接続する宛先で、ドメイン名またはIPアドレスを指定します。SNIやサーバー名はTLSハンドシェイクや認証に使われ、接続先アドレスとは異なる場合があります。WebSocketのHostやパスは、さらにアプリケーション層のトランスポート設定です。提供元がこれらの値を意図的に分けていることもあるため、すべてを同じドメイン名にそろえても接続の問題は解決しません。ポート番号もプロトコルの種類を決めるものではありません。よく使われるポートはデプロイ上の慣例にすぎず、サーバーの待ち受け設定と一致させる必要があります。

トランスポート固有の項目は、種類に応じて確認してください。WebSocketでは通常、パスとHostを一致させ、gRPCではサービス名を合わせます。通常のTCPにこれらの項目は不要です。既存ノードのトランスポートを変更すると、古い項目がクライアントに無視される場合もあれば、設定生成に使われ続ける場合もあります。正しい種類のノードを新しく追加し、参照元を見ながら項目を一つずつ入力するのが確実です。既存の項目で複数のプルダウンを何度も切り替える方法は避けましょう。

ノードが正しくても、すべてのアプリがプロキシを使うとは限らない

ノード設定が対象にするのは、クライアントからサーバーまでの接続です。アプリの通信がクライアントに届くかどうかは、システムプロキシ、TUN、アプリ独自のプロキシ設定によって変わります。届いた通信をどの出口へ送るかはルーティングルールで決まります。そのため、ブラウザーは接続できても別のアプリは接続できないというだけで、プロトコルに問題があるとは限りません。まずアプリの通信がプロキシに入っているかを確認し、次にルーティングとDNSを確認してください。すぐにUUIDを変更したり、証明書検証を無効にしたり、暗号方式を変えたりする必要はありません。

ログもレイヤーごとに切り分けます。名前解決の失敗は接続前、タイムアウトは接続先への接続中、TLS認証エラーはセキュリティ層、認証失敗は通常プロトコル設定に関係します。一つのログに複数の原因が関わることもあるため、発生したタイミングも確認してください。元のインポート設定を残し、変更のたびに一つの項目だけを記録すれば、設定ミスと一時的なネットワーク障害を区別しやすくなります。手当たり次第に変更して元の状態に戻せなくなる事態も防げます。

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

VMessはProject Vのエコシステムで早くから使われてきたプロキシプロトコルです。設計上、ユーザー認証とデータ保護をプロトコル自体で担います。V2Rayが単なるシステムプロキシの切り替え機能ではないことを理解する手がかりにもなります。コアはユーザーを識別し、宛先アドレスをカプセル化して、プロトコルの形式に沿ってデータを処理します。VMessは後の改良でAEAD認証方式を導入し、従来の認証方式に伴う負担を軽減しました。この背景を知る主な目的は、古い設定項目を見分けることであり、旧式の互換モードを使い続けることではありません。

VMessのalterIdと暗号方式

クライアントによっては「alterId」や追加IDの項目が残っています。現在よく使われるVMess設定では追加IDを0にし、AEAD方式を使います。この値はノード数でも、自由に大きくして安全性を高める数値でもありません。提供元が別の値を指定している場合は、サーバーと使用するコアが該当する旧方式に対応しているかを確認してください。インポート後に認証エラーが出たら、元の設定値と互換性を優先して確認しましょう。数字を手当たり次第に変えて試すのは避けてください。

暗号方式のautoは、実装が条件に応じて適切な方式を選ぶという意味で、暗号化を無効にする設定ではありません。アルゴリズムの処理効率はプロセッサの命令セットにも左右されるため、端末のハードウェアを考慮せずに特定の方式が必ず速いとは言えません。手動で方式を指定する場合は、プロトコル実装の対応範囲とも一致させる必要があります。正常にインポートしたノードでは、根拠なく別の方式に変更するより、提供元の設定を維持するほうが安全です。比較するなら、どちらもサーバーが受け入れる設定を用意してください。

VMessでは時刻のずれが認証失敗につながることがあります。アドレス、ポート、ユーザー識別子が正しくても、端末の時刻がずれていれば接続できない場合があります。パスワードの誤りと決めつけず、システムの自動時刻設定とタイムゾーンを確認してください。外側でTLSを使う場合は証明書の有効期限確認にも影響し、同じ時刻の問題が認証エラーと証明書エラーの両方に見えることがあります。まずシステム時刻を修正してから再接続すれば、不要な設定変更を減らせます。

VLESSでは暗号化を外側の層に任せる

VLESSは、ユーザー識別子とプロキシリクエストの形式を保ちながら、よりシンプルに設計されています。プロトコル層で重複してデータを暗号化しません。一般的なクライアント設定ではencryptionにnoneを指定しますが、接続全体を暗号化せずに使うという意味ではありません。実際にはTLSや、対応するREALITY設定など適切なセキュリティ付きトランスポートと組み合わせます。VLESSのnoneをVMessの暗号方式選択と同じものと見なすと、安全性の境界を誤って理解することになります。

VLESSのflowでは、対応するフロー制御方式を選択します。xtls-rprx-visionはVisionを指定する値です。汎用の高速化スイッチではなく、どのVLESSトランスポートにも指定できるわけではありません。サーバー、クライアントのコア、トランスポートの組み合わせすべてが対応している必要があります。ノード情報にflowの指定がない場合、項目が表示されているからといって追加しないでください。提供元がVisionを明示している場合は、flowを削除しても元と同じ接続になるとは考えないでください。

新旧ではなくデプロイ条件で選ぶ

VMessのサービスが安定して稼働している場合、クライアント側でプロトコルをVLESSに変えるだけでは移行できません。サーバーに対応する待ち受け設定とユーザー設定が必要で、共有リンクも再発行する必要があります。新たにVLESSを導入する場合は、まず外側のセキュリティとコアの対応状況を確認し、その後でフロー制御や性能を検討します。プロトコル名が新しいからといって、現在の回線が優れているとは限りません。サーバー負荷、回線品質、トランスポート方式の影響は、プロトコルヘッダーのわずかな違いを上回ることがあります。

この2種類のノードでは、決まった順序で確認すると切り分けやすくなります。ユーザー識別子が完全か、プロトコルがサーバーと一致しているかを確認し、次にトランスポート、セキュリティ層、システム時刻を調べてください。VMessではalterIdと認証方式の互換性、VLESSではencryptionとflowが提供元の指定どおりかを確認します。元のリンクが対応コアで使えるのに手入力したノードだけ接続できない場合は、サービス停止と判断する前に、項目が欠けていないかを比較してください。

TrojanとShadowsocks：異なる接続保護方式

TrojanとShadowsocksはどちらもクライアントのプロトコル一覧に表示されますが、接続を保護する仕組みは異なります。Trojanは一般にTLS接続を前提として認証とプロキシリクエストを処理し、Shadowsocksは事前共有キーと共通鍵暗号を中心に設計されています。比較する際は、認証情報、暗号化の範囲、トランスポート設定を合わせて確認してください。「パスワードの形式が違うだけの同じノード」と考えてはいけません。サーバーが提供する方式に合わせて、クライアント側でも正しい種類を選択します。

Trojan：パスワードだけでなくTLSも確認

Trojanのパスワードはプロトコル認証に使い、TLS証明書はサーバーの身元確認に使います。役割は別々です。パスワードが正しくても証明書の名前が一致しなければ問題は解決せず、証明書が有効でもパスワードが正しいとは限りません。クライアントでは接続先アドレスとSNIを別々に指定できる場合があります。IPアドレスで接続する場合も、サーバーの指定に従ってサーバー名を入力してください。パスワードだけをコピーしてSNIを設定し忘れると、TLSの段階で止まり、実際のパスワード認証に進めないことがあります。

「証明書の検証をスキップ」すると重要な身元確認を放棄することになるため、一般的な解決策として使うべきではありません。証明書エラーが出たら、システム時刻、サーバー名、証明書チェーン、サーバー設定の順に確認してください。独自の信頼設定を使う場合は、証明書の発行者とクライアント側で信頼を確立する方法を明確にし、検証を長期間無効にしたままにしないでください。ノード情報で検証を無効にするよう指定されている場合も、デプロイ上の理由を確認しましょう。画面上のスイッチがプロトコルの必須条件とは限りません。

Trojanで利用できるトランスポートの組み合わせは、コアによって異なる場合があります。プロトコル名が同じでも、WebSocket、gRPCなどの追加機能がすべて共通とは限りません。提供元がトランスポートを指定している場合は、パス、サービス名、セキュリティ設定も含めて保持してください。TrojanがTLSと組み合わされることが多くても、トランスポート層の項目を省略してはいけません。TLSハンドシェイクが成功しても、トランスポートの入口が合わなければ切断されたり、応答を待ち続けたりすることがあります。

Shadowsocks：暗号方式に合ったキーを使う

Shadowsocksは、比較的シンプルな暗号化プロキシ接続を重視して設計されています。初期の暗号方式と後年のAEAD方式では、形式やセキュリティ上の特性が異なります。クライアントに旧方式の一覧が残っているのは、主に互換性のためです。新規導入ですべての方式が適切とは限りません。ノードを選ぶ際は、メモにある「高速」といった表現より、暗号方式の正確な名称を確認してください。双方でのデータ処理方法と、現在のコアが接続を認識できるかどうかが決まります。

Shadowsocks 2022では、2022-blake3-aes-128-gcmのような方式でキーやセッションの処理が変更されています。この方式で使うパスワードは、任意の長さの一般的な文字列ではありません。定められた長さのキーと適切なエンコード形式が必要で、従来のパスワード派生方式とは異なります。サーバーから提供されたキーはそのまま使い、覚えやすい短い文に変更したり、エンコード済みの値を再度エンコードしたりしないでください。暗号方式とキー形式が合っていないと、設定を保存できても実行時に接続が失敗します。

一部のShadowsocks共有リンクには、プラグイン情報も含まれます。プラグインは追加の依存要素であり、すべてのコアやGUIクライアントがそのまま解釈できるわけではありません。インポーターがアドレスとパスワードを認識しても、プラグイン設定を無視すれば、項目がそろって見えても実際の接続経路は変わっています。クライアントの対応状況を確認し、プラグイン情報が変換または保持されているか調べてください。暗号方式を変えてもプラグイン機能の不足は補えません。また、プラグイン設定をTLSのサーバー名欄に入力しないでください。

UDPと性能は個別に確認する

両プロトコルのUDPの使い勝手は、コアの実装、サーバー設定、ローカルでの接続方式にも左右されます。Webページが開けても確認できるのは一部のTCPリクエストであり、音声通話、ゲームなどのUDPアプリが正常とは限りません。実際に使うアプリで試し、通信がプロキシに入っているか、ルーティングで想定した出口が選ばれているかを確認してください。サーバー側がTCPだけに対応している場合、クライアントでTUNを有効にしてもUDP対応が追加されるわけではありません。

リソースに余裕のない端末では、Shadowsocksの共通鍵暗号処理のほうが負荷を抑えられる場合がありますが、実際の性能はアルゴリズム、ハードウェア、実装によって異なります。TrojanではTLS接続時にハンドシェイクが必要ですが、接続を維持すればそのコストを分散できます。そのため、短いリクエストへの応答と長時間のダウンロードは分けて評価してください。信頼できるサービスがすでにあるなら、検証済みの設定を維持するのが基本です。改めて選ぶ場合は、アプリの種類、キーの管理方法、コアの対応状況を基準にしましょう。

REALITYとVision：設定項目をまとめて確認

REALITYはXrayのエコシステムにおけるセキュリティ付きトランスポート機能で、VLESSと組み合わせて使われることがよくあります。Visionは関連する接続で使われるフロー制御方式です。役割が異なるため、「REALITYを有効にする」と「Visionを有効にする」は同じ操作ではありません。クライアントでまとめて表示されても、よく使われる設定項目を一か所に集めているだけです。設定生成時には、プロキシプロトコル、トランスポート、セキュリティ方式、flowを個別に指定し、選択したコアがそれらに対応している必要があります。

REALITYの認証モデル

一般的なTLSのデプロイでは、証明書チェーンとサーバー名を使って接続相手を信頼できるか判断します。REALITYは独自のハンドシェイクと認証方式を使用し、クライアントはサーバーから提供された公開鍵などの情報を使って認証を行います。そのため、TLSの名称を置き換えただけの仕組みでも、「証明書エラーを無視する」ための代替スイッチでもありません。この違いを理解すれば、一般的なTLSノードの証明書設定をREALITYノードにそのまま当てはめずに済みます。

publicKeyは、クライアントが関連するハンドシェイクを検証するための公開鍵です。サーバー側に入力する秘密鍵ではありません。shortIdはデプロイ設定で使われる識別パラメーターで、通常は16進数で表し、サーバーが受け付ける値と一致させます。UUIDは引き続きVLESSのユーザー識別子として使われます。どれもランダムな文字列に見えますが、互いに置き換えることはできません。長さが似ていても、エンコードや処理の方法が異なります。

serverNameまたはSNIには、サーバー設定で許可された値を指定してください。アクセスできるWebサイトのドメインなら何でも使えるわけではありません。fingerprintはchromeなど、対応するクライアントのハンドシェイク指紋を指定します。指紋が表すのはハンドシェイクの動作であり、クライアントがブラウザーを起動するわけでも、該当ブラウザーのインストールが必要なわけでもありません。利用できる指紋はコアの対応範囲にも制限されるため、ブラウザー製品名を自由に入力しただけで有効になるとは限りません。

Visionは暗号化を追加する機能ではない

Visionはデータフローの処理方法、特にプロキシ接続内でTLSトラフィックを運ぶ際の挙動に関係します。認証用のパスワードでも、独立したプロキシプロトコルでもありません。一般的なVLESS設定では、xtls-rprx-visionでこのフロー制御方式を指定します。サーバー設定および対応するトランスポートと一致させる必要があります。WebSocketなど、任意のトランスポートとの組み合わせに指定しないでください。クライアントで不適切な組み合わせを保存できても、コアが拒否したり接続できなかったりする場合があります。

REALITYとVisionはよく併用されますが、必要な条件は別々に確認できます。セキュリティ方式はサーバーのデプロイ設定によって決まり、flowは双方が対応するフロー制御設定によって決まります。どちらもクライアントだけで決めることはできません。Visionが指定されていないREALITYノードでは、提供元の設定を維持してください。Visionが明示されたノードでは、インポート時にflowが失われていないかを確認します。説明的なメモだけを根拠に設定を追加すると、正しい設定に互換性の問題を持ち込むことになります。

インポート失敗とハンドシェイク失敗を分けて対処

リンクをインポートできない場合は、クライアントがREALITYの設定項目と使用中の共有形式を認識しているかを確認します。インポートできてもコアが未知の項目を報告するなら、問題は設定生成またはコアの互換性にあります。ハンドシェイクに失敗する場合は、アドレス、ポート、ユーザー識別子、公開鍵、サーバー名、shortIdを確認してください。サーバーがデプロイ時に必要とする接続先へ到達できない場合も、ハンドシェイク異常が起きることがあります。クライアント側の設定を確認することはできますが、公開鍵を変更してサーバー側のネットワーク条件を解決することはできません。

サブスクリプションの更新後に設定項目が変わっていたら、ノードの編集画面を開き、特にセキュリティ方式、フロー制御、公開鍵に関する項目を確認してください。古い公開鍵を新しいノードに付け足したり、アドレスが同じだからサーバー設定も変わっていないと判断したりしないでください。手動管理が必要なら、比較用にインポート直後のコピーを残しておきましょう。REALITYを使うノードでは、VLESS対応だけを根拠にセキュリティ方式やフロー制御も使えると判断せず、Xrayの機能対応を確認してください。

接続性能、リソース使用量、モバイル端末の電池消費

プロトコルに決まった性能順位はありません。ユーザーが「速い」と感じる内容には、接続確立の速さ、Webページの初回応答、ダウンロード速度、切断後の復旧の速さなどがあります。それぞれ影響する要因が異なるため、1回の速度測定ですべてを評価することはできません。プロキシプロトコルのヘッダーや暗号化は接続全体の一部です。DNS、サーバーまでの距離、トランスポートのハンドシェイク、輻輳制御、サーバー負荷のほうが大きく影響する場合もあります。

短時間の接続と長時間の接続では見るべきコストが異なる

Webページを開くと、複数の接続が発生する場合があります。名前解決、TCP接続、TLSハンドシェイクはデータ転送前に時間を消費し、トランスポートによっては固有の接続確立も必要です。接続を再利用すればコストを分散できますが、プロトコル、アプリ、コアすべてが対応している必要があります。短いリクエストが多い用途では接続確立の負荷が表れやすく、継続的なダウンロードでは回線容量、輻輳、サーバーの処理能力が重要になります。ハンドシェイクが少ないからといって、ダウンロード速度が必ず上がるわけではありません。

WebSocketはアプリケーション層のカプセル化を追加し、gRPCは通常HTTP/2に関係する接続動作を利用します。各方式にはデプロイのしやすさや接続再利用の利点がある一方、追加の処理も伴います。利用する価値があるかは、プロトコル名ではなくサーバーの入口とネットワーク条件で決まります。同じサーバーアドレスのままトランスポートだけを気軽に切り替えてはいけません。サーバー側に該当する待ち受け設定がない場合もあります。その接続失敗が示すのはデプロイとの不一致であり、性能差ではありません。

暗号化とメモリ使用量の見方

AES命令へのプロセッサの対応、アルゴリズムの実装品質、単一コアの性能はいずれも暗号化の処理負荷を左右します。コアのメモリ使用量は、同時接続数、バッファー、DNSキャッシュ、ルーティングデータの規模にも影響されます。クライアントプロセスの使用量が大きい場合は、GUIとコアのサブプロセスも区別して確認してください。アイドル時に一度だけ測ったメモリ使用量では、特定のプロキシプロトコルが省メモリかどうかは判断できません。同じ接続数、同じ負荷で比較しましょう。

多重化は一部の接続確立コストを減らせますが、通信を共有チャネルに集約することで、ブロッキングや復旧時の挙動が変わることもあります。すべてのノードで有効にすべき高速化スイッチではなく、UDPや一部のフロー制御との組み合わせには実装差もあります。提供元やコアの説明で明確に推奨されていなければ、まずデフォルト設定を使ってください。有効化後に同時リクエスト時だけ異常が起きた場合は、元の設定に戻して多重化が関係するか確認し、すぐにサーバーのパスワードを変更するのは避けましょう。

モバイル端末の電池消費はプロトコルだけでは決まらない

モバイル端末では、無線機能の起動、バックグラウンドアプリのリクエスト、接続の維持が電池消費に大きく影響します。軽量なプロトコルでも、頻繁に再接続すれば安定した接続より電力を消費することがあります。Wi-Fiとモバイルデータを切り替えると既存の接続が切れ、コアが再接続する場合があります。短時間の測定を何度も行ったり、ノードを頻繁に切り替えたりしても余計なリソースを消費します。1回の手動速度測定の電池消費をプロトコルのせいとせず、普段の利用時の傾向を確認してください。

v2rayNGとv2flyNGはAndroidのVpnServiceを介して通信を受け取り、アプリごとの設定でプロキシ処理の対象を決めます。不要なアプリを対象から外すほうが、プロトコルの変更より効果的な場合があります。システムの省電力設定でバックグラウンドサービスが停止され、画面ロック後に切断されることもあります。必要なバックグラウンド動作をシステム設定で許可し、通信を続けているアプリがないか確認してください。バックグラウンド制限と電池消費の多さを同じ問題として扱わないようにしましょう。

繰り返し確認できる測定方法を用意する

まず短いリクエストを試し、次に継続的なデータ転送を行い、最後に待機中とネットワーク切り替え時の挙動を確認します。接続できるか、安定して続くか、プロセッサ負荷が明らかに高くないかを記録すれば十分です。プロトコルに共通の点数を割り当てる必要はありません。各テストを複数回行い、同時にサブスクリプションの更新や別のダウンロードをしないでください。ドメイン名でのリクエストだけが遅い場合はDNSを切り分け、UDPアプリだけに問題がある場合は接続方式、ルーティング、サーバーの対応状況を確認します。

電池消費を比べる際は、画面の明るさ、アプリの負荷、測定時間をそろえ、前面での使用とバックグラウンド待機を分けてください。VpnServiceの許可、省電力の対象外設定、アプリごとのプロキシ設定についてはv2rayNGのAndroid設定のポイントをご覧ください。回線が安定し、端末の負荷に問題がなければ、理論上のわずかな負荷を減らすために何度も移行する必要はありません。運用のしやすさも選択時のコストです。

V2FlyとXray：系譜と互換性の範囲

Project Vのエコシステムでは、プロキシ接続、ルーティング、トランスポートなどの機能を設定可能なコアとして提供しています。V2FlyはV2Rayプロジェクトの関連開発を引き継ぎ、Xrayはこの技術体系から分岐し、独自の機能を発展させてきました。共通の設定概念や歴史的な基盤があっても、すべての設定が同じとは限りません。プロトコル対応、トランスポートの実装、セキュリティ機能、設定項目の構造には、それぞれの進化に応じて違いが生じます。

GUIクライアントとコアの役割

v2rayNはデスクトップ向けクライアントで、ノード管理、サブスクリプション、設定画面、実行制御を担当します。実際の接続は呼び出されたコアが処理します。v2rayNGはAndroid向けで、通常はXrayコアを使用します。v2flyNGはV2Flyコアを使う選択肢を提供します。画面が似ていても、基盤となる機能まで同じとは限りません。ノードが使えるか確認する際は、クライアントが設定を正しく入力できるか、コアが生成された設定を認識できるかの両方を確認してください。

デスクトップでは、ノード、ルーティング、システムへの接続方式をまとめて管理できるv2rayNがおすすめです。ただし、どの形式をインポートしても自動的に互換性が保たれるという意味ではありません。複数のコアを切り替えるには、クライアントのバージョンと実行環境がそれをサポートしている必要があります。コアを切り替えた後は、現在のノードとルーティングをあらためて確認してください。タスクトレイのアイコンが表示されるだけでは接続確認になりません。Androidで2つのクライアント間を移行する場合も、サブスクリプション形式、アプリの接続範囲、プロトコル設定を確認しましょう。

設定の概念が共通でも、項目をそのまま流用できるとは限らない

一般的なJSON設定には、インバウンド、アウトバウンド、ルーティング、DNSなどが含まれますが、各項目の解釈は対象のコアに合わせる必要があります。一方の系統でしか利用できない機能もあれば、両方に相当する機能があって設定形式が異なる場合もあります。JSONを別のコアで使う前に、プロトコル、トランスポート、セキュリティ設定を確認し、その後でルーティングとDNSを確認してください。起動できるまでエラー項目を一つずつ削除する方法は避けましょう。

REALITYとVisionは、Xrayの機能対応を確認する際によく見るポイントです。V2Flyが基本的なプロキシプロトコルに対応しているからといって、Xray独自の拡張をすべて利用できるとは限りません。逆に、XrayがV2Ray形式の設定を認識できても、過去の項目や今後追加される項目がすべて有効とは限りません。共有リンクはクライアントによる変換でコア形式の違いが見えにくくなることがありますが、ネイティブJSONでは違いが直接表れます。

ルーティング設定にも共通の概念がある

次の例はルーティング部分のJSONです。まずプライベートアドレスをdirectに送り、それ以外のTCPおよびUDP通信をproxyに送る設定を表します。対象コアの完全な設定に統合し、同名のアウトバウンドをあらかじめ定義してください。geoipの分類を使うには、対応するデータも必要です。接続情報は含まれておらず、単独で起動できるノード設定でもありません。この例が示すのはルールの順序であり、クライアントが生成した設定全体を置き換えるものではありません。

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

ルールは通常、上から順に照合します。先にある条件によって、後続のルールが適用されるかどうかが決まります。AsIsでは、IP条件に一致させるためにドメイン名を自動で名前解決しません。そのため、このプライベートアドレスのルールを「最終的にプライベートIPへ解決されるドメインはすべてdirectになる」と解釈してはいけません。名前解決後のIPに基づいて振り分けるには、domainStrategyを理解する必要があります。詳しい設定方法はdomain、ip、geositeとルールの優先順位をご覧ください。

更新や切り替えは元に戻せるようにする

クライアントの更新では、GUI、インポート処理、コア機能の一部または複数が変更されることがあります。動作している設定を残し、更新後も同じコアを使っているか確認してください。すべての機能に共通する固定のバージョン条件を決めつけず、現在のリリースノートと実際の設定への対応状況を確認しましょう。更新後に一部のノードだけ使えない場合は、そのノードのプロトコル構成を比較してください。すべてのノードが使えない場合は、実行環境、権限、設定生成の過程を確認します。

ログに未知のプロトコルや設定項目が表示された場合は、機能対応と構文を確認します。接続タイムアウトが出ただけで、コアに機能がないと判断してはいけません。別のコアに切り替えて問題が解消した場合も、クライアントがほかの設定を同時に変更していないか確認してください。デスクトップ向けのインストールやAndroidクライアントの選択については、インストーラーページでプラットフォームとアーキテクチャを確認できます。このページでは機能の互換性を解説しており、コア単体のダウンロード手順は扱いません。

サブスクリプションと共有形式：インポート後の互換性確認

サブスクリプションはノードの配布方法であり、新しいプロキシプロトコルではありません。複数のプロトコルを含む場合もあれば、特定のクライアントが認識できる形式だけを提供する場合もあります。サブスクリプションURLにアクセスできても、応答を解析できるとは限りません。クライアントにいくつかのノードが表示されても、それは一部のインポートが完了しただけです。すべてのトランスポートとセキュリティ項目が保持されているか、現在のコアが対応しているかも確認してください。

共有リンク、Base64、ネイティブJSON

共有リンクは通常、vmess://、vless://、trojan://、ss://などのプロトコルプレフィックスで種類を示します。各形式で、アドレス、認証情報、追加パラメーターの配置が異なります。VMessリンクにはエンコードされたJSONが含まれることが多く、VLESSやTrojanではURIのクエリパラメーターがよく使われます。プレフィックスだけを置き換えて相互変換できる形式ではありません。コピー時は内容をすべて保持し、特殊文字やパラメーターのエンコードにも注意してください。

複数の共有リンクを一つのサブスクリプション応答にまとめるため、Base64が使われることがあります。Base64はエンコード方式であり、接続を暗号化する機能ではありません。テキストをデコードしても、完全に動作するコア設定になるわけではなく、リンクがすべて有効になるわけでもありません。クライアントはリンクを個別に解析し、アウトバウンドを生成する必要があります。インポート前に内容の提供元を確認し、認証情報を含むサブスクリプションを不明なサービスにアップロードしないでください。ローカル解析とリモート変換ではプライバシー上の範囲が異なります。

ネイティブJSONには、ノード以外にインバウンド、ルーティング、DNS、ログ、複数のアウトバウンドが含まれることがあります。多くの場合、特定のコアやクライアントの動作を想定した形式です。単一の共有リンクとは含まれる情報量が異なります。JSON全体を共有リンクに変換すると、多くの共通設定に対応する項目がありません。共有リンクをJSONに変換する場合は、ローカルの接続設定やルーティングを追加する必要があります。変換は情報をそのまま複製する処理ではないため、ノード情報と運用設定のどちらを保持するのか明確にしてください。

欠落しやすい設定項目とエンコードの注意点

新しいセキュリティ設定、flow、ハンドシェイク指紋、特定のトランスポート項目は、古いインポーターや簡易変換ツールで無視されることがあります。ノード名、アドレス、ユーザー識別子が残っていても、必要な設定が欠けている場合があります。REALITYノードをインポートしたら編集画面を開き、全項目を確認してください。プラグイン付きのShadowsocksリンクでも、プラグイン情報が残っているか確認します。メモが保持されていても設定が完全とは限らず、項目同士の照合の代わりにはなりません。

URI内の特殊文字は形式に合わせてエンコードする必要があります。特にパスワード、パス、メモに区切り文字が含まれる場合は注意してください。手作業で組み立てると、パスワードの一部がクエリパラメーターと誤認されたり、パス内の文字が書き換わったりすることがあります。インポートに失敗したら、句読点を次々に削除せず、クライアントのクリップボードまたはファイルからのインポートを試してください。共有形式によって実装差があるため、特定の項目だけ解析できない場合は、すべてのリンクを書き換えるのではなく、提供元に対象クライアントを確認してください。

更新の失敗と接続の失敗は分けて調べる

サブスクリプションの更新に失敗したら、URLが完全か、無効になっていないか、リクエストを送信できるか、更新リクエストにプロキシが必要かを確認してください。ノードには接続できても更新に失敗する場合は、サブスクリプションサービスへのアクセス条件が異なる可能性があります。更新に成功してもノードを使えない場合は、ノード設定とサーバーの状態を確認します。システム時刻のずれが、更新リクエストのTLS検証に影響することもあります。更新リクエストのエラーをプロキシプロトコル自体の欠陥と考えないでください。

自動更新によってノード一覧が変わり、手動変更した設定が次回の更新で上書きされることがあります。試した設定を長期的に残す場合は、独立したノードまたはグループにコピーし、以後は提供元の変更が自動反映されないことを把握しておきましょう。サブスクリプションを変更したら、現在選択中のノードを確認してください。クライアントが常に正しいノードを自動選択するとは限りません。更新リクエストや間隔の設定については、サブスクリプションの更新に失敗する主な原因をご覧ください。

別のクライアントへ移行する場合は、まず少数のノードをインポートして確認し、次にUDP、ルーティング、アプリの接続を確認してから、残りを移行してください。コアの変更、サブスクリプションの変換、DNSの変更を同時に行うと、どの手順で問題が起きたのか分かりにくくなります。3つの形式の構造や変換上の制約は、Base64サブスクリプション、ネイティブJSON、共有リンクの比較をご覧ください。サブスクリプションに含まれる認証情報は機密情報です。トラブル対応の画像を共有する前に、必ず隠してください。

用途に応じた選び方と設定確認の手順

プロトコルの選択は、まずサーバーの対応状況で決まり、その次にクライアントの好みを考えます。利用できるサーバーが一つだけなら、新しいプロトコル名を追うより、正しくインポートして安定して使うことが重要です。デプロイ方式を選べる場合は、保守性、端末の機能、アプリの種類、性能要件を比較します。次の手順では選択とトラブルシューティングを一緒に行います。まず互換性のない組み合わせを除き、接続方法とルーティングを確認し、最後に再現性のあるテストで移行する価値を判断してください。

デスクトップとモバイルで基準を決める

デスクトップではv2rayNでノードを管理し、OSとプロセッサのアーキテクチャに合ったインストーラーを選んでから、使用するコアを確認してください。通常のブラウザー利用では、まずシステムプロキシで接続を確認します。システムプロキシに従わないアプリがある場合にTUNを検討してください。TUNはローカルで通信を取り込む方法を変えるもので、サーバー側のプロトコルを変更したり、誤った公開鍵やパスワードを修正したりするものではありません。まず通常の接続で動作する設定を確立すれば、その後の接続方式を切り分けやすくなります。

Androidではv2rayNGがおすすめです。特にXray関連の機能が必要な場合に適しています。V2Fly向けの設定が必要な場合はv2flyNGも選択肢になります。どちらも実際のプロトコル対応を確認してください。インストールできたからといって、ノードとの互換性があるとは限りません。初回起動時にはVpnServiceの使用を許可し、画面ロック後の安定性もバックグラウンド制限を含めて確認してください。アプリごとのプロキシ対象は利用目的に合わせます。プロキシを通っていないアプリの通信を、プロトコルの不具合と誤認しないようにしましょう。

アプリと保守条件に合わせて組み合わせを選ぶ

短いリクエストが多い用途では接続確立とDNS、継続的なデータ転送ではスループットと安定性に注目します。リアルタイム通信ではUDPとネットワーク切り替えを個別に検証してください。リソースに制約のある端末では共通鍵暗号の負荷や同時接続数に注目できますが、アイドル時のメモリ使用量を一度確認しただけで結論を出すべきではありません。標準的なTLS証明書を利用でき、保守手順も整っているサービスでは、TLSを使う方式を優先して検討できます。REALITYを使う場合は、公開鍵、サーバー名、関連設定を確実に管理する必要があります。

VMessやShadowsocksのサービスが安定稼働している場合、移行にはサーバー側で対応プロトコルを新たに提供する必要があります。クライアントのプルダウンを変えるだけでは移行できません。VLESSを選ぶならセキュリティ層とflow、Trojanならパスワードと証明書による身元確認、Shadowsocksなら暗号方式とキー形式をあわせて確認してください。複雑な設定を管理できない組み合わせより、運用担当者が理解し、継続して正しく更新できる組み合わせのほうが、長期利用の基準として適しています。

接続異常は発生段階ごとに切り分ける

第1段階ではインポートと起動を確認します。ノードが登録されているか、正しい項目を選択しているか、コアが正常に動作しているか、ログに未知の設定項目が表示されていないかを確認してください。第2段階では接続とハンドシェイクを確認します。アドレスの名前解決、ポートへの到達性、サーバー名、時刻を調べます。第3段階では認証とトランスポートを確認します。ユーザー識別子、パスワード、暗号方式、パス、公開鍵、flowを照合してください。各段階でまず提供元の設定に戻し、根拠のない「最適化」をいくつも重ねないようにしましょう。

接続が確立しているのにWebページを開けない場合は、アプリの通信がプロキシに入っているか、ルーティング先のアウトバウンド、DNSを確認します。IPアドレスを直接使うリクエストとドメイン名を使うリクエストを比べる方法もありますが、対象のサービスがそのアクセス方法を許可しているかに注意してください。一部のアプリだけ使えない場合は、システムプロキシに従うか、アプリごとの対象一覧に含まれているか、UDPを使っているかを確認します。プロトコルを変更する前に、問題がローカルの接続入口、プロキシ接続、接続先サービスのどこにあるかを特定すれば、無駄な試行を減らせます。

動作する設定と確認記録を残す

基準となる設定を確立したら、プロトコル、トランスポート、セキュリティ方式、コア、接続方式を記録します。認証情報を公開メモに残す必要はありません。変更は一度に一つの要素だけにし、インポート直後のノードも保存しておきましょう。クライアントやサブスクリプションを更新した後は、普段使うアプリ、特にバックグラウンド動作とUDPを再確認してください。一時的な回線の不調で設定をすべて変更せず、まず再テストしてログを確認し、問題が安定して再現することを確かめてから対処します。

このページでは選択時の互換性を解説しています。操作手順はクイックスタートガイドをご覧ください。個別の疑問はよくある質問、設定項目の意味は用語集で確認できます。最終的に目指すのは、提供元が明確で、項目が一致し、コアが対応し、実際のアプリでも動作を確認できた設定です。抽象的なプロトコルのランキングではありません。安定性、保守性、実際のタスクを完了できるかどうかが、設定の適切さを判断する基準です。