V2Ray プロトコルとコアの比較ガイド

01 / Configuration layers

ノード設定を構成する4つのレイヤー

クライアントのノード一覧にある1件の設定は、実際には複数の要素で構成されています。サーバーのアドレスとポートは接続先を示し、VMess、VLESS、Trojan、Shadowsocksはプロキシ要求の形式や認証方式を定めます。TCPやWebSocketなどの通信方式はデータの運び方を、TLSやREALITYは接続の保護方法に関わります。これらをまとめて「プロトコル」と呼ぶと便利な一方、選択を誤る原因にもなります。同じVLESSのノードでも、安全性や通信方式が異なれば接続条件は大きく変わります。

プロキシプロトコルと通信方式は別のもの

プロキシプロトコルは、接続先のアドレスを伝えるほか、ユーザー認証や要求の種類、データの形式を定める場合があります。通信方式は、それらのデータを接続先まで届ける役割を担います。同じプロキシプロトコルで複数の通信方式を使える場合もありますが、あらゆる組み合わせがコアやサーバーに実装されているわけではありません。ノードの詳細を確認するときは、名前に含まれる略称だけで判断せず、プロトコル、通信方式、安全性の種類、追加項目をそれぞれ記録しましょう。ノード名はサブスクリプションの管理者が付けたラベルであり、実際の接続動作を定義するものではありません。

たとえばWebSocketでは、接続時にHTTP Upgradeが行われ、通常はパスやリクエスト先のホスト名も指定します。TCPで直接接続する場合、こうした項目は自動的には設定されません。WebSocketを選んでもプロキシプロトコルのユーザー認証は不要にならず、接続が暗号化される保証もありません。同様に、TLSを有効にしても通常のプロキシ要求が別のプロキシプロトコルに変わるわけではありません。クライアントで項目が隣り合っているのは編集しやすくするためであり、同じ技術レイヤーに属することを意味しません。

安全性とトラフィックの入口を分けて考える

ローカルのインバウンドは、ブラウザーなどのアプリがクライアントへ接続する入口です。このガイドで主に比較するのは、リモート側へのアウトバウンドです。ローカルで待ち受けるSOCKSやHTTPのポートは、ノードのサーバーポートとは異なります。システムプロキシは通常、アプリの接続先をローカルのHTTP入口に設定します。SOCKS対応アプリでは、入口を個別に指定することもできます。コアに入ったトラフィックは、ルーティングルールによって一部が直接送信される場合もあります。したがって、システムプロキシが有効でも、すべての接続が選択中のノードを経由しているとは限りません。

認証と通信の保護も分けて考えましょう。ユーザーIDやパスワードなどは、サービスを利用できるかどうかを確認するための情報です。証明書の検証は、TLS接続先が信頼できる相手かどうかを判定します。失敗時のログや対処法はそれぞれ異なります。認証情報の誤りを証明書検証の無効化で解決しようとしてはいけません。証明書名が一致しない場合も、ユーザーIDを何度も変更するのは適切ではありません。まず問題がどのレイヤーで起きているかを特定し、複数の設定を同時に変えて比較できなくなる事態を防ぎましょう。

後から確認できる設定一覧を作る

ノードを比較する前に、この4つのレイヤーの情報を手元に記録し、使用するコアとクライアントも書き添えておきましょう。認証情報そのものを書き写す必要はありません。各項目が設定されているか、情報の出所が一致しているかを確認すれば十分です。サブスクリプションで設定一式が提供されている場合は、元の組み合わせを保ち、思い込みで通信方式を変更しないでください。クライアントの選択を変えても、サーバー側の設定が自動で切り替わるわけではありません。アドレスや認証情報が正しくても、パスや安全性の設定が誤っていればハンドシェイクに失敗します。

このレイヤー分けは、用語やログを確認するときにも役立ちます。ハンドシェイク、認証、パス、ルーティングの一致などの表示があれば、まず該当するレイヤーを特定してから、その項目を確認しましょう。用語集ではインバウンド、アウトバウンド、ルーティングの定義を確認できます。続く章では、設定が異なる組み合わせに分かれている理由と、利用者が選ぶべき違いを解説します。

02 / Proxy protocols

VMessとVLESSの設計上の違い

VMessはProject Vのエコシステムで早い時期に確立されたプロキシプロトコルで、ユーザー認証、リクエストヘッダー、データ保護の仕組みを備えています。一方、VLESSはプロキシレイヤーの処理を簡素化し、接続保護を外部の安全性レイヤーに委ねることを重視しています。拡張の余地も考慮した設計です。新旧だけで優劣を判断することはできません。また、ノードの種類をVMessからVLESSに変更するだけでアップグレードになるわけでもありません。サーバー側に対応する入口があり、クライアント側でも認証、通信方式、安全性の設定が一致している必要があります。

VMess：認証方式と時刻を確認

VMessの設定には、通常ユーザーIDと安全性に関する項目が含まれます。古い資料ではalterIdなどの歴史的な項目が見られますが、現在の設定ではAEAD認証方式が主流です。古いノードを取り込む際は、過去の画面に表示されていた項目をすべて追加するのではなく、サーバーが実際に使う認証方式と、現在のコアが対応しているかを確認しましょう。サブスクリプションから取得した新しい設定に古い項目をむやみに追加すると、互換性の問題が起こることがあります。設定項目の数が多いほど適切とは限りません。

時刻もVMessのトラブル対処で見落とされやすい条件です。一部の認証処理では時間の許容範囲が定められており、システム時計が大きくずれていると認証に失敗する場合があります。画面上のタイムゾーンだけでなく、端末の実際の日付と時刻、自動同期の状態を確認してください。正しい時刻を保ったままタイムゾーンだけを変更しても、通常は認証の時刻ずれにはなりません。すべてのVMessノードが同時に失敗し、ほかのプロトコルは正常なら、時刻同期も確認項目に加えます。ただし、プロトコル名だけで原因を決めつけず、ログも確認しましょう。

VMessのデータ保護には一定の処理負荷がかかりますが、実際のリソース消費はアルゴリズムの実装、プロセッサの性能、外側のTLS、接続数、通信パターンにも左右されます。ノードでTLSを重ねて使う場合、安全性はVMessだけに依存しません。この組み合わせを使うかどうかは、サーバーの設計と互換性の要件に基づいて判断しましょう。暗号化処理を1つ減らすために、既存の安全性レイヤーを独断で無効にするのは避けてください。接続できるかどうかと、適切に構成されているかどうかは、別々に確認する必要があります。

VLESS：シンプルでも暗号化を単独で担うわけではない

VLESSはプロキシ要求の形式とユーザー認証を扱いますが、一般的な設定ではアプリケーションデータの暗号化を行いません。画面に表示されるencryption: noneは、この種類の設定では通常の値です。外側のTLSやREALITYが無効という意味ではありません。この項目だけで接続が保護されているかを判断せず、安全性の種類も確認してください。信頼できないネットワークを経由する接続では、サーバーの指定に従って適切な安全性レイヤーを使用する必要があります。保護のない設定を一般的な構成として推奨することはできません。

VLESSは、flow項目のVisionなど、Xrayの拡張機能と組み合わせて使われることがあります。flowは自由に指定できる速度モードではなく、プロトコル上の意味と実装要件がある設定です。サーバーで該当する処理が有効でない場合、通信方式の組み合わせが要件を満たさない場合、使用中のコアがその機能を実装していない場合は、同じ値を入力しても同じ結果にはなりません。項目名だけを追うより、サブスクリプションの値を維持し、クライアントが実際に使用するコアを確認することが重要です。

クライアントでの選び方

VMessの設定が長期間安定しており、提供元がその接続先を引き続き管理しているなら、手動で変更するよりそのまま使うほうが安全です。新しい設定でVLESSと対応するTLSまたはREALITYが明示されている場合は、その組み合わせを一式で利用できます。比較する際は、サーバーの地域、ネットワーク経路、測定時間帯をできるだけそろえましょう。条件が異なると、プロトコルではなく経路の違いが測定結果に表れることがあります。ダウンロード速度だけでなく、接続失敗率や再接続の状態も確認してください。

v2rayNでは、まずノード編集画面でプロトコルと安全性の設定を確認し、その設定が実際にどのコアで動いているかを調べます。v2rayNGでも、取り込み時に追加項目が保持されたかを確認してください。目的の組み合わせが現在の実装範囲外なら、設定全体に対応したクライアントやコアを選びましょう。不明な項目を削除するのは避けてください。2種類のコアが対応する範囲については、コアの互換性の章で詳しく説明します。

03 / Alternative designs

TrojanとShadowsocksの使い分け

TrojanとShadowsocksは同じノード一覧に並ぶことがありますが、認証とデータ保護の方法は異なります。Trojanは通常TLSを接続の安全性の基盤とし、その中でプロキシ要求とパスワード認証を行います。Shadowsocksは軽量なプロキシと事前共有鍵を中心に、独自のデータ保護の仕組みを備えています。選ぶときは、短いラベルのTrojanやSSだけで互換性を判断せず、プロトコルの世代、暗号方式、通信方式の組み合わせを確認しましょう。

Trojan：TLS設定とパスワードを確認

Trojanの一般的な設定には、サーバーアドレス、ポート、パスワード、TLSに関するサーバー名が必要です。パスワードが正しくても証明書検証の失敗は解決できません。TCP接続が確立しても、TLSやその後の認証が完了したとは限りません。ログが証明書の段階で止まっている場合は、サーバー名、証明書チェーン、端末の時刻を確認してください。TLS完了後に接続先から要求を拒否された場合は、パスワードとサーバー側の入口を確認します。接続の段階ごとに調べるほうが、ポートを何度も変更するより効果的です。

設定では、サーバーアドレスとサーバー名が別の役割を担う場合があります。前者はネットワーク接続先を決め、後者はTLSハンドシェイクと証明書名の検証に使われます。アドレスにIPを指定していても、サーバー名まで同じIPに変更すべきとは限りません。サブスクリプションに記載されたサーバー名はそのまま使いましょう。証明書検証をスキップすると信頼の範囲が変わるため、通常の対処法としては適切ではありません。まずサーバー名、システム時刻、サーバー側の証明書設定を確認してください。

実装によってはTrojanに異なる通信方式を組み合わせるため、その場合はパス、ホスト名、通信方式の項目も接続に影響します。あるクライアントから書き出した拡張設定が、Trojan対応のすべての実装で使えるとは限りません。互換性を確認する際は、設定画面にTrojanがあるかだけでなく、使用するコアがその具体的な組み合わせに対応しているかを調べましょう。取り込み後に通信方式が既定値へ戻っていたら、接続前に確認してください。設定の読み込み漏れをノードの障害と誤認するのを防げます。

Shadowsocks：暗号方式は必須の設定

Shadowsocksでは、通常アドレス、ポート、暗号方式、パスワードを設定します。従来のAEAD方式と後続の2022シリーズでは仕様が異なり、鍵の要件や実装の対応状況も同じではありません。名称が似ていても互換性があるとは限りません。接続の両端で同じ仕様を使用する必要があります。鍵の長さやエンコード方法が定められた設定に、任意の長さの通常パスワードをそのまま使ってはいけません。接続に失敗したとき、すぐにネットワーク品質の問題だと決めつけないようにしましょう。

古い資料にある従来のストリーム暗号方式を、新しい設定の既定値にするべきではありません。提供元が現在も管理し、双方のコアが対応している方式を使用してください。古い画面に合わせるために過去の設定へ戻すのは避けましょう。サブスクリプションによっては追加の通信拡張情報を含みますが、これらはShadowsocksの基本プロトコルの一部とは限りません。クライアントがアドレスとパスワードを読み取れても拡張項目を解釈できないことがあるため、取り込みに成功した後も詳細を確認してください。

「軽量」だけで使い勝手を判断しない

Shadowsocksは基本的な処理が比較的シンプルですが、すべてのノードが速く、電池消費も少ないとは限りません。暗号方式のハードウェアアクセラレーション、ネットワークのパケットロス、サーバー負荷、クライアントの接続維持方法などで結果は変わります。TrojanがTLSを利用していても、リクエストのたびに完全なハンドシェイクが発生するわけではありません。接続の再利用やセッション再開によって実際の負荷は異なります。設計上の特徴は分析の手がかりとして扱い、測定に代わる固定の順位にしないようにしましょう。

提供元が両方のノードを用意している場合は、クライアントが設定全体を正しく読み取れ、日常のアプリで安定して使える組み合わせを選びましょう。UDPが必要なアプリでは、クライアント、コア、サーバー、現在の動作モードがそれぞれ対応しているかを確認してください。ウェブページが開けても、UDPに対応しているとは限りません。応答時間、接続先の地域、通信量の倍率を総合的に判断する方法は、ノード選びとテスト方法を参考にし、プロトコルをネットワーク全体の条件の中で評価してください。

04 / Security layers

TLS、REALITY、通信方式

REALITYは、VMess、VLESS、Trojanと並べて広告ラベルやノード名に記載されることがあります。しかし設定のレイヤーで見ると、プロキシ要求の形式を単独で担う同種のプロトコルではありません。一般的にはVLESSとREALITYを組み合わせ、プロキシレイヤーで接続先への要求を処理し、安全性の仕組みで接続の保護と相手の認証を行います。TLSはより汎用的な安全性プロトコルです。比較するときは組み合わせ全体を記載し、「VLESSとREALITYのどちらかを選ぶ」といった異なるレイヤーの混同を避けましょう。

TLS：接続先の名前、証明書、アプリケーションプロトコル

TLSは接続の暗号化、完全性の保護、接続先の認証を行います。クライアントは設定されたサーバー名に基づいて証明書の名前を確認し、証明書チェーンと有効期限も検証する必要があります。ネットワーク接続先のアドレス、TLSのサーバー名、WebSocketリクエストのホスト名は、同じ値の場合も別々に設定される場合もあります。すべてドメイン名に見えるからといって、3つの項目を同じ値に置き換えないでください。必要な項目が一致するかどうかは、サーバーの証明書、通信方式の受け入れ方、リクエスト処理によって決まります。

ALPNはアプリケーション層のプロトコルをネゴシエートするもので、接続先の地域や速度を調整する設定ではありません。通信方式が特定のアプリケーションプロトコルを必要とする場合、クライアントとサーバーのネゴシエーション結果が要件を満たす必要があります。フィンガープリントはTLSハンドシェイクの見え方や実装の互換性に影響する場合がありますが、特別な値にするほどよいわけではありません。サブスクリプションに値がある場合は、まずそのまま試してください。設定がない場合、別のノードの値をそのまま流用するのは避けましょう。サーバーごとに要件は異なるため、一部の項目だけをコピーすると、正常な設定を壊すことがあります。

REALITY：関連する設定一式で認証を確認

REALITYはXrayのエコシステムで実装され、一般的な証明書チェーン検証とは異なる認証方式を使用します。クライアントには通常、サーバー名、公開鍵に関する情報、ショートID、フィンガープリントなどが必要です。具体的な画面上の名称は実装の変更に伴って変わることがあります。これらの項目は同じ有効な設定から取得する必要があり、別々のノードの情報を組み合わせてはいけません。公開鍵は対応するサーバーを検証するために使われ、ショートIDもサーバー側で許可された値と一致する必要があります。どちらも任意に省略できる飾りの項目ではありません。

一般的なVLESS、REALITY、Visionの組み合わせでは、コアの実装と通信条件も一致させる必要があります。クライアントがVLESSに対応していても、REALITYに対応するとは限りません。REALITYに対応していても、あらゆるflowと通信方式を組み合わせて使えるわけではありません。サーバーが明示的に対応する組み合わせを一体として扱いましょう。接続に問題がある場合は、項目を1つずつ試しに変えるのではなく、まずコア、サーバー名、認証情報、flowを確認し、その後にネットワークの接続性を調べてください。

REALITYはサーバーアドレスの誤りを補う機能ではなく、接続先の品質を自動で保証するものでもありません。安全性のネゴシエーションに成功しても、その後のプロキシ認証、接続先へのアクセス、ルーティングで失敗することがあります。設定一式を保存し、対応するコアで使い、更新後に読み込み結果を確認するのが適切です。時刻や認証情報を無視したり、あらゆる証明書の仕組みを回避したりする万能スイッチとして扱わないでください。

TCP直接接続とWebSocketのコスト

TCPで直接接続すると、通常は中間処理が少なくなります。一方、WebSocketはHTTP Upgradeとメッセージのカプセル化を使い、既存のリバースプロキシやアプリケーションサーバーの構成でよく利用されます。追加のカプセル化には処理コストがかかりますが、実際の使い勝手は導入経路が適切かどうかにも左右されます。レイヤーの数だけでスループットを予測したり、階層を減らすためにサーバーがWebSocketしか提供していない設定をTCPへ変更したりしてはいけません。それはクライアント内部の最適化ではなく、接続先の入口を変更する操作です。

多重化をあらゆる通信方式に適した既定の機能と考えるのも、よくある誤解です。多重化は複数の論理接続で下位のリソースを共有する仕組みですが、パケットロスや長時間の通信、一部のプロトコル処理では接続同士が影響し合うことがあります。組み合わせによっては明確な制限もあります。有効にするかどうかは、使用中のコアのドキュメントとサーバー側の設定に従い、実際のアプリで検証してください。画面に設定項目があることは、すべてのノードに適していることを意味しません。

05 / Performance and battery

接続速度、リソース消費、モバイル端末の電池消費

プロトコルの比較は速度ランキングにまとめられがちですが、測定条件が分からない順位は参考にできません。アプリの使用感には、初回接続までの時間、リクエストへの応答、持続的なスループット、再試行の失敗率、長時間の安定性などが関わります。プロキシプロトコルは要因の1つにすぎません。ネットワークの往復距離、名前解決、輻輳、サーバー負荷、接続先の応答も結果を大きく左右します。比較する際は、まずこうした条件をそろえ、プロトコルの組み合わせやクライアント設定による違いを確認しましょう。

遅延、ハンドシェイク、スループットを分けて測定

クライアントのTCP接続テストで確認できるのは、通常ノードの入口まで接続できるかどうかです。プロキシ認証や接続先への要求が成功する証明にはなりません。実際のリクエストを使ったテストはアプリの動作に近づきますが、テスト先の地域、キャッシュ、サービスの状態にも影響されます。長時間のダウンロードで分かるのは主にスループットであり、短いリクエストへの応答速度とは異なります。テスト名がどの処理を測定しているかを確認し、同じ条件の同じ指標同士を比較しましょう。

初回接続では通常、名前解決、通信の確立、安全性のハンドシェイクが行われます。その後、同じ接続先へのリクエストでは接続の再利用によって時間が短縮される場合があります。比較では初回アクセスと継続利用の両方を確認し、すでに接続が確立した状態同士だけを比べないようにしてください。初回だけ遅く、その後は正常なら、ハンドシェイクや名前解決を確認します。開始直後は正常でも通信を続けるうちに悪化する場合は、輻輳、パケットロス、サーバーの制限、端末の温度を調べましょう。現象によって有効な対処法は異なります。

処理負荷は実装と通信内容によって変わる

データの暗号化はプロセッサのリソースを消費します。追加のカプセル化は処理やメモリコピーを増やし、接続の再利用やバッファリングの方法もメモリ使用量に影響します。ハードウェアアクセラレーションに対応する暗号方式でも、ある種類のプロセッサでは有利で、別の端末ではそうとは限りません。クライアントの画面とプロキシコアは別々に動作することがあります。システムのリソースを確認する際は、両者を区別してください。画面側のプロセスの使用量が少なくても、プロキシ全体の負荷が低いとは限りません。

メモリ使用量が多くても、アクティブな接続、キャッシュ、バッファーが原因であれば、必ずしも問題ではありません。近い負荷条件で使用量が増え続けるか、通信を止めると安定するか、システムによるメモリ回収やプロセス終了を伴うかを確認しましょう。頻繁な切断と再接続は、少数の接続を安定して維持するより多くのハンドシェイク処理を発生させる場合があります。逆に、多重化を過度に使うと、複数の要求が詰まった1本の接続を共有することがあります。リソース表示を最小にするのではなく、実際の負荷に合わせて設定してください。

モバイル端末では無線通信とバックグラウンド動作も確認

Androidの電池消費は、プロトコルの処理だけで決まりません。無線ネットワークの動作、アプリのバックグラウンド通信、端末のスリープ解除も影響します。短い間隔で接続を維持したり、自動速度テストを頻繁に実行したり、失敗後に再試行を続けたりすると、端末が低消費電力状態に入りにくくなります。電波が弱い場所では、モバイル通信による消費がさらに増えることがあります。v2rayNGやv2flyNGの電池消費を比べる場合は、ネットワークの種類、画面の状態、アプリの負荷をそろえ、自動更新やテストが動いていないかも確認しましょう。

OSのバックグラウンド制限は接続の維持に影響します。制限を緩めるとアプリが動作し続けやすくなりますが、電池消費の条件も変わります。一方のテストだけバックグラウンド動作を許可し、もう一方では制限したままにして、その差をすべてコアの違いに帰すことはできません。画面を表示した状態、画面消灯中の待機、無線ネットワークの切り替えという3つのシーンで、接続が復旧するか、再接続が発生するか、アプリが実際に通信しているかを確認しましょう。画面を表示したまま一度ダウンロードするだけでは、モバイル端末の日常的な使い方を評価できません。

比較する場合は一度に1つだけ条件を変更し、近い時間帯にテストを繰り返して、元の設定に戻せるようにしておきましょう。長時間の最大速度ダウンロードだけを基準にしないでください。端末の温度、通信量、OSの処理配分が同時に変わります。普段の閲覧では、短いリクエストを安定して完了できるかのほうが、ピーク時のスループットより参考になることがあります。結論は特定の端末、ネットワーク、設定の組み合わせで得られた結果としてまとめ、すべての利用者に当てはまるプロトコルランキングにしないでください。

06 / Core compatibility

V2Fly、Xray、クライアントの関係

V2Rayは当初、Project Vのエコシステムに属していました。V2Flyは関連プロジェクトをコミュニティ主導で引き継ぎ、Xrayはその技術基盤から分岐して、VLESS、XTLS、REALITYなどを中心に独自の実装を発展させています。共通する概念や従来の設定方法もありますが、どちらも自由に置き換えられる同一のプログラムではありません。コアを選ぶときは、まず目的の設定に対応しているかを確認し、その後で特定の端末におけるリソース消費や管理のしやすさを比較しましょう。

GUIクライアントとコアは役割が異なる

GUIクライアントは、サブスクリプションの管理、ノードの編集、システムプロキシの設定、起動制御を担当します。コアは実行設定を解釈し、接続、ルーティング、通信を処理します。v2rayNはデスクトップでの標準的な選択肢で、利用するプラットフォームやソフトウェアパッケージに応じてコアの設定を管理できます。v2rayNGはAndroid向けで、主にXrayコアを使用します。v2flyNGはV2Flyベースの選択肢です。クライアント名はプロキシプロトコルではありません。同じプロトコルの設定でも、動作するかどうかは最終的に生成された設定と実際に呼び出されるコアによって決まります。

クライアントの画面で項目を設定できても、実行中のコアがその項目に対応しているとは限りません。逆に、コアが機能を備えていても、画面に編集項目がまだない場合があります。トラブル対処では、取り込み結果、実行ログ、現在選択されているコアをあわせて確認してください。特に古い設定を移行したり、コアを切り替えたりした後は、以前の既定値が残っていないか確認しましょう。画面に「起動済み」と表示されても、起動処理が完了しただけです。実際の接続先への要求を確認する代わりにはなりません。

共通して対応するプロトコルにも設定上の違いがある

どちらのコアもVMess、VLESS、Trojan、一部のShadowsocks方式に対応している場合があります。しかし、通信方式、安全性の拡張、項目名、既定の動作は異なることがあります。REALITYやXTLS VisionはXray系の重要な機能であり、V2Flyが同じ設定をそのまま解釈できるとは限りません。これらの機能が必要な場合は、対応する実装を選びましょう。読み込みを通すために重要な項目を削除すると、接続の意味が変わります。互換性のある設定になったわけではありません。

JSONの構造が似ていることも、誤解の原因になります。どちらのコアにもインバウンド、アウトバウンド、ルーティングなどの構造がありますが、同名の項目でも指定できる値、拡張項目、DNSの処理方法が実装ごとに異なる場合があります。移行するときは機能要件をもとに対応する設定を項目ごとに確認し、設定ファイル一式を別のコアでそのまま実行しないでください。特にルーティングのタグが存在するか、アウトバウンドの参照先が正しいか、必要なデータを読み込めるかを再確認しましょう。

以下はルーティングの意味を説明するための一部抜粋であり、単独で起動できる完全な設定ではありません。指定したドメインの集合に一致した場合、directという名前のアウトバウンドを選択します。実行時には同じ名前のアウトバウンドが存在し、関連するドメインデータを読み込める必要があります。この例からも分かるように、互換性はプロキシプロトコルだけでなく、必要なデータやタグの関係にも関わります。ルールだけをコピーして対応するアウトバウンドを用意しなければ、意図した直接接続にはなりません。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

コアの切り替えは範囲を絞って検証する

切り替える前に、現在動作している設定を保存しておきます。まず、切り替え先のコアが対応していることを確認できるノードを1つ選んでテストしましょう。その後、名前解決、よく使うサイト、UDPが必要なアプリ、システムプロキシの復元を確認します。特定の種類のノードだけ失敗する場合は、そのプロトコルの拡張項目を優先的に調べます。すべてのノードが失敗する場合は、コアの起動エラー、待ち受けポート、設定の生成処理を確認してください。「コアが起動していない」状態と「特定のプロトコルに対応していない」状態を切り分けられ、誤った判断を減らせます。

コアとクライアントは別々に更新される場合があります。更新後に問題が起きたら、プロトコル、設定の読み込み、既定の動作のどれが変更されたかを確認し、以前使えていた設定と比較してください。サブスクリプション全体をすぐに作り直す必要はありません。当サイトのダウンロードページでは、3つのクライアントをプラットフォーム別に掲載しています。各系列の違いを詳しく知りたい場合は、Xray-coreとV2Fly-coreの比較記事もあわせてご覧ください。選ぶ基準は実際の設定要件であり、分岐の関係を品質ランキングとみなすことではありません。

07 / Subscription formats

サブスクリプション形式、共有リンク、移行時の確認

サブスクリプションは設定の配布方法であり、新しいプロキシプロトコルではありません。サブスクリプションのURLから通常は複数のノード情報が取得され、クライアントが内部形式に変換します。共有リンクは1つのノードだけを表すことがよくあります。どちらもエンコードされている場合がありますが、エンコードは情報の秘匿を意味しません。サブスクリプションのURLやノードの認証情報は機密情報として管理し、公開スクリーンショット、掲示板の投稿、ログ全文に載せないようにしてください。トラブル対処で必要なのは項目の有無であり、実際の値を公開することではありません。

取得に成功しても、すべての項目を読み取れたとは限らない

サブスクリプションの更新では、ネットワークへのリクエスト、内容の判定、項目の解析、ノード情報の登録が行われます。レスポンスを受け取れても、その内容がクライアントで理解できるノード一覧とは限りません。ログイン画面、エラーメッセージ、別形式の設定が返ることもあります。更新後にノードが表示されない場合は、取得の失敗と解析の失敗を切り分けましょう。前者ではURLの有効性とリクエストの経路を、後者では提供元の形式がクライアントに対応しているかを確認します。更新ボタンを何度も押すだけでは解決しません。

一般的な共有リンクにはVMess、VLESS、Trojan、Shadowsocksの形式がありますが、同じ接頭辞でも拡張項目の表現方法が異なる場合があります。通信パス、サーバー名、flow、フィンガープリント、REALITYの認証情報が、ある解析ツールではすべて認識されても、別のツールでは無視されることがあります。取り込み件数が正しく見えても、ノードの詳細をいくつか確認しましょう。最も危険なのは取り込み自体の失敗ではなく、重要な項目が抜けたまま正常に見える設定が作られることです。

ノード一覧と実行設定一式を混同しない

ノード一覧が含むのは通常アウトバウンドの接続情報です。完全な設定にはインバウンド、DNS、ルーティング、ポリシーなどが含まれる場合もあります。クライアントの通常のサブスクリプション機能では、後者を取り込めないことがあります。完全設定用の機能を使っても、画面上の設定がすべて適用されるとは限りません。まず取り込むデータの種類を判断し、適切な機能を選びましょう。完全設定がルーティングを管理しているときに画面のプリセットを何度も切り替えても、設定表示だけが変わり、実際の動作は変わらない場合があります。これはプロトコルの障害ではありません。

v2rayNからv2rayNGやv2flyNGへ移行する場合は、提供元が互換性を明示したサブスクリプションや共有形式を優先しましょう。デスクトップ版が生成した実行設定をコピーしても、モバイル端末に必要な入口や実行環境が保持されるとは限りません。モバイルではアプリのトラフィックを取り込む方法、ファイルの場所、バックグラウンドの制限がデスクトップと異なります。アウトバウンドのプロトコルが同じでも、設定全体がそのまま使えるとは限りません。すべてのプラットフォーム固有の項目を維持しようとせず、ノードの動作に必要な情報を保って移行しましょう。

更新方法では上書きの動作と通信経路を確認

サブスクリプションのグループは、同じ提供元から取得したノードをクライアントが識別するために使われます。更新時に該当するノードが置き換え、削除、再作成されることがあります。サブスクリプションのノードに手動で加えた変更は、次回更新で保持されない場合があります。設定を一時的に比較する場合は、クライアントの複製機能や独立したノードの作成機能を使い、複製したノードが元のサブスクリプションと引き続き連動するか確認してください。元のグループを残しておくと、提供元の変更とローカルでの変更を切り分けやすくなります。

更新リクエストを直接接続で送るか、プロキシ経由にするかで到達性は変わります。ただし、プロキシ経由で更新すると依存関係が生まれることがあります。現在使用中のノードが使えなくなると、そのノードを通して新しい設定を取得できません。その場合は、利用可能なネットワーク経路か別に使えるノードで更新し、何度も再試行しないようにしましょう。自動更新の間隔も短くしすぎないでください。提供元の更新頻度と端末のバックグラウンド動作に合わせて設定します。頻繁に更新してもノードの性能は上がりません。

移行後は、まずノードを1つ選んで確認し、その後グループ、ルーティング、普段使うアプリをチェックしましょう。一度にすべての設定を変更する必要はありません。更新時刻は正常でも項目が欠けている場合は、対象クライアント、プロトコルの種類、欠けている項目名を提供元に伝えます。認証情報の全文は送らないでください。更新の失敗についてはサブスクリプション更新のトラブル対処を参照してください。基本的な用語や取り込み方法は使い方ガイドで確認し、取得、解析、実行の各段階を分けて考えましょう。

08 / Selection workflow

用途に合ったプロトコルを選び、設定を検証する

実際の選択では、あらゆるプロトコルの中から永久に最適なものを探す必要はありません。まず端末、クライアント、サーバーが対応する有効な組み合わせを確認し、その中から必要な条件を安定して満たすものを選びましょう。デスクトップではv2rayNで設定を管理し、Androidでは通常v2rayNGから試します。V2Flyの動作が明確に必要な場合はv2flyNGを検討してください。クライアントは設定の入口にすぎず、接続できるかどうかはコアと設定全体で決まります。同じノード名でも、2台の端末で動作条件が同じとは限りません。

普段使いの閲覧と長時間の安定した利用

ウェブ閲覧、文書の利用、メッセージの送受信が中心なら、最大速度のダウンロードだけでなく、短いリクエストの成功率、初回応答、バックグラウンドからの復帰を確認しましょう。現在の組み合わせが安定し、サーバーが継続して管理され、クライアントが設定を正しく読み取れているなら、ラベルを新しくするために頻繁に移行する必要はありません。変更する場合は、同じネットワーク条件で新しい設定をテストし、よく使う接続先、名前解決、再接続が正常であることを確かめてから、普段使いに切り替えましょう。元の設定も残しておいてください。

接続を頻繁に確立する小さなリクエストでは、ハンドシェイクと接続の再利用に注意が必要です。ただし、応答が遅いからといって、すべてをハンドシェイクのせいにしてはいけません。接続先の応答が遅い場合や、ルーティングで直接接続が誤って選ばれた場合、DNSが適切でないアドレスを返した場合も、同じような現象が起きます。まず要求が意図したアウトバウンドを通っているか確認してから、プロトコルを比較してください。そうしないと、同じ通信を処理するプロトコルの差ではなく、異なるネットワーク経路を測ることになります。

モバイルネットワーク、連続通信、特定のアプリ

Wi-Fiとモバイルネットワークを頻繁に切り替える環境では、1回のテストで最小遅延を出すことより、切り替え後に復旧できるかが重要です。ネットワーク変更後に古い接続が解放されるか、新しい要求が自動で復旧するか、バックグラウンド制限がクライアントの動作を妨げていないかを確認しましょう。切り替え後にだけ問題が起きる場合は、まず接続を確立し直し、名前解決と現在のネットワークを確認してからプロトコルを変更するか判断してください。安全性の設定を何度も変えても、古い接続が復旧しない問題は解決しません。むしろ確認すべき要因が増えてしまいます。

大容量ファイルの転送や長時間の動画再生では、安定したスループットと端末の温度を重視しましょう。サーバーの地域と測定時間をそろえ、通信が頻繁に中断しないか確認してください。1回だけのピーク値を唯一の基準にするのは避けましょう。UDPが必要なアプリでは、経路全体が対応しているかを確認します。ローカルでトラフィックを取り込む方法、コアのアウトバウンド、サーバー、接続先のいずれも制限になる可能性があります。ウェブページが開けても、必要な機能すべてを確認できたことにはなりません。対象のアプリでもテストしてください。

リソースの限られた端末では、実装が安定しており、余分なレイヤーが少なく、双方が対応を明示している組み合わせを優先できます。ただし、必要な安全性の保護を削除するという意味ではありません。自動速度テストの頻度を下げる、適切な量のログを残す、バックグラウンドタスクの重複を避ける、異常な再接続を確認するといった対策のほうが効果的です。端末の発熱が続く場合は、実際の通信、バックグラウンド更新、接続失敗後の再試行を切り分けてから、プロトコルの処理負荷を比較してください。アプリの負荷変化をコアの問題と誤認しないようにしましょう。

順番に確認して接続失敗の原因を絞る

最初にアプリからクライアントへ接続できているかを確認します。システムプロキシが正しい入口を指しているか、ローカルの待ち受けが起動しているか、アプリがそのプロキシ設定に従うかを調べましょう。次に、ルーティングで意図したアウトバウンドが選ばれているか確認します。直接接続の失敗をノードの障害と誤認しないでください。最後にリモートのアドレスへ接続できるかを確認し、ログをもとに安全性のハンドシェイク、プロキシ認証、接続先への通信を順に調べます。ローカルからリモートへ範囲を狭めていくほうが、ノード設定一式を先に変更するより信頼できる結論を得やすくなります。

ログに設定の解析エラーが出ている場合は、まずコアとの互換性や項目の問題を解決します。安全性のハンドシェイクに失敗したら、サーバー名、時刻、対応する認証情報を確認してください。認証に失敗した場合は、ユーザー情報と接続先の種類を確認します。認証後に接続先へアクセスできない場合は、DNS、ルーティング、サーバーから接続先へ到達できる条件を調べましょう。テストでは一度に1つだけ変更して結果を記録し、元に戻してから次の項目へ進みます。すぐに解決しなくても、何を除外できたかが明確になり、複数の設定を同時に変更し続ける状況を避けられます。

ルーティングの優先順位とドメインの処理方法は、カスタムルーティングルールの構文で確認できます。クライアントが接続済みでもウェブページを開けない場合は、システムプロキシ、ルーティング、DNSの確認リストに沿ってチェックしてください。再インストールや別のプラットフォームへの切り替えが必要な場合は、ダウンロードページから該当する項目を選びましょう。プロトコル選びで目指すのは、内容を把握でき、検証でき、元に戻せる設定です。端末やネットワークの条件を無視した名称の順位ではありません。