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

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

v2rayN、v2rayNG、v2flyNGは、サブスクリプションの保存や設定の表示、実行パラメーターの生成、システムプロキシや仮想ネットワークインターフェースとの連携を担うGUIクライアントです。コアは接続の確立、プロトコル処理、名前解決、ルーティングを担当します。サーバーは接続先で動作するサービスです。画面上で選択できる名称は、クライアントがその設定を扱えることを示すにすぎません。実際に使えるかどうかは、稼働中のコアとサーバー側の設定にも左右されます。画面上の対応を、接続経路全体での対応と混同しないようにしましょう。

設定を選ぶ際は、アウトバウンド接続を複数の層に分けて考えると整理しやすくなります。プロキシプロトコルはユーザー認証と宛先の指定方法を定め、通信方式はデータを相手まで届ける方法を担います。セキュリティ層は接続の保護と相手の認証を行い、ルーティングはどのリクエストをこのアウトバウンドに流すかを決めます。インバウンドは端末上のアプリからトラフィックを受け取ります。それぞれ連携しますが、互いの代わりにはなりません。ルーティングモードを切り替えてもパスワードの誤りは直らず、システムプロキシを有効にしても不足しているサーバー証明書名は補われません。

プロトコル名が表すのは接続の一部分

たとえば、VLESSには複数の通信方式やセキュリティ設定を組み合わせられます。同じVLESSでも、一方は通常のTLS、もう一方はREALITYを使う場合があり、必要な設定項目やサーバー側の対応状況は異なります。WebSocketは通信を運ぶ方式の一つであり、VLESSと同列のプロキシプロトコルではありません。TLSも、ノード認証用パスワードの別名ではありません。サブスクリプションの詳細を確認するときは、プロトコル、アドレス、ポート、通信方式、セキュリティ方式、認証情報をそれぞれ記録し、プロトコル名だけで判断しないようにしましょう。

クライアントの「アドレス」は通常、サーバーへの接続に使うドメイン名またはIPアドレスです。「サーバー名」はTLSのserverNameにあたり、SNIと表示されることもあります。WebSocketのHostとパスはアプリケーション層のリクエストに属します。これらは同じ値の場合もあれば、サーバー側の指定により異なる場合もあります。すべてをアドレス欄のドメイン名にそろえると見た目は整いますが、証明書の検証やリバースプロキシの振り分けに支障が出ることがあります。項目名の似ているかどうかではなく、設定提供元の指定に従ってください。

「インポートできた」と「接続できた」は別々に確認

インポートに成功したということは、クライアントが入力形式を受け付け、設定を登録できたというだけです。一部の詳細項目が認識されなかったり、初期値が元の設定と異なったりすることもあります。実際に接続するには、アドレスへの到達性、ポートの開放、認証情報の一致、セキュリティ層の設定、宛先リクエストとルーティングルールの整合が必要です。名前やアイコンが正しく表示されているノードでも、ハンドシェイク前に失敗することがあります。まず詳細設定を確認し、単一接続で動作を検証してから、使い勝手を比較しましょう。

このように階層ごとに整理すると、トラブルの原因を絞り込めます。リクエストログがまったくない場合は、インバウンドとルーティングを確認します。サーバーには接続できても認証に失敗する場合は、プロトコルの認証情報を確認します。証明書やハンドシェイクのエラーなら、セキュリティ層と時刻を確認します。特定のサイトだけ失敗する場合は、DNS、接続先サイト、ルーティングを調べます。プロトコル、コア、ルーティングを一度に変更するより、層ごとに確認するほうが問題を再現しやすくなります。主な設定項目の簡単な説明は用語集を、本ページの以降の章では各層の違いや制約を参照してください。

VMess：プロトコル内での認証とデータ保護

VMessはProject Vのエコシステムとともに発展し、ユーザー識別子を使って認証を行い、プロトコル自体でデータを保護します。外側にセキュアな通信路を設ける方式と比べ、プロキシプロトコルがより多くの役割を担います。実際の設定ではUUIDだけでなく、実装が採用する認証方式や暗号化オプションにも注意が必要です。古い設定にある追加の識別子項目には歴史的な経緯があるため、古い記事を参考に数値を安易に追加しないでください。現在のサーバーに接続するときは、双方の実装が対応している認証方式を基準にします。

VMessの認証では時刻が重要です。端末の時刻が大きくずれていると認証に失敗することがありますが、エラーに「時刻の誤り」と明記されない場合もあります。まずシステムの自動時刻設定を有効にしてから認証ログを確認すると、サブスクリプションを何度も更新するより早く解決できることがあります。クライアントとサーバーの設定が明確で、安定して稼働している環境には適しています。正常に動作している接続を、別のプロトコルに乗り換える必要はありません。プロトコルの歴史の長さだけで性能や実装の保守状況を判断することもできません。

VLESS：役割を適切な層に分ける

VLESSは比較的シンプルな設計のプロキシプロトコルで、認証とリクエストの指定を担います。VMessのようにプロトコル自体が同等のデータ暗号化機能を提供するわけではありません。そのため、VLESSの設定でencryptionがnoneでも、接続全体が必ず平文になるとは限りません。TLSやREALITYが通信を保護する場合があります。逆に、VLESSという名称だけで接続が保護されているとも判断できません。設定を確認するときはセキュリティ層も併せて確認し、ドロップダウンのnoneだけを見て解釈しないでください。

VLESSではflowも確認が必要な項目です。Visionに関連する値など、特定のデータ処理方式を表しますが、どの通信方式にも自由に組み合わせられるわけではありません。クライアントで入力できても、サーバー側が受け入れるとは限りません。サブスクリプションに項目がないからといって手動で追加する必要もありません。サーバー側でflowが指定されている場合は、その値を変更せず、コアが対応していることを確認してください。設定項目が少ないから自由に組み合わせられる、というのはよくある誤解です。プロトコル自体の役割が少ないほど、各層の境界を正しく理解することが重要になります。

Trojan：TLSを使ったプロキシ接続

Trojanは一般に、外側をTLSで保護し、その内側でパスワード認証とプロキシリクエストを処理します。ユーザーが主に設定するのは、サーバーアドレス、ポート、パスワード、サーバー名です。パスワード認証と証明書検証は役割が異なります。前者は利用権限を確認し、後者は接続先が想定した相手かどうかを確認します。パスワードを修正しても証明書名の不一致は解消せず、証明書検証を無効にしてもパスワードの誤りは直りません。失敗した段階を確認して対処しましょう。

Trojanを選ぶ際は、証明書チェーン、サーバー名、リバースプロキシの有無を確認してください。ドメイン名で接続すれば、証明書との対応を保ちやすくなります。IPアドレスを指定する場合でも、正しいサーバー名を別途指定する必要があることがあります。追加の通信方式や多重化機能に対応しているかどうかは、使用するコアとサーバー実装を確認してください。特定のクライアントにある拡張機能が、すべてのTrojan環境で使えるとは限りません。プロトコル本来の仕様と実装による拡張は分けて考えましょう。

Shadowsocks：シンプルなデータカプセル化と方式の互換性

Shadowsocksは通常、プロキシのデータストリームを直接暗号化してカプセル化します。設定で重要なのは、アドレス、ポート、暗号化方式、パスワードです。証明書のハンドシェイクを必須としないため、外部の構成要素を減らしたい環境で使われることがあります。ただし、Shadowsocksのすべての暗号化方式に互換性があるわけではありません。従来方式、最新のAEAD方式、Shadowsocks 2022シリーズでは要件が異なり、パスワードの形式や長さの制約も変わることがあります。方式名を確認せず、パスワードだけをコピーしないでください。

具体的な方式は、サーバー環境やUDPの必要性、端末のコアが対応する方式、サブスクリプションで必要な項目を完全に指定できるかを踏まえて選びましょう。「軽量だから」という理由だけで、すべてのスマートフォンでShadowsocksのほうが省電力だとは言えません。VLESSの設定項目が少ないからといって、必ず高速とも限りません。詳しい比較は4つのプロトコルを用途別に比較をご覧ください。基本方針は、まず互換性と必要な機能を満たし、条件をそろえてから負荷を比べることです。

REALITYはセキュリティ機構であり、独立したプロキシプロトコルではありません

REALITYはVLESSと組み合わせて使われることが多いものの、両者は同じ階層の代替項目ではありません。VLESSはプロキシリクエストを処理し、REALITYは外側の接続でセキュアなハンドシェイクと関連する検証を行います。クライアント設定には、サーバー名、サーバー公開鍵に関するパラメーター、Short ID、クライアントフィンガープリントなどがあります。サーバー側の秘密鍵をクライアントのサブスクリプションに含めてはいけません。公開鍵関連の項目名は画面によって異なる場合があるため、名前の新旧だけで正否を判断せず、使用中のクライアントとコアのドキュメントを参照してください。

REALITYのハンドシェイクでは、クライアントの設定とサーバー側の設定が一致している必要があります。サーバー名は通常、サーバー側で許可された範囲内でなければなりません。公開鍵関連のパラメーターはサーバーの鍵と対応し、Short IDもサーバーが受け付ける値である必要があります。Short IDを空にできる環境もあれば、明示的な指定が必要な環境もあるため、一律には判断できません。クライアントフィンガープリントはハンドシェイクの特徴を構成するもので、ブラウザー名を適当に入力すれば接続が改善するわけではありません。有効な値と動作はコアの実装に依存します。

TLS：ポートに接続できるだけでは不十分

通常のTLS接続では、証明書チェーンと証明書名を検証する必要があります。サーバーのポートにTCP接続できても、ネットワーク層で接続できたことを示すだけで、相手の証明書が信頼できることやプロキシ認証の成功までは保証しません。よくある原因には、端末の時刻ずれ、中間証明書の送信漏れ、サーバー名と証明書の不一致、リバースプロキシによる誤った転送があります。こうした問題は証明書やサーバー構成を修正して解決し、検証のスキップを常用設定にしないでください。

ALPNはアプリケーション層のプロトコルをネゴシエートするためのもので、自由に使える高速化オプションではありません。特定の通信方式は所定のネゴシエーション結果を必要とし、サーバー側がその結果に応じて処理経路を選ぶ場合もあります。手動で削除や変更をすると、ハンドシェイク後のリクエストが失敗することがあります。サブスクリプションにALPNが指定されている場合は、まずその値を維持してください。指定がない場合も、別のノードの値を安易にコピーしないでください。一見任意に見える項目も、環境によっては明確な役割があります。

TCP・WebSocket・gRPCの実際のコスト

TCPを直接使う構成は経路が比較的シンプルで、追加のカプセル化も少なめです。WebSocketではHTTP Upgradeの後にデータを運ぶため、パスとHostの一致も必要です。gRPCは通常HTTP/2に依存し、サービス名の設定と途中のプロキシによる対応が欠かせません。これらの通信方式は、データの運搬やサーバー構成との適合を担うもので、「複雑なほど高機能」という序列ではありません。新しい名前の方式を選ぶより、サーバー側が実際に対応する組み合わせを使うことが大切です。

リバースプロキシを経由する場合は、アイドルタイムアウト、リクエストサイズ制限、長時間接続の処理、上流側のプロトコルも確認します。Webページは表示できても、長時間のセッションが定期的に切れる場合は、どこかの層のタイムアウトが原因かもしれません。プロキシプロトコルの認証が突然無効になったとは限りません。WebSocketのパスが1文字違う、gRPCのサービス名が変換時に失われるといった理由で、サーバーから通常のHTTPエラーが返ることもあります。その場合はパスとプロキシログを確認し、ローカルの待ち受けポートをむやみに変更しないでください。

多重化とUDPは接続経路全体で考える

多重化では、複数の論理接続で一つの基盤接続を共有し、接続の繰り返しを減らせる場合があります。一方、共有接続で発生した輻輳や障害の影響が、複数の接続に及ぶこともあります。通信方式自体が多重化に対応している場合、さらに多重化を重ねても効果がないことがあります。有効にするかどうかは、コア、プロトコル、サーバー、アプリの特性を踏まえて判断し、常時有効にする設定とは考えないでください。特にトラブル対処中は、まずシンプルな構成で基準を取り、その後、多重化の有無による短いリクエストと継続的な転送の違いを比べましょう。

UDPが使えるかどうかは、インバウンド、プロキシプロトコル、コアのカプセル化、サーバー、接続先ネットワークがそれぞれ対応しているかに左右されます。ローカルのSOCKSインバウンドでUDPを受け付けても、通常のHTTPプロキシインバウンドが同じ動作をするとは限りません。アプリがそのインバウンドを利用していなければ、プロトコルがUDPに完全対応していても機能しません。音声通話やゲームなど、UDPを使うアプリに問題がある場合は、端末からクライアント、アウトバウンド、サーバーまでの経路を順に確認してください。「ノードがUDP対応」という表示だけで結論を出さないようにしましょう。

接続確認の遅延、最初の応答、継続的な転送速度を区別する

クライアントのTCP遅延は通常、サーバーポートへのTCP接続にかかる時間を示します。実際のリクエストでは、さらにセキュリティハンドシェイク、プロキシ認証、接続先サイトの応答が加わる場合があります。測定対象が異なるため、結果をそのまま比較することはできません。TCP接続の速い接続先でも、宛先へのルート、DNS、サーバー負荷によってウェブページの表示が遅くなることがあります。逆に、特定の測定が失敗しても、測定先や方法が適切でない可能性があり、すべての通信が失敗すると断定はできません。

最初の応答時間は、新しいリクエストを開始してデータを受け取るまでの時間です。継続的な転送速度は、接続確立後にどれだけのデータを送れるかを示します。セキュリティハンドシェイクや通信方式の切り替えは前者に、回線帯域、輻輳制御、サーバーの外向き回線は後者に影響しやすくなります。ウェブページでは小さなリソースを多数同時に取得するため、大きなファイルを問題なく転送できても、ページ表示が速いとは限りません。プロトコルを比較する前に、新規接続、日常のブラウジング、長時間の転送のどれを改善したいのかを明確にしましょう。

プロトコルのコストは条件をそろえて比較する

プロトコルのカプセル化、認証、暗号化には計算リソースが必要ですが、使い勝手を左右する要因はそれだけではありません。接続先までの距離、パケットロス、ネットワークの切り替わり、サーバーの輻輳、接続先サイトの違いは、プロトコルヘッダーの数バイトより大きく影響することがあります。公平に比べるには、同じ端末、同じネットワーク、同じサーバーの地域、同じ測定先を使うのが基本です。サブスクリプションが異なるサーバーに接続している場合、結果が示すのは接続経路全体の差であり、プロトコル名だけの差ではありません。

端末の性能によっても結果は変わります。プロセッサーごとに暗号化アルゴリズムのハードウェアアクセラレーション対応は異なり、コアの実装、OSのスケジューリング、温度制限も処理時間に影響します。ノートPCは電源接続時と省電力モードで性能が異なることがあり、スマートフォンも長時間動作すると熱による性能制限がかかる場合があります。端末や測定条件を固定しない限り、あらゆる環境に当てはまるリソース使用量の順位を示すことはできません。一般ユーザーにとっては、わずかな瞬間的な差より、安定して必要なアプリを使えることが大切です。

メモリとバッテリー消費は動作方法に左右される

メモリはプロトコル処理だけでなく、接続バッファー、DNSキャッシュ、ルーティング用リソース、画面上のリストにも使われます。大量のノードをインポートしたり、詳細ログを長期間保存したり、大きなルールセットを読み込んだりすると、プロキシプロトコルを変えるよりもメモリ使用量に影響することがあります。比較するときはGUIクライアントとコアのプロセスを分け、起動直後ではなく安定稼働後の状態を確認してください。重複するグループを削除し、不要なログの保存期間を短くするほうが、数値を下げようとコアを何度も切り替えるより、結果を把握しやすくなります。

モバイル端末のバッテリー消費は、無線モジュールの起動頻度と関係することがよくあります。頻繁な接続テスト、短すぎる接続維持間隔、ネットワークが不安定なときの連続再接続、バックグラウンドアプリからの継続的なリクエストは、端末が稼働状態にある時間を延ばします。1回のハンドシェイクがわずかに短いプロトコルでも、実際のネットワークで頻繁に切断されるなら、結果的に消費電力が増えることがあります。アイドル時、通常のブラウジング時、ネットワーク切り替え後の状態を確認し、短時間のテストだけで一日分の使い勝手を判断しないでください。

再現できる比較記録を作る

まず動作確認済みの設定を1つ残し、測定するサイトとアプリを固定します。初回リクエスト、継続的な転送、アイドル時の接続維持、ネットワーク切り替え後の復旧をそれぞれ記録してください。1回のテストで変更する項目は1つにし、終了後は基準設定に戻してから次の項目を試します。プロトコル、サーバー、DNSを同時に変えると、使い勝手が改善しても原因を特定できません。ノードの速度測定は参考情報です。実際のタスクを継続して完了できるか、エラーを再現できるかを最終判断の基準にしましょう。

Project V、V2Fly、Xrayの関係

Project Vは、このツールのエコシステムを理解するうえでの背景です。V2Rayはその中で広く使われてきたコア実装でした。V2FlyコミュニティはV2Rayコアの開発と保守を引き継ぎ、Xrayは関連するコードを基盤に独立したプロジェクトとして発展し、独自の機能方針で進化を続けています。両者には歴史的なつながりがあり、共通する概念も多くありますが、同じプログラムの別名ではありません。ドキュメントを読む際は、どのコアを対象にした内容かを確認し、一方の新機能がもう一方にも当然備わっていると考えないようにしましょう。

どちらのコアも、プロキシ接続、ルーティング、名前解決などを担いますが、プロトコルの拡張機能、通信の細部、DNSの動作、設定項目には徐々に違いが生じています。REALITYやXTLS VisionはXrayの機能を理解するうえでよく登場しますが、V2Flyで同名の設定項目に同じパラメーターを指定できるとは限りません。反対に、V2Flyのドキュメントにある通信方式や特定のオプションも、共通の歴史だけを根拠にXrayで完全に互換だと判断せず、現在の実装で確認してください。

3つのクライアントの選び方

デスクトップでは、まずv2rayNを検討してください。Windows、macOS、Linuxに対応し、GUIでサブスクリプションを管理したり、アウトバウンドの設定を確認したりできます。配布パッケージによって画面や同梱コンポーネントが異なる場合があるため、選ぶ前にクライアントのダウンロードページでOSとアーキテクチャの説明を確認してください。Windowsのデスクトップ版にはクロスプラットフォームの画面を使うものと、従来の操作感を保つWPF版があります。これはクライアントの画面と配布形式の違いであり、特定のプロトコルの速度やコアの機能数を直接示すものではありません。

Androidでは、Xrayコアを使用するv2rayNGをまず検討してください。V2Flyとの互換性を確認する必要がある場合は、v2flyNGも選択肢になります。画面上の概念が似ていても、プロトコル拡張の対応範囲が同じとは限りません。サブスクリプションにXray固有のパラメーターが含まれている場合は、インポート後に未対応項目を削除するのではなく、選択したクライアントとコアが適合しているか先に確認してください。項目を削除すれば起動できるように見えても、サーバー側の要件を満たせなくなることがあります。

設定構文が似ていても、そのまま移行できるとは限らない

コアのJSONで使われるインバウンド、アウトバウンド、ルーティングには共通する概念がありますが、項目、初期値、許可される組み合わせが一致するとは限りません。設定ファイルがパーサーに受け付けられても、期待どおりに動作するとは限りません。未知の項目が無視されたり、初期ルーティングやDNSの問い合わせ経路が変わったりする場合があります。移行時はまずプロトコルとセキュリティ層を確認し、次に通信方式、最後にルーティングとDNSを確認してください。複雑な設定を一度に移すと、失敗時に原因となった層を特定しにくくなります。

クライアントは通常、独自のノード設定をコア用の設定に変換します。画面上で設定を変更すると、次回の起動時に生成ファイルが上書きされる場合があります。そのため、一時的な実行ファイルを直接編集しても、変更を維持できないことがあります。高度なカスタマイズが必要な場合は、クライアントが正式に対応するカスタム設定の入力欄を使い、標準ルーティングを置き換えるか、サブスクリプション更新を引き続き受け付けるかを確認してください。実行ログで実際に起動したコアを確認できますが、ファイルパスや設定内容を公開しないよう注意してください。

更新や移行では元に戻せる手段を確保する

クライアントの更新とコアの更新では、解決する問題が異なります。前者は画面、サブスクリプションの解析、パラメーター生成に影響し、後者はプロトコルの実装や実行時の動作を変えることがあります。更新後に問題が起きたら、どの部分を変更したか記録し、一括して「新しいバージョンは使いにくい」と判断しないでください。まず少数の設定で基本接続、よく使うアプリ、ネットワーク切り替えを確認し、その後にルールを戻します。明確な必要がなければ、拡張機能を試すためにすべてのコンポーネントを同時に入れ替える必要はありません。

元に戻せる手段を用意することは、古い実装を使い続けるという意味ではありません。変更の影響を比べるための基準を残すということです。更新前に必要な設定をエクスポートし、重要な画面設定を記録してから、起動ログと実際のリクエストを比較します。画面に表示されたコアの種類が想定と異なる場合は、まずクライアントの設定を修正してください。特定の拡張機能だけが失敗する場合は、その機能のドキュメントを確認します。エコシステム、クライアントの機能、実際に動作するコアを分けて考えると、「同じ設定なのに結果が違う」という誤解を避けやすくなります。

サブスクリプションURL、共有リンク、実行設定

サブスクリプションURLは複数の設定を取得するためのもの、単一ノードの共有リンクは1つの接続を表すもの、コアの実行設定はプロセスの動作を記述するものです。これらは同じファイル形式ではありません。サブスクリプションの応答は複数行のリンクの場合もあれば、Base64エンコードやクライアント固有の形式の場合もあります。ブラウザーでURLを開けても、内容が返ってきたことしか確認できません。ログインページ、案内文、エラーページが返された場合、クライアントは形式エラーを報告することがあります。更新に失敗したときは、接続の問題と応答形式の問題を分けて確認してください。

よく使われる共有形式にはvmess、vless、trojan、ssなどのURIスキームがあります。VMessの共有では、エンコードされたJSONペイロードが使われることがありました。VLESSやTrojanでは、接続パラメーターをクエリ部分に含める形式が一般的です。Shadowsocksにも、認証情報のエンコード方法など複数の記法があります。共有リンクのパラメーターは形式の一部であり、自由に編集できるメモではありません。同じプロトコルでも共有形式によって項目名が変わったり、表現できる内容に制限があったりします。先頭の数文字だけで完全な互換性を判断しないでください。

インポート時に失われやすい設定

高度なセキュリティ設定、flow、ALPN、クライアントフィンガープリント、WebSocketのHostとパス、gRPCのサービス名、一部のUDPカプセル化オプションは、特に確認が必要です。サブスクリプション形式によっては、基本的な接続情報しか表現できず、コアのすべての機能を保持できない場合があります。変換ツールが認識しない項目を省略したり、クライアントが未対応の項目を基本アドレスやメモだけ残して取り込んだりすることがあります。インポートに成功していても、元の設定と同等とは限りません。

エンコードの処理も結果に影響します。クエリパラメーター内の特殊文字には正しいパーセントエンコードが必要です。リンクのメモと認証情報で、異なるエンコード規則が使われることもあります。コピー時に末尾が欠ける、リンクの途中に改行が入る、エンコード済みの内容を二重にデコードするといった操作で、解析結果が変わることがあります。リンクを読みやすく見せるために記号を手作業で置き換えないでください。変更が必要な場合は、共有テキストの見た目だけを比べず、クライアントの詳細画面で各項目を確認しましょう。

サブスクリプション更新に失敗したときの確認手順

まずURLが完全か確認し、特にクエリパラメーター付きのリンクが途中で切れていないかを調べます。ログインが必要か、URLの有効期限が切れていないか、端末からサブスクリプションサービスにアクセスできるかも確認してください。ログにネットワークタイムアウトが表示される場合は、更新時に直接接続しているのか、現在のプロキシを経由しているのかを確認します。クライアントによっては複数の更新経路を選べます。現在のプロキシが使えないとき、そのプロキシ経由で更新しようとすると循環してしまいます。利用環境で到達可能な経路を選び、同じボタンを何度も押して結果が変わるのを待たないでください。

リクエストが成功しても解析に失敗する場合は、応答内容がウェブページではなく、使用中のクライアントに対応したサブスクリプション形式か確認します。アカウント情報が含まれる可能性があるため、サブスクリプション全体を見知らぬ変換サービスにアップロードしないでください。正しい形式を設定提供元に問い合わせるのが確実です。問題を報告する際は、エラーの種類、クライアント名、使用中のコア、機密情報を除いた設定構造を伝えれば十分です。共有リンク全体を公開したり、認証情報を公開の場に投稿したりしないでください。

グループ管理と更新による上書き

サブスクリプション内のノード設定は、更新時に再生成されることが多く、手動での変更が上書きされる場合があります。長期間使う検証用の設定は、独立したローカルグループにコピーし、用途を明記してください。ただし、グループのメモはセキュリティ上の隔離機能ではなく、設定を整理するためのものです。グループを削除する前に、手動で管理しているノードが含まれていないか確認しましょう。重複する設定を定期的に整理すると、古い接続先を誤って選ぶリスクも減らせます。

クライアント間で移行する場合は、サブスクリプション全体を読み込む前に、単一の設定を往復させて内容を確認してください。重要なのはノード数が一致することではなく、必要なパラメーターが保持されることです。基本設定が同じなのに動作が異なる場合は、コアの互換性に関する章で拡張機能の対応状況を確認します。接続はできてもルーティングが異なる場合は、クライアント側のルーティングを確認してください。サブスクリプションには通常、ルーティングポリシー全体は含まれません。サブスクリプションが接続情報を提供し、その情報の使い方はローカルのクライアントが決定します。

デスクトップでの作業：まずアプリの接続経路を確認

デスクトップでは、まずv2rayNでシンプルかつ検証可能な設定を用意してください。ブラウザー、ターミナル、業務用ソフトが同じプロキシ設定に従うとは限りません。システムプロキシを参照するアプリもあれば、独自設定を使うアプリや、個別の設定が必要なアプリもあります。特定のブラウザーでアクセスできても、すべてのプログラムがコアを経由しているとは限りません。プロトコルの違いを比べる前に、アプリの実際の経路を確認しましょう。システムプロキシが有効なのはシステム設定に従うアプリであり、端末の全通信を自動的に制御するものではありません。

日常の業務では、短いリクエスト、会議の長時間接続、バックグラウンド同期が発生します。単発の速度測定だけでなく、長時間接続の安定性、DNSの一貫性、ルールの分かりやすさを重視してください。正常に動作しているTLSまたはREALITYの設定があるなら、まずは既定値のまま使ってみましょう。UDPが必要なアプリでは、経路の各段階で対応状況を確認してください。すべての通信を同じ経路に見せるために複雑なモードを急いで有効にせず、必要な条件を確認してからインバウンドとルーティングの範囲を決めましょう。

通勤中のスマートフォン：ネットワーク切り替えとアイドル後の復旧を確認

Androidではv2rayNGを優先し、Xrayが対応するプロトコルの組み合わせに沿って設定を確認してください。Wi-Fiとモバイルネットワークを切り替えると送信元アドレスや基盤接続が変わり、既存の接続は復旧または再確立が必要になることがあります。復旧速度はプロトコルだけでなく、クライアントのネットワーク監視、OSのバックグラウンド制限、サーバーのタイムアウト、アプリの再試行動作にも左右されます。テストでは実際にネットワークを切り替えて普段使うアプリを開き、固定ネットワークで一度接続できただけで判断しないでください。

省電力設定は症状に応じて調整します。OSがクライアントを停止すると、画面を閉じた後に接続が切れることがあります。一方、バックグラウンド動作をすべて許可すると、必要以上に稼働時間が延びる場合があります。まずOSがクライアントに過度なバックグラウンド制限を適用していないか確認し、アイドル時に再接続や接続確認が頻発していないかを調べます。必要なバックグラウンド動作だけを許可し、高頻度の速度測定で接続を維持しようとしないでください。必要なのは利用中の安定性であり、アイドル時の余分な起動を抑えることです。

低速・不安定な回線：プロトコル変更より先に条件を整理

低速・不安定な回線では、パケットロス、遅延の揺れ、断続的な切断がよく問題になります。プロキシプロトコルを変えても、基盤となる回線の問題が自動で直るわけではありません。まず経路が安定し、通信構成を把握しやすい設定を選び、トラブル対処中は多重化や追加の転送を重ねないようにしましょう。新しいリクエストが頻繁に失敗する一方、確立済みの接続が比較的安定している場合は、ハンドシェイクと再接続を確認します。継続的な転送が止まる場合は、輻輳とパケットロスを調べます。状況ごとに確認方法は異なり、「プロトコルが低速回線に合わない」と一括して説明することはできません。

多重化は短いリクエストが多い場合、接続の再確立を減らせることがあります。一方、共有する基盤接続に問題が起きると、複数の論理リクエストが同時に影響を受けることがあります。まず任意の多重化を無効にして基準を取り、用途ごとに比較するほうが「低速回線では必ず有効にする」という一般論に従うより確実です。HTTP/2に依存する通信方式を使う場合は、経路上のプロキシが長時間接続を安定して維持できるかも確認してください。複雑な構成が有効な場面もありますが、不安定なネットワークの調査時に未知の要素を増やすべきではありません。

継続的な転送とリアルタイムアプリは別々に確認

ファイル転送では継続的な速度、接続の安定性、サーバーの外向き回線が重要です。リアルタイム音声では、遅延の揺れ、パケットロス、UDP経路がより重要になります。ダウンロード速度が速くても通話品質が良いとは限りません。ウェブページの応答が速くても、大容量転送で温度制限や帯域制限が発生しないとは限りません。長時間利用するタスクでは、実際の業務を一定時間行い、端末温度、エラーログ、切断後の復旧を確認してください。日常の利用に近い条件ほど、結果の参考度が高くなります。

V2Flyとの互換性が必要な場合は、v2flyNGを使って独立した設定で検証できます。ただし、あらゆる接続障害を解決する万能な代替として扱わないでください。サーバー設定が明確にXrayに依存している場合、別のコアに切り替えると問題が増えることがあります。クライアント、プロトコル、サーバーの選択は互いに適合させる必要があります。まずサーバーで利用できる機能を確認し、次に必要な設定を完全に扱えるクライアントを選び、最後に日常のタスクで比較してください。名称の好みだけで先に決めないようにしましょう。

選択の結論はランキングではなく条件で示す

役立つ結論は、「この端末と現在のネットワークで、この設定なら会議と同期を安定して行える」のように条件を含むものです。「このプロトコルは常に最速」といった一般化は避けましょう。条件には端末、コア、インバウンド、通信方式、セキュリティ方式、サーバーまでの経路が含まれます。条件を記録しておけば、ネットワークやコンポーネントが変わったときに再検証できます。複数の設定が要件を満たすなら、構成が分かりやすく、設定の出所が信頼でき、元に戻しやすい方法を選び、長期的な管理負担を減らしましょう。

まず最小構成で動作する基準を作る

設定項目がそろった接続を1つ選び、クライアントの既定ルーティング、または記録済みのルーティングを使って、一般的なウェブページへのリクエストを確認します。最初の接続時に複雑なカスタムルールのインポート、DNSの変更、多重化の有効化、コアの切り替えを同時に行わないでください。ログを開き、コアが正常に起動したことを確認してから、リクエストが実際にコアへ届いているかを確認します。起動時点で失敗しているなら、速度測定に意味はありません。設定構文、ポートの競合、未対応オプションを調べ、プロセスが安定して動作する状態にしてください。

ローカルの待ち受けアドレスも明確にする必要があります。以下はXrayの完全な設定に含められるinbounds部分の最小例で、設定項目の関係を示すものです。リモートサーバーを含む完全な設定ではありません。SOCKSインバウンドはローカルのループバックアドレスだけで待ち受け、LANには公開しません。ポートはアプリに指定する値と一致させてください。クライアントがすでにそのポートを使用している場合、別のプロセスで重複して使用することはできません。通常のGUI設定では、クライアント画面から該当項目を変更してください。

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

失敗した段階から原因を絞り込む

リクエストログがまったくない場合は、アプリがローカルのインバウンドを使っているか、ルーティングによってリクエストが直接接続されていないかを確認してください。接続がタイムアウトする場合は、サーバーアドレス、ポート、現在のネットワーク、サーバーの待ち受け状態を確認します。すぐに拒否される場合、接続先ポートが接続を受け付けていない可能性がありますが、ログと併せて判断してください。ハンドシェイクまで進んで失敗する場合は、TLSのサーバー名、証明書、REALITYのパラメーター、システム時刻を確認します。認証に失敗する場合はUUID、パスワード、暗号化方式を確認し、異なる種類のエラーをまとめて扱わないでください。

サーバーへの接続が確立しているのに一部のドメインだけ失敗する場合は、接続先サイトそのもの、DNSの結果、ルーティングルールへの一致を切り分けてください。直接接続用DNSとプロキシ経由のDNSでは、同じドメインでも異なる結果が返る場合があります。DNSクエリがプロキシを通るかどうかも、コアの設定に左右されます。パブリックDNSのアドレスを変更しただけで解決したと判断しないでください。名前解決経路の詳しい説明はv2rayNのDNS漏えい検出と設定方法を参照し、実際のリクエストで確認してください。

ログで通信経路を確認し、機密情報は公開しない

ログでは時刻の順序、インバウンドの送信元、選択されたアウトバウンド、エラーの種類を重点的に確認します。警告が1件あっても接続全体が失敗したとは限りません。バックグラウンドのリクエストが接続先に拒否されただけの場合もあります。反対に、画面で実行中と表示されても、実際の通信が成功しているとは限りません。他のアプリの動作を一時的に減らし、明確なテストリクエストを1回送って、時刻に対応するログを確認してください。調査中にログの詳細度を一時的に上げるのは有効ですが、終わったら通常レベルに戻し、大量のログが長期間残らないようにしましょう。

ログを共有する前に、サブスクリプションURL、認証情報、個人用ドメイン、アカウントを特定できるパラメーターを削除してください。問題を報告する場合は、クライアント名、コアの種類、インバウンド方式、プロトコルとセキュリティ層の組み合わせ、エラー前後の必要な情報を残せば十分です。実行設定全体を公開したり、サブスクリプション全体を通常のテストURLのように扱ったりしないでください。機密情報を伏せる際は技術情報をすべて削除するのではなく、設定構造とエラー原因を残し、接続にそのまま使える認証情報を取り除きましょう。

再テストに成功してから複雑な設定を戻す

最小構成で正常に動作したら、ルール、DNS、カスタムインバウンド、多重化を一つずつ戻し、毎回同じリクエストで再テストしてください。特定の設定を戻した後に問題が発生したら、その項目を中心に確認します。すべてのプロトコルから無作為に選び直す必要はありません。カスタムルーティングではルールの順序に注意してください。広いルールが先に一致すると、後ろにある具体的なルールが適用されないことがあります。構文の詳細はルーティングの一致条件と優先順位を参照し、変更は一度に一項目にしてください。

最終確認では、通常のブラウジング、実際に使うアプリ、アイドル後の復旧、ネットワーク切り替えを最低限テストしてください。UDPが必要な場合は該当アプリで個別に確認し、複数の端末で利用する場合は各端末のインバウンドを確認します。一台で成功したことをすべての端末に当てはめないでください。動作確認後は復元できる設定を保存し、重要な選択理由を記録しておきます。後日問題が起きた場合は、更新や移行を決める前に環境と設定の変化を比較してください。インストールとインポートはクイックスタートガイドを、インストーラーと対応プラットフォームの選択はクライアントのダウンロードページをご覧ください。