V2Rayのプロトコルとコア技術ガイド

1. プロトコル・通信方式・セキュリティ・クライアントを区別する

接続に必要な設定項目

v2rayNの「サーバーを追加」画面では、プロトコルの種類は設定の入口にすぎません。接続を確立するには、サーバーアドレス、ポート、ユーザー情報、通信方式、通信のセキュリティ設定も必要です。たとえばVLESSを選んだ場合、アドレスには your-server.example、ポートにはサーバー設定の値を入力します。ユーザー情報には通常UUIDを使い、通信方式にはtcp、ws、grpc、通信のセキュリティにはtlsやrealityを指定します。それぞれの項目には異なる役割があり、プロトコルが同じだからといってサーバー設定一式を使い回せるわけではありません。アドレスとポートは接続先を、ユーザー情報は相互認証の可否を、通信方式とセキュリティ設定は接続の確立方法を決めます。

ここでいう「プロキシプロトコル」とは、主にクライアントとサーバーの間でリクエストをどのように扱い、ユーザーを識別し、接続先アドレスを伝えるかを定めるものです。VMess、VLESS、Trojan、Shadowsocksがこの層にあたります。「通信方式」はデータの運び方を指します。tcpはストリーム接続を直接使い、WebSocketは独自のハンドシェイクとメッセージ形式を加え、gRPCはHTTP/2のストリームを利用します。どの方式を使うかはサーバーが実際に受け付ける設定で決まり、クライアント側で自由に切り替えるものではありません。アドレスとユーザー情報が正しくても、パス、サービス名、通信方式のいずれかが一致しなければ、ハンドシェイクの段階で接続が終了することがあります。

REALITYはプロトコルの種類として指定しない

tlsとrealityは通信のセキュリティに関する設定であり、REALITYはVLESSと並ぶ独立したプロキシプロトコルではありません。たとえば「VLESS、tcp、reality」という設定は、VLESSでプロキシデータを扱い、TCP通信上でサーバーの指定に従ってREALITY接続を確立することを意味します。設定を確認するときは、まずプロトコル、次に通信方式、最後にセキュリティの項目を確認してください。共有された設定に「REALITYノード」とだけ書かれていてプロトコルが不明な場合は、元のリンクや提供元の説明を確認します。表示名だけを頼りにサーバー設定を作ることはできません。

「コア」とは、これらの設定を読み込んで実行するプログラムです。v2rayNはWindows、macOS、Linux向けのデスクトップ用GUIクライアント、v2rayNGとv2flyNGはAndroid向けのGUIクライアントです。画面上ではサーバー設定、サブスクリプション、システム設定などを管理できますが、実際に利用できる項目は搭載されたコアとそのバージョンにも左右されます。設定を画面に保存できても、コアがその設定で起動できるとは限りません。項目が認識されない場合は、サーバーアドレスだけでなく、クライアント、使用中のコア、サーバーが必要とする機能をあわせて確認してください。

プロトコルを推測せず、項目ごとに確認する

サーバーの設定情報を受け取ったら、プロトコル、アドレス、ポート、ユーザー情報、通信方式、セキュリティの種類、通信方式固有のパラメーターを順に整理します。WebSocketではHostとパス、gRPCではserviceName、TLSではサーバー名の確認が必要になることがあります。REALITYでは公開鍵やショートIDなど、サーバーから指定されたハンドシェイク用パラメーターも確認してください。情報が不足している場合は、設定の提供元から元の情報を入手します。「このプロトコルは通常このポートを使う」といった決めつけは禁物です。ポートはサーバー側の設定であり、プロトコル名からは特定できません。

このページでは、クライアントの項目とサーバー設定の対応を説明します。不明なサーバー設定の変更を勧めるものではありません。サブスクリプションを追加すると、GUI上では複雑な項目が編集画面に折りたたまれていることがあります。確認が必要な場合は、一覧の表示名だけで判断せず、設定の詳細を開いてください。表示名はサブスクリプションの提供元が自由に付けられるため、プロトコルの判定材料にも、通信のセキュリティ設定が一致している証拠にもなりません。項目を階層ごとに確認すると、設定を何度も切り替えるより問題を特定しやすくなります。

2. VMessとVLESS：異なる設定項目の考え方

VMessの設計背景と実際の設定

VMessは、Project Vのエコシステムで早くから広く使われてきたプロキシプロトコルです。プロトコル層でユーザーを認証し、データをカプセル化するため、独自の接続形式を備えています。GUIクライアントでは通常、アドレス、ポート、ユーザーID、サーバー設定に応じたセキュリティや暗号化の項目を入力します。過去のチュートリアルにある項目名が、現在の画面と一致するとは限りません。古い設定形式の項目もあれば、通信方式やTLSの設定に移った項目もあります。入力時は現在のサーバー設定とクライアント上の各項目の意味を確認し、古い説明を再現するためだけに、提供されていない値を追加しないでください。

VMessは複数の通信方式と組み合わせられます。「VMess」と「WebSocket」は同じ意味ではなく、VMessだからといってTLSが必ず有効になるわけでもありません。接続に失敗した場合は、プロトコルのユーザー情報が一致していないのか、通信のハンドシェイクが失敗しているのかを切り分けます。サーバーがwsのパスを指定しているのに、クライアントをtcpに設定すれば、ユーザーIDが正しくても接続できません。サーバーがTLSを要求する場合は、入力したサーバー名や関連するセキュリティ設定も確認します。プロトコルを変更するには通常、サーバー側にも対応する設定が必要です。クライアントのVMessをVLESSに切り替えるだけでは変更できません。

VLESSでセキュリティ設定を別の層に分ける理由

VLESSはユーザーIDで接続を識別する方式を引き継ぎつつ、プロトコル層を簡潔にし、通常はプロトコル自体でデータ暗号化を重ねて行いません。通信を保護するには、サーバー設定に合わせてTLSやREALITYなどを使用します。このように層を分けることで、プロトコルと通信のセキュリティを別々に扱いやすくなり、VLESSを複数の通信方式と組み合わせられます。一方で、セキュリティの層を明示的に確認する必要があります。「VLESS」と書かれているだけでは、特定のセキュリティ設定が有効だとは判断できません。サーバーから指定された公開鍵やサーバー名の確認も省略できません。

VLESSではUUIDをユーザー情報として使うのが一般的です。設定によってはflowも指定されます。flowは特定の動作方式に関する指定であり、自由に設定できる性能向上用のスイッチではありません。サーバーが同じflowを明示し、クライアントのコアもその組み合わせをサポートしている場合にのみ設定してください。空欄にするか値を入力するかで、接続先のサーバー設定が異なることがあります。リンクを読み込んだ後にflowが欠落している場合は、すべての設定に値を追加するのではなく、まずサブスクリプションの出力形式と解析結果を確認してください。手入力では、汎用のスクリーンショットをまねるより、元のパラメーターと編集画面を項目ごとに照合するほうが確実です。

VMessとVLESSの選び方

すでにVMessのサーバーを安定して利用しており、サブスクリプションにユーザー情報、通信方式、セキュリティ設定がすべて含まれているなら、新しい名称に変えるためだけにプロトコルを変更する必要はありません。新しく設定する場合は、サーバーが実際に提供する種類と、必要な通信のセキュリティ設定を対象のコアがサポートしているかを確認してください。VLESSはプロトコル層が比較的簡潔ですが、接続全体の負荷にはTCPやTLSのハンドシェイク、選択した通信方式、アプリの通信も含まれます。「プロトコル層が軽い」ことを、あらゆるネットワーク環境で速いという意味に捉えることはできません。細かなカプセル化方式の差より、設定の一致と接続の安定性が重要です。

既存サーバーを移行するときは、比較用に元の設定を残し、新しい設定を追加して項目をそれぞれ確認することをおすすめします。同じアドレスとポートを使っていても、認証方式が同じとは限りません。テストでは同じ端末、同じネットワーク、同じアプリを使い、接続が確立するかを確認してください。プロトコル、通信方式、システムプロキシを同時に変更すると、どの変更が影響したのか分からなくなります。クライアント画面での具体的な追加手順は、入門ガイドをご覧ください。

3. TrojanとShadowsocks：パスワード項目の違い

TrojanとTLSの関係

Trojanはパスワードでユーザーを認証し、一般的な構成ではTLS接続を使用します。クライアントでは通常、アドレス、ポート、パスワード、サーバー名を設定します。証明書の検証はサーバー設定やドメインに合わせる必要があります。VMessやVLESSのUUIDとは異なり、GUI上で近い場所に表示されても、それぞれの意味は異なります。Trojanの共有リンクを受け取った場合は、サーバー名がリンクに正しく含まれているか確認してください。アドレスはドメイン名の場合も数字のアドレスの場合もありますが、TLSのハンドシェイクにはサーバーが想定する名前が必要です。接続先アドレスだけから、すべてのハンドシェイク用パラメーターを判断することはできません。

Trojanは追加の通信設定と組み合わせることもありますが、対応状況はコアとサーバーによって異なります。速度を比較するとき、プロキシプロトコルのカプセル化によるデータ量だけに注目するのは適切ではありません。TLS接続の確立、ネットワークの往復時間、接続の再利用方法も最初のリクエストに影響します。接続後の継続的な通信は、ネットワーク品質、サーバー負荷、アプリのデータ量にも左右されます。設定済みの項目では、まずパスワード、サーバー名、TLS設定が一致していることを確認し、アプリの通信がクライアントのローカルプロキシを経由しているかを確認するのが有効です。

Shadowsocksのmethod項目

ShadowsocksはSSとも呼ばれ、パスワードと暗号化方式が重要な設定項目です。比較的早くから普及しており、クライアント画面では通常、サーバーアドレス、ポート、パスワード、methodを入力します。暗号化方式には互換性の制約があります。サーバーとクライアントで同じ方式を選ぶ必要があり、パスワードだけを一致させても接続できません。方式によってはクライアントとサーバーの実装にも条件があります。そのため、「Shadowsocksに対応」とあっても、すべての方式が使えるとは限りません。サブスクリプションを追加したのに接続できない場合は、ルーティング規則を変更する前に編集画面を開き、methodが正しく読み込まれているか確認してください。

ShadowsocksとTrojanは、どちらも画面上で「パスワード」と表示されることがありますが、パスワード項目だけではプロトコルを判別できません。接続の仕組みとサーバー側の実装は異なるため、SSの設定をTrojanの編集画面に貼り付けても同等の設定にはなりません。Shadowsocksのプラグインや追加の通信層も、プロトコル本体の一部とは限りません。method、プラグイン設定、サーバー名を含む情報を受け取った場合は、元の形式を確認してから、サーバーの種類に応じて各項目を設定してください。プラグインの設定を通信のセキュリティ項目に誤って入力しないよう注意しましょう。

サーバー側の設定に合わせて選ぶ

既存サーバーがTrojanなら、クライアントでもTrojanを選び、対応するTLS設定を維持します。サーバーがShadowsocksなら、Shadowsocksを選んで暗号化方式を確認してください。自分でサーバーを管理する場合は、対象のクライアントとコアが選んだ方式をサポートしているかを確認したうえで、サーバー設定とサブスクリプションの出力形式を決めます。SSは設定項目が少なく手入力しやすい一方、間違いやすい箇所がパスワードだけとは限りません。method、ポート、プラグイン設定も正確に合わせる必要があります。Trojanは設定がシンプルに見えますが、TLSのサーバー名と証明書の検証を省略してはいけません。

両者を比較するときは、管理のしやすさも考慮してください。複数人で設定を共有するなら、「アドレス＋パスワード」だけを送るより、プロトコルの種類、method、TLSのサーバー名を明記したほうが入力ミスを防げます。サブスクリプションの提供元が設定を更新したら、編集画面を開いて重要な項目が想定どおり変更されているか確認してください。用途別にサブスクリプションを分け、ノードを絞り込みたい場合は、サブスクリプションのグループ分けとノードの絞り込みを参照してください。一覧を整理するためにプロトコル名を変更するのは避けましょう。

4. REALITY：プロトコルと並んで表示されるセキュリティ設定

よくある組み合わせの見方

REALITYはXrayエコシステムの通信セキュリティ機能で、VLESSの設定でよく使われます。提供元が設定を「VLESS・REALITY」と呼ぶ場合、これはプロキシプロトコルがVLESS、セキュリティの種類がrealityという2つの項目を示しています。通信方式も別途確認が必要で、tcpがよくある例です。クライアントにVLESSの設定項目があっても、対応するセキュリティ設定がない場合や、選択したコアがREALITYのパラメーターを認識しない場合は、アドレスとUUIDだけでは接続できません。新しいセキュリティ項目を見つけたら、まずコアが対応しているかを確認し、次にクライアントの編集画面に正しく表示されるかを確認してください。

REALITYの設定では通常、サーバーが指定するサーバー名、公開鍵、ショートIDなどを入力します。組み合わせによってはflowやその他のハンドシェイク用パラメーターも必要です。これらの値がドメイン名から自動生成されることはありません。公開鍵はサーバー設定に対応する公開パラメーターであり、別のサーバーの値を流用できません。ショートIDもサーバー指定の内容に従ってください。空欄にも特定の意味がある場合があります。GUIでは「通信のセキュリティ」の展開欄に項目が隠れていることがあります。インポート後は実際に画面を開き、空欄や解析されなかった項目がないか確認してください。

セキュリティ層とプロキシ層の問題を分けて考える

REALITYのハンドシェイク用パラメーターが一致していないと、プロキシプロトコルによる認証の前に接続が終了することがあります。この場合、VLESSのUUIDを何度も変更しても解決しません。次の順に確認してください。サーバーアドレスとポートが正しいか、通信方式がサーバーと一致しているか、セキュリティの種類にrealityを選んでいるか、サーバー名・公開鍵・ショートIDがそれぞれ一致しているかを確認し、最後にUUIDとflowを確認します。この順番で調べると、接続先の誤り、ハンドシェイクの失敗、ユーザー情報の誤りを切り分けやすくなります。具体的なエラー内容は、使用中のコアのログで確認してください。

コアのログは一覧の接続状態よりも、問題が起きた箇所を把握する手がかりになります。ただし、ひとつのエラーが複数の項目に起因することもあります。たとえば「ハンドシェイク失敗」が、必ずしも公開鍵の誤りを意味するわけではありません。ネットワークの切断やサーバー設定の変更でも、似た症状が起きることがあります。調査中に変更した項目を記録し、変更のたびに再接続してください。複数の設定をサブスクリプションから読み込んでいる場合は、元のパラメーターがすべて揃っている設定をひとつ比較用に選びます。サブスクリプションの変換で項目が欠落したことを、サーバーの停止と誤認しないためです。

利用条件と互換性の確認

REALITYをすべてのプロトコルで使える汎用のチェック項目と考えてはいけません。サーバーがREALITYを使用し、クライアントのコアがその組み合わせに対応している場合にのみ選択してください。既存のTLS設定をrealityに変更しても、自動的に移行するわけではありません。必要なパラメーターは異なります。通常のTLSとREALITYの設定が同じサブスクリプションに混在している場合は、個々の設定で元のセキュリティの種類を維持し、一括変更は避けてください。v2rayNでは選択中のコアが設定を実行します。Androidでもv2rayNGまたはv2flyNGのコアと、実際の対応範囲を確認する必要があります。

手入力する前に、元のリンクに含まれるプロトコル、通信方式、セキュリティの項目を簡単なリストにまとめ、入力後にひとつずつ確認してください。クライアントに「保存済み」と表示されても、入力を受け付けたことを示すだけで、サーバーがその組み合わせを処理できる保証にはなりません。コアの起動時に設定エラーが出る場合は、コアと各項目の対応状況を確認します。コアが正常に起動して接続に失敗する場合は、サーバーの設定とネットワーク経路を確認してください。起動時のエラーについては、Xrayコアの起動失敗とログの確認方法もご覧ください。

5. V2Fly、Xray、GUIクライアントの役割

同じエコシステムに属する異なるコア

Project Vのエコシステムでは、プロトコル、設定形式、クライアントツールがともに発展してきました。V2FlyはV2Rayプロジェクトのコア開発を引き継いでいます。一方、Xrayは独自に開発が進むコアの系列で、一部のプロトコル拡張、通信方式、セキュリティ機能に独自の実装があります。両者には共通の歴史的基盤と似た設定概念がありますが、名前だけが異なり機能が完全に同じプログラムではありません。「VLESSに対応」とあっても、すべてのflow、セキュリティの種類、拡張項目が使えるとは限りません。互換性は具体的な項目の組み合わせで判断し、特に新しいセキュリティ機能や通信方式を確認してください。

GUIクライアントは、サーバー設定、サブスクリプション、ルーティング設定を、コアが使える形式にまとめます。v2rayNはWindows、macOS、Linux向けで、サーバー設定の編集、サブスクリプション管理、ルーティング、システムプロキシの設定をデスクトップ上で行えます。v2rayNGはXrayコアを使うAndroidクライアント、v2flyNGはV2Flyコアを使うAndroid向けの選択肢です。Androidでクライアントを選ぶ際、サーバー設定にXray固有の機能が必要なら、v2rayNGがその機能に対応しているかを確認してください。既存の設定がV2Flyエコシステムに依存している場合は、v2flyNGで利用できるかを確認します。クライアント名はプロトコル名ではなく、サーバー設定の代わりにはなりません。

設定の互換性を3つの観点で確認

1つ目は概念の互換性です。どちらのコアも「アウトバウンド」「ルーティング規則」「ユーザーID」などの概念を理解できる場合があります。2つ目は構文の互換性です。同じ概念でも、設定ファイル上の項目名、値、既定の動作が異なることがあります。3つ目は機能の互換性です。プロトコルを解析できるコアでも、関連する拡張機能すべてを実装しているとは限りません。GUIクライアントはさらに、インポート時の解析や設定の変換も行います。そのため、コア本来のJSON設定、共有リンク、サブスクリプションのテキストを、完全に同じ内容を包む3種類の形式と見なすことはできません。

ある端末では使えるサーバー設定が別の端末では使えない場合、表示名だけでなく両方の編集画面を比較してください。プロトコル、通信方式、セキュリティの種類、flow、サーバー名、ユーザー情報が一致するかを確認し、Androidクライアントのコアがそれらの値に対応しているかも調べます。インポート時に無視された項目があっても、画面上には設定が表示されることがあります。コアの起動時に初めてエラーになる項目もあります。「インポート成功」「コアの起動成功」「アプリのリクエスト成功」の3段階を分けると、問題の範囲を大幅に絞り込めます。

ルーティングの例はコアの設定であり、サブスクリプションリンクではない

以下は、ドメイン名に一致するリクエストを direct というアウトバウンドに渡すルーティング規則の例です。これはJSONオブジェクトの一部で、同じ名前のアウトバウンドを含む完全なコア設定に追加した場合にのみ機能します。クライアントのサブスクリプションアドレス欄に貼り付けるものではありません。ドメイン名は各項目の位置を示すための例です。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

domainStrategyはルーティング判定でドメインをどのように扱うかを指定します。typeは規則の種類を、outboundTagは完全な設定内に存在するアウトバウンドを指定します。ルーティングで決まるのはリクエストを渡すアウトバウンドであり、そのアウトバウンドが使うサーバープロトコルではありません。ドメインと名前解決の結果を組み合わせた規則を設定する場合は、DNSとルーティングの関係を別途確認してください。詳しくはV2RayのDNS分岐と名前解決の設定をご覧ください。ルーティングを変更する前に基本の接続を確立し、名前解決の問題とプロトコルの問題が混ざらないようにしましょう。

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

初回接続と継続的な通信は別に考える

「速度」には少なくとも、接続の確立時間、最初のリクエストへの応答時間、継続的な通信のスループットがあります。プロトコルのカプセル化や認証は処理負荷に影響しますが、初回の接続時間にはDNS名前解決、TCP接続、TLSなどのセキュリティハンドシェイク、通信方式のハンドシェイク、ネットワークの往復時間も影響します。WebSocketやgRPCなどの通信方式はそれぞれ処理手順を増やしますが、採用するかどうかは既存のサーバー構成やアプリの要件によって決まります。確立済みの接続で大容量のファイルを転送する場合は、回線速度、輻輳、サーバー負荷、端末の性能が主な制限要因になることもあります。VMess、VLESS、Trojanの名前だけで絶対的な速度順位を決める根拠はありません。

設定を比較するときは、ネットワーク、時間帯、サーバーのリソース、セキュリティの層、通信方式などの条件を揃え、接続直後か確立済みかも区別してください。別のサーバーで動作するVLESS＋tcpとTrojan＋TLSを比較すると、サーバーやネットワークの違いも含まれるため、結果をプロトコルの差だけに帰属できません。クライアント画面の接続状態で分かるのは、各段階が完了したかどうかです。実際にアプリからリクエストを送った結果を確認し、そのアプリが想定した経路を使っているかを判断してください。デスクトップでは、システムプロキシが有効か、アプリがシステムプロキシを利用するかも確認します。

CPUとメモリの消費は処理全体に左右される

コアは接続を処理する際、暗号化と復号、プロトコルのカプセル化、ルーティング判定、DNS処理、ログ記録を行います。短時間の接続を大量に繰り返す場合はハンドシェイクやDNSの負荷が目立ち、継続的に大量のデータを送受信する場合は暗号化やデータのコピーが負荷の大部分を占めることがあります。複雑なルーティング規則、詳細なログ設定、同時接続数もリソース消費に影響します。VLESSのプロトコル層が比較的簡潔でも、設定全体で常にCPU使用量が少なくなるとは限りません。セキュリティの種類や通信方式を同時に変更すれば、処理経路全体が変わります。リソース消費を調べるときは、クライアントが起動しているかどうかだけでなく、実行中のアプリと通信の種類を記録してください。

Androidでのバッテリー消費を確認する

Androidでv2rayNGやv2flyNGを使用する場合、システムのネットワークインターフェース、バックグラウンドでの接続維持、Wi-Fiの状態、頻繁なスリープ解除などがバッテリー消費に影響します。プロトコルも要因のひとつにすぎません。動画再生や同期を続けるとネットワークとプロセッサーが動作し続けます。アプリが短時間の接続を何度も確立すると、スリープ解除やハンドシェイクが増えることがあります。モバイル回線の電波が不安定な場合も、無線モジュールの消費電力が増加します。特定のプロトコルが必ず最も省電力だとは言えません。比較する際は、端末を同じネットワーク環境に置き、似たアプリの負荷で使い、システムのバッテリー使用状況に表示される実際の稼働時間を確認してください。

待機中のバッテリー消費が多い場合は、クライアントが継続的に通信を処理しているのか、システムが何度も再接続しているのかを切り分けます。サブスクリプションの自動更新間隔が短すぎないか、バックグラウンドのアプリが通信を続けていないかを確認し、ネットワークの切り替え時に接続が繰り返し確立されていないかも観察してください。消費を抑えるには、不要なバックグラウンド処理を減らし、システムのバックグラウンド実行設定を確認して、サーバー設定とクライアントのコアを一致させることから始めます。こうした条件を変えずにプロトコルだけを変更しても、原因を切り分けられないことがあります。短時間のテストだけで一日のバッテリー消費を判断しないでください。

7. サブスクリプションと共有リンク：インポートできても項目が揃っているとは限らない

よく使われる3種類の入力形式

クライアントで読み込めるデータには、単一の共有リンク、複数のリンクをまとめたサブスクリプションのテキスト、サービス提供元が定めた構造化形式などがあります。単一のリンクは通常、プロトコルを示す文字列で始まり、サーバーの設定項目を含みます。一方、サブスクリプションアドレスは設定を取得する場所を示すもので、個別のサーバーそのものではありません。特定のクライアント向けの設定ファイルを配布している場合もあります。URLを開けるからといって、v2rayN、v2rayNG、v2flyNGがすべて同じ方法で解析できるとは限りません。インポートする前に提供元が示す形式を確認し、クライアントで対応する追加方法を選んでください。

互換性は少なくとも2つの観点で確認します。ひとつはクライアントがサブスクリプションの形式を認識できるか、もうひとつは解析時に各サーバーに必要な項目がすべて保持されるかです。一覧に設定が表示されても、解析器が表示可能な情報の一部を読み取っただけかもしれません。VLESS＋REALITYでは、UUID、通信方式、セキュリティの種類、公開鍵、ショートID、サーバー名、必要に応じてflowを確認します。Shadowsocksではmethod、パスワード、プラグイン設定、TrojanではパスワードとTLSのサーバー名を確認してください。一括インポート後に異なるプロトコルの設定をいくつか抽出して確認すると、一覧の先頭だけを試すより形式変換による欠落を見つけやすくなります。

更新、グループ分け、手動変更の関係

サブスクリプショングループを使うと、配信元を整理し、更新間隔や絞り込み条件を設定できます。更新時には通常、リモートの内容を再取得するため、設定の表示名やパラメーターが変わることがあります。サブスクリプションから取り込んだ設定を手動で修正した場合、次回の更新後も変更が残るかどうかはクライアントの動作によって異なります。より確実なのは、サブスクリプションの配信元を修正するか、長期的に独立して管理する設定をサブスクリプション由来の設定と分ける方法です。絞り込み用のキーワードは一覧の整理に使うもので、プロトコルの設定を直す手段ではありません。

サブスクリプションアドレスを追加しても一覧が空の場合は、ブラウザーで説明ページを開けるだけでなく、対象のクライアントが読み込めるデータが返されているかを確認してください。次に、グループの絞り込み条件ですべての設定が除外されていないか、単一の共有リンクをサブスクリプションアドレスとして扱っていないか、別形式のデータだけが含まれていないかを確認します。サーバーアドレスを推測して設定を作らないでください。元の形式に重要な項目がなければ、表示名から復元することはできません。複数の配信元を使う場合は、どこから追加した設定か追跡できるよう、グループに分かりやすい名前を付けてください。

クライアントを移行するときは共通の設定項目を確認する

デスクトップのv2rayNからAndroidへサーバー設定を移す場合は、移行先が明確に対応している共有リンクまたはサブスクリプション形式を使い、インポート後に編集画面で項目を確認してください。デスクトップのルーティンググループやシステムプロキシ設定と、Androidのアプリごとのプロキシ設定はクライアントや端末ごとの動作です。サーバーの共有リンクと一緒に移行されるわけではありません。サーバー設定が同じでも、端末側でプロキシを適用する範囲は個別に設定する必要があります。v2flyNGを使う場合は、設定がXray固有の機能を必要としないかも確認してください。現在のコアが必要な機能に対応していなければ、サブスクリプションのテキスト形式を変えても機能は追加されません。

確実に移行するには、2段階に分けて進めます。まず移行先の端末で、必要な項目が揃った代表的な設定をインポートして接続を確認し、その後グループ全体を移行します。最初の設定で接続できない場合は、元のリンクとインポート後の項目を比較し、テキストの解析、コアの起動、アプリからのリクエストのどの段階で問題が起きたかを確認してください。グループが多い場合は、サブスクリプショングループとノードの絞り込み方法を参考に、用途ごとに分かりやすく整理してから更新間隔を決めましょう。すべてを何度も削除して追加し直すより、問題を調べる手がかりを残せます。

8. 用途に合わせて選び、項目ごとに検証する

まず設定元を確認し、次に端末を選ぶ

既存のサーバーやサブスクリプションがある場合は、好みのプロトコル名を先に決めて設定を変更するのではなく、配信元が指定するプロトコルと必要な項目に従ってください。デスクトップではv2rayNを使い、Windows、macOS、Linuxの実際のOSに合ったインストーラーを選びます。Androidではv2rayNGが必要なXray機能に対応しているかを確認し、既存の設定がV2Flyコア向けならv2flyNGが適しているか調べてください。インストール方法はクライアントのダウンロードページにまとめています。クライアントを選んだら、搭載されたコアがサーバーのプロトコル、通信方式、セキュリティの組み合わせに対応しているかを確認します。

サーバーを自分で管理し、新しい設定の種類を決める場合は、チームで運用しているサーバー機能、既存のサブスクリプション出力形式、対象端末の範囲を基準にします。REALITYが必要なら、選択したコアとクライアントが各項目に対応しているかを確認してから、対応するVLESS設定を設計してください。すでにVMessやTrojanの設定を安定して運用している場合は、名称を揃えるためだけに移行するより、各項目を明記した説明を維持するほうが確実です。Shadowsocksを選ぶ場合は、利用端末のすべてが同じmethodに対応しているか事前に確認します。どの方式でも、サブスクリプションをまとめて生成する前に代表的な設定ひとつで接続を確認してください。サーバーや端末から切り離して考えられる「最適なプロトコル」はありません。

3つの段階に分けて問題を特定する

第1段階はインポートです。設定が一覧に表示されるか、編集画面に元の設定の重要な項目がすべて含まれているかを確認します。第2段階はコアの起動です。クライアントのログに、未知の項目、無効なパラメーター、ローカルポートの競合が出ていないか確認してください。第3段階はアプリからのリクエストです。コアの起動後、対象アプリが正しいローカルプロキシやシステムプロキシを使っているか、ルーティング規則が想定したアウトバウンドへリクエストを渡しているかを確認します。第1段階で失敗する場合はサブスクリプション形式、第2段階ならコアと設定項目の組み合わせ、第3段階ならシステム設定、DNS、ルーティング、アプリの動作を調べます。すべての問題を「プロトコルが使えない」とひとまとめにしないでください。

デスクトップのブラウザーとターミナルのコマンドは、それぞれ異なるプロキシ設定を使うことがあります。v2rayNのトレイメニューにある「システムプロキシを自動設定」は、主にシステムプロキシに従うアプリに適用されます。ターミナルのツールには、環境変数やアプリごとの設定が別途必要な場合があります。ブラウザーでは接続できてもターミナルでは使えない場合、すぐサーバーのプロトコルを変更するのではなく、それぞれが参照するプロキシ設定を確認してください。詳しい手順はmacOSでシステムプロキシが機能しない場合の確認方法をご覧ください。設定に関するよくある質問はよくある質問から項目別に確認できます。

あとから確認できるよう設定を記録する

代表的な設定について、プロトコル、通信方式、セキュリティの種類、コアの系列、設定の取得元を記録してください。ログインに使える機密情報は記録しないでください。サブスクリプションの更新、コアの切り替え、サーバー設定の変更後は、これらの項目を再確認してから接続の動作を確認します。問題が起きた場合は、関連ログのエラーの種類と変更の順序を記録してください。ログを共有する前に、アドレス、ユーザー情報、パスワードなどを削除しましょう。こうした記録があれば、「どの層が変わったか」を確認でき、「以前は使えたのに今は使えない」とだけ記録するより問題を特定しやすくなります。

ルーティングモードの設定は、基本接続を確認した後に行います。まず正しいサーバー設定で接続できることを確かめてから、必要に応じてローカルネットワークの除外、ルーティング規則、DNS名前解決を設定してください。パソコンのローカルプロキシポートをほかの端末と共有する場合は、待ち受けアドレスとシステムファイアウォールも設定する必要があります。サーバーのプロトコルの種類だけでは共有できるかどうかは決まりません。詳しくはLANからの接続を許可する設定をご覧ください。変更は一度に1つの層に限定し、同じアプリで再テストすると結果を判断しやすくなります。

この手順は、手動で追加した設定からサブスクリプション管理へ移行する場合にも使えます。まず単一の設定で接続を確認し、次に複数設定のインポートを確認してから、ルーティングと端末側でプロキシを適用する範囲を設定してください。初めて操作する場合は、入門ガイドに戻り、画面の手順に沿って進められます。接続済みで項目の意味を確認したい場合は、このページの該当する章をご覧ください。プロトコルの選択、コアの互換性、アプリのプロキシ設定を分けて確認すると、複数の設定を同時に変えて判断できなくなる事態を防げます。