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

クライアント、コア、サーバーの役割

GUIクライアントはサーバー一覧の表示、共有リンクの読み込み、サブスクリプションの管理、設定の保存を担います。コアはローカルでの待ち受け、ルーティングルールの適用、リモートへの接続、トラフィックの転送を行います。リモートサーバーは、定められたプロトコルに従って接続を受け付けます。v2rayN に編集項目が表示されていても、選択中のコアがその項目に対応しているとは限りません。リンクをインポートできても、サーバーがすべてのパラメーターを受け入れるとは限りません。互換性を調べる際は、クライアントが設定項目をどう解釈するか、コアがどのような設定を生成するか、サーバーがどの組み合わせを許可しているかを確認しましょう。画面上のプロトコル名だけでは判断できません。

ローカルアプリは通常、まずシステムプロキシまたは仮想ネットワークインターフェースに接続し、その後コアが通信をリモートへ転送します。ブラウザーの接続に失敗する原因は、ローカルの入口、名前解決、ルート選択、リモート接続、接続先サイトのいずれにもあり得ます。プロトコルはその一段階にすぎません。失敗のすべてを VMess や VLESS のせいにすると、ポートの競合、システムプロキシの未適用、ルールの誤判定といった直接的な原因を見落とします。初回テストではアプリと接続先を1つずつに固定し、リクエストがクライアントに届くことを確認してから、どの階層で失敗するかを見ます。ノードの切り替え、DNSの変更、ルーティングの調整を同時に行わないでください。

プロキシプロトコル、トランスポート、安全層

VMess、VLESS、Trojan、Shadowsocks は、プロキシの両端でユーザーを識別し、接続先アドレスを指定してデータをカプセル化する方法を定めています。TCP、WebSocket、gRPC などは通信を運ぶトランスポート方式です。TLS と REALITY は外側の安全機構に関係します。VLESS と REALITY は同じ階層のプロトコルではないため、単純に並べて比較できません。1つの接続で組み合わせて使うこともできます。同様に、WebSocket を見ただけで VMess の使用を判断したり、TLS を見ただけで Trojan と判断したりすることはできません。選ぶ際は異なる階層の名称を速度ランキングに並べるのではなく、接続全体の組み合わせを比較しましょう。

接続先アドレス、サーバー名、アプリのアクセス先

接続先アドレスは、クライアントが最初にネットワーク接続する相手を指定します。サーバー名は通常、安全なハンドシェイクや認証に使われます。アプリのアクセス先は、ブラウザーが本来開こうとしているサイトです。3つに同じドメイン名が使われる場合もありますが、役割は異なります。接続先アドレスを変更する際にサーバー名まで置き換えないようにしましょう。WebSocket の Host を変更しても、アプリのアクセス先が変わるわけではありません。サーバー側でリバースプロキシを使っている場合、パス、Host、サーバー名が連携して転送先を決めることがあります。いずれかの値が抜けると、接続先には到達できても適切なサービスに届かないことがあります。単純なアカウントエラーとは限りません。

設定を確認するときは、まず既存の値を階層ごとに記録します。プロトコル、トランスポート、外側の安全機構の有無、認証情報の入手元を整理してください。よく分からない項目は変更せず、インポート時の元データも保存します。共有リンクの短い項目名と画面上の日本語表記は、一対一で対応するとは限りません。名称が似ているだけで同じものと判断しないでください。最も確実な根拠は、サーバーから提供された完全な設定と、コアのドキュメントに記載された各項目の意味です。以降の章でもこの階層分けを使って、設計上の違いとクライアントでの確認手順を説明します。

VMess：認証とデータ保護を組み合わせた設計

VMess は Project V のプロトコル体系に属し、ユーザー認証、リクエスト情報、データ保護をプロトコル設計に取り入れています。一般的な設定では UUID でユーザーを識別し、暗号化方式も指定します。比較的新しい実装では AEAD 認証方式が使われます。古い解説にある追加の識別子や旧式の認証設定を、汎用的な推奨値として扱わないでください。インポート後は、過去の画面例に合わせて古い項目へ戻すのではなく、現在の形式に沿ってクライアントに設定を生成させましょう。認証に時刻条件が関わる場合、端末の時計が大きくずれていると、ネットワークに到達できても認証に失敗することがあります。端末の時刻も正確に保ってください。

VMess を使うかどうかは、主に既存のサーバーとクライアントの対応状況で決まります。VMess サーバーが安定して使えているなら、別の名称のほうが新しいという理由だけで変更する必要はありません。確認すべきなのは、トランスポート、ユーザー識別情報、暗号化設定、外側の安全機構が一致しているかどうかです。VMess は複数のトランスポートと組み合わせられるため、実際の接続負荷も組み合わせによって変わります。多重にカプセル化された VMess 接続と、別の経路の直接接続を単純比較して、差をすべてプロトコルの違いと考えることはできません。比較する場合は、少なくともサーバー、接続先、ネットワーク、テスト方法をそろえましょう。

Trojan：TLSを利用するプロキシ認証

Trojan は TLS 接続の中でプロキシリクエストを扱い、プロトコル独自の認証情報でユーザーを識別する設計です。UUIDを共通のアカウント形式として使うわけではなく、クライアントでは通常パスワードを設定します。利用時はリモートアドレスとサーバー名を区別し、証明書の名前が一致しているか確認してください。TLS接続が確立しても、プロキシ認証が成功したとは限りません。逆に、パスワードが正しくても証明書名の不一致は解消しません。ログではこの2つの段階を分けて確認しましょう。証明書の検証を無効にすることを通常の設定手順にしないでください。リモートの身元をクライアントが確認する能力が弱まります。

Trojan は設定項目が比較的まとまっているとされますが、実際の運用の複雑さは証明書、ドメイン、サーバー構成にも左右されます。接続の再利用、トランスポート拡張、外部転送の設定が加われば、さらに条件が増えます。クライアントが Trojan に対応していても、似た名称の拡張構成すべてに対応しているとは限りません。設定を移行するときは、サーバーで使っている具体的な実装とトランスポートを確認し、クライアントでパスワードとサーバー名がそのまま保持されているか確かめましょう。パスワードにURLエンコードが必要な文字が含まれている場合もあり、共有リンクを手入力すると特に間違いやすい項目です。

Shadowsocks：暗号化方式と鍵を正しく組み合わせる

Shadowsocks の設定は比較的コンパクトで、サーバーアドレス、ポート、暗号化方式、パスワードが主な項目です。SS はプロトコルの総称であり、具体的な暗号化方式の代わりにはなりません。従来の AEAD 方式と新しい Shadowsocks 2022 方式では、必要な鍵や実装の対応状況が異なります。後者では、任意の長さの一般的なパスワードをそのまま使えるとは限りません。クライアントが SS リンクを認識できても、リンクに指定されたすべての方式をコアがサポートするとは限りません。インポートはできるのに接続エラーが出る場合は、サーバーアドレスを何度も変更する前に、方式名と鍵の形式を確認してください。

これら3種類のプロトコルは、それぞれ認証と転送の仕組みを備えています。設定項目の数だけで安全性やリソース消費を判断することはできません。設定が短いから省電力とは限らず、階層が多いから必ず遅くなるわけでもありません。既存のサーバーを使う場合は、必要なパラメーターがそろい、クライアントの対応が明確な組み合わせを優先しましょう。複数の端末を運用する場合は、すべての端末で同じ設定形式を使えるかも重要です。4種類のプロキシプロトコルをさらに比較するには、VMess・VLESS・Trojan・Shadowsocksの選び方をご覧ください。次の章では、VLESSの安全性に関する考え方を解説します。

VLESSだけでは暗号化接続にならない

VLESS はプロキシプロトコル自体をシンプルにし、一部の役割を外側の仕組みに委ねる設計です。ユーザー識別には通常 UUID を使いますが、VMess の暗号化設定をそのまま適用することはできません。一般的な VLESS 設定にある encryption: none は、プロトコル層で追加のデータ暗号化方式を選択しないという意味です。接続全体が保護されていないことを示すものではありません。接続全体が保護されるかどうかは、トランスポート設定で TLS または REALITY が使われているか確認してください。逆に、外側に安全機構がない設定なら、VLESSという名称だけを根拠に暗号化されていると判断することはできません。

そのため、VLESSを説明するときは、VLESS と TLS、または VLESS と REALITY のように、トランスポート方式も含めた組み合わせを明記しましょう。組み合わせごとにサーバー要件、ハンドシェイク項目、コアの対応範囲が異なります。設定の flow も、汎用的な高速化スイッチではありません。特定のフロー制御方式を示す項目であり、サーバーやトランスポートの条件と一致させる必要があります。xtls-rprx-vision を任意に入力しても、その組み合わせに対応していないサーバーで機能が使えるようにはなりません。元のリンクにこの項目がない場合、解説画像だけを見て追加しないでください。

REALITYでクライアントが使う検証情報

REALITY は安全なトランスポート機構であり、VLESSに代わるユーザーアカウント用プロトコルではありません。一般的な Xray クライアント設定では、サーバー名、公開鍵に相当する検証情報、shortId、フィンガープリントなどを確認します。画面上の項目名はクライアントやコアの設定モデルによって異なり、共有リンクでは略称が使われることもあります。項目名だけでなく、インポート後にどのような意味として扱われているかを確認しましょう。クライアントがリモートを検証するための情報と、サーバーに保存されている秘密情報は役割が異なります。サーバー側の秘密情報を通常のクライアント設定にコピーしないでください。

shortId には通常、16進数表記や文字数の制約があります。空欄が許されるかどうかはサーバー側の設定によります。サーバー名は許可された範囲内のものである必要があり、任意の使い慣れたドメインに置き換えることはできません。フィンガープリント設定はハンドシェイクの動作に影響し、コアの実装状況にも左右されます。端末の識別情報を変更する汎用ツールではありません。元の設定では接続できるのに手作業で再構成すると失敗する場合は、これらの項目を1つずつ比較し、コピー時に空白や全角文字が入っていないか、クエリーパラメーターが抜けていないか確認します。複数の最適化設定を試すより、まず元の値に戻すほうが原因を特定しやすくなります。

互換性エラーを切り分ける順序

設定を保存した直後にコアが終了する場合は、未対応の項目、パラメーター構造の誤り、または無効な組み合わせをまず疑います。コアは起動するもののリモートとのハンドシェイクに失敗する場合は、アドレス、ポート、サーバー名、検証情報を確認します。ハンドシェイクに成功してもアプリからアクセスできない場合は、ルーティング、DNS、接続先を調べます。この順序なら、ローカルでの設定解析とネットワークのハンドシェイクを分けて考えられます。クライアントのログに安全層の名称が表示されても、その段階を処理していることが分かるだけです。その1行だけでユーザー認証やアプリデータの転送まで完了したと判断できません。

新しいデスクトップ設定を作る場合は、必要な機能に対応するコアと v2rayN の組み合わせが基本的な確認先です。Android で v2rayNG を使う場合も、実際に使用しているコアの対応状況を確認してください。Xray 向けの VLESS と REALITY の設定を別のコア系列に渡して、完全互換を期待してはいけません。現在使える設定がある場合は、クライアントがインポート時に項目を失っていないかを先に確認し、その後でクライアントの変更を検討しましょう。コアの対応範囲は第5章、共有リンクで項目を維持する方法は第6章で説明します。両方が、端末間でこの組み合わせを正しく移行できるかを左右します。

接続確立、応答時間、スループット

接続性能には、少なくとも3つの異なる指標があります。新しい接続の確立にかかる時間、リクエスト後に応答を受け取るまでの時間、継続転送時のスループットです。それぞれ影響する要因が異なります。名前解決、TCP接続、安全なハンドシェイク、プロキシ認証は初回応答に影響します。往復時間、パケットロス、輻輳制御、サーバー負荷は継続転送に影響します。アプリケーション層の項目が少ないプロトコルでも、回線状況が悪ければ速いとは限りません。速度測定の結果を1つ見ただけでは、プロトコルの実装、サーバーの場所、ネットワーク状態の影響を切り分けられません。

Tcping などのテストで分かるのは、通常、特定の TCP 接続先に接続できるかどうかです。プロキシ認証や接続先へのアクセスを最後まで確認するものではありません。実接続テストは、アプリがプロキシ経由でテスト先にアクセスする状況に近いものの、テスト先やクライアントの実装にも左右されます。両者は同じ指標ではありません。入口に接続できても実接続に失敗する場合、認証、安全なハンドシェイク、接続先へのアクセス、DNSなどが原因かもしれません。すぐに回線障害と決めつけないでください。初回接続と実接続テストのガイドを参考に、テスト先を固定して繰り返し確認しましょう。

カプセル化、接続の再利用、リソース消費

WebSocket や gRPC などのトランスポートには、それぞれハンドシェイクやカプセル化の仕組みがあります。また、既存のサーバー構成に合わせて利用できる利点もあります。カプセル化が増えれば処理する構造も増えますが、実際に負荷が目立つかはリクエストサイズ、接続の継続時間、実装効率によって異なります。短いリクエストではデータ処理より接続確立が重要な場合があり、長時間のダウンロードではスループットやパケットロスのほうが影響することがあります。あらゆるネットワークに当てはまる固定の速度順位を示すことはできません。設定項目が少ないから処理コストも低いと考えるのも適切ではありません。

接続の再利用は、接続を繰り返し確立するコストを減らせますが、すべての用途で改善するとは限りません。複数のリクエストが同じ基盤接続を共有すると、その接続の状態が各リクエストに影響します。回線が不安定な場合や特定のストリームが多くのリソースを使う場合、ほかのリクエストにも影響が及ぶ可能性があります。コアとサーバーの対応状況、用途を考慮し、まず初期状態を記録してから有効化を比較しましょう。CPU使用率は、暗号化方式、ハードウェア命令、通信量、ログレベルにも左右されます。プロセスの使用率が短時間上がっただけで、その端末にプロトコルが適していないとは言えません。

Androidの電池消費に影響する要因

モバイル端末の電池は、暗号化処理だけでなく、無線ネットワークの稼働時間、バックグラウンドでの起動、接続の再試行、アプリの通信によっても消費されます。電波が弱い環境で接続を繰り返すと、通常のデータ処理以上に電池を消費する場合があります。端末全体の通信をプロキシ経由にしていると、通常はプロキシを使わないアプリも処理対象になることがあります。対象通信が広がった場合、電池消費の差をすべてプロトコルのせいにはできません。システムのバックグラウンド制限でクライアントが停止すると、接続の復旧と再認証が繰り返され、待機中の電池消費、通知の遅延、ロック解除後の一斉再接続として現れることがあります。

意味のある比較を行うには、端末、ネットワーク種別、使用するアプリ、利用時間をそろえ、画面使用中の通信とバックグラウンド待機を分けて考えます。連続した速度測定や頻繁なログ出力を止め、接続の再試行が続いていないことを確認してから設定を比較してください。システムの電池使用状況を見る際は、画面、モバイルネットワーク、対象アプリの動作も確認します。プロトコルだけでなくサーバー、トランスポート、プロキシの対象範囲も同時に変えた場合、分かるのは2つの構成全体の差です。プロトコル単体の消費電力とは言えません。v2rayNG と v2flyNG を比較する際も同じ原則に従ってください。

実際には、まず設定ミス、不要な再試行、必要のない全通信のプロキシ化を解消してから、トランスポートの調整を検討しましょう。Web閲覧やメッセージの利用では、正しく設定され安定して接続できる既存構成のほうが、頻繁に切り替えるより評価しやすいことが多いです。大容量ファイルの転送では、継続的なスループットと失敗時の復旧を別に確認してください。再現可能なテスト条件がない場合、1回の画面表示を根拠にプロトコルを変更するより、現在使えている構成を維持するほうが妥当です。具体的なエラーを切り分けるには、よくある質問を参考に、障害が起きる段階ごとに確認しましょう。

Project V エコシステムにおける役割

このエコシステムを理解する出発点は Project V です。V2Ray の設定モデルとプロトコル設計は、後続ツールの基盤となりました。V2Fly は V2Ray 関連の実装を継続して保守し、Xray は関連するコードと技術基盤から発展した、独自に進化するコアプロジェクトです。両者にはインバウンド、アウトバウンド、ルーティング、DNSなど共通する概念が数多くありますが、機能や設定項目のモデルはそれぞれ変化します。Xray を V2Fly の単なるバージョンアップ版とみなすことも、2つを自由に置き換えられる同一のプログラムと考えることもできません。実際の互換性は機能ごとに判断する必要があります。

クライアントはコアとは別の階層にあります。v2rayN はデスクトップ向けのGUI管理機能を提供し、実際のプロトコル処理は使用中のコアが担います。v2rayNG は一般に Xray の機能を利用する構成です。v2flyNG は Android で V2Fly コアを使う選択肢です。どのクライアントを選ぶかは、画面の好みだけでなくプラットフォームと必要な機能で決まります。デスクトップでは v2rayN から検討を始め、Android で Xray 固有の機能が必要なら v2rayNG を確認し、既存の V2Fly 設定を使う場合は v2flyNG との互換性を調べましょう。

共通する設定の骨格と独自機能

inbounds はローカルでトラフィックを受け取る方法、outbounds は外部へ接続する方法、routing はリクエストをどのアウトバウンドに渡すかを定義します。こうした概念が共通していても、配下のすべての項目が一致するわけではありません。トランスポート設定、安全機構、フロー制御、DNSの挙動は特に確認が必要です。外側の JSON が見慣れた形式だからといって、REALITY や関連する Xray の接続機能を V2Fly にそのまま移行することはできません。別のコアでは項目を解析できない場合や、名称が似ていても動作が異なる設定がある場合があります。

ルーティング用のデータも、単に導入すれば同じように動作するわけではありません。ドメイン分類タグやIP分類タグは、実際に読み込まれるリソースの内容に依存します。ファイルがない、またはタグを利用できない場合、ルールによって起動に失敗したり、期待どおりに動作しなかったりすることがあります。移行時は JSON だけでなく、実行環境にあるリソースとパスも確認してください。相対パスの基準は、クライアントがコアを起動する際の作業ディレクトリによって変わることがあるため、別の端末で使っていた絶対パスをそのまま残すことはできません。GUIクライアントで管理するリソースは、上書き後にどのファイルが読み込まれているか分からなくなるのを避けるため、クライアントに用意された更新・設定画面を使いましょう。

どの階層を更新すべきか判断する

画面でリンクの項目を認識できない場合は、クライアントのインポート対応を確認します。設定を正しく生成できてもコアが未対応の項目を報告する場合は、コアの機能を確認します。コアは正常に動作しているのにルールのタグが見つからない場合は、リソースファイルを調べます。これらはそれぞれ異なる問題です。GUIだけ更新してもコアが変わるとは限らず、コアを入れ替えてもクライアントが項目を失う問題が解決するとは限りません。更新前に元のサブスクリプションと使える設定を保存し、更新後は既知の設定を1つ使って確認してから複雑なルールを戻してください。コア系列の変更、サブスクリプションの書き換え、新しいルール一式のインポートを一度に行わないようにしましょう。

オープンソースであることは、コードを閲覧し、該当するライセンスのもとで利用できることを意味します。2つのプロジェクトの設定形式が永遠に一致し続けるという意味ではありません。必要な機能、クライアントの対応状況、保守方法を基準に選び、どの場面でも特定の系列だけが正解だと考えないでください。設定の各項目を理解するには、Xray設定ファイルの構造を解説をご覧ください。別の端末用インストーラーを選ぶ場合は、ダウンロードページでOSとプロセッサーに合ったものを選びます。コアの仕組みとインストーラーのアーキテクチャを混同しないでください。

単一の共有リンクとリンク一覧

共有リンクはサーバー設定を1つ記述するもので、一般的なプレフィックスには vmess://、vless://、trojan://、ss:// があります。内部形式はすべて同じではありません。一般的な VMess の共有形式では JSON の内容をエンコードします。一方、VLESS と Trojan は通常、URLのユーザー情報、アドレス、クエリーパラメーターで設定を表現します。Shadowsocks にも複数の歴史的な表現形式があります。クライアントはインポート時にプレフィックスからプロトコルを判別し、それぞれに合った方法で解析します。ある形式のデコード方法を別のリンクにそのまま適用することはできません。

サブスクリプションURLは設定一覧を取得するための入口であり、特定サーバーのアドレスではありません。一般には、複数行の共有リンク、または共有リンク一覧を Base64 でエンコードした内容が返されます。Base64 はエンコード方式であり、暗号化やプロキシプロトコルではありません。デコードできても、得られたテキストがクライアントの対応形式かどうかを確認する必要があります。改行、文字コード、URLエンコードも解析に影響します。サブスクリプションをコピーする際は、提供元の完全なURLを使い、ページタイトル、説明文、見えない空白、メールソフトが挿入した改行が混ざらないようにしてください。

ネイティブ JSON とクライアント管理設定

Xray のネイティブ JSON は、複数のインバウンドやアウトバウンド、ルーティング、DNSを含む動作全体を記述できます。共有リンクを別の形式で表したものではありません。単一の共有リンクが扱うのは通常、リモート接続に必要な主な項目だけで、ローカルの待ち受け設定や複雑なルーティングは含まれません。そのため、ネイティブ設定をリンクに変換すると全体の動作が失われることがあります。リンクをインポートして生成された設定には、クライアント独自のデフォルトのインバウンドやルーティングが加わる場合があります。どちらも接続できるとしても、処理対象のトラフィック、DNSの経路、ルールの優先順位は異なる可能性があります。

クライアント独自の設定ファイルには、グループ、表示名、ウィンドウ状態、速度測定の設定など、コア共通の形式に含まれない情報が入っている場合もあります。移行時は、リモート接続の設定だけを残すのか、クライアント環境全体を残すのかを先に決めましょう。サーバー1つを別の端末へ移すだけなら、クライアントが認識できる共有形式を使うのが手軽です。複雑なルールを維持するには、ルーティングやDNSも別途記録する必要があります。共有リンクが自動的に引き継ぐことはありません。カスタム設定一式をインポートする際は、クライアントがシステムプロキシやポート設定を引き続き管理するか確認し、画面上のスイッチがカスタム設定をすべて上書きすると思い込まないようにしてください。

形式変換と更新でできることの限界

変換でできるのは既存情報の並べ替えであり、サーバー名、公開鍵に相当する情報、shortId、トランスポートのパスなど、元データにない内容を補うことはできません。変換ツールが有効な JSON を出力しても、項目の意味が正しいとは限らず、変換先のコアがその組み合わせに対応する保証もありません。新しいトランスポート項目を古いパーサーに渡すと、未知のクエリーパラメーターが無視されることがあります。その場合、インポート後の画面には正常なサーバー項目が表示されることもあります。項目名が一覧に出たことだけで互換性が確認できたとせず、元のパラメーターとインポート後の詳細を比較しましょう。

サブスクリプションを更新すると、管理対象の項目が再生成され、手動での変更が次回更新時に上書きされることがあります。テストする場合は、元のサブスクリプショングループを変更せず、設定をコピーして独立した項目として試してください。コピーやグループ分けの方法は、クライアントの画面に従います。更新後に同じ名前の項目が複数表示されても、同じ接続先とは限りません。アドレス、トランスポート、ユーザー設定が異なる場合があります。削除する前に重要な項目を比較してください。グループが突然空になった場合は、項目を削除・再作成したり全設定を消去したりする前に、取得結果と形式を確認しましょう。

問題を調べる順序は、サブスクリプションのURLにアクセスできるか、返された内容が想定した形式か、クライアントがプロトコルを認識するか、重要な項目が保持されているか、最後にコアが接続できるか、です。形式の問題とリモート認証の問題は分けて記録してください。各形式の構造や相互変換の制約については、Base64サブスクリプション、ネイティブ JSON、共有リンクの違いをご覧ください。このページにオンライン変換フォームはありません。機密性の高い設定は信頼できるローカルツールやクライアントで扱い、形式変換のために情報が漏れる範囲を広げないようにしましょう。

システムプロキシとTUNの適用範囲

システムプロキシはアプリにプロキシの入口を提供します。設定に従って利用するのは、関連するシステム設定を参照するアプリに限られます。独自のネットワークスタックや個別のプロキシ設定を持つプログラムもあるため、ブラウザーがアクセスできても、すべてのプログラムが同じ経路を通るとは限りません。TUN モードは仮想ネットワークインターフェースで通信を受け取るため、より広い範囲を対象にできますが、ルーティング、権限、DNSなどの条件も加わります。TUN はプロキシプロトコルを変更する機能ではなく、リモート側の設定ミスを自動で修正するものでもありません。プロトコル認証に失敗している場合、TUN を有効にしてもクライアントに通信が入る経路が変わるだけで、サーバーが誤ったアカウントを受け入れることはありません。

v2rayN の「システムプロキシを自動設定」と「Tun モードを有効にする」は、用途に応じて選んでください。すべての通信制御方式を常に同時に有効にする必要はありません。まずシステム設定に従うアプリでシステムプロキシを確認し、必要に応じて TUN を試すと、変数を減らせます。Windows、macOS、Linux では、権限、仮想インターフェース、システムのネットワーク設定が異なります。具体的な案内はクライアントとOSの表示に従ってください。Android クライアントはシステムの仮想ネットワーク機能を使うため、必要な権限とバックグラウンド動作を確認し、同種の通信制御アプリが同じ入口を取り合わないようにしましょう。

ルールの順序、アウトバウンドタグ、名前解決

ルーティングルールは通常、記述順に評価され、最初に一致したルールがアウトバウンドを決定します。詳細なルールを広範なルールより前に置き、アウトバウンドタグが実際の定義と一致しているか確認してください。domainStrategy はルーティング判定でドメインとIPの関係をどう扱うかを指定する項目であり、ブラウザーのDNS処理全体を制御するものではありません。IPIfNonMatch は、ドメインルールに一致しない場合、名前解決で得たIPアドレスを使ってルールに一致するか続けて確認することを表します。地理的な振り分けルールを自動で作るものではなく、すべてのドメインを意図どおりに分類する保証もありません。実際の挙動は既存ルールと名前解決の結果によって変わります。

以下は Xray のネイティブ設定で routing フィールドに入れられる JSON オブジェクトの一部であり、実行設定全体ではありません。ローカルのループバックアドレスを direct というアウトバウンドに、それ以外の TCP と UDP 通信を proxy というアウトバウンドに送ります。使用前に両方のアウトバウンドを定義し、プロキシ側が実際のリクエストのネットワーク種別に対応していることを確認してください。この例はルールの順序とタグだけを示すものです。LANの例外、DNS方針、仮想インターフェースのループバック防止設定を含む完全な構成の代わりにはなりません。また、クライアントが自動生成したルーティング全体を置き換えないでください。

{
  "domainStrategy": "AsIs",
  "rules": [
    {
      "type": "field",
      "ip": ["127.0.0.0/8", "::1/128"],
      "outboundTag": "direct"
    },
    {
      "type": "field",
      "network": "tcp,udp",
      "outboundTag": "proxy"
    }
  ]
}

DNS、UDP、失敗の切り分け

名前解決はアプリ、OS、コアのいずれかが行う場合があり、経路によってルーティングで参照できる情報が変わります。アプリがすでにIPアドレスへ解決している場合、コアが元のドメインに基づくルールをそのまま使えるとは限りません。トラフィックのスニッフィングにも対応範囲や制約があり、必ずドメイン名を復元できる仕組みではありません。DNSを設定するときは、どこが問い合わせを行い、どのアウトバウンドを通り、その結果を誰が使うのかを明確にしてください。DNS問い合わせがプロキシに依存する一方で、プロキシ接続先のアドレス解決にも同じプロキシが必要になると、循環依存が起こることがあります。リモート接続先には、確実に使える名前解決経路を確保しましょう。

UDPを利用するには、ローカルの入口、コア、プロトコル実装、リモートサーバーがすべて対応している必要があります。Webサイトは見られるのにリアルタイムアプリが動かない場合、UDP転送の条件が整っていないか、ルーティングの対象外になっている可能性があります。プロトコル名だけで利用可否を判断できません。テストでは、まず対象アプリの通信がクライアントに届いているか確認し、次に使用中のネットワーク種別と適用されるアウトバウンドを確認します。リモート接続は安定していて一部のドメインだけ失敗する場合は、ルールとDNSを優先して調べます。すべてのアプリの通信がコアに届かない場合は、まずローカルの入口を確認してください。ルール構文について詳しくは、カスタムルーティングルールとマッチングの優先順位をご覧ください。

デスクトップと Android の選び方

デスクトップではまず v2rayN を選び、Windows、macOS、Linux に合ったインストーラーを確認します。Windows の Desktop 版と従来の WPF 画面は、クライアントの形態の違いであり、プロキシプロトコルの違いではありません。macOS では Apple Silicon と Intel を区別し、Linux ではプロセッサーとパッケージ形式を合わせる必要があります。これらはプログラムを正しくインストールして実行するための条件で、リモートのプロトコルが使えるかどうかを決めるものではありません。インストール後はコアとインポートした設定を確認してください。各パッケージの入手先はダウンロードページをご確認ください。プロトコルの解説にある例示的な名称から、インストーラーファイルを判断しないでください。

Android では、まず設定がどの種類のコア機能に依存しているかを確認します。Xray 固有の機能が必要な場合は v2rayNG を第一候補にします。V2Fly を前提とした設定や保守手順がすでにある場合は、v2flyNG が適合するかを検討できます。名称が似ているというだけで、アプリ設定すべてを相互にインポートしないでください。特にカスタム JSON とルーティング用リソースに注意が必要です。プロセッサーアーキテクチャはプロトコルとは別の条件です。最近の端末では arm64 が一般的ですが、実際のシステム情報とインストール結果を確認してください。汎用パッケージを選んでも、コアが未対応のプロトコル構成は使えるようになりません。アーキテクチャと機能は別々に確認しましょう。

安定稼働中のサーバーと新しい構成の比較

サーバーが安定して使えている場合は、まず現在のプロトコルを維持し、必要なアプリやネットワーク種別で使えるか確認しましょう。移行する理由は、具体的な機能要件、端末との互換性の問題、保守の難しさなどであるべきです。プロトコル名が違うという理由だけで変更する必要はありません。サーバーが VMess しか提供していない場合、クライアント側で VLESS を選んでも互換性のある接続は作れません。サーバーが複数の組み合わせを提供している場合に限り、同じ接続先とネットワークで比較できます。まず各構成で認証できることを確認し、その後、初回応答、継続転送、バックグラウンドでの安定性を比較してください。接続できない設定で速度を測ると、設定ミスが性能評価に混ざります。

新しい構成を評価する際は、クライアント、実際に使うコア、プロキシプロトコル、トランスポート、安全機構、フロー制御項目、DNS、通信の適用方式を簡潔に記録します。一度に変更する階層は1つにし、使えることが確認済みの設定を残しておきましょう。長時間のバックグラウンド利用では、通信断からの復旧とOSのバックグラウンド制限を重点的に確認します。短いリクエストを大量に扱う場合は、接続確立と再利用を確認します。継続的にデータを転送する場合は、スループット、リソース消費、中断後の復旧を確認しましょう。用途によって適した構成は異なります。単一の指標であらゆる場面の結論を出す必要はありません。

エラーが起きた段階に応じて該当章を確認

インポート時に形式エラーが表示される場合は、第6章でリンクとサブスクリプションの形式を確認します。保存後にコアが起動しない場合は、第5章で対応範囲と項目構造を確認します。接続先には到達できるのにハンドシェイクに失敗する場合は、第2章と第3章で認証と安全設定を確認します。一部のアプリだけ失敗する場合は、第7章で通信の適用方式、ルーティング、DNSを確認します。接続はできるものの電池消費に問題がある場合は、第4章で接続の再試行や頻繁なテストを調べます。この順序なら、プロトコルを次々に切り替えるより再現性のある切り分けができ、機密情報を守りながら障害を正確に説明できます。

最終的な選択は、サーバーが実際に提供していること、クライアントが設定を正しく表現できること、コアが明確に対応していること、利用目的に沿った動作確認ができていること、の4つで判断できます。これらを満たしたうえで、管理方法やリソース使用量を検討しましょう。初回の設定はクイックスタートに沿って、インポート、接続、動作確認を進めてください。3つのクライアントを比較するにはクライアントの選び方をご覧ください。具体的な症状がある場合はよくある質問を確認してください。このガイドでは選択の技術的な条件を解説しています。サーバー側の条件を問わない、一律のプロトコルランキングは掲載していません。