V2Rayのプロトコルとコア解説

接続の階層：まず設定の役割を見分ける

クライアント、コア、サーバーはそれぞれ別のもの

GUIクライアントはサーバー情報の保存、サブスクのグループ管理、設定の生成、ログの表示を担います。コアは生成された設定を読み込み、ローカルの受け口、ルーティングの判定、リモート接続、データ転送を処理します。サーバーはリモート接続を受け付け、取り決めに従って認証します。画面にプロトコル名が表示されていても、それは設定項目が用意されていることを示すだけです。実際に使えるかどうかは、選択したコアが対応しているか、サーバー側で同じ組み合わせが有効かによって決まります。

デスクトップでは、アプリのリクエストがまずシステムプロキシに渡り、システムプロキシからクライアントが開いたローカルの待ち受けポートへ送られます。コアは宛先を確認して、直接接続するかリモートのアウトバウンドへ渡すかを判断し、その後にリモートのプロトコル接続を確立します。AndroidのVPNモードでは、システムの仮想ネットワークインターフェースを通じてアプリの通信を受け取ります。入口の仕組みは異なりますが、その後のプロトコル認証は項目ごとに一致させる必要があります。「システムプロキシが有効」だからといって、リモート接続まで成功したとは限りません。

接続設定を4つの情報に分けて確認

1つ目は接続先のサーバーアドレスとポートで、どこにつなぐかを示します。2つ目はプロキシプロトコルと認証項目です。たとえばVMessのユーザーIDやTrojanのパスワードが該当し、相手側がリクエストをどう識別するかを決めます。3つ目は通信設定で、プロキシのデータを下位の接続にどう載せるかを指定します。4つ目はTLS、サーバー名、証明書の検証、REALITYのパラメーターなどに関わる安全設定です。いずれかが一致しないと、タイムアウトやハンドシェイク失敗につながります。

よくある「VLESS＋TLS」は、複数の階層を組み合わせた設定です。VLESSはプロキシリクエストの形式と認証を担い、TLSは外側の通信を保護します。WebSocketは通信方式であり、ユーザー認証の代わりにはなりません。REALITYは安全機構で、サーバー一覧に単独で登録できる完全な認証情報でもありません。サブスクやチュートリアルを読むときは、用語がどの階層に属するかを確かめると、設定画面を探し間違えずに済みます。

接続先アドレスとサーバー名は異なる場合がある

サーバーアドレスは実際のネットワーク接続先です。一方、TLSのサーバー名はネゴシエーションと本人確認に使われます。構成によって両者が同じ場合も異なる場合もあります。アドレスをIPアドレスに変更したからといって、サーバー名まで削除してはいけません。逆に、サーバー名が正しくても、任意のアドレスに接続できるわけではありません。リバースプロキシ経由の構成では、通信経路、ホスト情報、サービス名も入口の設定に合わせる必要があります。

ポート番号だけから用途を決めつけることもできません。同じポート番号で異なるサービスが動く場合があり、番号を見ただけでTLSが有効だとは判断できません。クライアントの「安全でない接続を許可」は通常、証明書検証に関する設定で、互換性を高める万能策ではありません。通常は本人確認を有効にしてください。証明書エラーが出たら、検証を無効にして設定の不一致を隠すのではなく、システム時刻、サーバー名、信頼チェーンを確認します。

設定を確認するときは、まずクライアント名、コア名、プロトコル、通信方式、安全機構を記録し、サービス提供元の情報一式と照らし合わせます。一度に変更するのは1項目だけにして、保存後に再接続し、その操作に対応するログを確認してください。元のサブスクは使えるのに手動で作り直すと接続できない場合は、ルーティングを変える前に設定項目の不足を比べます。固定のボタン配置を覚えるより、階層ごとに記録しておくほうが長く役立ちます。

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

VMessはプロトコル自体が担う機能が多い

VMessはProject Vのエコシステムで早くから広く利用されてきたプロキシプロトコルです。設計上、ユーザー認証とデータ保護をプロトコル自体に組み込んでいます。ユーザーIDは通常UUID形式で、クライアントには暗号化方式などの項目が表示されることもあります。現在の設定では、サーバーが対応する認証方式に従ってください。古いチュートリアルを見て旧式の項目をそのまま入力するのは避けましょう。特にalterIdは、古い共有情報に残っていることがありますが、非ゼロの値を積極的に設定すべきという意味ではありません。

VMessの接続認証は時刻に関係するため、端末の時刻が大きくずれていると、設定が正しく見えても認証に失敗することがあります。トラブル対処では、まずOSの日時とタイムゾーンを自動設定にしてから再接続してください。表示されるタイムゾーンが異なるだけで、時計が間違っているとは限りません。重要なのはシステム時刻が正確かどうかです。同じ設定が別の端末で使える場合も、ユーザーIDを何度もコピーし直す前に、端末の時刻とコアの対応状況を比べてください。

VMess自体がデータを保護するからといって、外側のTLSが必ず不要になるわけではありません。外側の安全機構、通信方式、プロキシプロトコルにはそれぞれ役割があり、組み合わせはサーバーの構成によって異なります。サブスク一式を受け取っている場合は、元の組み合わせを維持してインポート結果を確認してください。「暗号化」という言葉を見ただけでTLSを削除するのは適切ではありません。層をむやみに減らすと、通信が軽くなるどころか、サーバーが待ち受けていない接続形式になるおそれがあります。

VLESSはプロトコル自体を簡素化するが、接続全体が簡素になるとは限らない

VLESSはプロトコル自体の役割を絞り、VMessと同様のデータ暗号化レイヤーを内部に持たない設計です。ユーザー認証には引き続き正しいIDが必要で、通信データの安全性は通常、組み合わせる安全機構が担います。画面にあるencryption: noneは、その項目の仕様を示すもので、外側の安全機構を無効にする推奨設定ではありません。ネットワーク越しに接続する場合は、サーバーが明示的に対応する安全設定一式を使ってください。

そのため、「VLESSはVMessより層が1つ少ないので、どんな場合も速い」とは言えません。ページの表示には、DNS名前解決、接続確立、安全な通信のネゴシエーション、サーバーの処理、接続先サイトの応答も関わります。プロトコルヘッダーの違いは、その一部にすぎません。短時間の接続ではハンドシェイクの影響が大きく、長時間の転送では回線容量や端末の暗号化性能がより重要になることがあります。同じプロトコルでも回線が違えば、その差はプロトコル自体の差を大きく上回る場合があります。

flowは対応する条件の一つであり、万能な高速化スイッチではない

VLESSの設定には、特定のフロー制御方式に対応するflow値が含まれることがあります。この項目は、クライアントのコア、サーバー設定、通信方式、安全設定の組み合わせがすべて対応していなければなりません。サブスクに記載がなければ、チュートリアルの画面にあったからといって勝手に追加しないでください。記載があるのにインポート後に消えている場合は、共有形式とパーサーが項目を保持しているか確認します。プロトコルのプルダウンを切り替えるだけで、有効なフロー制御の組み合わせが自動で作られるわけではありません。

手動で確認する場合は、「プロトコル、ユーザーID、暗号化項目、通信方式、安全設定、フロー制御」の順に見ていきます。まずプロトコルの選択を確認し、UUIDの前後に余分な空白がないかをチェックしてから、通信方式と安全設定の画面を確認してください。ログに不明な項目や未対応のフロー制御が表示されたら、クライアント画面に選択肢があるかではなく、実際に起動しているコアを確認します。画面で編集できることと、実行時に認識されることは別の条件です。

安定して使えているVMessの設定があるなら、プロトコル名だけを理由に移行する必要はありません。新しい設定でVLESSが提供されている場合は、コアの対応状況と安全設定の組み合わせを確認し、実際のアプリでも試してください。詳しい比較はVMessとVLESSの暗号化方式・互換性の違いをご覧ください。選定では、必要な項目がそろい、サーバーが対応し、保守しやすい設定を選びます。「シンプル」という言葉を、ほかの階層を確認しなくてよいという意味に捉えないでください。

Trojan・SS・REALITY：プロトコルと安全機構を区別する

TrojanではTLS接続が正しく確立されることが前提

TrojanはTLSで保護された接続上でプロキシ認証を行います。GUIでよく設定する項目は、アドレス、ポート、パスワード、サーバー名です。外側のTLSが重要な前提となるため、パスワードが正しくても接続できるとは限りません。サーバー証明書の名前、システムの信頼設定、実際の接続先が一致している必要があります。クライアントが先に証明書エラーを出す場合、プロキシのパスワード認証に進む前の問題です。パスワードを変えても通常は解決しません。

Trojanのパスワードは文字列全体をそのまま保存し、コピー時に前後の空白、改行、リンク内のエンコード文字に注意してください。共有リンクでは特殊文字がパーセントエンコードされることがあり、クライアントは形式に応じて解析します。手動編集では、すでにデコードしたパスワードを根拠なく再エスケープしないでください。また、リンクの項目を区切る記号をパスワードの一部と取り違えないようにします。まず元のリンクをそのままインポートし、手入力した設定と比較するのがおすすめです。

Shadowsocksは暗号化方式とパスワードを両方確認

ShadowsocksはSSとも呼ばれ、比較的シンプルな暗号化プロキシとして設計されました。設定ではサーバーアドレス、ポート、暗号化方式、パスワードを確認します。暗号化方式は自由に選べる好みの項目ではなく、接続する双方で一致させる必要があります。パスワードが正しくても方式が合わなければ、正常に復号できません。古い資料にある方式名が現在のすべてのコアで使えるとも限らないため、実際の実装とサーバー設定を確認してください。

従来のAEAD方式とShadowsocks 2022シリーズでは、必要な鍵の形式が異なります。後者では、長さやエンコード形式の要件を満たす鍵が必要な場合があり、通常のパスワードを入力しても自動で互換性が確保されるわけではありません。共有形式に拡張パラメーターが含まれていても、3つのクライアントすべてが認識するとは限りません。インポートできても動かない場合は、サーバー名が一覧に表示されるかだけでなく、方式名、鍵の形式、コアの対応状況を確認します。

REALITYは安全レイヤーの機能として理解する

REALITYはXrayエコシステムの安全機構であり、VMess、VLESS、Trojan、Shadowsocksと同じ階層で比較するものではありません。よく見かけるのはVLESSとREALITYの組み合わせです。VLESSがプロキシプロトコルを担い、REALITYが対応する安全なハンドシェイクを提供します。設定には有効なアドレス、ポート、ユーザー認証情報のほか、サーバーから提供された公開鍵情報、サーバー名、short IDなどが必要です。

通常のTLSのスイッチ名を変えるだけで、REALITYに切り替えられるわけではありません。サーバー側が明示的に対応し、使用するクライアントのコアも関連する設定項目を認識する必要があります。画面の項目名は実装によって異なることがあるため、それぞれの役割を理解して確認してください。どれが公開される検証情報か、どれがユーザー認証情報か、どれがハンドシェイク用の名前かを見分けます。秘密鍵はサーバー側の機密情報です。クライアントのサブスクに含めるものではなく、「インポート時に項目が欠けた」として提供を求めるものでもありません。

これらの方式を比べるときは、組み合わせ全体を記録してください。たとえば「REALITYを使用」だけではユーザー認証方式を判断できず、「SSを使用」だけでは暗号化方式が分かりません。クライアントに表示される略称は一覧を見るには便利ですが、トラブル対処の記録には不十分です。設定全体を記録すれば、伝達時の行き違いを減らし、外側のハンドシェイク失敗をプロキシプロトコル自体の問題と取り違えずに済みます。

まず現在のサーバー設定を基準に選びます。Trojanの接続口しかなければ、TLSとパスワードを確認します。SSしかなければ、方式と鍵を確認します。VLESSとREALITYが使えるなら、Xrayの対応状況と必要項目がそろっているかを確認してください。プロトコル情報が足りない場合は設定の提供元に問い合わせましょう。安全設定を次々と切り替えて推測するのはおすすめできません。変更する要素が増え、もともと不足していた項目を特定しにくくなります。

性能と電池消費：接続全体の負荷で比較する

通信速度は複数の段階で決まる

体感速度には少なくとも、接続開始、最初のデータ受信、継続的な転送の3段階があります。接続開始はDNS名前解決、往復経路、ハンドシェイクの回数に左右されます。最初のデータが届くまでには接続先の応答も関わり、継続転送は回線容量、混雑、端末の処理性能に影響されます。そのため、プロトコルを比較するときは、どの段階を測るのかを先に決めてください。1回の遅延測定をダウンロード速度の順位に直結させると、実際の利用感と逆の結論になることがあります。

プロトコル認証、暗号化、カプセル化は確かにリソースを消費しますが、端末ごとのハードウェアアクセラレーション、システムのスケジューリング、実装の最適化によって結果は変わります。VMess、VLESS、Trojan、SSという名称だけでは、CPU使用率の決まった順序は分かりません。VLESS自体が同種の暗号化を担わないからといって、組み合わせるTLSやREALITYにコストがないわけでもありません。同じ端末、近い回線条件、明確な安全設定で比較し、プルダウンの名前だけを見て判断しないでください。

通信方式のオーバーヘッドと多重化のコスト

WebSocketなどの通信方式は、サーバーの入口に合わせるために追加のカプセル化が必要になることがあり、その負荷の影響は用途によって異なります。多重化は少ない下位接続で複数のリクエストを運び、接続確立の繰り返しを減らす一方、複数のリクエストが同じ接続のパケットロスやスケジューリングの影響を受けることもあります。有効にするかは、サーバーとフロー制御方式の組み合わせを確認して判断してください。「多重化」と名の付くスイッチをすべて有効にするのは避けましょう。

テストでは同じ接続先サイトを選び、ルーティングとDNSの設定を変えずに、初回表示、再表示、継続読み込みをそれぞれ確認します。1回ごとに変更するのは1項目だけにし、接続が新しく確立されたかも記録してください。ブラウザーや接続先のキャッシュ、既存の接続は結果に影響します。1度繰り返すだけで誤差がなくなるわけではありません。異なる設定で別のサーバーにつないでいる場合、主に2つの接続経路を比べることになり、プロトコル単独の効率を示す結果にはなりません。

Androidの電池消費は、継続的な動作の影響が大きい

AndroidのVPNモードは、システムのVpnServiceを通じてアプリの通信を受け取ります。アプリが継続的にネットワークリクエストを送ると、クライアントが起動してデータを処理し続ける場合があります。接続の再試行、DNSクエリ、ログ出力も動作を増やす要因です。デスクトップでCPU使用率が低いプロトコルだからといって、スマートフォンの待機時に電池を節約できるとは限りません。無線LANやモバイル通信の品質、バックグラウンドアプリの数、OSの省電力設定も、端末ごとの違いに大きく影響します。

電池消費を調べるときは、同じ使い方でクライアントの有効時と無効時を比べ、まずシステムのバッテリー記録を確認します。その後、VPNモード、アプリごとのプロキシ設定、特定アプリへと範囲を絞ります。電波が不安定なとき、ネットワークが頻繁に切り替わるとき、バックグラウンドで転送が続くときに偏りがないか見てください。ログで接続の確立が繰り返されているなら、まず接続失敗の原因を解消します。すべてのタイムアウトを延ばすだけでは、失敗する接続が長く待機するだけで、実際の負荷は減りません。

ログレベルはトラブル対処の目的に合わせて設定します。一時的な調査では詳細度を上げ、原因が分かったら日常利用に適したレベルに戻して、大量のログが出続けないようにしてください。遅延測定や自動テストも接続を発生させます。状態を確認するために頻繁なテストを設定しすぎないでください。クライアント一覧の更新、サブスクの更新、実際のアプリ通信は分けて考えます。バックグラウンドの動作がすべて、今使っているアプリによるものとは限りません。

特定のアプリだけで電池消費が多い、または接続に失敗する場合は、UDP、長時間接続、バックグラウンド通知への依存を確認し、プロキシの対象範囲も見直してください。必要なアプリだけをVPN経由にすれば、不要な通信を減らせる場合があります。ただし、アプリごとの設定が何を意味するか理解しておく必要があります。詳しくはv2rayNGの権限・省電力・アプリごとの設定をご覧ください。速度の問題はサーバー、回線、ローカル設定を順に確認する方法で調べ、原因の特定をプロトコルの変更で代用しないでください。

V2FlyとXray：機能ごとに互換性を確認する

同じエコシステムでも実装が完全に同じとは限らない

Project VはV2Rayエコシステムを理解するうえでの背景です。V2Flyは関連するコアやコンポーネントの開発を引き継ぎ、Xrayは共通の歴史から独自の機能路線へと発展しました。プロトコル、設定構造、用語が似ている部分もあり、基本設定の見た目が共通していることは少なくありません。しかし、ファイルを自由に相互利用できるわけではありません。安全機構、フロー制御、通信の詳細、DNSの動作には違いがあるため、必要な機能ごとに確認してください。

カーネル選びで違いが表れやすいのは、REALITYや特定のVLESSフロー制御方式です。サブスクでXrayの機能が明示的に必要な場合、設定の見た目が似ていてもV2Flyに切り替えるだけで対応できるわけではありません。一方、そうした機能を使わない基本的な接続だからといって、どちらか一方の系統が必須とも限りません。既存のプロトコル構成と保守要件を基準に選び、コアの名称を性能ランクのように扱わないでください。

3つのクライアントが接続の中で担う役割

デスクトップではv2rayNを第一候補とし、Windows、macOS、Linuxでの利用に対応します。GUIでの管理と設定生成を担いますが、具体的なコアの機能は、使用する配布パッケージと実行設定に応じて確認してください。画面に項目があっても、すべてのコアで処理できるとは限りません。トラブル対処では、クライアント名だけから実行環境を推測せず、実際の起動ログで意図したコアが使われているかを確かめます。

Androidでは、v2rayNGがXrayコア向け、v2flyNGがV2Flyコア向けの選択肢です。操作方法が似ていても、プロトコル機能の違いを無視しないでください。インポートした設定に片方だけが対応する安全機能やフロー制御が含まれている場合は、権限や接続設定を調整する前に、機能に合ったクライアントを選びます。詳しい比較は3つのV2Rayクライアントの選び方と比較をご覧ください。

コアを移行するときは生成された設定を確認する

移行では、以前のクライアントの画面を見ながら項目を推測するのではなく、元のサブスクや完全な共有情報を出発点にします。まず移行先クライアントに専用のグループを作成し、インポート後にプロトコル、アドレス、認証、通信方式、安全設定、フロー制御を確認してください。元の設定をすぐ削除せず、先に1つの接続先で動作を検証します。元データに拡張パラメーターがなければ、移行先クライアントが対応していても、不足情報を復元することはできません。

ネイティブJSONを移行するときは、完全な設定と一部のアウトバウンド設定を区別します。完全な設定にはローカルの待ち受け、ルーティングのタグ、DNS、ログ設定などが含まれる場合があります。新しいコアが個々の項目を受け付けても、全体の動作が同じとは限りません。特に、ルーティングで参照するタグとアウトバウンドのタグが一致しないと、設定を読み込めても対象の通信が意図した経路を通らないことがあります。まず最小構成で接続を検証し、ローカルの設定を段階的に移行してください。

クライアントの更新とコアの更新は、必ずしも同じ操作ではありません。配布方法によって、コアがパッケージに同梱されている場合と、クライアントの機能から管理する場合があります。実際にインストールしたパッケージと画面の説明を確認してください。出所が不明なコアのファイルを混在させるのは避けましょう。更新前に設定を書き出して保管し、更新後は主要な接続とルーティングを確認します。問題が起きたら変更した範囲を記録し、パーサー、設定生成、コアの実行のどこに変化があったかを切り分けてください。

オープンソースであることは、コードや実装を調査・改善できるという意味であり、すべての派生版が同じライセンス、リリース間隔、機能一覧を持つという意味ではありません。再配布する場合は、各コンポーネントに適用されるライセンスの要件に従ってください。日常的な選定で役立つ記録は、「クライアント、実際に使うコア、必要なプロトコル機能」の3点です。「V2Rayをインストール済み」とだけ書くより、トラブルの状況を正確に伝えられます。

サブスク形式：インポートできても設定項目がそろうとは限らない

URL、返される内容、内部設定はそれぞれ別

サブスクURLは内容を取得するための入口であり、URLの末尾で返される形式が決まるわけではありません。リクエストの応答は、共有リンクの一覧、base64でエンコードされた一覧、ネイティブJSON、またはエラーページなどさまざまです。クライアントは取得した内容を判別して項目を解析し、自身の設定モデルに変換します。そのため、ブラウザーでURLを開けることは応答を受け取れたことを示すだけで、現在のクライアントがサーバー情報として認識できるとは限りません。

base64はエンコード方式であり、暗号化プロトコルでも、内容の安全性を保証するものでもありません。一般的なサブスクでは、複数の共有リンクをテキストとして連結してからエンコードします。デコード後も、それぞれのリンク形式に応じた解析が必要です。二重エンコード、改行の欠落、HTMLタグの混入、文字コードの誤処理などは解析に影響します。プライベートなサブスクをオンラインのデコードサービスにアップロードしないでください。サブスクURLにはアクセス情報が含まれることがあるため、機密情報として扱います。

共有リンクの項目形式は統一されていない

VMessの共有リンクにはエンコードされた構造化データが含まれることが多く、VLESSやTrojanのリンクはアドレスとクエリパラメーターを組み合わせる形式がよく使われます。SSにはまた別の共有形式があります。プロトコルの接頭辞が似ていても、クエリパラメーターをそのまま流用できるとは限りません。名前は通常メモとして使われ、変更しても接続先の機能は変わりません。一方、通信パス、サーバー名、フロー制御は接続に直接影響する場合があるため、変換時にまとめて削除しないでください。

パーサーが拡張項目に対応しているかも確認が必要です。クライアントによっては、プロトコル本体を保持しても、認識できない安全設定を無視することがあります。その結果、一覧には表示されても接続に失敗します。インポート後はサーバーの編集画面を開き、プロトコル、通信方式、安全機構、主要な関連項目を確認してください。情報が欠けていたら、項目を落とした変換結果を何度も更新するのではなく、移行先クライアントに適した元形式を探します。

ネイティブJSONはサブスク用グループの入口に適さない場合がある

ネイティブJSONは実行設定一式の場合も、部分的なアウトバウンド情報だけの場合もあります。完全な設定には、ローカルの待ち受けポート、DNS、ルーティング、複数のアウトバウンドが含まれることがあり、通常のサーバーサブスクとはインポート方法が異なります。クライアントによってはカスタム設定として管理するため、通常のサーバー一覧に自動で分割されるとは限りません。インポート前に入口の説明を確認し、完全な設定をサーバーごとの情報として扱わないようにしてください。

完全な設定をインポートすると、既存のローカル動作が置き換わる場合もあります。サブスク一覧では通常、クライアントが待ち受けやルーティングをまとめて生成しますが、カスタムJSONではそれらを独自に指定することがあります。インポート後にシステムプロキシが動かない場合は、実際の待ち受けポートがシステム設定と一致しているかを確認してください。追加のルーティングタグを使う場合は、参照先のアウトバウンドが存在するかも確認します。JSONとして正しいだけで、現在のGUIクライアントの管理方法に適しているとは限りません。

v2rayNでは、サブスクグループ管理から「サブスクグループ設定」を開き、URLを保存して該当する更新操作を実行します。「現在のサブスクを更新（プロキシを経由しない）」がある場合、これはサブスクの取得に既存のプロキシ経路を使わないという意味で、返される形式が変わるわけではありません。接続中は正常なのに直接更新できない場合は、クライアントが対応する更新方法を確認します。利用可能な接続がまったくない場合は、サブスクの入口へ直接アクセスできるかを確かめてください。

サブスク更新後にサーバーが表示されない場合は、まずリクエストが成功したか、次に内容を解析できるか、最後にグループのフィルターで非表示になっていないかを確認します。ログインページ、利用枠の案内、エラーテキストが返された場合は、形式に対応していないケースとは別の問題です。更新後に一部の項目だけ使えないなら、すべてのグループを削除するのではなく、該当するプロトコル設定を調べます。他の人に相談するときは、個人情報を削除したエラーの種類とプロトコルの組み合わせを伝え、サブスクURLや認証情報を公開しないでください。

形式変換で意味を保てるのは、元の情報が十分にある場合だけです。サーバー側の項目を推測して補うことはできません。完全な設定を簡易リンクに変換すると、複雑なルーティングやDNS設定は通常引き継がれません。リンクからJSONを作り直しても、リンクに含まれていないローカル設定は復元できません。詳しくはbase64、ネイティブJSON、共有リンクの変換で引き継げる範囲をご覧ください。変換後も重要な項目を確認し、接続テストを行ってください。

ルーティングと設定：プロトコル接続を確認してから振り分ける

ローカルの入口とリモートのアウトバウンドを区別する

ローカルのSOCKSまたはHTTP待ち受けはアプリのリクエストを受け取り、リモートのアウトバウンドはサーバーへ接続します。両者のポートはまったく異なる場合があります。サーバー側のポートをアプリのローカルプロキシ設定に入力しないでください。画面に表示されるローカルポートは例にすぎず、実際の値はクライアントが現在待ち受けているポートに合わせます。ローカルポートが別のプログラムに使われているとコアが起動できず、リモートの設定が正しくても使われません。

以下は、設定項目の関係を説明するための実際のインバウンド設定の一部です。単独でサーバーに接続できる完全な設定ではありません。この設定はローカルのループバックアドレスのみで待ち受けるため、アプリは同じ端末の該当ポートへ接続します。アプリの設定問題を解決するために、待ち受けアドレスをすべてのネットワークインターフェースに変更しないでください。ほかの端末からローカルプロキシへアクセスできる範囲が変わります。リモートのプロトコルと認証情報は、別途完全なアウトバウンド設定で指定します。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

domainStrategyはルーティングの照合時に名前解決をどう扱うかを指定

ルーティングのdomainStrategyは、ルールの照合中に宛先ドメインをどう扱うかを決めます。AsIsは元の宛先形式を優先し、IPルールのためにドメインを積極的にIPアドレスへ変換しません。IPIfNonMatchはドメインルールに一致しなかった場合に名前解決を試み、その後にIP関連の照合を続けます。IPOnDemandはIP情報が必要なルールの照合時に名前解決を行います。いずれも照合過程に影響する設定で、リクエストが必ずプロキシ経由または直接接続になると決めるものではありません。

これらの値を、アウトバウンドや別のモジュールにある似た名前の設定と混同しないでください。選ぶ前に、設定がどのオブジェクトに属するかを確認し、その意味を読みます。アプリが最初からIPアドレスだけを指定している場合、ルーティング側で照合できるドメイン情報がないことがあります。スニッフィングによって通信内容からドメインの手掛かりを得られる場合もありますが、すべてのプロトコルや通信に有効とは限らず、アプリが使った完全なドメイン情報を復元できる保証もありません。

DNS、ルールの順序、宛先形式が結果を左右する

一般的なルーティングでは、上から順に条件に合うルールを探します。広い条件を先に置くと、後ろの細かいルールが適用されない場合があります。ドメインルールやIPルールは、照合時に使える宛先情報にも左右されます。「ルールを書いたのに適用されない」ときは、まずリクエストの宛先がドメインかIPかを確認し、次に先に一致するルールを特定して、最後に宛先のアウトバウンドタグを調べます。最初からすべてのルール範囲を広げるのは避けてください。

コアのDNSとOSのDNSでは、適用範囲が異なる場合があります。アプリが自分で名前解決することもあれば、コアがルーティング判定のために再度解決し、さらにリモートサーバーが最終的な宛先を解決することもあります。DNSアドレスを1つ変更しても、すべてのリクエストが同じ経路を使うとは限りません。ドメインでは接続できるのにIPルールが想定どおりに動かない場合は、名前解決が行われる場所、返されたアドレスの種類、キャッシュを確認してからdomainStrategyを見直します。

Androidのアプリごとのプロキシ設定では、どのアプリをVPN経由にするか、またはVPNを迂回させるかを制御します。コアのルーティングは、VPNに入った後の通信経路を決めます。迂回モードでは、アプリ一覧が「対象アプリ」から「除外するアプリ」に変わる場合があるため、画面の説明を確認してください。変更後、システムに新しい対象範囲を反映するには、クライアントの案内に従ってVPNを再接続する必要があります。テストでは対象アプリと接続先を1つずつ決め、アプリ一覧、DNS、ドメインルールを同時に変更しないでください。

次の順に確認します。ローカルの待ち受けが開始していること、アプリのリクエストが実際に入っていること、プロトコル接続が正常であること、最後にルーティングを追加することです。問題が起きたら、検証済みのシンプルな設定に一時的に戻し、ルールを1つずつ追加し直します。ルーティング、DNS、プロキシモードに関するよくある事例はよくある質問をご覧ください。「入口につながっていない」「リモートに接続できない」「ルールに一致しない」を別々の問題として切り分ければ、プロトコル設定を何度も試し直す必要はありません。

利用シーンとトラブル対処：選定から確認手順につなげる

デスクトップでは先にクライアントを選び、次にプロトコルの組み合わせを確認

デスクトップではまずv2rayNを使い、ダウンロードページでOSと端末のアーキテクチャに合ったインストーラーを選びます。インストーラーの画面形式とリモートのプロトコルは別の選択です。Windowsのデスクトップ版と従来のWPF版は、画面や配布形態の違いであり、別途購入したり異なるプロトコルの接続口を作成したりする必要はありません。サブスクがある場合は、まずインポートして1つの接続を検証し、その後で画面の使い方やローカルのグループを調整してください。

Androidでは、Xrayの機能が必要な設定ならv2rayNGを選びます。既存の設定がV2Fly向けで、必要な機能にも対応しているならv2flyNGを検討できます。両方のアプリが同じ接頭辞を認識するからといって、関連する安全設定を無視しないでください。長時間のバックグラウンド利用では、VPN権限、省電力設定、アプリごとの対象範囲も確認します。OSによる権限の取り消しで接続が切れた場合、UUIDの変更や暗号化方式の切り替えでは解決しません。

使える選択肢は現在の接続情報で決まる

有効なサーバー情報が1つしかない場合は、一般的な順位で別のプロトコルを選ぶより、まずその設定を正しく行います。サーバーに複数の接続口がある場合は、クライアントの対応状況、情報の完全性、実際のアプリでの動作、保守の手間を比べてください。端末間で頻繁に移行する人にとっては、形式の汎用性や主要項目を完全にインポートできるかが、わずかなプロトコルのオーバーヘッドより重要な場合があります。特定のXray機能が必要なら、コアの対応は欠かせません。

LANの管理、ウェブ閲覧、継続的なデータ転送では、接続に求められる条件が異なります。ウェブ閲覧では短いリクエストが多く、リアルタイムアプリでは接続の安定性とUDP経路、長時間の転送では回線の持続的な容量が重要です。プロトコル名だけで実際の用途を判断することはできません。実際のタスクを1つ選び、同じネットワーク条件で試したうえで、切断後の再接続やネットワーク切り替え後の復旧も確認してください。一覧に表示される1回の測定結果より、実際の利用要件に近い評価ができます。

推測で設定を変えず、失敗した段階から原因を探る

最初にコアが起動しているか確認します。設定解析の失敗、不明な項目、ポートの競合が表示された場合は、まずローカルの問題を解消してください。次にサーバーのアドレスとポートへ接続できるかを確認します。接続タイムアウトはアドレス、経路、サーバー側の待ち受けなどが原因となる場合があり、この段階ではパスワードの誤りとは断定できません。続いて安全なハンドシェイクを確認し、システム時刻、サーバー名、証明書、REALITYの設定を調べます。プロキシ認証と宛先への転送を確認するのは最後です。

ログで接続が確立しているのにアプリにデータが届かない場合は、リクエストが実際にクライアントに入っているかを確かめてから、DNS、ルーティング先、リモート側の接続状態を確認します。特定のサイトだけ失敗し、ほかは正常なら、クライアントを再インストールするのではなく、該当ドメインとアプリの動作に範囲を絞ります。UDPを使う通信だけで問題がある場合は、TCP接続が1回成功したことを根拠にすべて正常と判断せず、ローカルの入口、プロトコルの対応、サーバー側の転送機能を確認してください。

サポートを受ける際は、失敗した操作に対応するログの一部を保存し、クライアント、実際に使っているコア、プロトコル、通信方式、安全機構、失敗した段階を記録してください。サブスクの認証情報、パスワード、ユーザーID、アカウントに結び付く情報は削除します。スクリーンショットも、隠れた欄やアドレスバー全体に情報が残っていないか確認してください。「つながらない」だけでは調査を最初から始めることになりますが、「安全なハンドシェイクに失敗」と分かれば、無関係な設定を多数除外できます。

最終的には、次の3点を確認すれば選択肢を絞れます。サーバーがどのような設定一式を提供しているか、現在のコアでその設定をそのまま表現できるか、対象端末で実際のアプリが安定して使えるかです。3点が明確になったら、ルーティングとバックグラウンド動作を調整します。初回接続の手順はクイックスタートガイドを、繰り返し起きる症状はよくある質問を参照してください。設計上の違いを知りたい場合は、このガイドの該当章に戻ります。操作、仕組み、トラブル対処を分けて考えると、設定を保守しやすくなります。