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

01 / SELECTION MODEL

プロトコル、トランスポート、セキュリティ層、コアを分けて理解する

クライアントの「プロトコルタイプ」は最初の選択にすぎない

GUIクライアントでは通常、VMess、VLESS、Trojan、Shadowsocksがノードタイプとして表示されます。しかし、1つの接続はこの項目だけで決まりません。完全な経路は、少なくとも4つの層に分けて考えられます。アプリケーションプロトコルは認証とリクエスト形式を担当し、トランスポート方式はデータをTCP、WebSocket、gRPCなどの通信路へ載せる方法を決めます。セキュリティ層は暗号化と接続先の本人確認を担い、コアは設定を解析して実際に接続を確立します。REALITYはVLESSと完全に並列するアプリケーションプロトコルというより、セキュリティとハンドシェイクの機能に近いものです。これらを1つの名称に混同すると、「プロトコルを正しく選んだのに接続できない」という誤判断につながります。

一般的なVLESSの組み合わせでは、ノードにVLESS、TCP、REALITY、XTLS Vision、サーバー名、公鍵などが同時に含まれる場合があります。VLESSが示すのは認証とリクエスト形式、TCPは基盤となるトランスポート、REALITYはハンドシェイクと本人確認、Visionはデータストリームの処理方法です。共有リンクをインポートすると、クライアントはこれらを1つのアウトバウンド設定にまとめます。重要な項目の欠落、表記の変化、現在のコアが認識できない場所への配置があると、最終的な動作がノード名から想像されるものと異なることがあります。

選定は既存のサーバー設定から始める

プロトコルはクライアント側の好みだけで一方的に変更できません。クライアントのノードは、プロトコル、ポート、認証情報、トランスポート方式、セキュリティパラメータのすべてでサーバーと対応している必要があります。サブスクリプションが既存設定を提供する場合は、VLESSを手動でVMessへ変更したり、サーバーアドレスとポートだけでノードを作り直したりするのではなく、クライアントが設定を完全に認識できるか確認するのが正しい方法です。プロトコル名が似ていても相互交換できるとは限らず、UUIDが同じでも他のパラメータの代わりにはなりません。ノード編集画面の各項目は、本質的にサーバー設定の一部を反映したものです。

両端の設定を自由に決められる場合は、まず双方のコアが対応する範囲を確認し、次にアプリケーションプロトコル、セキュリティ層、トランスポートの順に決め、最後にクライアントへのインポートと保守のしやすさを検討します。新規設定の多くでは、VLESSは軽量なプロトコル層を提供し、TLSやREALITYなどのセキュリティ機能と組み合わせやすい方式です。VMessは既存の設計要素を多く含むプロトコル層で、従来の設定によく使われます。Trojanはパスワード認証とTLSの利用方式を組み合わせ、Shadowsocksは構造がシンプルで対応クライアントも多い方式です。ネットワーク環境、サーバー実装、保守方針を離れて決められる絶対的な順位はありません。

互換性は名称ではなく、項目が揃っているかで判断する

クライアントがノードに対応しているか判断するには、少なくともプロトコル、アドレス、ポート、ユーザー識別子、トランスポート、セキュリティ方式、サーバー名、フィンガープリント、パスまたはサービス名などを確認します。クライアント一覧にノードが表示されても、すべての項目が正しく取り込まれたとは限りません。サブスクリプション変換、古いテンプレート、異なるコア間のインポートでは、認識できない拡張項目が破棄され、見た目は完全でも実際にはデフォルト値へ戻ることがあります。この場合はノード編集画面を開き、元のリンクまたはサーバーの説明と1項目ずつ照合し、未知の項目、ハンドシェイク失敗、設定解析に関するログも確認してください。

したがって、プロトコル選択の基本原則は、1つの名称を追いかけることではなく、一連のパラメータがサーバー、サブスクリプション、クライアント、コアの間で途切れずに渡ることです。このレイヤー構造を先に理解してこそ、その後の速度、リソース使用量、バッテリー消費を比較する意味が生まれます。基本的なインポート手順がまだ済んでいない場合は、まずクイック設定ガイドで動作する接続を1つ作り、その後このページに戻って異なる組み合わせを比較してください。

02 / VMESS & VLESS

VMessとVLESSの設計上の違い

VMessの背景と設定上の特徴

VMessはProject Vの初期エコシステムを代表するプロトコルです。ユーザー識別子、認証情報、プロトコル層の暗号化を独自形式にまとめており、長年にわたって多くのV2Ray設定やサブスクリプション形式で採用されてきました。一般的なノード項目には、サーバーアドレス、ポート、ユーザーUUID、alterId、トランスポート方式、セキュリティ設定などがあります。新しい設定では高いalterIdに依存しないことが多い一方、古いサブスクリプションや解説にはこの項目が残っている場合があります。インポート後はサーバーから指定された値を基準とし、古く見えるからといって独自に書き換えないでください。

VMessの主な利点は、蓄積されたエコシステムと従来設定との互換性です。多くのサブスクリプション生成ツール、パネル形式、クライアントが基本項目を安定して認識できるため、古い設定の移行負担が比較的小さくなります。一方で、プロトコル層が担う処理がやや多く、項目の意味がトランスポート層やセキュリティ層と混同されやすい面があります。リソースの限られた端末でも、これらの差だけで使用感が決まることは通常ありません。ただし、多数の同時接続、頻繁なスリープ復帰、長時間稼働では、プロトコルと実装による追加処理がCPU時間やバッテリー消費に表れる可能性があります。

VLESSはセキュリティの役割を組み合わせる層へ委ねる

VLESSはプロトコル層の簡素化を重視して設計されています。ユーザー識別子で認証しますが、VLESS自体に完全なデータ暗号化機能を重複して持たせず、TLSやREALITYなどの外部セキュリティ層に依存して完全な接続を構成します。この分離によって役割が明確になり、Xrayエコシステムの拡張機能を組み合わせる余地も生まれます。クライアントでVLESSを選択した後も、security、flow、transport、serverNameなどを確認する必要があります。アドレス、ポート、UUIDだけでは、元のノードを再現できないことが一般的です。

「VLESSは軽い」ことを、あらゆる環境で必ず速いという意味に捉えてはいけません。接続全体の所要時間には、名前解決、TCP接続、セキュリティハンドシェイク、認証、最初のリクエスト、継続的な転送が含まれます。プロトコル層の処理が減っても、影響するのはその一部だけです。ネットワークの往復遅延が大きい場合は、わずかなローカル計算量よりハンドシェイク回数と接続再利用のほうが重要です。大容量ファイルを主に転送するなら、輻輳制御、回線品質、サーバーの出口帯域がより大きく影響します。スマートフォンで短時間の接続を頻繁に作る場合は、ハンドシェイクとアプリの復帰処理が再び重要になります。性能はVLESSとVMessという4文字だけでなく、完全な組み合わせで判断してください。

Vision、TLS、REALITYは省略せず確認する

一部のVLESS設定にはflow項目が含まれます。たとえば、特定のTCPとセキュリティの組み合わせでVisionを使用する場合です。この項目は飾りではなく、両端のネゴシエーションとデータ処理の一部です。サブスクリプションをインポートした後にflowが空、値が途中で切れている、または現在のコアが該当する組み合わせに対応していない場合、ハンドシェイク後に接続が失敗することがあります。TLSでは、サーバー名、証明書に対応するドメイン、アプリケーション層プロトコルの項目を確認します。REALITYでは、公鍵、短い識別子、サーバー名、クライアントフィンガープリントなども必要になり、詳しい意味は第3章で説明します。

設定エディターにある「証明書の検証をスキップ」は診断用の項目であり、長期的な解決策には適しません。証明書エラーは通常、端末の時刻、サーバー名、サーバー側の証明書設定、サブスクリプション項目に問題があることを示します。検証を直接緩めると根本原因が隠れ、端末の移行やサブスクリプション更新時に再び失敗する可能性があります。まずシステム時刻を確認し、次にノードのサーバー名を照合し、最後にサーバーの該当ポートが想定どおりTLSを提供しているか確認するのが安全です。

実際の選択基準

既存のVMess設定が安定して動作し、複数の端末でクライアントが完全にインポートできているなら、名称が新しくなったという理由だけで直ちに作り直す必要はありません。新規構築でXrayエコシステムを使い、REALITYやVisionなどの組み合わせが必要なら、VLESSのほうが自然な選択になりやすいでしょう。V2FlyとXrayの間で幅広い互換性を保つ必要がある場合は、双方が理解できる基本項目を優先し、特定コア向けの拡張を汎用設定と誤解しないことが重要です。サブスクリプションを保守する側にとっては、「VLESSノード」と簡単に表示するより、プロトコル、トランスポート、セキュリティ層を明確に出力するほうが重要です。

v2rayNではノード編集画面から完全な組み合わせを確認できます。Androidでv2rayNGを使う場合も、ノード一覧の名称だけでなく、トランスポートとセキュリティの項目を展開して確認してください。v2flyNGは主にV2Flyコアを使用する方向けで、V2Flyが認識できる設定に適しています。3つのクライアントのインストール先と対応プラットフォームはダウンロードページで確認できます。

03 / TROJAN, SHADOWSOCKS & REALITY

Trojan・Shadowsocks・REALITYの役割分担

Trojanはプロトコルであり、正しいTLSパラメータが前提

Trojanはパスワード認証を使用し、TLS上に接続を構築します。クライアントのノードには通常、サーバーアドレス、ポート、パスワード、サーバー名、証明書検証に関する項目が必要です。多くの拡張項目を持つVLESSより設定画面はシンプルに見えますが、TLSパラメータは接続成立の中心です。サーバーアドレスにはドメイン名またはIPを指定できますが、サーバー名は通常TLSハンドシェイクでの名前照合に使われます。両者が同じ場合もあれば異なる場合もあります。サブスクリプション変換でアドレスだけが残りサーバー名が失われると、証明書名の不一致が起きる可能性があります。

Trojanは、成熟したTLS構成を使い、設定の意味を比較的直接的に保ちたい場合に適しています。性能はTLSハンドシェイク、接続の再利用、下位トランスポートの影響を受けるため、項目が少ないからといってすべてのオーバーヘッドが自動的に減るわけではありません。長時間接続では初回ハンドシェイクのコストが後続データに分散されますが、短時間の接続が多い場合はハンドシェイク回数が重要になります。クライアントログにTLS関連のエラーが出たら、ローカルのプロキシモードを何度も変えるのではなく、まず名前、時刻、サーバー設定を確認してください。

Shadowsocksのシンプルさは明確な暗号方式に由来する

Shadowsocksノードの主要項目は通常、サーバー、ポート、パスワード、暗号方式です。構造が比較的コンパクトで、多くのプラットフォームとコアに実装されているため、基本互換性と設定の簡潔さを重視する用途でよく使われます。ただし、暗号方式は両端が対応し、完全に一致していなければなりません。クライアントの選択肢にある方式をサーバーが使っているとは限らず、変換ツールによってサブスクリプション内の方式名が書き換えられると認証に失敗することもあります。

暗号方式によって、プロセッサへの要求と実装品質の影響は異なります。現代の端末は通常、共通鍵暗号を十分に処理できますが、省電力端末、古いプロセッサ、高い同時実行数では差が現れることがあります。評価では、1回だけウェブページを開くのではなく、継続的なスループット時のCPU使用率、温度、安定性を確認してください。サーバーまたはクライアントのログにunsupported methodが出た場合は、サブスクリプションの元の値に戻し、現在のコアに該当実装が含まれているか確認します。

Shadowsocksのシンプルさは、一部の高度な動作を外部層やクライアントのポリシーが担うことも意味します。分岐ルーティング、DNS、システムプロキシ、アプリの通信取り込みはプロトコル自体の機能ではありません。これらの設定の違いをShadowsocksノードの違いと考えてはいけません。同じノードが2つのクライアントで異なる動作をする場合、よくある原因はルーティングルール、DNS問い合わせ経路、システムへの取り込み方式の違いであり、ノードのプロトコルが変わったからではありません。

REALITYは5番目の独立したプロキシプロトコルではない

REALITYはVLESSと組み合わせて使われることが多いものの、担当するのはセキュリティハンドシェイクと接続先の確認であり、VLESSのプロキシリクエスト形式を置き換えるものではありません。このタイプのノードを新規作成する場合は、通常まずVLESSを選び、セキュリティ方式をREALITYに設定して、公鍵、短い識別子、サーバー名、フィンガープリント、flowなどを入力します。サブスクリプション画面で「REALITYノード」と略記されていても、理解上はVLESS、トランスポート、セキュリティ層、フロー制御の4つに分けて考えてください。

公鍵はクライアントがサーバーの身元を確認するために使われ、短い識別子はサーバー設定によって限定されます。サーバー名はハンドシェイクパラメータに関与し、クライアントフィンガープリントはハンドシェイクの特徴を表します。これらの項目は互いに自由に代用できません。通常のTLS証明書項目をREALITYにそのまま当てはめたり、ノードの表示名から公鍵や短い識別子を推測したりすることもできません。サーバー設定を変更した場合はサブスクリプションも更新し、複数端末を手動編集して一部に古い値を残さないようにしてください。

REALITY関連の拡張は、主にXrayコアの機能と結びついています。V2Flyコアを使うクライアントでは、「VLESSに対応している」ことだけから同じREALITY拡張にも対応しているとは判断できません。プロトコルの基本互換性と拡張機能の互換性は分けて確認する必要があります。異なるコアに同じサブスクリプションを提供する場合は、コアごとにグループを分けるか、少なくとも必要条件が分かるノード名を付け、インポート後に項目が無視される事態を避けてください。

3つの方式を選ぶときは、まず「この項目は接続スタックのどの役割を担うのか」を確認し、次にクライアントとコアがすべての項目に対応しているかを確認します。この順序のほうがノード名だけで判断するより確実です。インポート後にノードが欠ける、項目が空になる、更新に失敗するといった問題は、よくある質問とサブスクリプション更新失敗の対処法でまとめて確認できます。

04 / PERFORMANCE & POWER

接続速度、リソース使用量、モバイル端末のバッテリー消費

接続確立、最初のデータ、スループット、安定性を分けて考える

「速度」には少なくとも4つの異なる指標があります。接続確立時間は接続開始からプロトコルとセキュリティのハンドシェイク完了まで、最初のデータ到達時間はリクエスト送信後に有効なデータの最初の部分を受け取るまでの時間です。持続スループットは長時間転送時の実効速度を示し、安定性はネットワーク切り替え、アイドル、継続負荷の下で接続を維持できるかを見ます。接続確立時の処理が1つ少ないプロトコルでも、長時間転送で必ず高スループットになるとは限りません。逆に、スループットが近くても短時間接続の体感が同じとは限りません。

公衆網の経路、サーバー負荷、名前解決、TCP輻輳制御、アプリ自体のキャッシュは、プロトコル層の差より大きな影響を与えることがよくあります。意味のある比較を行うには、サーバー、出口、クライアント、ルーティングルール、テスト時刻を固定し、プロトコルの組み合わせだけを1項目変更します。複数回連続して測定し、1回だけの最速値ではなく中央値の傾向を記録するほうが、通常の状態を反映できます。テスト中はバックグラウンド同期とシステム更新も停止し、余分な通信が判断に影響しないようにします。

プロトコルとトランスポート方式がオーバーヘッドを共同で決める

VMessはプロトコル層で比較的多くの処理を担い、VLESSのプロトコル層は軽量です。TrojanはTLSに依存し、Shadowsocksの処理負荷は選択した暗号方式に左右されます。これらは計算コストの一部にすぎません。WebSocketでは追加のフレーミングとヘッダー処理が必要で、gRPCはHTTP/2の接続管理に依存します。TCPの直接接続では中間のカプセル化が減ります。バッファー、接続再利用、同時実行のスケジューリングに対する実装の違いも、実際のリソース使用量を変えます。

メモリ使用量は通常、接続数、DNSキャッシュ、ルーティングルールの規模、ログレベル、GUIクライアントの画面により大きく左右されます。アイドル状態の1ノードだけを比較しても、プロトコルのコストを代表するのは困難です。同じ数の接続を作り、同じ時間タスクを実行してから、コアプロセスが安定した範囲を観察するのが合理的です。ログを詳細レベルにするとディスク書き込みとテキスト整形の負荷も増えるため、調査が終わったら通常レベルに戻してください。

CPU使用率は端末のハードウェアと合わせて確認します。デスクトップ用プロセッサなら日常的な接続は通常容易に処理できますが、省電力端末では、高スループット、複雑な暗号化、大規模なルール、多数の同時接続で負荷が目立つことがあります。スループットに比例してCPU使用率が上がるなら、まず暗号方式とトランスポートの組み合わせを比較します。アイドル時も使用率が高い場合は、プロトコルを変える前に、再接続ループ、サブスクリプション更新タスク、異常なDNSリクエスト、ログのローテーションを確認してください。

モバイル端末の電池消費はウェイクアップと通信活動が主な要因

モバイル端末のバッテリー消費は暗号アルゴリズムだけで順位付けできません。常時接続、頻繁な再接続、無線LANとモバイル回線の切り替え、アプリのバックグラウンド復帰、DNS問い合わせ、多数の短時間接続が、無線モジュールとプロセッサを何度もアクティブ状態にします。計算量がやや少なくても頻繁に切断・再接続する組み合わせは、計算量がやや多くても安定した組み合わせより電力を消費することがあります。したがって、安定性、キープアライブ間隔、アプリの通信パターンはプロトコル自体と同じくらい重要です。

バッテリー消費を測定するときは、同じ端末、近い電波強度、同じアプリタスクを使い、前面での連続使用とバックグラウンド待機の両方を少なくとも含めます。システムのバッテリー統計は傾向を見るには適していますが、短時間の小さな変化を結論にするには不向きです。v2rayNGまたはv2flyNGがバックグラウンドで大きく電力を消費する場合は、まず継続的な再接続、過度に短い自動更新間隔、すべてのアプリ通信をプロキシへ送るルーティング、システムによる接続サービスの停止と再起動を確認してください。

メッセージ、ウェブ閲覧、軽量な同期が中心なら、ピークスループットより安定した接続と適切な分岐ルーティングが重要です。継続的なダウンロードや動画ストリーミングでは、サーバーの出口帯域と回線品質の比重が高くなります。開発ツールからのリクエストが多い場合は、接続再利用とDNSの挙動を観察する価値があります。まず用途を定義してこそ、プロトコル性能の比較が場面から切り離された数字競争になりません。

総合的に見ると、VLESSの簡素なプロトコル層は一部の処理削減に有利で、Shadowsocksの構造もコンパクトです。VMessは従来の互換性を重視し、Trojanの性能はTLS接続管理と密接に関係します。ただし、これらの傾向だけでトランスポート、実装、ネットワーク条件の影響を覆すことはできません。一般ユーザーは、プロトコル名だけで理論上の負荷を追うより、項目が揃い、接続が安定し、使用コアが明確なノードを優先するほうが効果的です。

05 / CORE FAMILY

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

共通の設定慣習があっても機能が完全に同じとは限らない

V2FlyとXrayはいずれもProject Vエコシステムの設定構成を受け継いでおり、inbounds、outbounds、routing、dns、logなどの一般的な構造を持ちます。基本的なVMess、VLESS、Shadowsocks、Trojan、ルーティング設定の概念は近いため、似たJSON階層やクライアント項目を目にすることが多くあります。構造が似ていることは移行に役立ちますが、すべての拡張がそのまま相互利用できることを意味しません。両方のコアはそれぞれ機能、項目、実装を保守しているため、対応範囲は対象コアごとに確認する必要があります。

GUIクライアントはコアの上位に位置します。v2rayNはノード管理、サブスクリプション、ルーティングテンプレート、システムプロキシ、コアの起動を担当し、デスクトップ版では通常、ユーザーの選択をコア設定へ変換します。v2rayNGはAndroidで同様の管理機能を提供し、主にXrayコアの機能に合わせて設計されています。v2flyNGはV2Flyコアを対象とします。クライアント画面に項目があることは、その項目を表現できることを示すだけで、実際に有効になるかは使用中のコアと項目の組み合わせで決まります。

Xrayの拡張とV2Fly共通項目は分けて考える

REALITY、特定のflow値、一部の拡張組み合わせはXrayの機能とより密接に関係します。これらの項目を含むサブスクリプションを、V2Flyを実行コアとするクライアントへインポートすると、認識されない、無視される、起動に失敗するといったことがあります。逆方向の移行でも、Xrayが受け入れられる設定が、双方に推奨される共通形式とは限りません。コアをまたいでサブスクリプションを構築する場合は、基本プロトコルのノードと特定コアを必要とするノードを明確に分けてください。

互換性は3つの層に分けて判断できます。第1層は構文で、JSONを解析できるか、項目の型が正しいかを確認します。第2層は構造で、項目が対象コアの認識する位置にあるかを確認します。第3層は意味で、そのプロトコル、トランスポート、セキュリティの組み合わせが実装されているかを確認します。形式チェックだけでは第1層しか確認できず、ノードが接続できる証明にはなりません。ログのunknown field、failed to build config、unsupported securityなどは、それぞれ構造または意味の問題を示します。

最小限のルーティング構造で設定の境界を理解する

次の例は汎用的なルーティング構造だけを示します。プライベートアドレスをdirectという名前のアウトバウンドへ送り、それ以外の通信は後続ルールとデフォルトのアウトバウンドで処理します。この断片自体にノードの認証情報は含まれておらず、routing、rule、outboundTagの対応関係を理解するために使えます。実際のクライアントは通常、より完全な設定を生成するため、手動で変更する前にバックアップをエクスポートしてください。

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

outboundTagは、設定内に実在するアウトバウンドのタグを指していなければなりません。クライアントのテンプレートで直接接続用アウトバウンドに別の名前が付いている場合、このルールだけをコピーすると存在しない参照になります。domainStrategyはルーティング段階でドメインとIPの照合を処理する方法を制御します。DNS設定とは関係しますが、システムやコアによる完全なDNS判断を置き換えるものではありません。GUIクライアントに既定のルーティングがある場合は、まずその効果を理解してからカスタムJSONを編集してください。

コアの移行では機能一覧を項目ごとに検証する

移行は実行ファイルを置き換えて起動できるか確認するだけではありません。まず現在のノードで使用しているプロトコル、トランスポート、セキュリティ方式、flow、ルーティングルール、DNSポリシー、ローカルインバウンドを一覧化し、対象コアで1項目ずつ照合します。その後、最も単純な項目構成のノードで基本接続を確認し、拡張ノードと分岐ルーティングをテストします。これにより、問題を基本動作、プロトコル拡張、ルーティング設定のいずれかに絞れます。

設定ファイルを異なるクライアント間で長期的に相互上書きするのも避けるべきです。v2rayN、v2rayNG、v2flyNGは、それぞれの画面モデルに基づいて設定を生成するため、追加項目、タグ名、既定のインバウンドが異なる場合があります。サブスクリプションリンクはノード情報の配布に、クライアントのバックアップは同種クライアントの設定復元に、完全なコアJSONは項目の意味を把握したうえでの利用に適しています。用途が異なるため、混用するとクライアントの生成層とコアの実行層が混乱します。

デスクトップでWindows、macOS、Linuxを使う場合、当サイトではv2rayNを第一候補としています。AndroidでXray設定を中心に使うならv2rayNG、V2Flyコアを使うならv2flyNGを選びます。インストーラーの種類とシステムアーキテクチャはクライアントダウンロードページにまとめています。本章ではコアと設定の互換性だけを扱います。

06 / SUBSCRIPTION COMPATIBILITY

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

サブスクリプションは設定の入れ物であり、新しいプロキシプロトコルではない

サブスクリプションリンクはノード情報をまとめて配布するもので、ノード内部のプロトコルはVMess、VLESS、Trojan、Shadowsocksなどのままです。一般的な形式には、base64でまとめた共有リンク一覧、クライアントが認識できるネイティブ設定、共有リンクを1件ずつ並べた形式があります。base64は単なるテキストエンコードであり、プロトコルの機能を増やしたり、欠落した項目を修復したりするものではありません。クライアントはサブスクリプションを取得した後、まず入れ物の形式を判別し、各ノードを解析してから現在のコア設定へ変換します。

共有リンクでは通常、URI schemeでプロトコルタイプを示し、認証、トランスポート、セキュリティ情報を本体とクエリパラメータで表します。基本項目はクライアント間で渡しやすい一方、拡張項目はリンク仕様とパーサーの実装に依存します。REALITYの公鍵、短い識別子、フィンガープリント、flow、gRPCのサービス名などは、サブスクリプション生成側が標準的でないパラメータ名を使うと受信側で無視される可能性があります。ノードが一覧に表示されるのは外側の解析が成功したことを示すだけで、すべてのクエリパラメータが設定に反映された証明ではありません。

ネイティブJSONと共有リンクは用途が異なる

ネイティブJSONは、インバウンド、アウトバウンド、DNS、ルーティング、ログを含む完全な設定を表現でき、単一コアのインスタンスを正確に制御するのに適しています。ただし、GUIクライアントのノードデータベースと完全に同じものではありません。完全なJSONをGUIクライアントへインポートすると、カスタム設定として実行するクライアントもあれば、アウトバウンドノードだけを抽出するクライアントもあります。画面の設定が元ファイルへ書き戻されない場合もあります。使用前に、インポート入口が「ノード」「サブスクリプション」「カスタム設定」のどれを示しているか確認してください。

共有リンクは単一ノードの受け渡しに適しており、QRコード、クリップボード、サブスクリプションへの集約にも便利です。一方、複雑なルーティングやDNSポリシーを単一ノードのリンクに詰め込むべきではありません。ノードはサブスクリプション、端末側のルーティングはクライアントが担当するほうが役割が明確です。複数端末で同じ分岐設定を維持する必要がある場合は、ノードのサブスクリプションとルーティングテンプレートを分け、各クライアントに合った形式を使ってください。

更新失敗と更新後に使えない問題は別物

更新失敗とは、クライアントがサブスクリプションを取得できない、または内容を解析できない状態です。リンクにアクセスできない、端末の時刻がずれている、返却内容が想定形式ではない、証明書エラー、ローカルネットワークの出口に問題がある、といった手がかりがあります。更新は成功したのにノードが使えない場合は、項目の完全性、コアの対応範囲、サーバーの状態を確認します。ログの場所も対処順も異なるため、まずサブスクリプション要求が成功したか、次に解析されたノード数、最後に単一ノードの接続を確認すると、すべてをリンクの問題と決めつけずに済みます。

自動更新間隔は短くしすぎないでください。頻繁な取得はバックグラウンド復帰を増やし、サーバー側で内容を一時的に生成している間にローカル一覧を何度も上書きする可能性もあります。ノードの変更頻度に合わせて周期を設定し、大規模な変更前にはクライアントのバックアップを残すのが適切です。グループ名、有効状態、並び順、ローカルメモはクライアント固有のデータである場合があり、更新時に保持されるかは実装次第です。重要な説明を上書きされやすいノード名だけに書かないようにしてください。

複数のサブスクリプションを管理する場合は、すべてのノードを1つの一覧に入れるより、提供元やコア要件ごとにグループを作るほうが問題を見つけやすくなります。基本互換ノード、Xray拡張ノード、V2Flyノードを分け、キーワードの包含・除外で一覧のノイズを減らせます。具体的なグループ分けはサブスクリプションのグループ分けとサーバーキーワードフィルターを、形式の違いはbase64・ネイティブJSON・共有リンクの違いをご覧ください。

サブスクリプションにv2rayNでは認識できても別のクライアントでは認識できない拡張が含まれる場合、元のサブスクリプションを完全な汎用形式として無理に使わないでください。対象クライアント向けに明確で項目が揃ったサブスクリプションを出力するか、双方が対応する基本構成を選ぶほうが保守負担は小さくなります。設定JSONにおけるinbounds、outbounds、routingの役割は設定ファイルの構造を項目ごとに解説で確認できます。

07 / CLIENT WORKFLOW

クライアントでプロトコルを選択し、項目を確認する

デスクトップではまずv2rayNで基準設定を作る

デスクトップ環境ではv2rayNを優先します。インストール後、まずサブスクリプションをインポートして1回更新し、すぐにノード項目を変更しないでください。提供元が明確なノードを1つ選び、編集画面でプロトコル、アドレス、ポート、ユーザー識別子、トランスポート方式、セキュリティ方式、サーバー名、flow、拡張パラメータを記録します。保存して接続した後、クライアントログで設定の生成、コアの起動、アウトバウンドの確立を確認します。この手順で基準設定を作り、以後の性能テストやプロトコル移行はこれと比較します。

ノードが接続できたら、システムプロキシとルーティングモードを設定します。システムプロキシは、その仕組みに対応するアプリがリクエストをクライアントへ渡すかどうかを決め、ルーティングモードはコアに入った通信をプロキシ、直接接続、ブロックのどれで処理するかを決めます。どちらもプロトコル項目ではありません。VMessをVLESSへ変更しても、無効なシステムプロキシが自動的に直るわけではなく、ルーティングルールを変更してもREALITYの公鍵は補われません。切り分けでは層を分けて考えることで、効果のない変更を減らせます。

v2rayNに複数のデスクトップ版がある場合は、ダウンロードページの説明に従って適切なUI版を選びますが、ノードとコアの選定原則は同じです。Windows、macOS、Linuxではシステムプロキシの入口や権限の挙動に違いがありますが、クライアント内部で生成されるアウトバウンド設定は同じレイヤー構造に従います。LAN共有を行う場合は、リッスンアドレス、ファイアウォール、ポートを別途設定してください。詳しくはLAN接続を許可する設定ガイドをご覧ください。

Androidではコアの方向性でクライアントを選ぶ

Xray拡張ノードを使う場合は、v2rayNGのほうが項目モデルに適しています。V2Flyコアを使う場合はv2flyNGを選べます。サブスクリプションをインポートしたら、まずノード詳細を開き、特にVLESSのセキュリティ方式、flow、サーバー名、公鍵、短い識別子を確認してください。モバイル画面は表示領域が限られ、一部の項目が詳細設定やトランスポート設定内に隠れていることがあります。一覧に表示されないからといって、項目が存在しないと判断しないでください。

接続を確立すると、システムにローカル接続サービスの状態が表示されます。アプリに通信がない場合は、まずそのアプリが現在のアプリ別ルールに含まれているか確認し、次にルーティングとDNSを確認します。接続サービスが繰り返し終了する場合は、クライアントログの設定解析やコア起動に関する情報を確認してください。ネットワーク切り替え後だけ失敗するなら、手動で切断して再接続し、回線切り替え、システムのバックグラウンド制限、ノードのハンドシェイクのどれが原因か比較します。プロトコル移行中は一度に1項目だけ変更してください。

手動ノードは検証向けであり、長期サブスクリプションの代わりにはならない

手動でノードを作成する方法は、特定のパラメータ一式が使えるか確認するのに適しています。作成時はプロトコルから始め、サーバー、ポート、認証情報、トランスポート、セキュリティ層の順に入力し、保存後すぐ編集画面へ戻って確認します。クライアントによっては空欄にデフォルト値を入れるため、サーバーの要求と異なる値がないか確認できます。テストに成功しても、ノードがサブスクリプションで管理されているなら、各端末に手動コピーを残し続けるのではなく、サブスクリプションの出力を修正してください。

サブスクリプションのノードをローカルで変更すると、次回更新で変更が上書きされたり、重複ノードが作られたりすることがあります。一時的な調査では、ノードをローカルグループへコピーして複製側を変更し、元のノードを残すことができます。問題を確認したら、正しい項目をサブスクリプション元またはサーバー設定へ反映し、一時的な複製を削除します。これにより、元の設定、診断用設定、最終設定を区別でき、数週間後にどれが標準なのか分からなくなる事態を防げます。

ログは段階ごとに読む

設定解析段階では項目の型、未知の項目、アウトバウンド構築エラーを確認します。コア起動段階ではポートの競合、権限、ローカルリッスンを確認します。接続段階では名前解決、TCP接続、セキュリティハンドシェイク、認証を確認します。ルーティング段階では、リクエストが最終的にどのアウトバウンドタグへ一致したかを確認します。ログの最後の行が根本原因とは限らないため、同じ接続試行の開始点から順に読み進めてください。診断が終わったら通常のログレベルに戻し、不要な情報を長期間記録しないようにします。

初回設定はV2Ray使用ガイドに従って、サブスクリプションのインポート、ノード接続、確認を行えます。本ページのチェックリストは、ノードに接続できない場合、クライアント間で移行する場合、プロトコル変更を検討する場合に適しています。エラーの分類が難しいときは、よくある質問ページでインストール・設定とトラブルシューティングの分類から探してください。

08 / SCENARIO GUIDE

利用シーンに応じて選定を決める

既存設定が安定している場合：維持しつつ代替ノードを作る

既存のVMess、Trojan、Shadowsocksノードが長期間安定しているなら、現状を維持しながら新しい組み合わせを独立してテストするのが最も安全です。新しいノードには別の名称とグループを設定し、サブスクリプション更新時に旧ノードと混同しないようにします。テストでは、ウェブの短時間接続、継続転送、端末の待機復帰、ネットワーク切り替えを確認し、1回接続できたことだけで判断しないでください。一定期間比較した後、新しいノードを既定にするか決めます。

この方法は、VMessからVLESSへ移行する場合や、通常のTLS構成からREALITY構成へ移行する場合に特に適しています。移行にはサーバー、サブスクリプション、クライアントの3か所が関わるため、段階的に切り替えることで復旧経路を残せます。複数端末で異なるクライアントを使う場合は、まず項目を最も詳しく表示できるクライアントで検証し、その後ほかのクライアントでサブスクリプション解析をテストします。いずれかに拡張項目が欠けている場合は、本番切り替え前に対処してください。

Xray設定を新規作成する場合：組み合わせ全体の対応を優先する

新規設定で両端がXrayの機能を使える場合、VLESSをプロトコル層の候補とし、サーバー設計に応じてTLSまたはREALITYを選び、特定のflowが必要か確認します。判断基準は流行ではなく、サーバー側で正しく保守できるか、サブスクリプションが完全に出力できるか、クライアントが安定して解析できるかです。デスクトップでv2rayN、Androidでv2rayNGを使う場合は項目モデルを揃えやすいものの、1項目ずつ確認する必要があります。

同じサブスクリプションをV2Flyコアで動作するクライアントにも提供する必要がある場合は、基本互換ノードを用意するか、コア固有ノードを明確なグループに分けます。「VLESSの基本プロトコルを認識できる」ことを「すべてのVLESS拡張組み合わせを実行できる」ことと混同しないでください。コア間の互換性では、未知の項目をクライアントが無視することに頼るのではなく、共通して使える項目の集合を絞り込むことが重要です。

省電力・モバイル用途：安定した接続を優先する

モバイル端末では、再接続が少なく、項目が明確で、サブスクリプション更新が安定しているノードを優先します。VLESSとShadowsocksはプロトコル構造が軽量ですが、最終的なバッテリー消費はセキュリティハンドシェイク、電波、分岐ルーティング、アプリの通信にも左右されます。テストでは、バックグラウンド待機後に復帰できるか、ネットワーク切り替え後に再接続を繰り返さないか、システムのバッテリー統計で接続サービスが長時間アクティブになっていないかを確認します。問題がバックグラウンド制限や電波変化に由来するなら、プロトコル変更だけでは直接解決しません。

自動更新の頻度、ログレベル、グローバルプロキシの範囲もバッテリー消費に影響します。ノードの変更が少ない場合は頻繁に更新する必要はありません。調査が終わったら詳細ログを無効にし、必要な通信だけをプロキシへ送ることで不要な接続活動を減らせます。v2rayNGとv2flyNGの選択は、まずノードが必要とするコアで決め、その後に画面の好みを比較します。

複数クライアント・チーム設定：説明可能な最小構成を選ぶ

複数端末、異なるデスクトップOS、Androidクライアントへ設定を配布する場合は、項目の定義が明確で、対象となるすべてのコアが対応を確認できる組み合わせを優先します。サブスクリプションのグループ名にプロトコル、必要なコア、用途を記載すると、「高速」「予備」のような曖昧な名称より保守しやすくなります。ルーティングとDNSポリシーは各プラットフォームのクライアントテンプレートで管理し、ノードのサブスクリプションはアウトバウンド情報だけを渡すと、プラットフォーム間の変換が簡単になります。

設定ドキュメントにはプロトコル、トランスポート、セキュリティ層、コア要件、重要な拡張項目を記録しますが、完全な認証情報を複製する必要はありません。変更時にはどの項目が変わったかを記録し、検証が終わるまで旧ノードを残します。これにより、クライアントが解析方式を変更しても、構造から差分を特定でき、ノードの意味を推測し直す必要がありません。

問題が起きたら判断ツリーに沿って切り分ける

第1段階では、サブスクリプションが内容を正常に取得できたかを確認します。失敗したらリンク、端末の時刻、返却形式を確認します。第2段階では、ノードの項目が揃っているかを確認します。欠落していれば、サブスクリプションの生成と変換を確認します。第3段階では、コアが設定を構築できるかを確認します。失敗したら未知の項目、型、未対応の組み合わせに対処します。第4段階では、セキュリティハンドシェイクが完了したかを確認します。失敗したらサーバー名、公鍵、短い識別子、パスワード、端末の時刻を照合します。第5段階では、リクエストが正しくルーティングされたかを確認します。接続は成功しているのにアプリが使えない場合は、システムプロキシ、アプリ別ルール、DNS、アウトバウンドタグを確認してください。

各段階では関連する層の設定を1項目だけ変更し、ログと元の設定を比較できるように残します。プロトコル、トランスポート、セキュリティ層、ルーティングを同時に何度も変更すると、接続できても再現が難しくなります。サブスクリプション更新後に問題が起きた場合は、まず旧ノードを複製して比較します。コア変更後に起きた場合は、最も基本的なノードでコアの動作を確認します。特定のプラットフォームだけで起きる場合は、クライアントが生成した項目とシステムへの取り込み方式を比較し、すぐにサーバー異常と判断しないでください。

選定が終わったら、v2rayN・v2rayNG・v2flyNGのダウンロードページから対応するプラットフォームのインストーラーを選び、設定ガイドに従って接続を構築してください。サブスクリプション、コア起動、システムプロキシ、ルーティングで問題が起きた場合は、本章の判断ツリーとトラブルシューティング分類を使って層ごとに切り分けるほうが、ノードタイプを何度も変更するより効果的です。