V2Rayプロトコルとコア
技術リファレンス

プロトコル、伝送、セキュリティ層を分けて考える

1つのノードは、1つのプロトコル名だけで決まらない

クライアント一覧に「VLESS」や「VMess」と表示されていても、それは接続構造の一部にすぎません。完全なノードには少なくとも、サーバーアドレス、ポート、ユーザー識別情報、プロキシプロトコル、下位伝送、セキュリティパラメータが含まれます。たとえばVLESSはTCP上で直接動作させることも、WebSocketやgRPCなどの伝送に載せることもできます。外側には標準TLSを使うことも、REALITYを組み合わせることも可能です。同じVLESSでも伝送層とセキュリティ層が異なれば、ハンドシェイク回数、最初のパケットサイズ、接続の再利用方法、障害の現れ方は変わります。

階層で理解すると、トラブルの切り分け範囲を絞れます。クライアントに「接続タイムアウト」と表示されても、原因はドメイン解決、TCP接続、TLSハンドシェイク、REALITYパラメータの一致、プロキシプロトコル認証のいずれかかもしれません。VMessとVLESSを何度も切り替えるだけでは、誤ったサーバー名、ポート、伝送経路は変わりません。まずネットワーク層の到達性を確認し、次にセキュリティ層のハンドシェイク、最後にプロトコルの識別情報とルーティングルールを確認するのが正しい順序です。

一般的な接続スタックの組み合わせ

VMessはユーザー識別情報と時刻に関連する認証を備え、VMess over TCP、VMess over WebSocketにTLSを重ねる構成などが一般的です。VLESSはプロトコル層を軽量化し、機密性とサーバー認証を主にTLSやREALITYに委ねます。TrojanはTrojan over TLSが一般的で、認証情報は保護された接続内で送信されます。Shadowsocksは規定のAEAD暗号方式でデータストリームを直接保護し、設定項目は比較的少なめです。REALITYはVMessやVLESSと同列のプロキシプロトコルではなく、Xray体系の伝送セキュリティ方式で、通常はVLESSと組み合わせて使います。

WebSocket、gRPC、HTTPUpgrade、ネイティブTCPも認証プロトコルではありません。データを下位接続にどう載せるかを決めるものです。WebSocketは成熟したHTTP基盤との互換性に優れますが、フレームのカプセル化が増えます。gRPCはHTTP/2を基盤とし、多重化やストリーミングに適していますが、クライアント、サーバー、中継経路での整合性が必要です。ネイティブTCPは経路が短く設定項目も少ないため、問題を特定しやすい傾向があります。QUIC系の伝送はUDP上で動作し、良好に機能するかどうかはUDPの品質とタイムアウト方針に左右されるため、理論上の特性だけで判断できません。

比較時は他の変数をそろえる

プロトコルをテストする際は、変数を管理する必要があります。サーバーのハードウェア、回線、暗号アルゴリズム、伝送方式、同時接続数、テスト対象をできるだけそろえてください。近距離のVLESSノードと遠距離のVMessノードを直接比較しても、分かるのは2本の完全な経路の結果だけで、プロトコル自体の速さは証明できません。ダウンロード速度はサーバーの出口帯域や対象サイトの速度制限にも左右されます。短時間の接続テストはハンドシェイク負荷を反映しやすく、長時間の大容量転送は継続的なスループットとCPU使用率を観察するのに適しています。

クライアントの「遅延」も区別が必要です。ICMP ping、TCP接続時間、実際のプロキシハンドシェイク、プロキシ経由でテスト先へアクセスする時間は、それぞれ別の指標です。詳しい原理は遅延テストの仕組みを分解して解説しています。選定では一覧中の最小値だけでなく、実接続の安定性、普段使うアプリの動作、連続利用後のリソース変化を優先してください。

5種類の方式の背景と設計上の選択

VMess：完全な認証機構と成熟した互換性

VMessはProject Vのエコシステム初期に形成された主要プロトコルの1つです。ユーザー識別情報、リクエストメタデータ、動的認証をプロトコル構造に組み込み、設定で最もよく使われる識別フィールドはUUIDです。VMessの強みは設定項目の少なさではなく、長年蓄積されたクライアント対応と設定ノウハウにあります。既存のサブスクリプション、管理パネルの出力、古い設定にはVMessを基盤とするものが多いため、既存環境との互換性が必要な場合に堅実な選択肢となります。

VMessの認証はシステム時刻と関連します。端末の時刻が大きくずれていると、アドレス、ポート、UUIDがすべて正しくても認証を完了できない場合があります。同じノードが一方の端末では使えるのに、別の端末では直ちに失敗する場合は、自動時刻合わせも確認してください。VMessには複数の暗号・セキュリティ設定があり、クライアントの自動設定は通常、コアの能力に合わせて調整されます。手動指定する場合はサーバー側の対応を確認し、古い解説の固定値をすべての設定にそのまま適用しないでください。

VLESS：プロトコル層を簡素化し、外部セキュリティ層に依存

VLESSは、プロトコル自身が担う暗号化と認証の負荷を減らすことを重視して設計されています。軽量な識別情報とプロキシリクエストの表現を残し、伝送の機密性は主にTLSやREALITYなどのセキュリティ層に委ねます。これにより二重暗号化の可能性を抑え、プロトコル層とセキュリティ層の役割も明確になります。一方、設定はUUIDだけでは完結しません。フロー制御、伝送方式、セキュリティ種別、サーバー名、公開鍵などが最終的な接続に影響します。

VLESS自体が「暗号化済み」を意味するわけではありません。サブスクリプションにVLESSと表示されたら、securityフィールドを確認してください。TLSを使う場合はサーバー名と証明書の関係を確認し、REALITYを使う場合は公開鍵、短い識別子、フィンガープリント、サーバー名も確認します。クライアント画面でこれらの項目が別々に表示されると、アドレスとUUIDだけをコピーしてしまいがちです。その結果、ノードは保存できても接続を確立できません。

Trojan：TLSを基本構成とする方式

Trojanは通常、パスワードで認証し、TLSで接続を保護します。概念は比較的明快で、まずTLSハンドシェイクを正常に完了し、その保護されたデータ内で認証とプロキシリクエストを処理します。利用者が確認すべき主な項目は、サーバーアドレス、ポート、パスワード、サーバー名、証明書検証設定です。ドメインと証明書が一致しなければ、プロトコル認証が始まる前にTLS層で接続が終了します。

Trojanの実性能は、TLSセッション、ネットワークの往復時間、下位実装に大きく左右されます。名前が単純だからといって、VMessやVLESSより必ず省リソースになるわけではありません。長時間接続ではハンドシェイクコストが継続転送に分散されますが、短時間接続が多い場合はTLSセッション再利用とクライアントの接続プールが重要です。Trojanを比較する際は、クライアントログで失敗箇所がTLS段階なのか認証段階なのかを確認してください。

Shadowsocks：コンパクトな暗号化プロキシ構造

ShadowsocksはSSと略されることがよくあります。パスワードと暗号方式からセッションに必要な情報を生成し、現在のコアが対応するAEAD方式を使うのが基本です。設定項目が少なくデータ経路も直接的なため、設定の複雑さを抑えたい環境に適しています。ただし暗号方式の名称は完全に一致していなければなりません。似た名称を同じアルゴリズムだと誤認したり、クライアントのコアが実装していない方式を使ったりすると、接続に失敗します。

Shadowsocksのサブスクリプション表現には、過去の形式が複数あります。暗号方式、パスワード、ホスト、ポートを直接含むリンクもあれば、プラグインパラメータを追加したものもあります。クライアントが基本的なSSを認識できても、すべてのプラグイン構成を認識できるとは限りません。インポート後は「暗号方式」と「プラグイン」欄が完全か確認してください。ノード名が一覧に表示されたからといって、解析成功とは判断できません。

REALITY：独立したプロキシプロトコルではなくセキュリティ方式

REALITYはXrayの機能体系に属し、通常はVLESSと組み合わせます。クライアントに「VLESS REALITY」と表示されている場合、VLESSがプロキシの意味論を担い、REALITYが伝送セキュリティを担います。主なパラメータはサーバー公開鍵、短い識別子、サーバー名、クライアントフィンガープリントです。公開鍵は証明書ファイルではなく、短い識別子もユーザーUUIDではありません。それぞれ役割が異なるため、入れ替えても接続は成立しません。

REALITYは設定精度を求められますが、日常利用が複雑になるとは限りません。サブスクリプションが完全で、クライアントのコアが対応し、途中のツールでフィールドが失われていなければ、通常はインポート後すぐ接続できます。問題は、古いクライアントがフィールドを認識できない、サブスクリプション変換ツールが新しいパラメータを削除する、手入力でpublicKey・shortId・serverNameの位置を誤る、といった場合に起こります。V2Flyコアのクライアントを使う場合は、対象方式が対応範囲に含まれるか先に確認してください。すべてのXray拡張がそのまま動くとは限りません。

接続速度、スループット、リソース使用量

最初のデータ到着速度はハンドシェイク経路に左右される

体感上の「開く速さ」は、DNS検索、下位接続、伝送ハンドシェイク、セキュリティハンドシェイク、プロトコル認証、対象サイトの応答によって決まります。プロトコル層が占めるのはその一部です。往復遅延の大きい経路では、相手の応答を待つハンドシェイクが1回増えるだけで最初のデータ到着時間が大きく延びます。一方、低遅延のローカルネットワークでは体感差が小さいこともあります。TLSセッション再開、HTTP/2接続の再利用、コアの接続プールも結果を変えます。

VMess、VLESS、Trojan、Shadowsocksはいずれも長時間接続を維持できますが、クライアントやアプリによる接続再利用の方法は同じではありません。ブラウザはHTTP/2やHTTP/3のセッションを再利用することがあり、コマンドラインツールは接続を頻繁に新規作成し、メッセージアプリは少数の長時間接続を維持します。1つのウェブページをテストしただけでは、すべてのアプリを代表できません。少なくとも短時間のページ接続、継続的なダウンロード、常駐アプリの3種類を確認してください。

継続的なスループットは回線と暗号処理能力に左右される

安定した転送に入ると、パケットロス、輻輳制御、サーバーの出口帯域、端末の1コア性能、暗号実装が、プロトコルヘッダーのサイズより重要になることが多いです。VLESSはプロトコル層が軽量でも、外側の伝送で余分なコピーやヘッドオブラインブロッキングが発生すれば、最終スループットが高くなるとは限りません。Shadowsocksはデータ経路がコンパクトですが、暗号方式がハードウェアアクセラレーションに対応しているかどうかが、低消費電力端末のCPU使用率に直接影響します。

デスクトップCPUは通常、1コア性能に余裕があり、一般的なブラウジングや動画視聴では、複数方式の差がネットワーク変動に埋もれやすいです。ルーター、低消費電力PC、古いAndroid端末では差が出やすくなります。この場合は、継続的な高負荷でCPUが長時間フル稼働するか、端末がクロックダウンするか、ネットワーク断から素早く復旧できるかを確認し、1回の速度測定ピークだけを見ないでください。ルーター機器のハードウェア要件は、ルーターとサブルーターでV2Rayコアを動かす際の概要も参照してください。

カプセル化層は帯域と処理コストを増やす

ネイティブTCPは通常、カプセル化経路が最短です。WebSocketはフレームヘッダーとHTTPアップグレード処理が増えますが、互換性が成熟しており、多くの場面では業務データに対する割合は小さくなります。gRPCはHTTP/2を基盤とし、多重化を利用できますが、フロー制御ウィンドウ、接続再利用、中継経路によるHTTP/2処理が実際の挙動に影響します。伝送層が複雑になるほど確認すべきパラメータが増え、障害時にはログを階層ごとに確認する必要があります。

小さなパケットが頻繁に発生するアプリは、カプセル化とスケジューリングの影響を受けやすくなります。音声、ゲーム、リアルタイム制御の通信はジッターやパケットロスに敏感で、平均ダウンロード速度だけでは体感を判断できません。UDPをプロキシ経由で使う場合は、プロトコルがUDPに対応しているか、クライアントが機能を有効にしているか、ネットワークがUDPマッピングを頻繁に破棄しないか、ルーティングルールが関連ドメインとIPを同じ出口へ送っているかも確認してください。どこか1つでも一致しないと、ログインはできるのにリアルタイム機能だけが異常になることがあります。

再現可能な比較方法を作る

テストでは端末、ネットワーク、サーバーの場所、対象ファイルを固定し、経路を変える他のプロキシツールは停止します。まず実際の接続テストを連続して複数回行い、最小値ではなく中央値を記録します。次に十分な時間ダウンロードして安定したスループットを観察し、最後にクライアントプロセスとコアプロセスのCPU・メモリ変化を確認します。異なるサーバーのプロトコルを比較する場合は、ノード全体の品質しか評価できず、プロトコル設計に原因を帰すことはできません。

コールドスタートと既存接続も区別してください。初回起動にはコアの読み込み、DNSキャッシュの構築、セキュアセッションの作成が含まれます。後続アクセスでは既存接続が再利用される可能性があります。頻繁にネットワークを切り替える環境ではコールドスタートと再接続が重要で、端末を常時オンラインにする環境では安定性とバックグラウンドリソースが重要です。すべての指標で常に優位なプロトコルはありません。

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

消費電力は暗号計算だけで決まらない

モバイル端末のプロキシによる消費電力は、無線ネットワークの復帰、CPU計算、仮想ネットワークインターフェースでの転送、DNS検索、接続維持、アプリのバックグラウンド通信によって決まります。プロトコル暗号化はその一要素にすぎません。画面消灯後も多くのアプリが短時間接続を繰り返すと、携帯通信が低消費電力状態から何度も復帰し、プロトコル自体より大きな電力を消費することがあります。逆に、少数の安定した長時間接続なら、TLSを使っていても消費電力を比較的安定させられます。

v2rayNGはXrayコアを使用し、VLESSやREALITYなどXrayの機能を必要とするサブスクリプションに適しています。v2flyNGはv2flyコアを使用し、V2Fly向けに作られた設定の選択肢になります。どちらもAndroidのVPNインターフェース経由で通信を引き受ける場合があります。実際の消費電力は、ルーティング範囲、アプリ数、DNS方針、接続状態に左右され、クライアント名やプロトコル名だけでは判断できません。

仮想ネットワークインターフェースモードとシステムプロキシの違い

Androidクライアントは通常、システムが提供するVPNインターフェースを通じてアプリ通信を転送します。各パケットはユーザー空間での処理、ルーティング判定、アウトバウンド接続を通過するため、ルールが複雑で同時接続が多いほどスケジューリング負荷が増します。デスクトップ版v2rayNはシステムプロキシだけを設定することも、TUNモードでシステムプロキシに従わないプログラムまで引き受けることもできます。TUNの仕組みと権限要件はTUNモードで全トラフィックを引き受ける設定方法を参照してください。

モバイル端末ですべてのアプリを常にプロキシへ通す必要はありません。クライアントがアプリ別の振り分けに対応しているなら、必要なアプリだけを選び、無関係なバックグラウンド通信を減らします。ルーティングルールも説明可能な形に保ち、まずLANと必要な直接接続を定義し、次にプロキシルールを処理し、最後にデフォルト出口を設定します。重複や相互に上書きするルールが多いと、保守だけでなく障害の切り分けも難しくなります。

接続維持、再接続、ネットワーク切り替え

Wi-Fiと携帯ネットワークを切り替えると、既存のTCP接続は通常再確立が必要になります。クライアントが無効な接続を長く保持すると、アプリの待ち時間が長くなります。逆に探測や再接続が頻繁すぎると、端末の復帰回数が増えます。この挙動はプロトコルだけで決まらず、コアの接続管理、Androidのバックグラウンド制限、アプリ自身の再試行方針も関係します。安定運用では、短い間隔の接続確認を複数同時に有効にしないことをおすすめします。

WebSocket、gRPC、ネイティブTCPはネットワーク切り替え後の復旧方法が異なりますが、最終的にはアプリがリクエストを再発行するかどうかにも依存します。QUICなどUDPベースの伝送は接続の意味論が異なる一方、モバイルネットワークではUDPマッピングが積極的に破棄されることがあります。画面ロック後の復旧が遅い場合は、まずクライアントがシステムによってバックグラウンド実行を制限されていないか確認し、ログでネットワーク到達不能、DNSタイムアウト、リモート接続終了のどれかを確認してください。

DNS方針は復帰と再試行に影響する

DNS設定が一致していないと、重複検索、タイムアウト、フォールバックが発生します。ローカルDNS、リモートDNS、システムDNS、アプリ内蔵の暗号化DNSを同時に設定すると、リクエスト経路が想定以上に複雑になることがあります。どのドメインをローカルで解決し、どれをプロキシ出口で解決するかを明確にし、同じ種類の検索を複数のルールで同時に処理しないのが安全です。ノードサーバーにドメインを使う場合は、サーバー接続用の名前解決が自身のプロキシ経路で循環しないことも確認してください。

「ブラウザは使えるのに一部のアプリだけ電池を消費し続ける」場合は、そのアプリが解決できないドメインへ繰り返しアクセスしていないか、現在のプロキシ方式が引き受けないネットワークインターフェースを使っていないか確認します。コアログに同じタイムアウト行が繰り返し出ているなら、バッテリー統計の単一の割合より切り分けに役立ちます。同じ宛先への高速な再試行が続いている場合は、まずルーティングまたはDNSを修正し、すぐにプロトコルを変更しないでください。

意味のある消費電力比較の方法

2つの設定を比較する場合は、同じ端末、同じネットワーク、近い業務通信量を使います。充電状態、画面輝度、電波強度、バックグラウンド同期が結果を乱します。少なくとも日常利用の1サイクルを観察し、システムのバッテリー統計、クライアントログ、端末温度を組み合わせて判断してください。短時間ページを開いた後の電池残量だけでは、無線通信とプロトコル計算の影響を分離できません。

リソース消費を減らすことが目的なら、まず無効な接続、プロキシ対象アプリの範囲、DNSタイムアウトを減らし、端末に適した暗号実装を選びます。プロトコル層は互換性と安定性を前提にしてください。理論上ヘッダーが小さくても、現在のクライアントでエラーと再接続を繰り返す方式は、実際には省電力になりません。

V2FlyとXrayのコアファミリーの関係

共通の起源と異なる進化の方向

V2FlyとXrayはいずれもProject Vの技術エコシステムを起源とし、インバウンド、アウトバウンド、ルーティング、DNS、ポリシー、伝送設定など多くの概念を共有しています。両者はVMess、Shadowsocksなど複数の一般的な設定を扱え、構造化された設定で接続関係を記述します。ただし、似ているからといって完全に同じではありません。進化の過程で、新しいプロトコル機能、伝送オプション、フィールド名、デフォルト動作に差が生じています。

XrayはVLESS、フロー制御、REALITYなどに対応しているため、v2rayNやv2rayNGではこの種のノードをXrayで処理することがよくあります。v2flyNGはv2flyコア向けで、サブスクリプション自体がV2Flyの機能に合わせて生成される場合に適しています。クライアント画面は設定の入口にすぎず、接続できるかどうかは、実際に起動しているコアがそのフィールドを理解できるかで決まります。

設定が似ていても、そのまま相互利用できるとは限らない

基本的なアウトバウンド構造は両方のファミリーでよく似ている場合がありますが、拡張フィールドが互換性の境界になります。たとえばREALITY設定を含むXray設定は、外側がJSONだからといってV2Flyで読み込めるとは限りません。未知のフィールドが起動時に直接エラーを起こすこともあれば、無視されて想定と異なる動作になることもあります。設定移行では、実行コアの名前だけを変更せず、機能ごとに確認してください。

双方が同じプロトコル名に対応していても、伝送の詳細が異なる場合があります。network、security、flow、streamSettings、TLSパラメータ、DNS構造を確認してください。クライアントが設定を自動生成する場合は、選択したコアに合わせてフィールドが調整されます。しかし完全なJSONを手動インポートする場合、この変換が行われないことがあります。一般ユーザーは、コアをまたぐ大規模な設定ファイルを長期管理するより、サブスクリプションや共有リンクをインポートしてクライアントに実行設定を生成させるのが安全です。

v2rayN、v2rayNG、v2flyNGの対応関係

デスクトップではv2rayNが第一候補です。Windows、macOS、Linuxに対応し、サブスクリプション管理、システムプロキシ、ルーティングモード、コアログへの入口を備えているため、複数のデスクトップ環境をまとめて管理できます。Androidでは、サブスクリプションにVLESS、REALITY、またはXrayへの依存が明記されたフィールドが含まれる場合はv2rayNGを優先します。V2Flyの機能に合わせて出力されたサブスクリプションや、V2Flyの動作を確認する必要がある場合はv2flyNGを選べます。

この3つのクライアントは、3種類のプロトコルではありません。クライアントは画面、設定生成、システムネットワークの引き受け、コアプロセス管理を担当します。コアは設定の解析とトラフィック転送を担当し、プロトコルはクライアントのコアとサーバーがデータを交換する方法を定義します。この3層を分けて考えると、共有リンクをインポートできない問題はクライアントの解析、コア起動失敗は設定互換性、ハンドシェイク失敗はプロトコルまたはセキュリティ層の問題として切り分けられます。

ログから互換性の問題を判断する

コアの起動に失敗した場合は、末尾で繰り返される終了情報ではなく、最初のエラーを確認してください。未知のフィールド、認識できないプロトコル種別、必須パラメータの不足、JSON構文エラーは、通常起動段階で明確に表示されます。詳しい方法はログの1行目からコア起動失敗を特定する方法を参照してください。コアが起動済みで接続時に失敗する場合は、DNS、ダイヤル、TLS、認証に関する行を確認します。

設定移行後、一部のノードだけが使えなくなった場合は、利用可能なノードと利用できないノードを、プロトコル、セキュリティ層、伝送層で分類します。REALITYノードだけがすべて失敗しVMessが正常なら、まずコアの対応機能を確認します。同じプロトコルで特定の伝送だけが失敗するならstreamSettingsを確認し、すべてのノードが起動できないなら設定全体の構造、ポートの競合、権限を確認します。この分類は、ノードを1つずつ削除して作り直すより効果的です。

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

サブスクリプションは入れ物であり、プロトコルではない

サブスクリプションリンクは通常、複数のノード定義を返します。ノードはVMess、VLESS、Trojan、Shadowsocksのいずれかで、クライアント専用フィールドを含むこともあります。サブスクリプションURL自体は内容の場所を示すだけで、内部プロトコルを示しません。クライアントが更新すると、まずテキストをダウンロードし、エンコードと形式を判別し、各ノードをローカル設定へ変換します。どこかの段階で失敗すると、ユーザーには「ノードがありません」と表示されることがあります。

一般的な内容には、複数の共有リンク、エンコードされたリンクの集合、構造化設定などがあります。拡張フィールドや複合形式をどこまで扱えるかはクライアントによって異なります。サブスクリプションがREALITYパラメータを出力していても、中間の変換処理が基本的なVLESSフィールドしか残さなければ、インポート後もノードは表示される一方、公開鍵、短い識別子、フィンガープリントが失われます。このケースは完全な解析失敗より見つけにくい問題です。

共有リンクで表現できる情報

VMessの共有情報には通常、アドレス、ポート、ユーザー識別情報、伝送、セキュリティ設定が含まれます。VLESSリンクは、encryption、security、type、flow、serverName、publicKey、shortIdなどをクエリパラメータで表します。Trojanリンクにはパスワード、アドレス、ポート、TLS関連パラメータが必要です。Shadowsocksリンクは主に暗号方式、パスワード、サーバー、ポートを表し、プラグインパラメータを含む場合もあります。

リンクのパラメータ名は明確に区別されています。VLESS REALITYを例にすると、pbkは通常サーバー公開鍵、sidは短い識別子、sniはサーバー名、fpはクライアントフィンガープリントに対応します。クライアント画面では正式名称、サブスクリプションでは短縮パラメータが使われることがあります。インポート後はフィールドの意味を照合し、表示順だけで推測しないでください。

vless://ユーザー識別子@example.invalid:443?encryption=none&security=reality&type=tcp&sni=www.example.invalid&fp=chrome&pbk=サンプル公開鍵&sid=サンプル短縮識別子#VLESS-REALITY-サンプル

上記の構造はフィールドの位置を説明するためのもので、ドメインと識別情報は明示的なサンプル値です。実際のノードでは、サーバーが提供する完全なパラメータを使用してください。リンクを手動編集する場合はURLエンコードにも注意が必要です。ノード名の空白、日本語、特殊記号は正しくエンコードし、パスワードに予約文字が含まれる場合も、見た目の文字列をそのまま連結しないでください。

インポート成功と設定の完全性は別

クライアントがノードレコードを作成できても、最外層の形式を認識できたことしか分かりません。次にノード詳細を開き、プロトコル種別、アドレス、ポート、識別フィールド、伝送方式、セキュリティ層を確認します。WebSocketではpathとHost、gRPCではserviceName、TLSではserverName、REALITYではpublicKey、shortId、fingerprint、flowを確認してください。

サブスクリプション更新後、既存ノードは使えるのに追加ノードだけ使えない場合は、両者のフィールド差分とクライアントのコア対応を確認します。すべてのノードが消えた場合は、サブスクリプションの返却内容が空でないか、URLが途中で切れていないか、クライアントが現在の形式を認識しているかを確認してください。よくある6つの原因と確認順はサブスクリプションリンクの無効化・解析失敗を確認する方法にまとめています。

サブスクリプション更新とローカル編集の上書き関係

多くのクライアントはサブスクリプション更新時、サブスクリプショングループに基づいてノードを再生成します。ローカルで行った手動編集は、次回更新時に上書きされる可能性があります。長期的に保持したいカスタムルーティング、DNS、システムプロキシ設定は、サブスクリプションノードを個別に編集せず、クライアントが提供する独立した設定領域に保存してください。問題検証のため一時的にノードを変更する場合は、ローカルノードとして複製して名前を変えると、サブスクリプション由来のノードと混同しにくくなります。

ノード名は安定した識別子ではありません。サブスクリプション提供元は名前や並び順を変更でき、クライアントもアドレス、プロトコル、内部識別子などで重複排除することがあります。切り分けでは「2番目のノード」ではなく、プロトコル、サーバー、ポート、主要な伝送パラメータを記録してください。ログの宛先アドレスとアウトバウンドのラベルの方が対応関係を作るのに適しています。

クライアントはフィールドの保持性で選ぶ

デスクトップ環境ではv2rayNを使うと、同じ画面で複数プロトコルのフィールドと実行ログを確認できます。AndroidのサブスクリプションにXray拡張が含まれる場合はv2rayNGを使い、V2Fly設定向けであることが明確ならv2flyNGを使います。複数のプロトコルを含むサブスクリプションでは、クライアントが各ノードのフィールドを保持し、すべてを単一プロトコルへ強制変換しないことが重要です。

複雑なサブスクリプションでは、複数の変換処理を何度も通すより、目的のクライアントへ元のサブスクリプションを直接インポートし、異なるプロトコルから1件ずつ抽出確認するのが安全です。フィールドが完全だと確認してから接続テストを行います。形式変換を1回追加するたびに、フィールドの欠落、デフォルト値の変更、エンコードエラーの可能性が増えます。

プロトコルパラメータの確認とトラブル切り分け

アドレス、ポート、識別フィールド

どのプロトコルでも、まず基本の3項目から確認します。サーバーアドレスを解決できるか、ポートが正しいか、識別フィールドが完全かを確認してください。VMessとVLESSではUUID、Trojanではパスワード、Shadowsocksではパスワードと暗号方式を使うことが多いです。コピー時は前後の空白を削除しますが、内容内部の文字は変更しないでください。ポートは有効な数字で、サーバーの待受ポートと一致している必要があります。

サーバーアドレスがドメインの場合は、まずクライアントのいるネットワークで名前解決できることを確認します。設定にIPとserverNameの両方がある場合、それぞれ用途が異なります。IPは接続先を決め、serverNameはTLSまたはREALITYのハンドシェイクに使われます。serverNameをIPに置き換えるとセキュリティ層が失敗することがあり、接続アドレスを証明書のドメインへ変更すると実際の経路が変わる可能性もあります。

TLSとサーバー名

TLS設定では、serverNameは通常、サーバーの身元確認とハンドシェイクに使われます。サーバー設定および証明書との関係が一致していなければなりません。クライアントに「証明書検証をスキップ」のような項目があっても、通常の修復策として使わないでください。証明書エラーは、ドメイン、時刻、証明書チェーン、中間ネットワークの問題を示すことが多く、検証を無効にすると根本原因を隠し、後の移行判断も難しくなります。

システム時刻も証明書の有効期限判定に影響します。複数のTLSノードが同時に失敗し、非TLSノードが正常なら、端末の時刻、タイムゾーン、証明書関連ログを確認してください。1つのドメインだけが失敗する場合は、そのノードのserverName、接続先アドレス、サーバー証明書設定を重点的に確認します。

REALITYの4つの主要パラメータ

REALITYのクライアント設定では、少なくともpublicKey、shortId、serverName、fingerprintを正しく理解する必要があります。publicKeyはサーバー側の対応する鍵から取得し、shortIdはサーバーが許可する値の1つです。serverNameはサーバー設定に適合し、fingerprintはクライアントのハンドシェイク指紋タイプを表します。VLESSの識別UUIDは別途存在し、publicKeyで代用することはできません。

flowフィールドがVLESS設定に関係する場合もあります。サーバーとクライアントは互換性のある値を使わなければなりません。サブスクリプションにflowが明記されている場合はそのままインポートし、サーバーが対応するフロー制御を有効にしていないなら、他のノードを参考に勝手に追加しないでください。誤ったflowは、基本接続が確立した後も正常な転送を妨げることがあり、クライアントの一般的なエラー表示よりログの方が具体的です。

WebSocket、gRPC、パスフィールド

WebSocketでは主にpathとHostを確認します。pathがスラッシュで始まるか、クエリ部分を含むかは、サーバー側の値をそのまま扱ってください。HostとTLSのserverNameは同じ場合もあれば、異なる役割を持つ場合もあります。gRPCでは主にserviceNameを確認し、多重化モードなどのオプションについてクライアントとサーバーの理解が一致していることを確認します。WebSocketのpathをgRPCのserviceNameに入れても、名前が似ているだけでプロトコルの動作はまったく異なります。

接続ログで下位TCP接続とTLSが成功した後、HTTPステータスエラーが返る、またはストリームが閉じられる場合は、伝送経路を重点的に確認します。サーバーの前段にリバースプロキシがある場合は、対象のアップグレード処理やHTTP/2転送に対応していることも確認してください。クライアントは設定で指定されたリクエストを送るだけで、正しいパスを自動推測することはできません。

最小限の変数で切り分ける

まず設定が完全だと分かっているノードを1つ選び、カスタムルーティングと追加DNSルールを無効にし、クライアントのデフォルトプロキシモードで基本接続をテストします。基本接続に成功したら、ルーティング、TUN、アプリ別振り分け、カスタムDNSを1項目ずつ戻します。最初からプロトコル、伝送、ルーティング、システムプロキシを同時に変更すると、失敗しても原因を特定できません。

ログは最初のエラーから読みます。再接続を繰り返すと似た行が大量に記録され、末尾にはプロセス終了やコンテキストキャンセルだけが残ることが多いです。ログを消去してコアを起動し、明確な対象へアクセスしてエラーが出たら停止する、という一度きりのクリーンなテストを保存してください。DNS、ダイヤル、ハンドシェイク、認証を時系列で並べて確認できます。

利用シーンに応じたプロトコルとクライアントの選び方

既存のサブスクリプションは元の設定を優先する

サブスクリプションに利用可能なノードがすでに含まれているなら、まず元のプロトコルとパラメータのままインポートするのが原則です。特定の名前に合わせるために手動変換しないでください。VMessノードは種類を変更するだけでVLESSにはなりません。TrojanのパスワードをそのままShadowsocksのパスワードとして使うこともできません。プロトコル変換には、サーバー側が対応する待受とパラメータを同時に提供する必要があります。クライアント側だけの変更では変換は完了しません。

デスクトップではまずv2rayNを選び、サブスクリプション内容に応じてノードを選択します。AndroidでVLESS、REALITY、その他Xray拡張を使う場合はv2rayNGを使用し、サブスクリプションが明確にV2Flyコア向けに生成されている場合はv2flyNGを使えます。対応するインストール入口はクライアントダウンロードページにまとめています。Windows、macOS、Android、Linuxのプラットフォーム情報も掲載しています。

旧環境との互換性を重視するならVMess

既存のサーバー、サブスクリプションシステム、クライアントがVMessを安定してサポートしているなら、新しいプロトコルが登場したという理由だけで急いで移行する必要はありません。VMessは設定資料と互換性の実績が豊富で、既存のWebSocket、TLS、TCP構成を使い続けたい環境に適しています。システム時刻、UUID、伝送フィールド、セキュリティ設定を重点的に管理してください。

段階的に移行する場合は、サーバー側で新旧の入口を並行して提供し、同じ回線と端末でテストします。まず機能と安定性を検証し、その後にサブスクリプションを切り替えます。移行中も動作する元の設定を残しておけば、新プロトコルの問題とサーバー全体の問題を区別できます。

階層を明確に分けたいならVLESS

VLESSは、軽量なプロトコル層とTLS、REALITYなどのセキュリティ層を明確に組み合わせたい環境に適しています。標準TLSを使う場合は、証明書、serverName、伝送設定を完全にそろえる必要があります。REALITYを使う場合は、Xrayコアに加えて、対応する公開鍵、短い識別子、フィンガープリント、フロー制御パラメータが必要です。強みはVLESSという名前だけでなく、完全な接続スタックを適切に組み合わせることで生まれます。

v2rayNやv2rayNGへVLESS共有リンクをインポートした後は、streamSettingsを抽出確認してください。サブスクリプションを変換している場合は、特にREALITYパラメータが削除されていないか確認します。設定が正確なら日常操作は他のプロトコルより複雑ではありませんが、設定元が不完全だと基本的なVMessより確認すべきフィールドが増えます。

TLS設定を中心に考えるならTrojan

サーバーがTrojan方式でパスワードとTLSパラメータを提供しているなら、クライアントでは対応するノードをそのまま使えます。選定の要点は、証明書とサーバー名が正しいか、TLSセッションが安定しているか、伝送方式がサーバーと一致しているかです。Trojanは明確なパスワード認証とTLS接続構造を好む環境に適していますが、証明書、ネットワーク、サーバー設定の基本要件を回避することはできません。

短時間接続が多い環境では最初のデータ到着とセッション再利用を確認し、継続的なダウンロードでは安定したスループットを確認します。プロトコル構造だけから性能を推測しないでください。Trojanノードと他のプロトコルノードが別サーバーにある場合、結果は主に完全な経路の差を反映します。

設定項目を減らしたいならShadowsocks

Shadowsocksの基本設定はアドレス、ポート、パスワード、暗号方式に集約されており、サーバーがクライアント対応の現代的なAEAD方式を提供し、複雑な拡張に依存しない環境に適しています。低消費電力端末では、選択したアルゴリズムの実装が良好かも確認してください。「設定が少ない」ことは「どの端末でも速い」ことを意味しません。

共有リンクにプラグインパラメータが含まれる場合は、クライアントがそのプラグインとオプションに対応しているか確認します。基本的なSSはインポートできても、プラグインフィールドが失われるとノードを使えない場合があります。UDPアプリについては、クライアント、コア、サーバー、ネットワーク経路のすべてが対応する転送をサポートしているか個別に確認してください。

モバイルでは安定接続と分かりやすい振り分けを優先する

Android端末では、プロトコル差よりも、バックグラウンド制限、電波強度、DNS再試行による差の方が大きいことがよくあります。まずクライアントのコアが明確に対応するノードを選び、不要なアプリをプロキシ対象から外し、ルーティングルールを簡潔に保ち、ネットワーク切り替え後の復旧を観察してください。画面ロック後に異常が起きても、すぐにプロトコルが原因だと決めつけないでください。

長時間バックグラウンドで動かす場合は、安定していて頻繁に再接続しない完全な設定を選びます。速度測定が一度だけ高くても、ハンドシェイクの再試行が続くノードは、バックグラウンドの標準接続には向きません。ログで再接続の原因を確認してから、パラメータ修正、伝送変更、ノード変更のいずれかを判断します。

最終的な判断手順

第1に、サーバーが実際に提供するプロトコルと完全なパラメータを確認します。第2に、対象クライアントとコアがその組み合わせに対応しているか確認します。第3に、インポート後のフィールドが完全か確認します。第4に、実接続、継続的なスループット、普段使うアプリで安定性をテストします。第5に、CPU、メモリ、バッテリー、ネットワーク切り替えを観察します。この順序なら、形式解析の問題をプロトコルの問題と誤認せず、単発の遅延値で長期的な体感を判断することも避けられます。

インストール、サブスクリプション、接続だけが必要なら、入門ガイドの手順に沿って進めてください。インストールパッケージを選ぶ場合はV2Rayクライアントダウンロードページへ進みます。サブスクリプションの解析、コアの起動、遅延指標で問題がある場合は、本ページからリンクしている専門記事も参照してください。プロトコル選択に、サーバー、コア、ネットワーク条件から切り離した唯一の正解はありません。理論上の差より、完全な互換性と安定動作を優先してください。