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

プロトコルと設定の階層：ノードの読み解き方

接続を4つの要素に分けて考える

クライアントのノードは、単独のプロトコル設定ではなく、複数の接続パラメーターの組み合わせです。設定を読むときは、接続先のサーバー、認証に使う情報、データのトランスポート方式、接続の外側に適用する安全機構の4点を確認します。サーバーアドレスとポートは接続先を示し、VMess、VLESS、Trojan、Shadowsocksはプロキシプロトコルを決めます。TCPやWebSocketはデータの運び方、TLSやREALITYは安全層に関わります。これらは相互に関係しますが、同じ階層の設定ではなく、互いに置き換えられるものでもありません。

たとえば「VLESS + WebSocket + TLS」なら、ユーザー識別子、WebSocketのパス、リクエストホスト、TLSのサーバー名をそれぞれ確認します。パスが正しくてもユーザー識別子の誤りは補えませんし、サーバー名が正しくても、そのポートで接続を待ち受けているとは限りません。クライアントの画面ではこれらの項目が一つのウィンドウにまとまっていることがあり、「プロトコルを選べば設定完了」と誤解しがちです。ノード名から推測するのではなく、サーバー側から提供されたパラメーター一式を階層ごとに確認しましょう。

システムプロキシとTUNは別の階層

システムプロキシは、アプリがリクエストをローカルのプロキシ入口に渡すかどうかを決めます。一方、TUNは仮想ネットワークインターフェースを通じて、そこへルーティングされた通信を受け取ります。変わるのはクライアントに通信が入る経路であり、VMessがVLESSに変わるわけでも、サーバー側の認証失敗が直るわけでもありません。あるブラウザーは接続できるのに別のアプリは接続できない場合、まずアプリがシステムプロキシに対応しているか確認します。すべてのアプリで失敗する場合は、ローカルの入口、コアのアウトバウンド、サーバー側の入口の順に調べましょう。

ドメイン名の名前解決が行われる場所を区別する

サーバーアドレスにドメイン名を使う場合、接続前に名前解決が必要です。一方、アクセス先サイトのドメイン名は、ローカルアプリ、クライアントのDNSモジュール、またはサーバー側で解決されることがあります。この2つは別の名前解決経路です。アクセス先ドメインのルーティングルールを変更しても、サーバーのドメイン名の解決結果が変わるとは限りません。「ドメイン名では接続できないが、アドレスを直接指定するとつながる」場合は、接続先ドメインの名前解決とアドレスファミリーの選択を確認しましょう。すぐにプロトコルを変更する必要はありません。アドレスの直接指定は原因の切り分けに使えますが、安全層に必要なサーバー名は正しく設定してください。

クライアントを選ぶときも、この階層に沿って確認します。まず利用中のサービスがどの組み合わせを提供しているか、次にクライアントのコアがその組み合わせに対応しているかを確かめ、最後にTUN、ルーティング、サブスクリプション管理が必要かを検討します。デスクトップではv2rayNのダウンロードページから対応するプラットフォームを選べます。サブスクリプションリンクしかない場合は、先にインポートしてからノードの詳細を確認しましょう。安全層の名前だけをむやみに変更すると、元の設定との対応が崩れることがあります。

VMessとVLESS：認証と暗号化の違い

VMessの設計背景と互換性

VMessはProject Vエコシステムのプロキシプロトコルで、ユーザー認証とデータ保護の仕組みを備え、プロトコル内で一連の処理を行います。既存のサブスクリプションでも広く使われているため、登場時期が古いというだけで使えないと判断するべきではありません。現在のクライアントコアとサーバー実装が互換性を持つか、設定がそろっているか、用途に合っているかを基準に判断しましょう。プロトコル内部のデータ保護と外側のTLSは別の階層です。両方を使っていても、暗号化設定を単純に重複させているわけではありません。

VMessでよくあるトラブルの原因は、ユーザー識別子、暗号化設定、システム時刻です。認証では時刻に関係する検証が行われるため、端末の時刻が大きくずれているとハンドシェイクに失敗することがあります。その場合はサブスクリプションを何度も更新するのではなく、システムの時刻を自動設定にしましょう。古い設定には追加の識別パラメーターが残っている場合がありますが、新しい実装では通常AEAD認証が使われます。旧式の項目がある場合は、サービス提供元に適用条件を確認してください。古い画面例を参考に適当に入力したり、旧パラメーターに対応していれば新旧すべての実装で相互接続できると考えたりしないようにしましょう。

VLESSでは安全性を組み合わせで確保する

VLESSはプロトコル自体の処理を簡素化し、VMessと同じデータ暗号化の役割をプロトコル層では担いません。そのため、通常はTLSやREALITYと組み合わせて使います。仕組みが簡素だからといって自動的に安全になるわけでも、どの接続でも高速になるわけでもありません。公衆ネットワークで利用する場合は、外側の保護がどのように確立されるかを確認してください。VMessノードのプロトコル設定をVLESSに変えただけでは、サーバー側に対応する入口がない限り認証に成功しません。プロトコルを変更するには、クライアントとサーバーの両方を設定する必要があります。

VLESSのユーザー識別子は引き続き認証情報として使われ、TLSのサーバー名とは別の項目です。フロー制御の項目にも実装上の制約があります。サービス提供元からVision関連の設定が示された場合は、トランスポート方式、コアの対応状況、サーバー側の要件を確認しましょう。すべてのVLESSノードで同じフロー制御を設定する必要はありませんし、REALITYを見ただけで独自にフロー制御の値を追加するのも避けてください。一般的とされる設定を当てはめるより、サブスクリプションに明記された設定を維持するほうが確実です。

どちらを選ぶか

安定して動作するVMess設定があり、利用するクライアントに問題なくインポートできるなら、「新しいプロトコルは速い」という一般論だけを理由に移行する必要はありません。サーバーがVLESSと適切な安全層を提供しており、クライアントのコアもその組み合わせに対応している場合は、元のパラメーターに沿って試せます。比較する際は、サーバー、テスト対象、ローカルでの通信取り込み方法をそろえてください。異なる接続先の負荷、回線、ルーティング方針がプロトコルの差を覆い隠し、結果として2つのノード全体の差を測ることになりかねません。

移行前に元の設定を保存し、新しい設定は別のグループにインポートしましょう。Webサイトへのアクセス、長時間接続、必要なUDPアプリを確認してから、既定のノードを置き換えるか判断します。動作中の設定を上書きしてからトラブルシューティングを始めるのは避けてください。新しい設定が特定のコアだけで失敗する場合は、トランスポートと安全層の対応状況を確認します。どのコアでも失敗する場合は、サーバー側のパラメーターとネットワーク到達性を確認しましょう。インポート手順はv2rayNのサブスクリプションインポートガイドを参照してください。この章では項目同士の関係を解説します。

TrojanとShadowsocks：2つの接続方式

Trojanは完全なTLS接続を前提とする

Trojanは一般に、TLS接続内でプロキシリクエストを処理し、パスワードで認証します。設定画面がシンプルでも、アドレスとパスワードだけでよいとは限りません。サーバー名、証明書の信頼性、トランスポート設定も重要です。接続先のIPアドレスと検証するドメイン名が異なる場合もあります。前者はサーバーの特定に、後者はTLS上の期待する相手の確認に使われます。サーバーから専用のサーバー名が指定されている場合は、その値を使い、ノードのアドレスをすべての欄に機械的にコピーしないでください。

証明書エラーは、まず名前が一致しているか、システム時刻が正しいか、信頼チェーンが完全かを確認しましょう。証明書検証を無効にすると安全性の前提が変わるため、通常の対処法として使うべきではありません。サーバー独自の構成を利用している場合は、どのトランスポート方式を使っているかも確認が必要です。拡張機能の組み合わせを表す方法は、コアやクライアントによって異なることがあります。一般的なTrojanの入口で接続できても、追加のトランスポート拡張に対応しているとは限りません。実装とパラメーターを確認しましょう。

Shadowsocksでは暗号化方式の指定が必須

ShadowsocksはSSと略されることが多く、共有鍵方式を採用しています。クライアントにはサーバーアドレス、ポート、パスワード、暗号化方式が必要です。主に外側のTLSに依存する設定とは異なるため、SSの暗号化方式をVLESSの安全層の項目に入力することはできません。旧式の方式と現代的なAEAD方式には違いがあり、実際に選べる方式はサーバーの対応状況によって決まります。クライアントの一覧で強そうに見える方式に変更しても、サーバー側が自動的に更新されるわけではありません。かえって両者がデータを解釈できなくなります。

新しいShadowsocksの方式には、鍵のエンコードや長さに明確な要件があり、任意の短い文字列を共通パスワードとして使えるとは限りません。クライアントに方式名が表示されていても、現在の実行コアが実装しているとは限りません。インポート後に方式が消える、パスワードが途中で切れる、認証に失敗し続けるといった場合は、同じ接続を何度も試すのではなく、元の共有形式と照合しましょう。プラグインのパラメーターにも注意してください。基本的なSSに対応していても、特定の外部プラグインや拡張トランスポートを実行できるとは限りません。

UDP、接続の再利用、利用上の制約

どちらのプロトコルも、「UDP対応」と書かれているだけでは目的のアプリが必ず使えるとは判断できません。サーバー側で転送が許可されているか、クライアント側で機能が有効か、ローカルアプリの通信がプロキシに入っているか、ルーティングで許可されているかが結果に影響します。TCP接続の確立だけを測るテストでは、音声通話、ゲームなどのUDPアプリの動作はわかりません。Webサイトは見られるのに特定のアプリが動かない場合は、パスワードをすぐ変更するのではなく、まずアプリの通信方式と取り込み経路を確認し、その後サーバー側の対応状況を調べましょう。

設定を管理するとき、TrojanではTLSのサーバー名、証明書、パスワードが主な確認点です。SSでは暗号化方式、鍵、任意の拡張パラメーターを確認します。サーバーがどちらか一方だけを提供しているなら、その構成に対応するクライアントを選べば十分です。名称を統一するために別のプロトコルへ変換する必要はありません。デスクトップではv2rayNでノードの全パラメーターを確認し、Androidではコアの要件に応じてv2rayNGまたはv2flyNGを選べます。両方の端末で同じサーバーパラメーターを使うと、クライアントの違いとサーバー側の問題を切り分けやすくなります。

TLSとREALITY：安全層の設定項目を確認する

サーバー名の検証とネットワークの接続先を区別する

TLSは接続を保護し、通常は接続相手の身元確認も行います。サーバー名は接続先として期待する相手を示すもので、実際の接続先アドレスと必ずしも同じではありません。ALPNはアプリケーション層のプロトコルをネゴシエートするための仕組みであり、自由に入力できる高速化パラメーターではありません。サーバー側の設定で値が指定されている場合に限り、その内容に合わせて設定します。接続を通すためにサーバー名や証明書の問題を無視すると、もともとの検証条件が失われます。設定の入手元とサーバー側の構成が一致しているか、まず確認しましょう。

WebSocketなどの中間トランスポートを使う構成では、リクエストホスト、TLSのサーバー名、パスがそれぞれ異なる処理段階に影響することがあります。これらを同じドメインにする構成もあれば、別々に設定する構成もあります。トラブルシューティングでは項目名と意味を整理し、画面上の入力欄が少ないからといって一律に同じ値へ置き換えないでください。ブラウザーで特定のドメインにアクセスできても、プロキシの認証、パス、サーバー側の転送まで正しいとは限りません。

REALITYは5つ目のアウトバウンドプロトコルではない

REALITYはXrayエコシステムの安全層機能で、VLESSとの組み合わせでよく使われます。通常のTLS証明書を使う構成とは設定上の関係が異なるため、安全層の名前をREALITYに変えるだけでは移行できません。クライアントでは通常、サーバーから提供されたサーバー名、認証用の公開鍵パラメーター、shortIdが必要です。必要に応じてフィンガープリントとフロー制御も確認します。クライアントによって関連項目が「公開鍵」と表示されたり、コアの更新に伴って項目名が変わったりすることがあります。コアの説明とサブスクリプション提供元の項目対応を確認しましょう。

公開鍵はサーバー側の秘密鍵と対応する値であり、ドメイン名から推測できません。shortIdはサーバー側で許可された値のいずれかである必要があり、空欄が使えるのもサーバー側で明示的に許可されている場合だけです。他のノードの値を流用しないでください。接続アドレスはサーバーの入口を特定し、サーバー名はその構成で求められる条件を満たすためのものです。役割は異なります。サブスクリプション更新後にこれらの値が変わった場合は、古い設定が使えなくなっている可能性があります。アドレスとポートだけを更新するのではなく、すべてのパラメーターを再インポートしましょう。

フィンガープリントもフロー制御も、単独で使える性能向上スイッチではない

クライアントのフィンガープリントは、TLSハンドシェイクの特徴をどう実装するかに関係します。選択肢はコアによって異なるため、名前だけで互換性を判断できません。フロー制御もプロトコルの組み合わせとサーバー側の設定に左右されます。インポート後に不明なパラメーターが表示された場合は、まず正しいコアを選んでいるか、現在の設定形式でその項目を表現できるか、変換時に情報が失われていないかを確認しましょう。画面ごとに既定値が異なる場合もあるため、インポート前の共有テキストを思い出すだけでなく、実際に保存された内容を確認する必要があります。

比較的安全な確認手順は、まずサーバー側が通常のTLSとREALITYのどちらを使うか確認し、次にサーバー名を照合します。REALITYの場合は公開鍵パラメーターとshortIdを確認し、最後にフィンガープリント、フロー制御、トランスポート方式を調べます。毎回、関連する項目を一組ずつ変更し、元の値を保存してください。アドレス、コア、安全層を同時に変えると原因を特定できなくなります。ハンドシェイクエラーについてはトラブルシューティングの接続診断を参考にログを確認できますが、認証情報を含む設定全体を公開しないでください。

接続速度、リソース使用量、スマホの電池消費

初回接続と継続的な通信を分けて考える

「どのプロトコルが速いか」を比べる前に、何を測るのかを決めましょう。ページを初めて開くときは、名前解決、サーバーとの接続確立、プロトコル認証、場合によってはTLSハンドシェイクが発生します。継続的なダウンロードでは、回線容量、輻輳、サーバー側の負荷、端末の処理能力がより大きく影響します。ある組み合わせで処理が一段階減っても、すべてのネットワークでページ表示が明らかに速くなるとは限りません。テスト対象やサーバー側の入口が異なる場合、結果の差をすべてプロトコルの違いとみなすことはできません。固定の速度ランキングを導き出すのは特に避けましょう。

ハンドシェイクは通信の往復時間に影響され、大容量ファイルの転送では安定したスループットが重要になります。接続の再利用は適切な場面で接続確立の繰り返しを減らせますが、接続同士の競合や障害の影響範囲を変える場合もあります。クライアントに接続再利用の設定があっても、すべてのノードで有効にすべきとは限りません。組み合わせによっては再利用やフロー制御に固有の制約があります。サーバー側の推奨設定を優先しましょう。効果を確かめる場合は、ほかの設定を変えずに、短いリクエスト、長時間接続、同時アクセスをそれぞれ観察してください。

CPUとメモリの負荷は処理全体から生じる

VMessのプロトコル処理、SSの暗号化方式、TLSハンドシェイク、データのコピー、トランスポートのカプセル化など、さまざまな処理が負荷になります。最新のプロセッサーに搭載されたハードウェアアクセラレーションによって、相対的なコストも変わります。VLESSではプロトコル層の処理が少なくなりますが、外側の安全機構には引き続き計算資源が必要です。TUN、DNSモジュール、ルールの照合もリソースを消費するため、クライアント全体の使用量を特定のプロトコルだけの負荷とみなすことはできません。デスクトップでモード切り替え後にメモリ使用量が変わった場合は、コアの追加機能やルールセットも同時に有効になっていないか確認しましょう。

スマホではスリープ解除と再接続を確認する

Android端末の電池は、暗号化処理だけでなく、無線接続の維持、バックグラウンドのハートビート、DNSリクエスト、接続失敗後の再試行でも消費されます。電波が弱い場合やネットワークが頻繁に切り替わる場合は、同じプロトコルでも結果が変わることがあります。クライアントを起動してから待機中の電池消費が明らかに増えた場合は、接続失敗のログが続いていないか、アプリが頻繁に通信していないか、サブスクリプションの更新や接続確認が多すぎないかを確認しましょう。同じ再接続ループを残したままプロトコルだけ変えても、根本的な解決にはなりにくいでしょう。

電池消費を比較するときは、電波状況が近い環境でアプリと使い方をそろえ、画面を点灯させたテストとバックグラウンド待機を分けて測定します。短時間の電池残量の変化だけでは、プロトコルの優劣は判断できません。デスクトップでもアイドル時と高負荷時をそれぞれ確認し、比較中に別のダウンロードを動かさないようにしましょう。ブラウザー以外のアプリの通信も取り込みたい場合は、v2rayNのTUNモードの仕組みと設定を確認してください。余分な負荷を評価する前に、まず通信経路を正しく設定しましょう。

V2Fly、Xray、3つのクライアントの役割

コアとグラフィカルインターフェースは別の階層

Project Vはこのエコシステムを理解するための出発点です。V2FlyはV2Ray関連プロジェクトの開発を引き継ぎ、XrayはV2Rayと共通の歴史を持ちながら独立して発展しています。両者はプロトコル、トランスポート、設定構造に共通点があり、それぞれ独自の機能も追加されています。オープンソースであるため、各プロジェクトのライセンスに基づいてコードを確認・利用できますが、異なるプロジェクトが常に同じ設定仕様を共有するという意味ではありません。個別機能については、プロジェクト名だけで判断せず、実際に動作しているコアの実装を確認してください。

グラフィカルクライアントはサブスクリプション管理、ノード編集、コアの起動、システムプロキシなどを操作します。コアは接続処理、プロトコルの実装、ルールの適用を担います。デスクトップではv2rayNが第一候補で、Windows、macOS、Linuxに対応しています。同じクライアントでも、画面の種類やパッケージ形式の違いを別のプロキシプロトコルと混同しないようにしましょう。インストーラーを選ぶときは、まずOSとプロセッサーアーキテクチャを確認し、その後、実際に使用するコアと読み込まれる設定内容を確認します。

Androidでは必要なコアに合わせて選ぶ

v2rayNGはAndroid向けで、Xrayコアを採用しています。V2Flyコアを使う代替クライアントとしてv2flyNGもあります。インポート手順が似ていても、コアの対応機能まで同じとは限りません。REALITYなどXray関連の機能が必要な場合は、v2rayNGが現在の組み合わせに対応しているか確認しましょう。v2flyNGが同じ設定をそのまま扱えるとは限りません。V2Fly向けの設定をすでに使っている場合は、名前の類似性だけで選ばず、実際のトランスポートとプロトコルの対応状況を見てv2flyNGを検討してください。

v2rayNでコアを選べる場合は、ノードやルーティングの設定が最終的にどのコアへ渡されるか確認しましょう。画面上で項目を保存できても、エディターがテキストを受け付けただけで、バックグラウンドのコアがその機能を実装しているとは限りません。起動に失敗した場合はまずコアのエラーを確認し、接続に失敗した場合はハンドシェイクやルーティングのエラーを調べます。不明な項目や未対応のトランスポートがログに出た場合は、システムプロキシのオン・オフを繰り返すのではなく、コアの互換性を確認してください。この2つのエラーは異なる処理段階で発生します。

設定の互換性は項目ごとに確認する

両方のコアがJSONを使っていても、設定ファイル全体をそのまま交換できるとは限りません。プロトコル名が同じでも、拡張パラメーター、既定値、トランスポートの実装、DNSの動作が異なる場合があります。設定を移行するときは、まず最小限のアウトバウンド設定を移し、その後、ルーティング、DNSなどの機能を一つずつ追加しましょう。複雑な設定を一度にすべてコピーすると、未対応項目や依存関係まで持ち込んでしまい、ノードではなく設定の読み込みが原因で接続できないことがあります。

クライアントを更新するときも、画面とコアの変更を分けて考えましょう。画面に新しい項目が追加されても、既存の設定をすべて変更する必要があるとは限りません。コアの更新後に旧項目について警告が出たり、互換性が変わったりする場合もあります。復元できる設定を保存し、使用中のコア名を記録したうえで、まずノードを一つだけ検証すると移行の負担を抑えられます。インストールと実行環境の問題はv2rayNの初回インストールと初期設定をご覧ください。クライアントとアーキテクチャに合った配布ファイルはダウンロードセンターで確認できます。コア専用のダウンロードページを別に探す必要はありません。

サブスクリプションの互換性：インポート後に確認する項目

サブスクリプションURL、共有リンク、コア設定

サブスクリプションURLは通常、ノード情報を返すネットワークリソースを指します。単一ノードの共有リンクは一つの接続設定を含み、コア設定ファイルにはローカルのインバウンド、DNS、ルーティングなども含まれる場合があります。それぞれ用途が異なるため、テキストが長いというだけで同じ方法でインポートしてはいけません。複数形式を自動認識するクライアントもありますが、対応範囲には限りがあります。まずサブスクリプションURLか単一ノードの情報かを確認し、適切なインポート方法を選ぶと、WebページのURLや設定ファイル全体をノードリンクとして誤って扱うのを防げます。

従来のサブスクリプションでは、Base64でエンコードされた複数行の共有情報がよく使われますが、ほかの構造化形式もあります。Base64はエンコード方式であり、情報を保護するものではありません。デコードできても、各行が有効なノード情報とは限りません。VMessの共有情報ではフィールドがエンコード後のJSONに含まれることが多く、VLESSとTrojanではクエリパラメーター付きのURIがよく使われます。SSには複数のエンコード形式があります。形式によって新しい項目を表現できる範囲が異なるため、サブスクリプション変換では安全層、フロー制御、拡張トランスポートの項目が保持されているか特に注意してください。

エンコードが正しくても設定の意味が失われることがある

パスワード、パス、クエリパラメーターに特殊文字が含まれる場合は、それぞれの形式で定められたエンコード規則に従う必要があります。たとえばURLの区切り文字を通常の文字として扱うことはできず、チャットツール経由の改行やコピー時の欠落もリンクを壊す原因になります。問題を調べるときは、手作業でデコード・編集・再エンコードするのではなく、まず元の情報源からコピーし直してください。サブスクリプションの取得結果がログイン画面やエラーメッセージなら、ネットワークリクエストが成功していても有効なノード情報は得られません。

以下はローカルSOCKSインバウンドの最小構成例です。コアの設定ファイルとノードの共有リンクが異なる形式であることを示しています。完全なクライアント設定ではないため、サブスクリプションとしてインポートできません。対応するコアの完全な設定に組み込み、アウトバウンドも設定する必要があります。この例ではループバックアドレスだけにバインドし、ローカルのプロキシ入口がほかの端末に公開されないようにしています。GUIクライアントを使う場合は、通常、画面からローカルポートを変更すればクライアントが設定を生成します。生成ファイルを直接編集するのは避けてください。

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ]
}

サブスクリプション変換でコアの機能は補えない

サブスクリプション変換は、すでにある情報を別の形式で表現し直すものであり、未対応機能をクライアントに追加するものではありません。変換先の形式でREALITYに必要なパラメーターを保持できない場合、ノード一覧は表示されてもハンドシェイクに失敗することがあります。元の設定と照合し、プロトコル、安全層、サーバー名、公開鍵パラメーター、shortIdが残っているか確認してください。元の情報に項目が不足している場合、変換サービスが正しい値を推測することはできません。設定提供元に必要な情報一式を問い合わせましょう。

サブスクリプションURLには、アカウント設定にアクセスできる識別情報が含まれることがあります。機密情報として扱ってください。URLを第三者の変換サービスに送ると、そのサービスがサブスクリプション内容にアクセスできることになります。画面を共有するときも、リンク、QRコード、認証情報が写らないようにしましょう。更新に失敗した場合は、有効期限と取得結果を確認し、「直接接続での更新失敗」と「プロキシ経由での更新失敗」を切り分けます。確認手順はサブスクリプションの解析エラーを自分で確認する方法、変換の制約はサブスクリプション変換のよくある質問をご覧ください。

用途に応じて選び、接続を検証する

利用可能なサブスクリプションがある場合：まず互換性を確認し、その後に最適化

有効なサブスクリプションをすでに持っているなら、その設定項目を正しく扱えるクライアントを使うのが現実的です。デスクトップではv2rayNを優先し、OSとプロセッサーに合ったインストーラーを選びます。Androidでは必要なコアに応じてv2rayNGを選び、V2Fly向けの既存設定にはv2flyNGが適するか検討します。プロトコルの優先順位を先に決めて、すべてのノードを上位の方式に無理やり変更しないでください。利用できる組み合わせはサーバー側で決まっています。クライアントの役割は設定を正しく再現することであり、存在しない組み合わせを作り出すことではありません。

初回の検証では、できるだけシンプルな経路を保ちましょう。サブスクリプションをインポートし、設定がそろったノードを一つ選び、システムプロキシに対応するアプリでアクセスを確認します。基本的な接続を確かめてから、ルーティングルール、TUNなどを追加してください。すべてを同時に有効にすると、失敗の原因がプロトコル、DNS、ルール、権限のどれなのか判断しにくくなります。基本操作はサブスクリプションのインポート手順、Androidでの操作はv2rayNGへのサブスクリプションインポートをご覧ください。

モバイル利用と複雑なアプリの問題を分けて考える

モバイル端末ではネットワークを切り替える機会が多いため、一度の接続テストだけでなく、再接続、バックグラウンド動作、システムの電池管理を確認しましょう。スリープ後に接続が切れる場合は、クライアントがシステムによって制限されていないか、ネットワーク切り替え後に再接続しているか、サーバーのドメイン名を再解決できるかを確認します。電池消費を抑えたい場合は、特定のプロトコル名にこだわるより、不要な接続確認や再試行を減らすことが有効です。サブスクリプションの更新間隔は適切に設定しましょう。設定の参考としてv2rayNGのサブスクリプション自動更新をご覧ください。

デスクトップでシステムプロキシに対応していないアプリを使う場合は、TUNの利用を検討し、システム権限、DNS、ルーティングループも確認しましょう。仮想ネットワークインターフェースを有効にしても、すべての通信をサーバーへ送る必要があるわけではなく、ローカルネットワークへのアクセスを無視できるわけでもありません。リモートワーク、LAN内の機器、ローカルサービスでは、直接接続を残す必要がある場合があります。ルーターやサブルーターへの導入は別の実行環境となり、プロセッサーアーキテクチャや設定の保守も考慮が必要です。詳しくはルーターでXrayを動かす方法の概要をご覧ください。

階層ごとに検証して原因を絞り込む

接続の検証は4段階で進められます。1つ目は、クライアントのコアが正常に起動し、ローカルの入口でポート競合が起きていないこと。2つ目は、サーバーのドメイン名を解決でき、接続先へ到達できること。3つ目は、プロトコル認証と安全層のハンドシェイク。4つ目は、アクセス先アプリに必要なDNS、ルーティング、トランスポートです。それぞれの段階で、確認できる情報を照合しましょう。ポートに到達できても認証成功とは限りません。認証に成功してもWebサイトへアクセスできるとは限らず、ブラウザーが使えてもほかのアプリの通信がプロキシに入っているとは限りません。

設定を比較するときは、クライアント、コア、プロトコルの組み合わせ、通信の取り込み方法を記録し、一度に一つの条件だけを変更します。特定のノードで問題が発生するなら、サーバーの設定と稼働状況を確認します。特定のアプリで発生するなら、プロキシ対応とルーティングを調べます。ネットワーク切り替え後にだけ発生するなら、名前解決、再接続、ネットワークの制約を確認しましょう。最終的には、設定を維持しやすく、必要なアプリが安定して動作し、端末への負荷が許容範囲に収まるものを選びます。プロトコルに、環境を問わない一律の順位はありません。見慣れない設定を頻繁に試すより、復元できる設定を残しておくほうが実用的です。