V2Ray プロトコルとコア選定ガイド

// 01 · DECISION MODEL

プロトコル・伝送・セキュリティ・ルーティングを分けて考える

クライアント設定は単一のプロトコルではない

V2Ray GUIクライアントは複雑な設定をいくつかの入力項目にまとめるため、VMessやVLESSを選べば技術的な選択がすべて終わったように見えがちです。実際には、接続は少なくとも5層に分けられます。アプリの通信が生むTCPまたはUDPトラフィック、ローカル入口、認証とカプセル化を担うプロキシプロトコル、TCP・WebSocket・gRPCなどにプロキシデータを載せる伝送方式、外側のハンドシェイクと暗号化を担うTLSまたはREALITYです。遠端に到達した後も、アウトバウンドとルーティング規則によって直接接続・プロキシ・ブロックが決まります。どこか1層でもパラメータが一致しなければ、「設定はインポートできるが接続できない」という症状になります。

プロトコル層は主に認証フィールド、リクエストヘッダー構造、コア実装を決めます。たとえばVMessはユーザー識別子と独自のプロトコル構造を使用し、VLESSはより軽量で、暗号化と伝送セキュリティを外側に委ねます。伝送層はデータのフレーム化、HTTPセマンティクスの要否、中継経路が正しく転送できるかを左右します。セキュリティ層は証明書検証、サーバー名、鍵交換、接続先の本人確認を処理します。ルーティング層はプロトコル自体を変えませんが、どのリクエストがプロキシ接続に入るかを直接決めます。トラブルシューティングではまず層を特定してからパラメータを変更してください。複数の項目を続けて入れ替えると、本当の原因が隠れてしまいます。

「最強のプロトコル」ではなく制約条件で選ぶ

プロトコルに環境を離れた一律の順位はありません。サーバーが提供する機能、現在のクライアントコアが解析できる内容、OSに必要な機能、リバースプロキシや特定の伝送方式だけを受け付ける設備の有無を同時に確認する必要があります。サーバーがVMessに固定されているなら、クライアント側だけでVLESSに変更できません。サブスクリプションがWebSocketしか提供しない場合も、ローカルだけでgRPCに切り替えることはできません。クライアントのプロトコル、アドレス、ポート、ユーザー識別子、伝送方式、セキュリティ設定は、サーバーと項目ごとに一致させる必要があります。

判断の優先順位は「可用性、互換性、リソースコスト、保守コスト」です。まずサーバーとコアの対応を確認し、次にサブスクリプションのフィールドが完全に渡るかを確認し、その後で接続確立速度、スループット、消費電力を比較します。複数の端末で使うなら、デスクトップとAndroidで同じサブスクリプションを再利用できるかも重要です。一方の端末でしか完全に認識できない組み合わせは、わずかな性能向上より日常の保守負担のほうが大きくなりがちです。

切り戻せるベースライン設定を作る

プロトコルを比較する前に、動作確認済みのベースライン設定を1つ残しておき、直接上書きしないでください。ベースラインは、ローカルポート、システムプロキシ、DNS、ルーティング規則による干渉を切り分けるために使います。新しい設定を試す前は、一時的にグローバルプロキシや最も単純なルーティングモードを使い、基本接続を確認してから分割ルーティングに戻します。基本接続が正常で、規則を戻した後に異常が出るなら、原因はルーティングまたはDNSです。プロトコルパラメータを変更し続けるべきではありません。GUIクライアントは通常、設定の複製やサブスクリプション単位のグループ管理に対応しています。グループを活用すれば、何度もインポートすることで起きるフィールドの混乱を大幅に減らせます。

// 02 · PROTOCOL FAMILIES

VMess、VLESS、Trojan、Shadowsocks、REALITY

VMess：完全なプロトコル構造と成熟した互換性

VMessはProject Vエコシステムの初期に形成された中核プロキシプロトコルで、ユーザー認証、時刻検証、データカプセル化を1つのプロトコルにまとめることを目的として設計されました。クライアントでよく使う項目には、サーバーアドレス、ポート、ユーザーID、alterId、暗号化方式、伝送設定があります。現在の設定ではalterIdが通常ゼロですが、古いサブスクリプションにゼロ以外の値が含まれている場合は、サーバーの実際の設定に従って保持し、新しい設定の慣例だけを根拠に変更しないでください。VMessはシステム時刻の影響を受けやすく、端末の時刻が大きくずれていると認証を完了できないことがあります。そのため「同じ設定が一方の端末では使えるのに、別の端末では使えない」場合は、自動時刻合わせを確認してください。

VMessの強みは、長年の利用で蓄積されたツール互換性と既存導入例の多さです。多くのサブスクリプション形式で基本フィールドを安定して表現できます。一方、プロトコル自体の構造はVLESSより複雑で、認証とカプセル化に追加処理が発生します。現代のデスクトップやスマートフォンでは、このコストがボトルネックになることは通常ありません。体感を左右するのは、ネットワーク往復、伝送方式、TLSハンドシェイク、サーバー負荷である場合が多いです。既存のVMess設定が安定しているなら、理論上のわずかな処理コスト差だけを理由に移行しても、再設定や端末間検証のコストを回収できないことがあります。

VLESS：認証とセキュリティ層を分離

VLESSはユーザーIDによる認証方式を引き継ぎつつ、データ暗号化をプロトコル内部で重ねて行わず、TLSやREALITYなど外側の仕組みに委ねます。これによりプロトコル層の冗長性が減り、伝送セキュリティの役割も明確になります。VLESS設定では、アドレス、ポート、ユーザーIDに加えてflowフィールドを使うことがあります。flowはすべてのVLESS設定で必要なわけではなく、サーバーが対応するフロー制御を有効にしている場合だけ入力します。代表的な値は xtls-rprx-vision です。空欄や誤った値は、クライアントとサーバーの動作を不一致にします。

VLESSそのものがREALITYを意味するわけでも、特定の伝送方式を自動的に指定するわけでもありません。TCP、WebSocket、gRPCなどと組み合わせることができ、TLSやREALITYも利用できます。VLESSを選んだ後も、network、security、serverName、flowなどの項目を確認してください。現代のXray設定では、VLESSとREALITY、Visionの組み合わせがよく使われます。これらの機能が同じコアファミリー内で連携して実装されているためです。V2Flyの機能だけに対応したクライアントへ設定を渡す場合は、その組み合わせに相当する実装が対象コアに存在するか先に確認してください。

Trojan：TLSを基盤とするパスワード認証

Trojanの主要項目は比較的シンプルで、サーバーアドレス、ポート、パスワード、TLSサーバー名、任意の伝送パラメータです。正しく構築されたTLSに依存し、クライアントはサーバー名に基づいて証明書を検証します。接続先にIPアドレスを使い、サーバー名にドメインを指定する組み合わせは正常です。接続先と証明書の識別情報を分けられるためです。ただしサーバー名が空、綴りが誤っている、証明書チェーンに異常がある場合は、プロキシデータの段階に入る前に接続が失敗します。証明書検証を無効にすれば一時的にエラーを回避できる場合がありますが、本人確認を失うため長期的な対処には適しません。

Trojanはプロトコルの理解にかかる負担が小さく、標準TLSを安定して提供するサーバー環境に向いています。VLESS TLSとの性能差は、回線品質や伝送方式による差より小さいことが一般的です。比較時はサーバーの場所、ポート、伝送方式、同時接続数をそろえてください。一方が直接TCP、もう一方がWebSocketと中継を重ねているなら、ダウンロード速度だけでプロトコルの優劣を判断しても意味がありません。

Shadowsocks：軽量な暗号化プロキシ

ShadowsocksはSSと略されることが多く、設定は主にアドレス、ポート、パスワード、暗号化方式で構成されます。構造が簡潔で、リソース使用量も通常少なく、TCPとUDPの成熟した実装があります。暗号化方式はサーバーと完全に一致させる必要があり、名称が似ていても置き換えられません。現代の導入では、クライアントとサーバーが共に対応するAEAD系方式を使用してください。古い方式を一部のコアが解析できる場合でも、互換性、安全性、保守状況を現代的な方式と同一視してはいけません。

SSは、項目が少なく、複数クライアントでの再利用性を重視する場面に適しています。サブスクリプションリンクも比較的コンパクトですが、生成ツールによってユーザー情報のエンコード、プラグインパラメータ、備考の表記が異なることがあります。基本的なSS設定は移行しやすい一方、追加プラグインを含む設定では、移行先クライアントが同じ機能を実装しているか確認が必要です。v2rayN、v2rayNG、v2flyNGは一般的な基本設定を処理できますが、複雑な拡張は各コアとインポーターの制約を受けます。

REALITY：伝送セキュリティ方式であり、独立したプロキシプロトコルではない

REALITYはVLESSと同時に登場することが多いため、独立したプロトコルと誤解されがちです。より正確には、VLESSがプロキシプロトコルとユーザー認証を担い、REALITYが外側のハンドシェイクとサーバー本人確認を担います。クライアントでよく使う項目には、サーバー名、公開鍵、短い識別子、ブラウザー指紋の模倣値、任意のSpiderXがあります。公開鍵はサーバーの鍵ペアに由来し、短い識別子はサーバーが許可する値です。どちらもクライアント側で生成して置き換えることはできません。サーバー名もサーバー設定に合わせる必要があります。

REALITYを完全にサポートするのは主にXrayコアです。設定をインポートする際、画面がVLESSを認識していても、サブスクリプション変換でREALITYのpublicKey、shortId、fingerprintが失われれば接続できません。トラブルシューティングでは設定詳細を開き、項目ごとに確認してください。リスト上のプロトコルラベルだけを見てはいけません。V2Flyコアが必要な端末では、別途互換設定を用意し、REALITYの項目をV2Flyが自動的に無視して動作することを期待しないでください。

// 03 · PERFORMANCE & RESOURCE

接続速度・スループット・リソース使用量の比較方法

まずハンドシェイク速度と持続スループットを分ける

「速度」には少なくとも接続確立時間、最初のバイトまでの時間、継続ダウンロード速度、アップロード速度、高負荷時の安定性が含まれます。プロトコル層が軽いからといって、すべての指標が速くなるわけではありません。新しい接続では、DNS問い合わせ、TCP接続、TLSまたはREALITYのハンドシェイク、プロキシプロトコル認証、接続先への接続が発生します。地域をまたぐ経路では、ネットワークの往復時間がローカルでのプロトコル処理時間を大きく上回ることがよくあります。短い接続を多用するWeb閲覧はハンドシェイク回数の影響を受けやすく、長時間のファイル転送は回線帯域、パケットロス、輻輳制御、サーバー処理能力に左右されます。

VMess、VLESS、Trojan、SSを比較するときは、できるだけ同じサーバー、同じ経路、近いポート、同じ伝送層を使います。テスト前に経路を変えるカスタムルーティングを無効にし、DNSの解決結果が一致することを確認してください。各設定は複数回交互にテストし、一方をすべて測ってから他方を測る方法は避けます。ネットワーク負荷は時間によって変化するためです。結果には中央値と異常回数を記録し、最速の1回だけを残さないでください。差がごく小さい場合、プロトコル自体が優れている証拠とは通常いえません。

伝送カプセル化はプロトコル差より大きく影響することが多い

直接TCPは追加のフレーム化が少なく、エンドツーエンドで安定した接続が許される経路に適しています。WebSocketはデータの外側にHTTPアップグレードとフレーム構造を加えるため、HTTPを理解する基盤設備に接続しやすい一方、ヘッダーとフレーム化のコストが増えます。gRPCはHTTP/2を基盤とし、ストリームと接続の管理機能を備えています。サーバーと中継経路の双方がHTTP/2を正しくサポートする環境に適しています。HTTPUpgradeとWebSocketは入口の形式が似ていますが、具体的な対応はコアとサーバーに依存します。理論上のコストだけでなく、経路全体でバッファリング、時間制限、長時間接続のリセットが起きないかも確認してください。

多重化は複数の論理リクエストで少数の下位接続を共有する仕組みです。接続確立の頻度を減らせる一方、パケットロス時には複数の論理ストリームが同時に待たされ、先頭ブロッキングが起きることがあります。Webの小さなリクエスト、インスタントメッセージ、大容量ファイル転送では多重化への反応が異なります。有効化後にダウンロードは安定するのにWeb閲覧だけ時々止まる、または1接続のパケットロスですべてのリクエストが停止する場合は、多重化を無効にして比較してください。現象をVLESSやVMessのせいにしてはいけません。

CPU・メモリ・暗号化実装

リソース使用量は、プロトコル解析、暗号化アルゴリズム、TLS実装、伝送フレーム化、ログレベル、接続数によって決まります。VLESSはデータ暗号化を外側に委ね、プロトコル処理は比較的直接的です。TrojanはTLSに依存し、SSは設定した暗号化方式を使い、VMessは独自のプロトコル構造を持ちます。現代の端末には効率的な暗号化実装が備わっているため、通常のWeb閲覧では数種類のプロトコル間のCPU差を体感しにくいことがあります。低性能端末、高速転送、大量の同時接続では、アルゴリズムの実装やメモリコピー回数がボトルネックになりやすくなります。

ログもリソースに影響します。トラブルシューティングでは詳細ログがハンドシェイクやルーティングの特定に役立ちますが、デバッグレベルを常用するとディスク書き込み、メモリバッファ、画面更新が増えます。安定したら通常のログレベルに戻してください。ルーティング規則も、少ないほど速いという単純な関係ではありません。整理されたドメイン集合とIP集合はコアが効率よく照合します。避けるべきなのは、大量の重複、競合、順序の不明確なカスタム規則です。

再現可能なテスト手順

まず1つのブラウザーでコールドスタートをテストし、初回表示と連続表示の差を記録します。次に継続転送を行い、スループットが安定するか確認します。その後、複数の同時リクエストとUDPアプリをテストし、最後に普段のルーティングとDNS設定へ戻します。各段階では1つの変数だけを変更してください。VMess WebSocket TLSからVLESS TCP REALITYへ一度に変更して改善しても、プロトコル、伝送、セキュリティのどれが原因かは判断できません。より確実なのは、まず伝送とTLSを固定してVMessとVLESSを比較し、次に伝送方式だけを変更し、最後にセキュリティ層を比較する方法です。

クライアント画面の接続テストは通常、遠端が応答できるかだけを確認し、実際のサービス経路の安定性までは保証しません。実際のアプリは異なるドメイン、IPv4またはIPv6、UDP、長時間接続、同時リクエストを使うことがあります。設定を主設定として使えるか判断するには、Web閲覧、継続転送、スリープ復帰、ネットワーク切り替えを少なくとも確認してください。特定のアプリだけで異常が出るなら、プロトコルを無作為に変更し続けるのではなく、DNS、ルーティング、そのアプリのプロキシ接続方式を調べます。

// 04 · MOBILE POWER

Android接続の消費電力・バックグラウンド・ネットワーク切り替え

消費電力はプロトコル名だけでは決まらない

Androidのプロキシクライアントは通常、システムVPNサービスで通信を取り込みます。消費電力の要因には、常時動作するローカル入口、暗号化と復号、DNS処理、ルーティング照合、接続維持、ログ書き込み、ネットワーク再接続が含まれます。画面消灯後はシステムのスケジューリングやバックグラウンド制限によって接続状態が変わり、Wi-Fiからモバイル通信へ切り替えると既存のTCP接続は通常再確立が必要です。そのため、VMess、VLESS、SSの理論上のカプセル化コストだけで端末全体の電池持ちを正確に予測することはできません。

v2rayNGはXrayコアを使用し、VLESS、REALITY、Xrayのルーティング機能が必要な設定に適しています。v2flyNGはv2flyコアを使用し、V2Flyエコシステムの設定向けAndroidクライアントとして利用できます。両者の消費電力は、同じ設定、同じルーティングモード、近い日常操作で比較してください。一方で完全なログ、複雑なDNS分割、継続的なプローブを有効にし、他方では単純なプロキシだけを動かしているなら、結果をコアファミリーの差には帰せません。

接続維持と頻繁なウェイクアップ

キープアライブは接続を維持し、障害を早期に検知するために使います。ただし間隔が短すぎると、ネットワークとプロセッサーを頻繁に起こします。インスタントメッセージには安定した長時間接続が必要ですが、通常のWeb閲覧は必要に応じた再接続でも対応できます。クライアントやサーバーのアイドルタイムアウト、中継ネットワーク機器の接続回収ポリシーも適切な間隔に影響します。待機中の消費電力が明らかに高い場合は、まず継続転送、詳細ログ、異常な再接続を確認し、キープアライブの調整を検討してください。間隔をむやみに極端に短くするのは避けます。

多重化によって下位接続数を減らせる場合がありますが、1本の長時間接続がシステムやネットワークに回収されることもあります。多重化を無効にすると接続数とハンドシェイク回数が増える可能性があり、有効にすると主接続の頻繁な失敗によって一斉再接続が起きることがあります。実際の選択は、前面利用と待機を含む一連のサイクルで観察してください。システムの電池画面ではアプリ活動の傾向を確認できますが、プロトコルのコストまでは区別できません。クライアントログの繰り返し接続、DNSタイムアウト、ネットワーク切り替え記録と合わせて判断します。

ルーティング範囲とDNSが消費電力に与える影響

全体の通信を取り込むと、より多くのアプリ通信がコアに入り、バックグラウンド同期、メディア転送、システムサービスの処理量も増えます。アプリ単位のプロキシや適切なドメイン・IP分割により不要な転送を減らせますが、規則が複雑すぎたり、リモートDNS問い合わせを頻繁に発生させたりすると負荷が増えます。省電力化の重点は規則を最少にすることではありません。ローカルトラフィック、LANアクセス、明確な直接接続先を迂回させず、名前解決経路と最終アウトバウンドを一致させることが重要です。

DNS設定が不適切だと、重複問い合わせ、タイムアウト後のフォールバック、接続再試行が発生します。この消費電力はプロトコルの問題と誤認されがちです。ログに名前解決のタイムアウトが続く場合は、現在のネットワークから設定したDNSへアクセスできるか、問い合わせが正しいアウトバウンドへルーティングされているか、IPv6の結果が実際のネットワーク能力と合っているかを確認してください。IPv6を無効にすればよいとは限りません。安定したIPv6が使えるネットワークでは余計なフォールバックが発生し、IPv6経路が不完全なネットワークでは無効なアドレスを先に試すことで遅延する場合があります。現在のネットワークで実測して判断してください。

プロトコルと伝送方式の実際の選び方

サーバーが複数の方式を提供しているなら、モバイル端末ではまず、フィールドが完全で、コアがネイティブ対応し、接続復帰が安定する組み合わせを選びます。VLESS REALITYにはv2rayNGで使われるXrayの機能が必要です。基本的なVMess、Trojan、SSはより幅広い設定で利用できます。伝送方式では直接TCPが比較的シンプルですが、WebSocketとgRPCが適切かはサーバー構成によって決まります。デスクトップのブロードバンドで安定する伝送方式でも、モバイル通信の切り替え時に同じとは限りません。特にバックグラウンドから復帰した後、手動再接続が必要になるかを確認してください。

消費電力が高いとき、すぐにサブスクリプションを削除しないでください。まず設定を複製して比較環境を作り、詳細ログを無効にし、不要なプローブを減らし、プロトコルとサーバーを固定したまま多重化だけを切り替えます。次に多重化を固定して伝送方式だけを比較し、最後にプロトコルを比較します。各テストでは画面使用時間と通信内容をそろえてください。消費電力が通信量の多さに伴うなら、正常なデータ処理コストかもしれません。通信がほとんどないのに動作し続ける場合は、再接続ループ、DNS再試行、バックグラウンドアプリによる継続リクエストを重点的に調べます。

// 05 · CORE FAMILIES

V2FlyとXrayのコアファミリーの関係

共通する基盤と異なる進化の方向

V2FlyとXrayはいずれもProject Vの設定体系にある多くの基本概念を引き継いでおり、インバウンド、アウトバウンド、ルーティング、DNS、伝送、ポリシーオブジェクトなどを扱います。VMess、基本的なVLESS、Shadowsocks、SOCKS、HTTPといった一般的な機能には共通部分が多く、基本設定が似て見えることがあります。しかし両者は独立して進化するコアファミリーです。新機能、フィールド名、デフォルト動作、リリース時期が完全に同期するとは限りません。構造が似ているからといって、任意の設定をそのまま交換できるわけではありません。

XrayはVLESS、XTLS Vision、REALITYなどで明確な組み合わせを形成しています。V2Flyは独自コアを中心に、プロトコル、伝送、ルーティング、プラットフォーム機能を継続的に保守しています。コアを選ぶときは、どちらが「新しい」かだけでなく、サブスクリプションの機能がどちらに属するか、クライアントが対応する設定を公開しているか、サーバーが同じ実装を採用しているかを確認してください。基本的なプロトコルほどコア間の互換性は高く、専用のセキュリティ層、フロー制御、実験的フィールドを使うほど互換範囲は狭くなります。

3つのGUIクライアントの対応関係

デスクトップではv2rayNが第一候補です。Windows、macOS、Linuxに対応し、サブスクリプション管理、システムプロキシ、ルーティング規則、複数コアの設定入口を備えています。Androidではv2rayNGが主にXrayコアを使用し、VLESS、REALITY、VisionなどのXray機能を必要とする設定に適しています。v2flyNGはV2Flyコアに対応し、サーバーやサブスクリプションがV2Fly互換機能を明確に採用している場合に使えます。具体的なインストール方法とプラットフォーム要件は、クライアント入手ページでOSを選んで確認してください。

クライアント名とコア名を混同してはいけません。v2rayNはサブスクリプション、設定編集、コア起動、システムプロキシを管理するGUI層です。実際にプロトコル、伝送、ルーティングを実行するのは選択したコアです。同じv2rayNの画面でも、コアを切り替えると利用できるフィールドや実行結果が変わることがあります。トラブルシューティングではクライアント名だけでなく、現在のコアの種類も記録してください。「v2rayNが接続できない」だけでは情報が足りません。同じ設定でもコアによって結果が異なる場合があります。

設定互換性の3つの段階

第1段階は構文互換性です。JSONを解析でき、フィールドの型とオブジェクトの位置がコアの要件を満たすかを確認します。第2段階は機能互換性です。フィールドを読み取れても、対象のプロトコルや伝送方式が実際に実装されているかを確認します。第3段階は動作互換性です。両方が同名の機能を実装していても、デフォルト値、フォールバック規則、境界処理が一致するとは限りません。サブスクリプションのインポート成功は、GUIクライアントが入力を受け付けたことを示すだけです。コアが実行できることや、サーバーのパラメータと一致することまでは保証しません。

たとえばVLESS REALITY設定を汎用リンク形式でv2flyNGにインポートすると、リストにアドレスとユーザーIDが表示されることがあります。しかし対象コアがREALITYに対応していなければ、接続が通常のTLSへ自動的に切り替わることはありません。サーバーが期待するハンドシェイクがまったく異なるため、セキュリティ層を黙って置き換えることはできません。サーバーが別途提供する互換設定を使うか、対応機能を備えたv2rayNG、v2rayN、Xrayコアで使用してください。

コア移行前の検証方法

移行前に、元の設定のプロトコル、伝送、セキュリティ、ルーティング、DNSをエクスポートまたは記録してください。共有リンクだけを保存してはいけません。次に対象コアが各重要フィールド、特にflow、REALITY公開鍵、短い識別子、伝送サービス名、カスタムアウトバウンドに対応しているか確認します。移行後はまず複雑なルーティングを無効にし、単一設定で基本接続を確認します。その後DNS、最後に分割ルーティングを戻します。これにより、プロトコル非互換、DNS動作の差、規則タグの変更を切り分けられます。

コアを切り替えた後は、ローカル待受ポートとシステムプロキシも確認してください。GUIクライアントは設定モードごとに異なる入口を使う場合があります。古いブラウザーやアプリのプロキシ設定が元のポートを指していると、「コアは起動したが通信がない」という状態になります。ログにインバウンド接続の記録がなければ、まずアプリがローカル入口に入っているか確認します。インバウンドはあるが遠端ハンドシェイクに失敗する場合は、プロトコルとセキュリティ項目を確認してください。ポート競合についてはローカル待受ポートのトラブルシューティングを参照してください。

// 06 · TRANSPORT & SECURITY

伝送方式・TLS・REALITYと重要パラメータ

TCP、WebSocket、gRPC、HTTPUpgrade

クライアント設定でTCPと表示される場合、通常はプロトコルデータをTCPに直接載せることを意味し、TLSがないという意味ではありません。networkは伝送方式、securityは外側のセキュリティを決める独立したフィールドです。WebSocketにはパスが必要で、構成によってはHostも必要です。パスは通常スラッシュで始まり、サーバーおよび中継規則と一致させなければなりません。gRPCはserviceNameでサービスを識別するため、WebSocketのpathをそのまま入力しないでください。HTTPUpgradeもパスとHostを使用しますが、WebSocketとは異なる伝送タイプであり、サーバーが明確に対応している必要があります。

サブスクリプションのインポート後、アドレス、ポート、ユーザーIDが正しいのにHTTPステータスエラー、サービス不存在、即時切断がログに出る場合は、まず伝送方式を確認します。よくある原因は、パス末尾の余分なスラッシュ、変換ツールがserviceNameをpathとして扱うこと、Hostとサーバー名の混同、中継がHTTP/1.1またはHTTP/2の一方しか有効にしていないことです。クライアントが自動推測してサーバーの実際の構成を当てることはできません。フォームの値は正確である必要があります。

TLSのサーバー名と証明書検証

TLS設定のserverNameはハンドシェイク時の本人確認に使われ、証明書のドメイン名と一致することが多い項目です。接続先はドメインまたはIPにできますが、serverNameはサーバーの要件に合わせて入力します。allowInsecureのような項目は証明書検証を制御します。通常の設定では厳格な検証を維持してください。証明書エラーが出たら、端末時刻、サーバー名、証明書の有効範囲、証明書チェーンを確認します。長期的に検証を無効にしてはいけません。証明書エラーはプロキシ認証より前に起きるため、ユーザーIDやパスワードを変更しても解決しません。

ALPNは上位プロトコルのネゴシエーションに使われ、HTTP/2やHTTP/1.1に関係する値が一般的です。サーバーや中継設備から明確な指定がある場合だけ手動設定します。必要なく追加すると、サーバーが正しく処理できないプロトコルをクライアントが選ぶ可能性があります。指紋模倣フィールドはTLSクライアントのハンドシェイク特性に影響し、選択肢はコア実装によって決まります。サブスクリプションに含まれている場合は通常そのまま保持し、手動編集前に現在のコアが受け付ける名称を確認してください。

REALITYで確認すべき4つの主要フィールド

REALITY設定で特に確認すべきなのはserverName、publicKey、shortId、fingerprintです。serverNameはハンドシェイクで使うサーバー名、publicKeyはサーバーの鍵ペアに含まれる公開鍵、shortIdはサーバーが許可する値、fingerprintはクライアントのハンドシェイク指紋を指定します。1つでも欠落や文字誤りがあると、接続が初期段階で失敗することがあります。共有リンクでは、これらが sni、pbk、sid、fp などのパラメータで表されることがあります。インポート後は設定詳細で、値が途中で切れていないことを確認してください。

VLESS REALITYはVisionのフロー制御と組み合わせることがよくあります。この場合、クライアントのflowはサーバーと一致させる必要があり、他のVLESS設定が空欄だからといって削除してはいけません。逆に、サーバーがVisionを有効にしていないなら勝手に追加しないでください。REALITYの項目は「詳細設定」に見えても、実際には接続に必須の情報です。サブスクリプション変換、QRコード認識、手動コピーの後に問題が出たら、まずこれらのフィールドを1文字ずつ照合するほうが、ルーティングモードを何度も切り替えるより有効です。

ルーティング設定例とプロトコル設定の境界

ルーティング規則は遠端のプロトコル接続を確立するものではなく、コアに入ったリクエストを異なるアウトバウンドへ振り分けます。次の例は、広告カテゴリを先にブロックし、プライベートアドレスと地域内ドメインを直接接続し、それ以外をデフォルトのプロキシアウトバウンドへ送る一般的な優先順位を示します。例は解析可能なXray/V2Rayルーティングオブジェクトの断片です。実際に使うときは、完全な設定内に block、direct、proxy という名前のアウトバウンドタグが存在することを確認してください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

規則はコア設定のセマンティクスに従って照合され、競合する規則の順序が結果を左右します。カスタム規則を追加する前に、最終設定を生成する際にクライアントがプリセット規則を追加するか確認してください。画面上の順序が最終JSONの順序と一致するとは限りません。domainStrategyは、IP規則との照合を続けるためにドメインをIPへ解決するタイミングを決め、DNS問い合わせ数と分割結果に影響します。domain、ip、geositeの具体的な書式と優先順位は、カスタムルーティング規則の構文詳解で確認できます。

// 07 · SUBSCRIPTION COMPATIBILITY

サブスクリプション形式・共有リンク・フィールド互換性

サブスクリプションは設定を運ぶ仕組み

サブスクリプション自体はプロキシプロトコルではありません。提供元からクライアントへサーバー設定を渡すもので、Base64でエンコードされた複数行の共有リンクの場合もあれば、クライアントが解析できる構造化設定の場合もあります。一般的な共有リンクは vmess://、vless://、trojan://、ss:// で始まります。リンクのスキームがプロトコルの種類を示し、クエリパラメータが伝送、セキュリティ、サーバー名、パス、公開鍵などを表します。クライアントはインポート時にデコード、フィールド変換、内部設定の生成を行います。

Base64はエンコード方式にすぎず、内容が暗号化されていることも、プロトコルの機能を決めることもありません。同じサブスクリプションURLでも、更新によってノード、備考、パラメータが変わることがあります。クライアントは通常、更新時にグループ単位で古い設定を置き換えるか統合するため、サブスクリプションから生成された項目を手動編集しても次回更新で上書きされる可能性があります。ローカルの変更を長期保存するなら、独立した設定として複製するか、クライアントの前処理・後処理機能を使い、変更理由を記録してください。

共有リンクのフィールドが失われる理由

フィールドの欠落は、生成元、変換処理、クライアントのインポーターが同じパラメータに異なる名称を使う場合に起こりやすくなります。VLESS REALITYでは、公開鍵がpbk、短い識別子がsid、サーバー名がsni、指紋がfpと表記されることがあります。インポーターが1種類の命名しか認識しないと、リストにはアドレスとユーザーIDが生成されても、重要なセキュリティ項目が空になります。VMessのJSON共有内容も、古いフィールド、文字エンコード、備考に含まれる特殊文字によって解析に失敗することがあります。

サブスクリプションの問題を判断するときは、「サブスクリプションの取得」と「個別設定の実行」を分けて考えます。サブスクリプションURLを更新できない場合は、URLが完全か、認証が必要か、システム時刻とネットワークから提供元へアクセスできるかを確認します。更新は成功するのに特定の設定だけ実行できない場合は、その項目のプロトコルフィールドを確認します。元の共有リンクを手動インポートすると使えるのに、サブスクリプション経由では使えないなら、問題はコアではなくサブスクリプション内容や変換処理にある可能性が高いです。

3つのクライアントの互換性を判断する

v2rayNはデスクトップでVMess、VLESS、Trojan、SSなどの一般的なタイプを集中管理し、選択したコアで実行するのに適しています。v2rayNGはAndroidとXray設定向けで、VLESS REALITYなどのXray機能に適しています。v2flyNGはV2Flyコアを使用し、V2Flyで実行できる設定を明確に提供するサブスクリプションに向いています。3つのクライアントが基本的な共有リンクを認識できる場合でも、「リンクを認識できること」と「リンク内のすべての機能をサポートすること」は分けて判断してください。

複数端末で同じサブスクリプションを使う場合、最も安全なのは、基本互換設定と専用コアが必要な設定を同時に提供し、分かりやすい備考で区別することです。すべての項目がREALITYに依存しているなら、v2flyNG側で利用可能な代替設定が自動的に得られることはありません。逆に、基本的なVMessまたはSSだけを使う場合はコア間の移行が簡単ですが、伝送拡張、UDP、暗号化方式は確認が必要です。完全なインポート手順はv2rayNとv2rayNGでサブスクリプションリンクをインポートする方法を参照してください。

サブスクリプション更新時の安全な手順

更新前に、現在使っている項目とルーティングモードを記録し、重要な手動設定はサブスクリプションとは別のグループへ先に複製します。更新後すぐに古いグループを削除せず、項目数が妥当か、備考が変わっていないか、現在の設定が選択されたままかを確認してから接続テストを行います。更新後にすべての項目で異常が出た場合は、古い設定に戻して、サブスクリプション内容の変更かローカルネットワークの問題かを判断します。1項目だけが異常なら、更新前後のアドレス、ポート、プロトコル、セキュリティ、伝送フィールドを比較してください。

QRコードからのインポートも共有リンクの解析にあたります。QRコードが鮮明でも内容が完全とは限りません。画像の切り抜き、拡大縮小、長いリンクの容量が認識に影響することがあります。認識後は設定詳細を確認し、「インポート成功」と表示されたことだけで最終確認にしないでください。サブスクリプションや共有リンクに機密性の高い接続情報が含まれる場合は、アクセス認証情報として扱い、公開ページやログのスクリーンショットに完全な内容を表示しないでください。問い合わせ時はプロトコルの種類とフィールド名を残しつつ、アドレス、ユーザーID、パスワード、鍵パラメータは隠します。

// 08 · SCENARIO CHOICE

用途別にプロトコルとクライアントを選ぶ

既存サーバー：一致を最優先

既存サーバーやサブスクリプション由来の設定では、選択肢はサーバーによって決まります。クライアントではプロトコル、伝送、セキュリティパラメータをそのまま使い、VLESSをVMessに変えたり、WebSocketをTCPに変えたりしないでください。デスクトップではv2rayNを優先し、設定項目を完全にサポートするコアを選びます。AndroidでVLESS REALITY、VisionなどのXray機能を使う場合はv2rayNGを使用し、V2Fly互換設定であることが明確ならv2flyNGを使えます。プロトコル名の新しさより、安定して動くことが重要です。

同じサブスクリプションに異なるプロトコルの項目が複数ある場合は、まずフィールド欠落とコア不一致の項目を除外し、その後で実際の経路を比較します。VMessは成熟した導入を継続したい場合に適し、VLESSは現代的なTLSやREALITYとの組み合わせに向いています。Trojanは標準TLSのパラメータが明確な構成に適し、SSは基本項目がシンプルでUDP対応を重視する場合に適しています。最終的には、リストの順序や名称の印象ではなく、安定性、復帰速度、日常アプリの動作で選んでください。

複数プラットフォームで共有：互換性を優先

Windows、macOS、Android、Linux間で設定を共有する場合は、まず各端末のクライアントが完全にインポートできるか確認します。基本的なVMess、Trojan、SSは環境をまたいで表現しやすく、基本的なVLESS TLSも広く対応しています。REALITY、Vision、特定の伝送拡張を加える場合は、端末ごとにコアを確認してください。複数プラットフォーム向けには、新しい機能を使う主設定を1つ残し、項目がシンプルな互換設定も用意すると、コアの違いで端末が完全に接続不能になる事態を避けられます。

サブスクリプションの備考には、Xray専用や基本互換など、読みやすいプロトコルと用途の情報を含めてください。クライアントが自動認識した後に推測する運用は避けます。更新時はまず1台で検証し、フィールドとグループが正常なことを確認してから他の端末を更新します。これにより、サブスクリプション生成元のフィールド変更が全端末に同時に影響するリスクを下げられます。端末ごとに同じクライアントを使う必要はありませんが、各端末のコアと設定の対応関係は記録してください。

低リソース・モバイル利用：追加処理を減らす

低性能端末や待機中の電池持ちを重視する場合は、コアがネイティブ対応し、伝送層がシンプルで、複雑な変換を必要としない設定を優先します。SSは構造が簡潔で、VLESSはプロトコル層のオーバーヘッドが小さいものの、最終的なリソース使用量は外側のセキュリティ、接続数、DNS、ルーティングにも左右されます。直接TCPは多層のHTTPセマンティクスを重ねるより単純になりやすいですが、サーバーの構成が許容していることが前提です。少しのプロトコル処理を節約するために、必要な本人確認や証明書検証を無効にしないでください。

Androidではまず、デバッグログ、無効なDNS再試行、短すぎるキープアライブを減らしてからプロトコルを比較します。待機後に頻繁に切断する場合は、暗号化方式だけを変えるのではなく、バックグラウンド制限とネットワーク切り替えを確認してください。UDPが必要なアプリでは、サーバー、プロトコル、伝送、クライアント入口のすべてがUDPに対応しているか確認します。どこか1層が欠けるだけで一部機能が異常になります。TCPのWeb閲覧が正常でも、UDP経路が正常とは限りません。

複雑なルーティング：コアと規則の機能を優先

ドメイン、IP、アプリ、プロトコル種別ごとに細かく分割ルーティングする場合、プロキシプロトコルよりもクライアントの規則生成方式とコアの機能が重要です。v2rayNはデスクトップで複雑なルーティングを管理するのに適し、v2rayNGはAndroidでXrayの規則と組み合わせて使えます。規則を設計するときは、まずdirect、proxy、blockの3種類のアウトバウンドを決め、その後に高優先度の例外、プライベートネットワーク、地域集合、デフォルト経路の順に整理します。規則が増えるほど、順序とDNSポリシーを明確にしてください。

ルーティング異常の典型例は、一部のドメインだけアクセスできない、LAN機器に到達できない、名前解決結果と接続先アウトバウンドが一致しない、といった症状です。この場合、VMessとVLESSを切り替えても通常は解決しません。一時的に単純なルーティングを使って基本プロトコルを確認し、その後に規則をグループごとに戻します。DNSリーク、リモート名前解決、ローカル名前解決はDNSとルーティング設計の問題です。DNS検出とクライアント設定の実践ガイドを参照して、さらに確認してください。

最終チェックリスト

1. サーバーを確認：プロトコル、アドレス、ポート、伝送、セキュリティ層、すべての認証フィールドを記録し、クライアント側だけで変更しない。
2. コアを確認：REALITYとVisionはまずXrayの対応を確認し、V2Fly設定はv2flyNGまたは対応するデスクトップコアで検証する。
3. サブスクリプションを確認：インポート後のflow、sni、publicKey、shortId、fingerprint、path、serviceNameが完全か確認する。
4. ベースラインを作る：まず単純なルーティングと通常のDNSで接続を確認し、その後に分割ルーティング、多重化、高度な項目を戻す。
5. 用途別にテスト：短時間接続、継続転送、UDP、スリープ復帰、ネットワーク切り替え、複数端末でのインポートをそれぞれ確認する。
6. 切り戻しを残す：検証済み設定を複製し、プロトコル移行、コア切り替え、サブスクリプション更新を同時に行わない。

それでも判断できない場合は、デスクトップではv2rayNとサーバーの元設定から確認し、Androidではコアの機能に応じてv2rayNGとv2flyNGを選びます。エラーが出たらまず層を特定してください。ローカル入口に通信がないならシステムプロキシとポート、遠端ハンドシェイクの失敗ならプロトコルとセキュリティ項目、一部ドメインだけの異常ならルーティングとDNS、サブスクリプション更新後の異常なら更新前後のフィールドを比較します。この順序で進めると、プロトコルを次々に変えるより早く原因を見つけられます。