V2Rayプロトコルの選び方
とコア互換性ガイド

01 / 接続モデル

プロトコル、通信方式、セキュリティ層の違い

接続は複数のパラメーターで決まる

v2rayNでサーバーの編集画面を開くと、プロトコル種別は接続設定の一部にすぎません。接続先はアドレスとポートで指定し、ユーザーIDやパスワードで認証します。通信方式はデータの運び方を定め、TLSやREALITYが対応するセキュリティハンドシェイクを処理します。どのリクエストをこの接続に流すかはルーティングルールで決まります。各階層を分けて考えれば、どちらもVLESSと表示されているのに、ほかの項目を入れ替えるだけでは使えない理由が分かります。

アプリのリクエストは通常、まずクライアントのローカルインバウンドに入り、コアがルーティングに基づいてアウトバウンドを選びます。アウトバウンドがリモートサーバーに接続し、サーバーが宛先へアクセスします。設定を管理するのはGUIですが、実際に接続を確立するのはコアです。システムプロキシや仮想ネットワークインターフェースは、アプリのリクエストをインバウンドへ送ります。そのため、「クライアントが起動した」「ローカルプロキシのポートが待ち受けている」「リモートとのハンドシェイクが成功した」「目的のページにアクセスできた」はそれぞれ別の段階です。接続アイコンひとつで全部を確認することはできません。

サーバーアドレス、サーバー名、リクエスト先ホスト名

サーバーアドレスには、ドメイン名またはプロバイダー指定のアドレスを設定します。TLSのサーバー名は通常、証明書名の検証に使われ、SNIにも含まれます。HTTP系の通信方式では、Hostやリクエスト先ホスト名を別に指定する場合もあります。これらは同じこともあれば、サーバーの構成によって異なることもあります。項目ごとにサーバー設定を確認し、編集画面にあるすべてのドメイン欄をサーバーアドレスに統一したり、無関係なスクリーンショットから値を転記したりしないでください。

通信方式は、速度を切り替えるための設定ではありません。生のTCP、WebSocket、gRPCなどを使うには、サーバー側にも対応する接続口が必要です。パス、サービス名、中継リバースプロキシの転送ルールも一致していなければなりません。WebSocketのパスはウェブサイトの任意のディレクトリではなく、gRPCのサービス名もメモ欄ではありません。リモート側が特定の通信方式しか受け付けない場合、ローカルの設定を切り替えてもハンドシェイクに失敗するだけで、別の方式に自動的に切り替わることはありません。

元の設定を保存してから、一項目ずつ変更する

接続設定をインポートしたら、まず元のエントリーを残し、複製を作って試すのがおすすめです。メモには変更した項目を記録しましょう。ルーティングルールだけ、またはサーバー名だけというように、一度に一種類の設定を変更します。コア、通信方式、DNSを同時に変えると、接続が復旧しても原因を特定できません。次に問題が起きたとき、また最初から手探りになります。サブスクリプションの更新で編集内容が上書きされる場合があるため、継続して使うローカル設定は、個別に管理するエントリーや設定に保存しましょう。

ログも同じように階層ごとに確認します。名前解決に失敗したらアドレスの解決を確認し、接続拒否ならリモートのポートとサービスの稼働状況を確認します。証明書名が一致しない場合は、時刻とサーバー名を確認します。ハンドシェイク後にアクセスできない場合は、宛先の名前解決とルーティングを調べます。画面に似たエラーが出ても、原因の段階は異なることがあります。ログで最初に確認できるエラーを、実際に操作した時刻と照らし合わせるほうが、設定を手当たり次第に切り替えるより効率的です。

02 / 認証と暗号化の境界

VMessとVLESSの設計上の違い

VMess：プロトコル自体に認証と暗号化の仕組みがある

VMessはProject Vのエコシステムで早くから使われてきたプロキシプロトコルで、ユーザー認証とデータ保護をプロトコル自体に組み込んでいます。クライアントはリモートアドレスだけでなく、一致するユーザーIDを持ち、双方が対応する方式でリクエストを構成する必要があります。現在の一般的な構成ではAEAD認証方式が使われますが、古い設定には追加ID数など、以前の仕様に由来する項目が残っている場合があります。項目名だけで用途を決めつけたり、「互換性のため」と数値を適当に入力したりしないでください。

VMessの認証は時刻に関係するため、システム時刻が大きくずれているとハンドシェイクに失敗することがあります。トラブル対処では、OSの自動時刻同期を有効にし、タイムゾーンの表示と実際の時刻が合っていることを確認してから再接続してください。クライアントのメモを変えたり、ブラウザーを再起動したり、ルーティングを切り替えたりしても、認証時刻の問題は解決しません。古いサブスクリプションで旧式のパラメーターが求められ続ける場合は、古いクライアントで読み込み続けるのではなく、プロバイダーに現在使える形式を確認しましょう。

VMessのセキュリティ設定は、コアの機能とサーバー側の要件に合わせる必要があります。最初は手動でアルゴリズムを固定するより、自動選択を使うのが無難です。実際の処理負荷は、プロセッサーがハードウェアアクセラレーションに対応しているかどうかでも変わります。プロトコル自体にデータ保護機能があっても、外側のTLSが常に不要とは限りません。TLSの接続口やリバースプロキシを使ってサービスを構成する環境もあります。外側のセキュリティ層が必要かどうかは、構成全体で判断してください。

VLESS：プロトコル層を簡素化し、セキュリティを外側に委ねる

VLESSはプロキシプロトコル層を簡素化し、ユーザーの識別に必要な情報を残しながら、通信の安全性を外側の方式で確保する設計です。一般的な設定にある暗号化項目のnoneは、VLESSのプロトコル層で該当するデータ暗号化を行わないことを示します。接続全体が保護されていないという意味ではありません。安全性を判断するには、外側でTLSまたはREALITYが有効か、認証や証明書の設定が正しいかも確認してください。

逆に、ユーザーIDが設定されているからといって、暗号化層の代わりになるわけではありません。サーバー側でTLSが必須なら、トラブル対処のためにローカルでセキュリティ層を無効にしても、通常は接続できません。平文接続を受け付ける別の接続口があったとしても、両方の接続が同じ安全性を持つとは限りません。VLESSを使うには、サーバーから提供された設定一式を理解する必要があります。「項目が少ない」ことだけを追求したり、VMessをそのまま置き換えられるものと考えたりしないでください。

VLESS設定のflowは特定のフロー制御方式を表し、通常のルーティングによる振り分けとは別の概念です。flowによっては特定のコア、通信方式、セキュリティ層との組み合わせが必要で、ある接続の値をすべてのVLESSエントリーにコピーすることはできません。クライアントに入力欄があるのは、その項目を設定できるという意味にすぎません。実際に対応するか、組み合わせが受け入れられるかは、使用するコアとサーバーの双方で決まります。

プロトコル選びはサーバーの対応状況を優先する

VMessのサービスが問題なく使えているなら、名称が新しいという理由だけでVLESSに変更する必要はありません。サーバー側の認証方式が異なるため、ローカルでプロトコル種別を変えても移行にはなりません。移行するには、サーバーが対応する接続口を用意し、新しい接続情報をインポートして、目的のサイトへのアクセスや必要なUDPアプリを確認してから、旧エントリーを置き換えます。動作が確認できている設定を残せば、サーバーとローカル環境のどちらに変化があったのかも判断しやすくなります。

サーバーが両方の完全な設定を提供している場合は、同じ端末、同じネットワーク、近い時間帯で接続状況を比較できます。ルーティング、接続先、テスト内容をそろえてから、接続の安定性、継続的な通信、スリープ復帰後の再接続を確認します。一度の速度測定だけでプロトコルの差と判断しないでください。接続先の回線、サーバー負荷、通信方式、ローカルDNSのほうが、プロトコル層の違いより大きく影響することもあります。

03 / 異なるセキュリティモデル

Trojan、Shadowsocks、REALITY

Trojan：TLSを使ってプロキシ接続を構成

Trojanは一般にTLS接続を基盤とし、保護された通信路の中でパスワード認証とプロキシリクエストを処理します。多層の通信方式を組み合わせる設定より分かりやすい場合がありますが、パスワードだけで設定が完了するわけではありません。サーバーアドレス、ポート、サーバー名、証明書の検証も重要です。証明書のドメイン名と設定したサーバー名が一致しない場合、クライアントは接続を拒否するべきです。検証エラーを無視してよい警告として扱わないでください。

Trojanのハンドシェイク時間は、TLSのネゴシエーション、リモート側の応答、回線品質によって変わります。TLSを使うからといって、必ず接続確立が遅くなるわけではありません。条件によってはセッション再開でハンドシェイクの負荷を減らせますが、効果は実装と接続の使われ方によります。選ぶ際は、リモート側の証明書管理、パスワードの更新、クライアントの対応状況を確認してください。証明書エラーについてはTLSハンドシェイクと証明書エラーのトラブル対処をご覧ください。

Shadowsocks：方式名が互換性を左右する

ShadowsocksはSSとも略され、事前共有鍵で暗号化されたプロキシ通信路を確立する方式です。仕様の進化に伴い、方式ごとに認証、鍵の扱い、データの構成が異なります。旧方式、AEAD方式、新しい方式群は、どれもSSだからといって互換性があるとは限りません。インポート時は、正確な方式名とパスワードの形式を保ってください。特定の長さの鍵が必要な設定を、任意のパスワード欄として扱わないようにしましょう。

SSは設定項目が比較的まとまっているため、暗号化方式とクライアント互換性を理解する例として適しています。ただし、接続情報にプラグインのパラメーターが含まれている場合は、別の互換条件も加わります。コアが基本的なSSに対応していても、GUIクライアントがすべてのプラグインを起動できるとは限らず、サブスクリプション変換でプラグイン設定が保持されるとも限りません。インポートできてもハンドシェイクに失敗する場合は、元の情報にあった追加要件が失われていないか確認し、現在のクライアントで扱えるかを調べてください。

REALITY：独立したプロキシ種別ではなく、セキュリティ層の方式

REALITYはVLESSと組み合わせて使われることが多いものの、VLESSのプロキシ機能をすべて代替するわけではありません。VLESSがプロキシリクエストを定義する層なら、REALITYは特定のセキュリティハンドシェイク方式です。クライアントには通常、サーバー名、公開鍵、短いIDなどの情報が必要で、実装によってはフィンガープリントの項目もあります。これらの値はサーバー側の設定で決まるため、接続先サイトの証明書や別の接続から推測できません。

クライアントにはサーバーが指定した公開鍵を保存し、サーバー側は対応する秘密鍵を保持します。両者の役割を混同しないでください。サブスクリプションに公開鍵が含まれている場合は、そのまま使います。ローカルで鍵を作り直しても、リモート側が受け入れるとは限りません。短いIDもサーバーが許可する値と一致させる必要があり、空欄が有効かどうかは設定次第です。サーバー名も、アドレス欄のドメインに置き換えるのではなく、プロバイダー指定の値を使ってください。

REALITYへの対応は、コアの実装を基準に判断してください。v2rayNとv2flyNGが近いエコシステムに属していても、設定項目が完全に一致するとは限りません。REALITY、特定のflow、対応する通信方式を組み合わせる場合は、まずXray側の実装要件を確認し、GUIクライアントで必要な項目がすべて生成されるか確かめましょう。画面に必要な項目がない場合、同じリンクを何度読み込んでも、コアの不足機能は補えません。

この3つは、同じ基準で単純に順位を付けられる方式ではありません。比較する際は接続設定全体を明示したうえで、メンテナンスの手間、端末への負荷、リモート側での利用可能性を確認してください。設定情報が不十分な場合は、汎用的な最適値を探すより、まず必要な情報をそろえることが重要です。クライアントは不足している項目からサーバー側の設定を推測できません。

04 / 実装と設定

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

接続を実行するのはコア、設定をまとめるのはクライアント

Project Vは、このエコシステムを理解するうえでの背景となるプロジェクトです。V2FlyはV2Ray関連コアの保守と開発を引き継ぎ、Xrayは関連する技術基盤をもとに独自の機能開発を進めています。共通する概念がある一方、実装や設定項目には違いもあります。コアはGUIの別名ではありません。同じクライアントで複数のコアを呼び出せる場合があり、コアが対応する機能でも、GUIのスイッチとしてすべて表示されるとは限りません。

デスクトップではv2rayNを優先しておすすめします。Windows、macOS、Linuxに対応しています。インストール方法はクライアント一覧ページをご覧ください。v2rayNはサーバー一覧、サブスクリプショングループ、システムプロキシ、設定の生成などを管理します。選択できるコアと機能は、実際に提供されるビルドや設定に左右されます。どのインストーラーにも同じコンポーネントが含まれると思い込んだり、互換性のないプログラムのファイル名を変えて別のコアに見せかけたりしないでください。

Androidではv2rayNGを第一候補とします。Xrayコアを使用します。v2flyNGはV2Flyコアを使用し、関連する設定の代替候補になります。操作の考え方が似ていても、設定項目や初期動作はアプリによって異なることがあります。既存サービスの要件を確認してから、使いやすいアプリを選びましょう。REALITYなど特定の機能が必要な場合は、アプリ名が似ているかではなく、該当する実装の要件を確認してください。

設定の構造が似ていても、項目をそのまま流用できるとは限らない

どちらのコアでも、インバウンド、アウトバウンド、ルーティング、DNSといった概念が使われ、基本構造がよく似ている場合があります。しかし、通信方式の名称、受け付ける項目、フロー制御、新機能への対応が一致する保証はありません。JSONの構文チェックを通過しても、括弧や文字列の形式が正しいと分かるだけです。現在のコアがすべての項目を解釈できるとは限らず、起動時や接続時になってからエラーが出ることもあります。

GUIクライアントは、多くの場合、サブスクリプションを読み込み、内部のサーバー情報として保存した後、コア用の設定を生成します。互換性の問題は、リンクの解析、内部データへの拡張項目の保存、コアによる設定の受け入れなど、どの段階でも起こり得ます。まず編集画面の値を確認し、次に起動時のエラーを調べましょう。問題をすべてリモートサービスのせいにしないでください。設定の各セクションについてはJSON設定の構造解説も参考になります。

コアを切り替える前後の確認手順

切り替え前に、プロトコル、通信方式、セキュリティ層、flow、DNS、ルーティングを記録し、動作確認済みのエントリーを残しておきます。切り替え後は、クライアントの設定チェックを実行するか起動を試し、未対応項目、コンポーネント不足、ポートの競合がないことを確認してからリモート接続を試します。ブラウザーの表示だけを判断基準にすると、ローカルでの通信取り込み失敗とリモートプロトコルの非互換を混同しやすくなります。

一般的な接続でも、移行時には初期値の変更を確認してください。ドメインの照合方式、スニッフィング、UDP転送、接続の多重化などは、サーバー編集画面に表示されなくても実際のリクエストに影響します。以前の環境を再現するために、高度な項目をすべて有効にする必要はありません。まず必要最小限の設定で接続を確認し、用途があるものだけを一つずつ戻しましょう。移行後の安定性は、スイッチの数よりも設定の範囲を明確にすることで得られます。

コアの更新とサブスクリプションの更新は、別の問題を解決します。前者はローカルの実装機能を変え、後者はリモート接続情報を変えます。更新後に接続が復旧しても、両者が互いに代わりになるわけではありません。問題が再発した場合は、最後に変更したのがクライアント、コア、サブスクリプションのどれかを記録し、エラーの発生時刻も残してください。トラブル対処の情報を共有する前に、設定から認証情報とサブスクリプションURLを取り除き、必要な項目名とエラーの種類だけを残しましょう。

05 / 性能の見方

通信速度、リソース使用量、電池消費

接続確立と継続的な通信を分けて確認する

「速度」には、接続確立までの時間、最初の応答、継続的なスループット、長時間の安定性が含まれます。名前解決、リモートまでの往復時間、セキュリティハンドシェイク、リモートから宛先への接続は、最初の応答に影響します。継続的な通信では、回線帯域、輻輳制御、サーバー負荷、端末の処理能力がより大きく関わります。短いページをすばやく開ける方式が、大きなファイルの転送でも速いとは限りません。バックグラウンドで接続を維持する場合に電池を節約できるとも限りません。

プロトコル層を簡素化すれば処理負荷を減らせることがありますが、回線距離やパケットロスは解消できません。WebSocketやgRPCなどの通信方式は追加のカプセル化を行いますが、既存のサービス基盤に適合する場合もあります。追加のカプセル化がボトルネックになるかは、実際の環境で確認してください。階層の数だけで性能が悪いと決めつけたり、異なる回線にあるサーバーの結果を厳密なプロトコル比較として扱ったりすることはできません。

暗号化方式の処理負荷は、プロセッサー、システムライブラリ、コアの実装によって変わります。対応するハードウェアアクセラレーションを備えた端末では、特定の暗号化処理を低負荷で行えることがありますが、別の端末では結果が異なります。継続的な高速通信ではCPU負荷が目立つ場合があり、通常のウェブ閲覧ではネットワーク応答待ちが主な要因になることもあります。比較時には端末の発熱とタスクの完了状況も確認し、一時的な負荷をクライアントの異常と誤認しないようにしましょう。

接続の多重化ですべての処理が速くなるわけではない

接続の多重化は、複数の論理リクエストで同じ基盤接続を共有し、接続確立の繰り返しを減らす仕組みです。一方で、共有する接続の混雑や切断の影響を複数のリクエストが同時に受けることもあります。効果はタスクの種類、通信方式、実装によって変わります。短いリクエストが少数の場合と、大量の通信を継続する場合では、適切な設定が異なることがあります。有効にして一部のアプリが止まる場合は、高度なスイッチを追加するのではなく、まず多重化を無効にして比較してください。

UDPを使うタスクは個別に確認しましょう。ウェブサイトを開けても、対応するTCPやHTTPのリクエストが成功したと分かるだけで、音声通話、リアルタイム通信、その他のUDPアプリが正しく転送されるとは限りません。クライアント、プロトコル実装、サーバー、ルーティングがそれぞれ影響する可能性があります。UDPの扱いがTCPと異なるネットワークもあるため、一度の速度測定をすべての互換性確認の代わりにせず、実際に使うアプリで試してください。

モバイルの電池消費は通信の取り込み方と再接続の影響が大きい

Androidの電池消費は、プロトコル名だけでは決まりません。仮想ネットワークインターフェースが取り込む通信の範囲、バックグラウンドアプリの動作、無線LANの電波状況、ハートビート、再接続の頻度などが影響します。モバイル回線と無線LANを切り替えると、古い接続を再確立する必要がある場合があります。バックグラウンドでリクエストが続いていると、再試行によって無線モジュールの稼働時間が長くなることもあります。電池消費の増加をすべてTLSやREALITYのせいにするのは、十分な根拠がないことがほとんどです。

OSのバッテリー最適化には、メリットとデメリットがあります。バックグラウンド動作を厳しく制限するとクライアントが一時停止し、前面に戻した後に再接続を繰り返す場合があります。反対に制限を解除すると、ほかのアプリの継続的な通信もそのまま通過することがあります。まずアプリの電池使用履歴を確認し、画面消灯やネットワーク切り替えと切断時刻が一致するか調べましょう。一度の切断を解消するためにOSの最適化をすべて無効にすると、原因を特定しにくくなり、ほかのアプリの電池消費にも影響する可能性があります。

再現性のある比較には、設定を2つ保存し、同じ端末、同じ接続ネットワーク、同じタスクで交互に試します。充電しながら比較して端末が熱くなる状況は避けましょう。最初のアクセスに成功したか、継続タスクが途切れたか、画面消灯後に復帰できたか、OSの電池使用記録をそれぞれ残します。複数回の観察で同じ傾向が見られた場合に、その結果を参考にしてください。異なる出口や時間帯で得た一度きりの最高値から、プロトコルの順位を決めるのは適切ではありません。

06 / 設定情報の受け渡し

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

サブスクリプションは設定の受け渡し方法であり、プロトコルではない

サブスクリプションURLは通常、接続情報の一覧を返し、クライアントが内容を認識して各エントリーを解析し、グループに登録します。返される内容は、共有リンクの一覧、エンコードされたテキスト、構造化設定などの場合があります。同じURLでも、リクエストの条件によって異なる内容が返されることがあります。そのため、「ブラウザーでサブスクリプションを開けた」と分かるのは応答を取得できたことだけです。現在のクライアントに適した形式とは限らず、含まれるすべてのプロトコルを現在のコアが使えるとも限りません。

共有リンクにもそれぞれの形式があります。VMessリンクではエンコードされた構造化データがよく使われ、VLESS、Trojan、SSでは認証情報やクエリパラメーターを含むURI形式が一般的です。プロバイダーによっては拡張項目が追加されます。リンク内の文字をパーセントエンコードする必要があるほか、メモやクエリパラメーターに日本語などの文字が含まれる場合もあります。末尾が欠ける、改行がURLに混ざる、メッセージアプリで途中までしか送られないといったことが、インポート失敗の原因になります。

Base64はデータのエンコード方式であり、暗号化による保護ではありません。サブスクリプションや共有情報が目で読めなくても、そのまま使える認証情報が含まれている場合があります。サブスクリプションURL全体を公開の掲示板に貼り付けたり、内容の分からない変換サービスに渡したりしないでください。形式を確認する場合は、まずローカルで内容の種類を確認し、認証項目を削除しましょう。メモだけを隠して接続情報を丸ごと残しても、漏えいリスクは下がりません。

インポート後も、項目が正しく読み込まれたか確認する

インポート後はエントリーを開き、プロトコル、アドレス、ポート、ユーザー認証、通信方式、パス、セキュリティ設定を一つずつ確認してください。REALITYなどの組み合わせでは公開鍵と短いIDも確認し、VLESSでは必要なflowが設定されているかを確認します。一覧に一行表示されるのは、解析によってエントリーが作成されたことを示すだけです。拡張パラメーターがすべて保存されたとは限りません。メモが正しくても重要な項目が空なら、接続設定は不完全です。

クライアント間の移行には、両方が明確に対応する共有形式を使い、まず少数のエントリーをインポートしてから残りのグループを移してください。アプリのデータフォルダーをそのままコピーすると、OS固有のパス、ローカルポート、専用設定が含まれることがあり、汎用的な移行方法にはなりません。デスクトップのシステムプロキシ設定がAndroidの通信取り込み設定に自動変換されることもありません。接続情報を移行した後、ローカルでの通信取り込みと権限を改めて確認してください。

サブスクリプションを更新すると、通常はリモート情報をもとにエントリーが再生成または統合されます。手動編集が保持されるかどうかは、クライアントの管理方式によります。メモ、ルーティングとの関連付け、接続項目などを継続して変更する場合は、更新時に上書きされる条件を確認してください。検証用の設定は独立したグループに保存し、元のサブスクリプションにも分かりやすい名前を付けておくと、次回の更新で設定がすべて変わったと誤解するのを防げます。

一覧が空の場合は応答と解析を分けて確認する

更新に失敗したら、まずURLが完全か、有効期限が切れていないか、現在のネットワークから応答を取得できるかを確認します。応答が返っている場合は、接続情報なのか、ログインページなのか、一般的なエラーテキストなのかを調べてください。リクエストが成功することと、内容の解析が成功することは別です。ウェブページの内容を何度エンコードしても、有効なサブスクリプションにはなりません。詳しい手順はサブスクリプション更新失敗・一覧が空のときの確認リストをご覧ください。

サービスによってはUser-Agentやリクエストパラメーターに応じて、サブスクリプションの形式を切り替えます。プロバイダーから明確な案内がある場合だけ設定を変更し、試しに別のクライアントを装うような変更は避けてください。更新に既存のプロキシを使う設定になっているかも確認しましょう。まだ確立していない接続に依存して同じ接続情報を更新しようとすると、処理が循環することがあります。まず少なくとも一つの更新経路を確保し、返される形式を確認してから、各エントリーの互換性を調べましょう。

07 / リクエストの経路

ルーティングルールとDNSの役割分担

ルーティングはアウトバウンドを選ぶもので、ハンドシェイクを修復するものではない

ルーティングによる振り分けでは、ドメイン、アドレス、ポートなどの条件に基づいてアウトバウンドを選びます。処理はコアがリクエストを扱う段階で行われ、リモート認証の代わりにはならず、証明書名の不一致も解決しません。どのサイトにもアクセスできない場合は、まずローカルでの通信取り込みとプロキシのアウトバウンドが使えるか確認します。一部のドメインだけで問題が起きる場合は、該当するルールと名前解決の結果を調べてください。接続の問題と振り分けの問題を分ければ、効果のない設定変更を避けられます。

一般的なルールは記載順に照合されます。上の広い条件に一致すると、後にある細かな条件が適用されないことがあります。デフォルトのアウトバウンドも重要です。一般的な設定では、どのルールにも一致しないリクエストはデフォルト経路に流れる場合があります。実際の動作は生成された設定で確認してください。ルール名だけでなく、参照先のアウトバウンドタグが存在するか、大文字・小文字やスペルが一致しているかも確かめましょう。

次の例は、プライベートアドレスを直接接続するルーティング設定の一部です。単独で動作する完全なクライアント設定ではありません。他のセクションと組み合わせ、directというタグの直結アウトバウンドと、対応するアドレスルールのデータがあることを確認してください。GUIクライアントがすでに同じ設定を生成している場合は、この断片を重ねて追加しないでください。ルーティング設定画面で同じ内容を設定するのがおすすめです。

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

名前解決が行われる場所によって、ルールが参照できる情報が変わる

アプリはドメイン名をプロキシに渡すこともあれば、ローカルで先に名前解決して、アドレスだけを送ることもあります。前者ならコアがドメイン名を直接ルールに照合できますが、後者ではアドレスしか残らない場合があります。システムプロキシ、アプリ独自のプロキシ、仮想ネットワークインターフェースによる通信取り込みでは、リクエスト情報の保持方法が同じとは限りません。そのため、同じドメインルールでも通信の取り込み方によって動作したり、照合されなかったりすることがあります。必ずしもルールの記述ミスとは限りません。

AsIsは通常、ルーティング照合のためにドメイン名を積極的にアドレスへ変換しないことを意味しますが、接続全体でDNSが不要になるわけではありません。他のドメイン照合方式では、アドレスルールとの照合を試みるため、特定の条件下で名前解決が行われることがあります。方式を変えるとルールの結果と名前解決の負荷の両方に影響します。積極的に名前解決するほど正確になる、という単純な話ではありません。ドメインとアドレスのどちらを基準に判断したいのかを明確にし、それに合う動作を選びましょう。

コアのDNS、OSのDNS、ブラウザーの暗号化DNS、リモート側での宛先解決は、それぞれ異なる経路を通る場合があります。一つの設定を変更しても、すべてのリクエストに反映されるとは限りません。ブラウザーと他のアプリで結果が異なる場合は、ブラウザー独自の名前解決が使われていないか、アプリの通信が実際にクライアントを通っているかを確認してください。DNSサーバーが応答しても、アクセス経路が正しいとは限りません。名前解決に成功した後、予期しないアウトバウンドにリクエストが流れる場合もあります。

システムプロキシ、スニッフィング、ローカルネットワークへのアクセス

システムプロキシの自動設定が影響するのは、通常、システム設定に従うアプリです。すべての通信が取り込まれるわけではありません。グローバルプロキシ、LANを迂回する設定、直結などのモード名は、クライアントが用意したプリセットの場合もあります。実際にどのルールが生成されるかを確認してください。LAN内のプリンター、共有フォルダー、ローカル管理画面を使う場合は、まずプライベートアドレスの扱いを確認し、必要に応じて内部ドメインのルールを追加しましょう。

トラフィックスニッフィングは、リクエストからドメイン名などを取り出してルーティングの手掛かりにできますが、すべてのプロトコルを識別できるわけではなく、アプリ層の情報を完全に置き換えるものでもありません。宛先アドレスの扱いに影響する設定もあるため、用途に応じて有効にしてください。特定のサイトを調べる場合は、アプリがドメインとアドレスのどちらを送ったか、どのルールに一致したか、どのアウトバウンドを通ったかを記録すると、DNSとルーティングのモードを同時に変えるより原因を説明しやすくなります。

IPv6も通信経路の確認に含めてください。OSがアドレスレコードを取得した後、実際の接続で別のアドレスファミリーが選ばれることがあります。一方の経路にしかルールや対応がないと、断続的にしか接続できないように見える場合があります。特定のアドレスファミリーを無効にすることを固定の解決策にせず、ローカルネットワーク、サーバー、接続先が選んだ経路に対応しているかを確認しましょう。画面上の設定手順はDNS設定ガイドをご覧ください。

08 / 選択と動作確認

用途に合わせたクライアントとプロトコルの選び方

既存のサービスは設定一式を維持し、まず互換性を確認する

安定して使えているサービスがある場合は、まず提供されたプロトコル設定一式を維持し、別の方式への変更を急がないのが基本です。デスクトップではv2rayNを優先し、OSとプロセッサーのアーキテクチャに合ったインストーラーを選びます。WindowsのDesktop版と従来のWPF画面の選択については、Windowsのインストールと設定ガイドをご覧ください。画面の違いだけでリモートプロトコルの安全性は判断できません。実際の機能は、使用するコアと生成される設定によって決まります。

Androidではまずv2rayNGを検討します。既存サービスがV2Flyの特定機能を前提に構成されている場合は、v2flyNGも候補にしてください。初回の確認では、接続情報がそろったエントリーを一つだけインポートして基本的なアクセスを試し、その後で必要な振り分けや通信の取り込み範囲を設定します。サブスクリプション、ルール、バックグラウンド設定を最初からすべて移行すると、失敗の原因が情報の解析、コアの互換性、OSの権限のどれなのか分かりにくくなります。

複数の接続先を選べる場合は、制約を整理してから比較する

サーバーがVMess、VLESS、Trojan、SSを複数提供している場合は、まず満たすべき条件を書き出します。必要なコアに端末が対応しているか、UDPが必要か、特定の通信方式の接続口を使うか、証明書や鍵を継続して管理できるかを確認してください。条件を満たすものの中から、接続の安定性や実際の使い勝手を比較します。REALITYはセキュリティ層を含む設定一式の一部として評価しましょう。プロトコルのプルダウンから、すべての接続を置き換えられる単独の選択肢を探すものではありません。

複数の端末で使う場合は、すべてを最低共通の設定にそろえる必要があると考えないでください。端末ごとに互換性のある接続情報をサービスから提供してもらえる場合があります。デスクトップ用の新しい項目を別のコアにそのままコピーすると、互換性が失われることがあります。名称を統一するために必要な項目を削除すれば、安全性の条件を損なう可能性もあります。そろえるべきなのは利用目的とルールの意図であり、各編集画面の文字列ではありません。

モバイルとデスクトップでは長時間利用時の注意点が異なる

デスクトップで長時間利用する場合は、スリープからの復帰、ネットワークの切り替え、ポートの競合、アプリがシステムプロキシに従うかを確認してください。Androidではさらに、バックグラウンド制限、通信を取り込むアプリの範囲、電池使用履歴も確認します。macOSの初回インストールでOSによるブロックや権限の確認が表示される場合は、インストールとネットワーク権限の対処をご覧ください。プラットフォームの権限問題はOS側で解決する必要があり、ユーザーIDやプロトコル種別を変えても修復できません。

短時間のウェブ閲覧で使う方式を選ぶ場合は、接続確立と最初の応答に注目します。継続的な通信では、タスクの間に途切れや再接続が起きるか、端末にどの程度の負荷がかかるかを確認してください。リアルタイムアプリではUDPの経路も個別に検証します。用途によって重視する点が異なるため、このガイドではネットワーク条件を無視した固定の速度順位は示しません。テスト条件が不明なおすすめ表示より、説明できて再現できる結果のほうが、長期的に役立ちます。

失敗したら段階をさかのぼり、設定をやみくもに変えない

まったく起動できない場合は、設定チェック、実行環境、ローカルポートを確認します。起動するもののハンドシェイクに失敗する場合は、リモートアドレス、認証、通信方式、セキュリティ層を調べます。ハンドシェイクが成功しても一部のアプリで失敗する場合は、通信の取り込み方式、UDP、DNS、ルーティングを確認してください。サブスクリプション更新後だけ発生するなら、更新前後の重要項目を比較します。画面消灯後だけ発生するなら、バックグラウンド制限と再接続ログを優先して確認しましょう。

トラブル対処では、同じ端末、同じネットワーク、同じ宛先、同じ接続のうち、いくつかの条件を固定して、一度に一つの変数だけを変更してください。ログは一回の明確な操作に合わせて収集し、過去のエラーと現在の接続成功を混ぜないようにします。エラーの種類や、機密情報を削除した項目の構成は共有できますが、認証情報全体を公開しないでください。こうすることで、たまたま接続が戻っただけではなく、次回も再現できる判断につながります。

最終的に使う設定では、次の4点を説明できるようにしておきましょう。どのプロトコルを組み合わせたか、現在のコアが対応する理由、どのアプリの通信がクライアントを通るか、問題が起きた際にどこで状況を確認できるか。初回の設定はクイックスタートガイドに沿って進めてください。このページではその手順の背景にある制約を説明し、設定変更が必要なときに根拠をもって選べるようにします。