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

設定の階層：プロトコル名だけでは接続方式は決まらない

プロキシプロトコル、トランスポート、セキュリティ層を分けて考える

クライアントのサーバー設定では、少なくとも3つの要素を確認します。宛先や認証情報をどのプロトコルで表すか、データをどのトランスポートで運ぶか、安全な接続をどのように確立するかです。VMess、VLESS、Trojan、Shadowsocksは主に最初の要素、TCP、WebSocket、gRPCなどは2つ目に関わります。TLSとREALITYは安全な接続に関する選択肢です。画面上では同じ設定フォームに並んでいても、互いに置き換えられる項目ではありません。サーバーがVLESSを使うという情報だけでは、接続設定を再現できません。

たとえば、どちらもVLESSの設定でも、一方はTCPとREALITY、もう一方はWebSocketとTLSを使う場合、ハンドシェイクの手順や必須項目、サーバー側の構成が異なります。前者の公開鍵を後者にコピーしたり、後者のパスを前者に入力したりしても、通常は問題を解決できません。プロトコル、トランスポート、セキュリティ層をそれぞれ記録し、アドレス、ポート、認証情報は別に控えると確実です。クライアントの画面表示が変わっても、項目の意味を基に確認できます。

サーバーアドレスとハンドシェイク名を区別する

サーバーアドレスは接続先を指定し、ドメイン名またはIPアドレスを使います。TLSのサーバー名は通常SNIフィールドで指定し、ハンドシェイクや証明書の本人確認に使われます。アドレス欄と完全に同じ文字列である必要はありませんが、サーバー側の構成に合っていなければなりません。WebSocketのHostはHTTPリクエストヘッダー、パスは接続先のエンドポイントを選ぶ項目です。同じドメイン名を入力することもあるため、重複項目と誤解しがちです。トラブル対処では各項目を個別に確認し、アドレス欄を変更すればほかの名前も自動で同期されると思い込まないでください。

ローカルの受け口、システムプロキシ、ルーティングは、さらに別の設定項目です。ローカルの受け口はアプリからの接続を受け取り、システムプロキシは一部のアプリにその受け口を使わせます。ルーティングは、コアに入った通信の出口を決定します。アプリがシステムプロキシを使っていなければ、プロトコルの暗号化方式を変更しても自動的にコアへ通信が流れることはありません。ルールによって直結になっている場合は、サーバーを変更してもその通信の出口は変わりません。AndroidのVPN経由の通信制御とPCのシステムプロキシは仕組みが異なるため、設定スイッチをそのままコピーせず、適用範囲を確認してください。

変更は最小限にして、切り分けの手掛かりを残す

インポート後は元の設定を残し、ローカル側の動作を一項目ずつ調整してください。アドレス、認証、トランスポート、セキュリティの各設定はサーバー側の情報に従います。ローカルポート、アプリごとの適用範囲、ログレベルは端末に合わせて設定できます。プロトコル、DNS、ルーティングを同時に変更すると、成功しても失敗しても原因を特定しにくくなります。設定を複製して比較し、変更は一度に一つに絞り、エラーが起動、ハンドシェイク、アクセスのどの段階で起きるか記録しましょう。各項目の簡単な説明は用語集を参照してください。初回インポートの手順は入門ガイドで確認できます。

VMess：認証、時刻、暗号化方式

設計の背景と接続コスト

VMessはProject Vの初期から使われている主要なプロキシプロトコルで、認証、リクエストの表現、データ保護をプロトコル設計に取り入れています。一般的なTCP接続に名前を付けただけのものではなく、クライアントとサーバーが共通の形式でリクエストを処理する必要があります。選択する際の利点は、成熟したエコシステムと多様なトランスポートを利用できることです。一方、プロトコル自体の暗号化と外側の安全な接続との関係を理解する必要があります。古い設定を扱う場合は、過去の認証方式と現在の実装を区別してください。VMessのリンクがすべて同じ形式とは限りません。

VMessの速度は、暗号化の有無だけでは判断できません。アクセス時にはローカルでの名前解決、トランスポート接続、認証、リモートへの転送が行われ、外側にTLSを重ねる場合はそのハンドシェイクも加わります。現在のプロセッサは一般的な暗号アルゴリズムをさまざまな程度でハードウェア処理できます。短いリクエストは往復時間の影響を受けやすく、長時間のダウンロードでは継続的な転送速度が問題になりやすい傾向があります。VMessの接続が別の接続より遅い場合は、まず回線、サーバー負荷、トランスポートの条件が同じか確認してから、プロトコルの処理コストを比較しましょう。

UUID、暗号化、alterIdの注意点

VMessの設定では、UUIDは認証情報です。ノードのメモ欄ではなく、クライアント側で生成したランダムな文字列をそのまま使えるものでもありません。暗号化方式は双方の実装が対応している必要があります。クライアントの自動選択機能は、通常、実行環境に合わせたアルゴリズムを選ぶもので、認証エラーを自動修復する機能ではありません。負荷を減らすために、データを暗号化しない方式を安易に選ばないでください。外側のTLSとプロトコル自身による保護は役割が異なります。特定の組み合わせを使うかどうかは、明確な構成設計に基づいて決めましょう。「層を減らせばよい」という考え方は、一般的な最適化ルールではありません。

古い解説ではalterIdがよく登場します。これは過去の互換性機能に関係し、現在のVMess AEAD設定では通常ゼロが使われます。クライアントによってはこの項目が表示されないこともあります。サブスクリプションにゼロ以外の値が残っていても、数字だけゼロに変更すれば移行が完了するわけではありません。サーバーが対応する認証方式を使っている必要があります。まず提供元の設定要件を確認し、現在のコアがその方式を処理できるか調べてください。古い設定が残っているとインポートには成功しても接続できない場合があります。画面に構文エラーが出ないことは、双方の認証方式が一致している証拠にはなりません。

システム時刻とトランスポート項目の確認順

VMessの認証では時刻が関係するため、システム時刻が大きくずれているとリクエストが拒否されることがあります。トラブル対処では、まずシステムの自動時刻設定を有効にし、タイムゾーン表示だけでなく日付と実際の時刻を確認してください。タイムゾーン表示の違いだけで、システム時計が誤っているとは限りません。続いてUUID、ポート、サーバーが現在の設定を受け入れているかを確認します。認証に必要な情報が正しいと確認できてから、WebSocketのパス、Hostなどのトランスポート項目を調べましょう。認証の問題を回線障害と誤認しにくくなります。

VMessリンクからインポートする場合は、リンク内の項目とクライアントの編集画面との対応も確認してください。古い形式のリンクでは、トランスポート名、TLSの有効化、ホスト名を旧形式の項目で表していることがあります。インポーターが独自のルールで既定値を補う場合もあります。インポート後の設定を開き、特にアドレス、SNI、パス、暗号化方式を確認してください。ノード一覧のプロトコル表示だけで判断しないことが大切です。同じ設定が別の端末で使えるなら、同じリンクを何度も削除して貼り直すのではなく、項目とコアのログを比較しましょう。

VLESSとREALITY：軽量プロトコルと安全なハンドシェイクを分けて考える

VLESSはプロトコル自体の役割を絞った設計

VLESSは、プロトコル自体の認証やリクエスト処理を簡素化する設計です。VMessのように、基本プロトコル内で同様のデータ暗号化機能を提供するものではありません。一般的な設定でencryptionがnoneとなっているのは、この層の処理方式を示します。接続全体が暗号化されずに通信するという意味ではありません。安全性を確保できるかどうかは、外側でTLSまたはREALITYを使っているか、必要な検証が正しく有効になっているかで判断します。階層ごとに組み合わせられる一方、一つの項目の意味を接続全体に当てはめないことが大切です。

そのため、VLESSを「暗号化を省いたから必ず速い」と単純化することはできません。プロトコル処理を一部減らせても、TLSやREALITYにはハンドシェイクとデータ保護の処理があり、トランスポートのオーバーヘッドが主な負荷になる場合もあります。現在の端末にVLESSが適しているかは、サーバーが提供する組み合わせ、コアの実装、ネットワーク環境によって異なります。PCではv2rayNが使うコアが必要な設定一式に対応しているか、Androidではクライアントのコアと設定形式が一致しているかを確認してください。UUIDを認識できるだけで、すべての機能に対応しているとは限りません。

REALITYは単独のプロキシプロトコルではない

REALITYはXrayエコシステムの安全な接続方式で、VLESSと組み合わせて使われることがよくあります。クライアントには通常、サーバーの公開鍵、サーバー名、shortId、対応するフィンガープリントの設定が必要です。これらはハンドシェイクに関わる情報で、一般的なTLS設定から推測できるものではありません。証明書のドメイン検証とは設定方法が異なりますが、本人確認を無視してよいわけではありません。クライアントに設定するのは接続に必要な公開情報だけです。サーバーの秘密鍵をサブスクリプション、スクリーンショット、クライアントの入力欄に含めてはいけません。

公開鍵はコピーできる文字列に見えますが、サーバーの鍵と対応していなければなりません。shortIdもサーバーが許可する値と形式に合っている必要があります。サーバー名は構成要件に従って設定し、アクセス可能なドメイン名を適当に入力しないでください。フィンガープリントは関連するハンドシェイク動作を指定する互換性設定で、地域や速度を選ぶ項目ではありません。インポーターがいずれかの項目を取り込まなかった場合、一覧に設定が表示されていてもハンドシェイクで失敗することがあります。検証を無効にしてエラーを回避するのではなく、元の設定と項目ごとに照合してください。

flowとトランスポートは自由に組み合わせられない

VLESSのflowは、XTLS Vision関連の値など、特定のフロー制御方式を表します。汎用の高速化スイッチではなく、すべてのトランスポートの組み合わせで使えるわけでもありません。サーバーがVisionを要求する場合、クライアントもその方式に対応し、互換性のあるトランスポートとセキュリティ層を使う必要があります。サーバー側に対応するflowの設定がなければ、独自に追加すると接続に失敗することがあります。Webページの解説に載った一部の設定は、元の組み合わせ全体に対して有効なものです。文脈から切り離してWebSocketなど別の接続方式にコピーしないでください。

設定は「プロトコルとUUID—トランスポート—セキュリティ層—公開鍵とサーバー名—shortId—flow」の順に確認できます。編集画面で既定値に置き換わっていないかを確かめてから、コアのログで設定の解析エラーとリモートのハンドシェイクエラーを区別します。前者は実装が未対応、または項目の形式が誤っている可能性があります。後者ではサーバーの要件とネットワークの到達性を確認してください。サブスクリプション更新後に急に失敗した場合は、以前の設定を残して項目を比較しましょう。すべての原因を公開鍵の変更と決めつけないことが大切です。

TrojanとShadowsocks：TLSへの依存と暗号化方式

TrojanはTLS上に安全な接続を確立する

Trojanの一般的な接続では、まずTLSを確立し、その後プロトコル認証とデータ転送を行います。クライアントで重要な項目は、サーバーアドレス、ポート、パスワード、サーバー名です。設定項目が短く見える場合でも、TLSの本人確認は必要です。証明書名の不一致、証明書チェーンの異常、システム時刻の誤りがあると、パスワードの確認前に接続が終了することがあります。Trojanで接続できない場合は、パスワードを何度も変更するのではなく、まずログでどの段階まで進んでいるか確認しましょう。

アドレスにIPアドレスを指定し、証明書がドメイン名に対して発行されている場合は、サーバーの説明に従って正しいサーバー名を入力してください。SNIはハンドシェイクでサーバー名を伝え、証明書検証は相手の本人確認に使います。関連する項目ですが、同じ設定ではありません。証明書検証を無効にすると本人確認が弱まるため、通常の修正方法として使うべきではありません。サーバー側が特別な信頼設定を採用している場合は、その手順に従ってください。一般的な公開証明書の場合は、時刻、サーバー名、証明書チェーンを修正し、通常の検証を維持しましょう。

Shadowsocksの方式名はプロトコル要件

ShadowsocksはSSとも略され、比較的シンプルなプロキシ転送と暗号化処理を重視した設計です。クライアントにはサーバーアドレス、ポート、パスワード、暗号化方式が必要です。方式名はクライアントだけで選ぶ性能設定ではなく、接続する双方で一致していなければならないプロトコル要件です。パスワードが正しくても、方式が一致しなければ接続できません。古い設定と新しいプロトコルの派生形式では鍵の要件が異なる場合があります。SSと記載された設定がすべて、パスワードを入れ替えるだけで相互接続できるとは限りません。

従来のAEAD方式とShadowsocks 2022シリーズでは、鍵の扱いなどが異なります。後者で使う方式名とエンコード済みの鍵は、サーバーまたはサブスクリプションの提供元から入手してください。任意の短いパスワードをそのまま入力する方式ではありません。方式に対応しているかは、クライアント画面にShadowsocksが表示されるかではなく、実行中のコアによって決まります。インポート時に方式が不明と表示されたら、まず表記とコアの対応状況を確認してください。使い慣れた別の方式名に変更しても、サーバー側のアルゴリズムが自動で切り替わることはありません。

トランスポートの組み合わせとUDPの要件

TrojanやSSでは、サーバー構成によって追加のトランスポート設定が必要な場合があります。一般的な共有リンクですべての拡張項目を表現できると思い込まないでください。特にSSリンクの追加パラメーターは、すべてのインポーターが対応しているとは限りません。提供元が指定する組み合わせを、現在の3つのクライアントとそれぞれのコアで設定できるか確認してから使いましょう。インポート後に拡張項目が消えていたら、互換性の問題として扱ってください。項目が欠けた設定で回線速度を測り続けても解決にはなりません。

音声通話、ゲームなどデータグラム通信が必要な場合は、UDP経路も個別に確認してください。プロトコルがUDPに対応していても、ローカルの受け口、クライアントの通信制御、サーバー側の転送先、宛先ネットワークのすべてがデータグラム通信を許可しているとは限りません。TCPでウェブページを閲覧できても、確認できるのは該当するリクエスト経路だけです。実際にUDPを使うアプリでテストし、ログを確認して、アプリがコアを経由していないのか、サーバーが転送していないのか、宛先から応答がないのかを切り分けましょう。ウェブページが開くというだけで、UDPの問題をアプリ自体のせいにしないでください。

速度、リソース、バッテリー：ハンドシェイクと継続転送を分けて考える

接続が速いこととダウンロードが速いことは別

短いページを開く場合は、名前解決、接続確立、ハンドシェイク、最初のデータが届くまでの時間が主に影響します。継続的なダウンロードでは、回線容量、輻輳制御、サーバーの出口、端末の処理能力がより重要になります。あるプロトコルがハンドシェイクを減らせば短い接続の使い心地は改善するかもしれませんが、長時間接続の転送速度まで上がるとは限りません。逆にダウンロード性能の高い回線でも、名前解決やハンドシェイクに時間がかかると、ウェブページの表示開始が遅くなります。プロトコルを比較するときは、接続成功率、最初の応答、安定した転送性能を分けて記録してください。一つの遅延値ですべての使い心地を評価することはできません。

TCP、WebSocket、gRPCでは、データのカプセル化や接続管理の動作が異なりますが、実際の影響は実装とサーバー構成によって変わります。WebSocketではHTTPのアップグレードとフレーム処理が加わり、gRPCではHTTP/2の動作とサーバー側の対応が必要です。これらの方式は多くの場合、接続アーキテクチャ上の要件で使われ、あらゆる回線で遅延を減らすためのものではありません。パケットロスや輻輳、中継機器の処理も結果に影響します。回線とサーバーの条件をそろえない比較では、その接続の組み合わせについてしか評価できず、プロトコルの速度を固定順位で示すことはできません。

CPU、メモリ、接続の多重化の注意点

暗号アルゴリズムがプロセッサ命令を利用できるか、コアのバッファー処理、接続数、ログ出力の量は、いずれもリソース使用量に影響します。PCの負荷が低いときは、ブラウザーやシステムのタスクに隠れてプロトコル間の差が見えにくいことがあります。小型端末では、長時間にわたって大量のデータを転送すると温度制限の影響が出やすくなります。リソースを確認するときは、転送速度と継続時間もあわせて見てください。同じCPU使用率でも、転送量は大きく異なる場合があります。クライアント画面のプロセス使用量を、コア全体の消費量と見なさないようにしましょう。別プロセスとして動作していることがあります。

接続の多重化は、複数の論理リクエストで少数の下位接続を共有し、接続の確立を減らす仕組みです。一方、輻輳時や長短のリクエストが混在するとき、実装が合わないときには待ち時間が増える場合もあります。すべてのプロトコルに有効な共通の最適化ではありません。まず既定の設定を維持し、短い接続が多くサーバーも対応している場合に比較テストを行いましょう。有効にした後で断続的な停止が起きる場合は、接続を分離した状態を基準に戻してください。ルーティング、DNS、トランスポートを同時に変更すると、多重化の設定だけの効果を判断できません。

Androidのバッテリー消費は、主にスリープ解除と再接続で変わる

モバイル端末のバッテリー消費は、暗号化処理だけでなく、無線ネットワークの接続維持、バックグラウンドでのスリープ解除、キープアライブの頻度、失敗後の再接続にも左右されます。処理負荷が低そうなプロトコルでも、頻繁に切断して安全な接続を確立し直すと、結果的に消費電力が増えることがあります。モバイル回線とWi-Fiを切り替える際も、接続の再確立に追加の負荷がかかります。v2rayNGとv2flyNGを比較するときは、電波状況、画面点灯時間、アプリの負荷をそろえて確認してください。一度のバックグラウンド消費量の順位を、プロトコル固有の特性と決めつけないようにしましょう。

VpnServiceはAndroidの通信をVPN経由で制御しますが、コアの接続成功を保証するものではありません。省電力制限によって画面ロック中にバックグラウンド処理が中断され、画面を再び点灯すると復旧することがあります。アプリごとの設定によって、一部のアプリがコアを経由せずに直結する場合もあります。まずシステムのバックグラウンド制限と通信制御の範囲を確認してから、プロトコルの変更を検討してください。詳しくはv2rayNGの権限、省電力設定、アプリごとの設定を参照してください。速度測定の違いは遅延測定の仕組みで解説しています。ICMPの結果を実際のプロキシリクエストの代わりに使わないでください。

V2FlyとXray：系統と設定の互換性

GUIクライアントとコアの役割分担

Project Vは、このツール群の背景となるエコシステムです。V2FlyはV2Ray関連の開発を引き継ぎ、Xrayは関連するコードを基に分岐して独自の機能を発展させてきました。共通する概念や設定方法もありますが、単なる名称変更と考えることはできません。GUIクライアントは設定、サブスクリプション、ローカルの通信制御、ログ表示を管理し、コアは実際の接続、ルーティング、プロトコル処理を担います。画面から特定のサーバー設定を作成できても、それは編集機能があることを示すだけです。最終的には実行中のコアがその設定を処理します。

PCでは、設定管理や複数の利用環境を扱いやすいv2rayNをおすすめします。ただし、実際に使えるプロトコルは選択したコアに応じて確認が必要です。Androidではv2rayNGが主にXrayの機能に対応し、v2flyNGはV2Fly系の選択肢です。どちらを選ぶ場合も、まずサーバーが必要とするプロトコルと拡張機能に対応しているか確認し、そのうえで画面の使い勝手を考えましょう。同じサブスクリプションが両方のアプリに表示されても、すべての設定が同じように実行されるとは限りません。

共通する設定項目があっても、完全に互換とは限らない

どちらのコアにも、インバウンド、アウトバウンド、ルーティング、DNSといった共通の概念があり、同じプロトコルに対応する場合もあります。しかし、拡張項目、既定の動作、対応するトランスポートには違いがあります。JSONの見た目が似ていても、Xray系のREALITYやXTLS Vision関連機能をV2Flyでそのまま実行できるとは限りません。逆方向に移行する場合も、V2Fly特有の設定とクライアントの生成方法を確認してください。安全な移行方法は、設定ファイル全体をコピーするのではなく、各項目の意味を確認して移し替えることです。

カスタム設定とGUIの編集画面では、設定の反映や保存の仕組みが異なる場合があります。クライアントは画面上で保存した情報を基に実行用の設定を生成し、起動時に一時ファイルを上書きすることがあります。生成されたファイルを直接編集しても、次回接続時に変更が残るとは限りません。カスタム設定を継続して使う場合は、クライアントが提供する専用の設定欄を使い、システムプロキシ、ルーティング、DNSのどの機能をGUIが引き続き制御するのか確認してください。ファイルに記述したルールと、実際に読み込まれるルールが異なると、トラブル対処の方向もずれてしまいます。

最小限の設定例を読む

以下はXray形式のルーティングオブジェクトの一部で、項目の階層を示す例です。そのまま起動できる設定ではありません。domainStrategyはルーティングの判定時にドメインを処理する方法を指定します。ルールは上から順に照合され、outboundTagは定義済みのアウトバウンドタグと一致している必要があります。この設定だけでサーバーを作成したり、システムプロキシを自動設定したりはできません。既存の設定に追加する前に、使用中のコアが各項目に対応しているか、クライアントがルーティング設定を再生成するか確認してください。正しいルールを誤った場所に貼り付けないよう注意しましょう。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

コアを更新するときは、クライアントが設定を生成する機能もあわせて確認してください。更新によって新しいプロトコル項目に対応したり、互換性の処理が変わったりすることはありますが、サーバー側に不足している設定が補われるわけではありません。起動エラーが出た場合は、最初に現れた解析エラーを読み、想定したコアが実行されているかを確認してから、生成された設定の項目を調べましょう。更新前に使えていた設定が動かなくなった場合は、戻せる設定のコピーを残し、最小限の構成で再現してください。オープンソースであることは、コードの確認や保守に役立ちますが、異なる実装間の互換性を保証するものではありません。クライアント間の違いは比較レビューをご覧ください。

サブスクリプションと共有リンク：インポート成功でも項目がすべて反映されるとは限らない

アドレス、データ形式、接続設定はそれぞれ別

サブスクリプションURLは通常、複数のサーバー設定を取得するために使います。共有リンクは個別の設定を直接表します。用途は異なり、サブスクリプションは後から更新できる一方、共有リンクは通常、その時点の設定を保存したものです。サブスクリプションのURLが一般的なウェブアドレスだからといって、取得する内容がウェブページとは限らず、どのクライアントでも解析できるわけでもありません。サーバーからリンクの一覧、エンコードされたテキスト、特定の設定形式が返されることがあります。クライアントが該当するインポート形式に対応して初めて、その内容を編集可能なサーバー設定に変換できます。

サブスクリプションの取得に成功したというだけでは、応答を受け取れたことしか分かりません。ログインページ、エラーメッセージ、未対応の形式が返ると、一覧が空のままになることがあります。まずリクエストの失敗と解析の失敗を区別してから、ネットワーク経路を変更するか判断してください。一部のクライアントでは、サブスクリプションの更新に直結と既存プロキシのどちらを使うか選べます。現在の設定が無効なときにプロキシ経由で更新すると、更新に必要な接続を更新対象に依存する状態になる場合があります。変更前に更新設定と利用可能な接続を確認し、エラーを見ずに同じURLへのリクエストやルート変更を繰り返さないでください。

リンク形式ごとに欠落しやすい情報

VMessの共有リンクは、エンコードされた構造化データを含む形式が一般的です。VLESSやTrojanのリンクでは、アドレス部分とクエリパラメーターで設定を表します。SSには複数のエンコード形式があります。サーバー名、パス、サービス名に特殊文字を含む場合は、各形式のエスケープ規則に従う必要があります。チャットアプリによる改行、コピー時の末尾の欠落、二重エンコードによって、パラメーターが変わることがあります。インポーターが一部の誤りを許容しても、変換後の設定が元の意味と一致するとは限りません。インポート後に重要な項目を確認してください。

VLESSのflow、REALITYの公開鍵とshortId、TLSのサーバー名、WebSocketのHostとパスは、特に確認が必要な項目です。プロトコル、アドレス、認証情報だけを残す形式変換では、ハンドシェイクに必要な拡張情報が失われることがあります。ノード名が一致するかだけで判断しないでください。ノード名はラベルであり、接続処理には使われません。インポート手順の違いは共有リンクとサブスクリプションURLの違いを参照してください。操作手順と本ページの設定項目の解説をあわせて確認できます。

更新とローカル変更は分けて管理する

サブスクリプション管理では、通常、グループ単位でサーバー設定を更新します。ローカルで加えた変更が維持されるかどうかは、クライアントの動作によって異なります。サブスクリプションから作成された設定のポート、名前、トランスポートを直接変更すると、次回の更新で上書きされることがあります。長期間比較する場合は、ローカル設定として複製して用途を記録してください。ただし、サーバー側の変更を手動で反映する必要があります。ルーティングルールやアプリごとの適用範囲は通常ローカルの設定です。サブスクリプション更新で修正されると思い込まず、変更する項目がどの階層に属するか確認してください。

別のクライアントへ移行する場合は、まず元のサブスクリプションを再インポートして拡張項目を確認してください。特定クライアント用の設定ファイル全体を、汎用サブスクリプションとして扱わないでください。PCのシステムプロキシのポート、Androidのアプリ別リスト、ローカルDNSの選択には端末固有の情報が含まれるため、移行先で再設定が必要です。実際のウェブリクエストと、必要なUDPアプリの少なくとも両方をテストし、更新が繰り返し正しく行えることを確認しましょう。初回に接続できても、次回のサブスクリプション更新後も設定が正しく反映されるとは限りません。

用途別の選び方とトラブル対処：まず条件を合わせ、その後に性能を比較

サーバーと端末に合わせて候補を絞る

利用できるサーバーがある場合は、プロトコルを変えること自体を目的にせず、サーバーが明確に対応し、すでに動作を確認できている組み合わせを使うのが基本です。PCでv2rayNを使う場合は、まずシステムのアーキテクチャとインストール方法を確認し、その後に選択したコアを調べてください。AndroidでREALITYやVisionなどXray関連の機能が必要なら、まずv2rayNGの対応設定を確認します。V2Flyの設定をすでに利用しており、必要な機能が合致する場合は、v2flyNGを候補にできます。インストール先はダウンロードセンターにまとめています。プロトコルの解説は、OSやアーキテクチャの選択に代わるものではありません。

短いウェブページを頻繁に開く場合は、接続確立、名前解決、最初の応答までの時間を重視します。長時間の転送では、継続的な速度、パケットロス、端末の温度を確認してください。バックグラウンドでメッセージを受信するアプリでは、通信制御の範囲、接続の復旧、システムのバックグラウンド制限が重要です。複数の用途があっても、一つの設定ですべての要件を満たそうとする必要はありません。まず安定した状態を基準にし、特定のアプリに合わせてルーティングやアプリごとの範囲を調整すると、プロトコルとトランスポートを同時に変更するより結果を把握しやすくなります。

接続のどの段階で失敗するかを確認する

コアが起動しない場合は、設定の解析、ポートの競合、機能の対応状況を確認してください。この段階では、リモートの速度を測っても意味がありません。コアは起動するものの接続を確立できない場合は、アドレス、ポート、システム時刻、トランスポート設定を確認します。接続できても安全なハンドシェイクに失敗する場合は、サーバー名、証明書、公開鍵、shortId、認証情報を調べてください。ログ上でリクエストの転送後に宛先から応答がない場合は、サーバーの出口、宛先への到達性、DNSの結果を確認します。すべての問題をクライアントへのインポート手順のせいにしないでください。

ウェブページは表示できるのに一部のアプリが動かない場合は、まずそのアプリの通信がプロキシを経由しているか確認し、次にルーティングとUDPの要件を調べます。PCではシステムプロキシを使わないアプリがあり、Androidではアプリごとの除外によって直結する場合があります。コアに入った後も、ルールによってdirectまたはblockに振り分けられる可能性があります。そのため、ルールの順序とアウトバウンドタグをあわせて確認してください。DNSの応答はIPアドレスに基づくルール判定にも影響します。ドメインの処理方式を変更する前に適用範囲を理解し、名前解決の選択とプロトコル認証を混同しないようにしましょう。

速度低下と接続タイムアウトは別々に調べる

接続タイムアウトでは、まず「接続を確立できるか」を確認し、システム時刻、サブスクリプションの有効性、ポート、トランスポート、コアのログを順に調べます。速度が遅い場合は、接続できる状態を確認してからノードの負荷、回線、ローカル設定を比較してください。確認項目はノードのタイムアウト対処チェックリストと速度低下の段階別トラブル対処で解説しています。両方の問題が同時に起きることはありますが、認証失敗を何度も速度テストして調べたり、一度接続できたことを根拠に継続的な輻輳を否定したりしないでください。

後から確認できる記録を残しましょう。クライアント名、実際に使用したコア、プロトコルとトランスポートの組み合わせ、エラーが発生した段階、直近の設定変更を記録します。アクセス情報を含める必要はありません。安定した状態に戻ったら、一時的に詳細にしたログレベルを通常に戻し、試験用の重複設定を整理してください。次に同じような問題が起きたときは、まず基準の設定と比較してから一項目ずつ変更します。一般的な疑問はFAQをご覧ください。インポートと動作確認を最初から行う場合は入門ガイドに戻ってください。選ぶ際に重視すべきなのはプロトコル名ではなく、組み合わせ全体と実際の要件です。