V2Rayプロトコル・コア選びのガイド

接続設定を構成する4つのレイヤー

クライアント、コア、接続先サーバーを区別する

クライアントでプロトコルを選ぶ前に、3つの要素を確認しましょう。v2rayN、v2rayNG、v2flyNGは、設定の保存や表示、接続の開始、サブスクリプションの管理を行うGUIクライアントです。コアは設定を解釈し、接続を確立して、ルーティングやデータ処理を担います。接続先サーバーは、定められたプロトコルに従って接続を受け付けます。この3つは異なるソフトウェア層です。画面上で設定を保存できても、クライアントが入力を受け付けたというだけで、コアがすべての項目を認識することや、サーバー側と同じパラメーターであることまでは保証されません。PCではv2rayNの各プラットフォーム向けページからインストーラーを選び、Androidでは設定に必要なコアに合ったクライアントを選びましょう。

接続設定は通常、サーバーアドレス、プロキシプロトコル、トランスポート方式、セキュリティ層の4つに分けられます。サーバーアドレスは接続先、プロキシプロトコルは認証と宛先の表現方法、トランスポート方式はプロトコルデータの運び方、セキュリティ層は通信の機密性と認証の仕組みを示します。すべてを「プロトコル」と呼ぶと、問題の切り分けが難しくなります。たとえばVLESSはプロキシプロトコル、WebSocketはトランスポート方式、TLSはセキュリティ層です。これらは1つの設定で併用でき、互いに排他的な選択肢ではありません。ポートはサーバー側の待ち受け口にすぎず、それだけで使用プロトコルを判断することはできません。

クライアントの各設定項目には対応関係がある

クライアントの「アドレス」は通常、下位の接続先を指定します。「サーバー名」またはSNIはTLSハンドシェイクで使う名前情報です。両者が同じ場合もあれば、サーバー側の設定によって異なる場合もあります。WebSocketのHostやパスは別のアプリケーション層パラメーターです。名前が似ていても、SNIをすべての項目にコピーしてはいけません。IPアドレスに直接接続する場合も、証明書の検証にはドメイン名が必要になることがあります。サービス提供元の指定に従い、アドレス、Host、SNIを自由に置き換えられる別名のように扱わないでください。設定ミスを隠すために証明書検証を無効にするのも避けましょう。

ルーティングルールで接続先のプロトコルは変わらない

ルーティング設定は、リクエストがコアに届いた後、どのアウトバウンドで処理するかを決めます。直接接続、プロキシ経由、ブロックのいずれかを選べますが、VMessを自動的にVLESSへ変更したり、不足しているTLSパラメーターを補ったりするものではありません。AndroidのVPNモードとPCのシステムプロキシは、ローカル側の接続方式の違いです。前者はシステムの仮想ネットワークインターフェースで対象の通信を受け取り、後者はシステムプロキシに従うアプリへローカルの待ち受けポートを使うよう伝えます。クライアントが実行中なのに特定のアプリだけプロキシ経由にならない場合は、接続先のプロトコルをすぐに変更するのではなく、まず接続方式を確認しましょう。レイヤーの違いについてはシステムプロキシとルーティングモードの解説もご覧ください。

共有リンクを確認するときは、同じ順序で項目を一覧にすると便利です。アドレスとポートがあるか、認証情報がどのプロトコルに属するか、トランスポートに専用パスがあるか、セキュリティ層が有効かを確認し、最後にルーティングとDNSを確認します。こうすればクライアントを変更するときも、接続先に必要な条件と端末側の使い方に関する設定を区別できます。リンクの長さ、メモ、プロトコル名だけで設定が優れているかを判断しないでください。メモはラベルにすぎず、接続動作を決めるのは最終的にコアへ渡される設定です。

VMessとVLESSの設計上の違い

VMessは認証とデータ保護をプロトコルに組み込む

VMessはProject Vのエコシステムで早期に開発されたプロキシプロトコルで、ユーザー識別、リクエスト認証、データ保護を考慮して設計されています。クライアントでよく使われるUUIDはユーザーを識別するもので、サーバーのドメイン名やサブスクリプションURLではありません。設定の暗号化方式やセキュリティ項目は、コアが対応する方式に合わせる必要があります。インポートできたからといって、別の値へ自由に変更してよいわけではありません。VMessは複数のトランスポート方式で利用でき、TLSを重ねることもできます。プロトコル自体の暗号化と外側のTLSは役割が異なるため、どちらか一方の項目だけで接続全体の安全性を判断することはできません。

現在のVMess環境では、通常AEAD認証方式が使われます。古い記事に登場する追加ID、旧式の認証方式、過去の互換オプションを、現在の設定に一律で推奨される値として扱わないでください。既存の設定を引き続き使えるかどうかは、クライアント側とサーバー側の両方が同じ方式に対応しているかによります。古いサブスクリプションを使う場合は、サーバーが実際に使用している認証方式を確認し、新しい接続パラメーターを入手してから、クライアントとコアの対応状況を確認しましょう。追加IDを何度も変更したり、ネット上の固定値をそのまま使ったりすると、設定の食い違いが増えるだけになりがちです。

システム時刻も個別に確認しましょう。プロトコルによっては認証処理で時間の許容範囲が使われるため、端末の時刻が大きくずれていると、TCP接続は成功していても認証に失敗することがあります。クライアントを何度も再インストールするより、まず日付、時刻、タイムゾーンの自動設定を有効にしてから接続を試すほうが効果的です。時刻が正しくても、認証情報が正しいとは限りません。UUID、ポート、接続先サーバーの設定もそれぞれ照合してください。ログが認証段階で止まっている場合は、DNSやルーティングを変更する前にこれらの条件を確認しましょう。リクエストが後続の転送処理まで進んでいない可能性があります。

VLESSはデータ保護を外側のセキュリティ機構に委ねる

VLESSはプロトコル自体の暗号化処理を抑え、データ保護をTLSやREALITYなどの外側の仕組みに委ねる設計です。それでも認証や宛先の指定は必要であり、プロトコルの処理負荷がゼロという意味ではありません。一般的なVLESS設定では暗号化フィールドにnoneを指定します。これはフィールドのプロトコル上の意味であり、すべてのデータがネットワーク上を平文で流れるという意味ではありません。接続全体を判断するには、セキュリティ層も確認する必要があります。反対に、外側の保護がなければ、VLESSという名前だけを根拠に通信の機密性があると判断することもできません。

VLESSの設定には、xtls-rprx-visionのようなflowフィールドが含まれる場合があります。これはどの接続にも貼り付けて使える汎用の高速化スイッチではなく、特定の処理方式、トランスポートの組み合わせ、コアの機能に関わるパラメーターです。クライアントとサーバーの両方が必要な条件を満たす必要があります。対応していないトランスポートの組み合わせに追加すると、設定が拒否されたりハンドシェイクに失敗したりする可能性があります。サービス提供元からflowの指定がない場合は、名前だけを見て独自に追加しないでください。指定がある場合も、別のクライアントに入力欄がないからといって省略できるとは限りません。

既存の設定を移行するときは全パラメーターを保持する

VMessとVLESSは、ドロップダウンの選択を変えるだけで相互に置き換えられる形式ではありません。サーバーアドレスとユーザー識別子が同じでも、サーバー側で対応するインバウンドプロトコルが設定されている必要があります。移行時はサーバーが提供する新しいリンクを入手し、セキュリティ層、サーバー名、トランスポート、パス、flowをそれぞれ確認してから、独立した設定を追加してテストしましょう。現在使えている設定を残しておけば、新しい設定に失敗したとき、「移行時のパラメーター間違い」と「ローカルネットワークの変化」をすばやく切り分けられます。サブスクリプション管理下の設定を直接上書きすると、次回の更新で手動変更が元に戻ることもあります。

VMessの接続が安定していて、接続先で移行する予定も当面ないなら、プロトコル名だけを理由に環境全体を変更する必要はありません。新規導入でVLESSと特定のセキュリティ層が指定されている場合は、その項目を設定できるクライアントとコアを選びましょう。いずれの場合も、まず接続全体の互換性を優先し、その後で処理負荷を比較します。サービス提供元から「VLESS対応」としか案内されず、トランスポートやセキュリティ層の情報がない場合は、設定が不完全です。必要なパラメーターを確認してからインポートし、互換性の問題をサーバーへの接続不能と取り違えないようにしましょう。

Trojan、Shadowsocks、REALITY

TrojanではTLS接続の設定が重要

TrojanはTLSを基盤とし、パスワード認証と宛先リクエストを保護された接続内で扱うよう設計されています。一般的な設定には、サーバーアドレス、ポート、パスワード、名前検証に関する項目が必要です。接続用パスワードは公開ログや掲示板に貼らないでください。TLSハンドシェイクの成功とプロキシ認証の成功は別の段階です。証明書名が一致しない場合は、サーバー名と証明書の設定を確認します。ハンドシェイク完了後に拒否される場合は、パスワードと接続先サーバーの設定を確認しましょう。両方をひとまとめに「接続できない」と考えると、調査範囲が広がりすぎます。

証明書検証は、気軽に無効化してよいスイッチではありません。接続先のサービスが正しいかを確認する機能であり、無効にすると一時的に接続できても、元の安全性の前提が変わります。端末の時刻誤り、証明書チェーンの設定漏れ、サーバー名の不一致など、失敗の原因を個別に修正してください。Trojanの拡張機能は実装によって異なります。あるクライアントで基本的なパスワード設定をインポートできても、別の実装が追加したすべてのオプションを理解するとは限りません。共有リンクに追加の項目があれば、飾りだと決めつけず個別に確認しましょう。

Shadowsocksでは暗号化方式と鍵の仕様を一致させる

Shadowsocksはクライアント上でShadowsocksまたはSSと表示されることがあります。事前共有した秘密情報と暗号化方式を組み合わせて使うため、設定項目は少なく見えても、方式名は接続プロトコルの一部です。接続する両側で同じ方式を使う必要があり、見慣れた方式へクライアント側だけ変更してはいけません。従来のAEAD方式とShadowsocks 2022系も、名称を変えるだけで相互に置き換えられるものではありません。後者では鍵素材の形式や長さに指定があり、任意の普段使いのパスワードを有効な鍵として使うことはできません。クライアントがサーバーの必要とする値へ自動変換することも期待しないでください。

Shadowsocksを使う場合は、サブスクリプションにプラグインのパラメーターが含まれているかも確認しましょう。基本プロトコルへの対応とプラグインへの対応は別の機能です。プラグインが実装されていないと、アドレス、ポート、方式、パスワードがすべて正しくても使えないことがあります。方式やプラグインの対応範囲はコアによって異なるため、実際に利用するコアが設定を受け付けるか確認してください。UDPを使うアプリでは、接続先がUDP転送を許可しているか、クライアントの接続経路でUDPを扱えるか、ルーティングでブロックされていないかも確認しましょう。Webページが表示されただけでは、これらの条件を満たしたことにはなりません。

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

REALITYはVLESSと組み合わせて使われることが多いため、共有設定に「VLESS + REALITY」と名前が付いている場合があります。REALITYはセキュリティ層に関わる役割を担い、VLESSと同列の別アカウント方式ではありません。一般的なクライアント項目には、サーバー名、公開鍵、Short ID、フィンガープリントがあります。公開鍵はサーバー側の鍵設定に対応し、Short IDはサーバーが許可する識別子との照合に使われ、フィンガープリントはクライアントのハンドシェイク特性に関わります。項目の形式や必須かどうかは設定によって異なります。別の接続から値をそのまま流用せず、公開鍵をUUIDと取り違えないようにしましょう。

REALITYのパラメーターは、サーバー側で設計して提供される必要があります。接続先アドレスへ到達できても、公開鍵、Short ID、サーバー名の組み合わせが正しいとは限りません。接続できない場合は、まずリンク全体が正しくコピーされているか、特に特殊文字を含むクエリパラメーターを確認しましょう。続いて、現在のクライアントのコアが必要な項目を認識できるか確認します。ランダムなフィンガープリントやShort ID、無関係なドメイン名を試すのは避けてください。画面上で項目が空欄でも、サーバー側で不要なのではなく、インポーターが解析できなかった可能性があります。元の共有内容に戻って確認しましょう。

この3つを「新しい」「古い」という基準で置き換えの順に並べることはできません。既存のTLS環境、現在のサブスクリプション形式、サーバー側の実装、モバイル端末での対応状況は、最終的な選択に影響します。クライアントだけを使う場合は、サービス提供元のパラメーター構成を保ち、手元の環境がすべてに対応するかを確認してから、同じネットワークと同じ用途で比較するのが確実です。セキュリティ層やプロキシプロトコルの名前が多いほど設定が優れているわけではありません。不要な中間層を減らすと、構成を理解しやすく管理もしやすくなります。

接続速度、スループット、リソース消費

接続開始時と継続転送を分けて見る

「速い」には、クリックしてから最初の応答が返るまでの時間、長時間の通信で維持できるスループット、複数のリクエストを同時に処理したときの安定性という、少なくとも3つの異なる要素があります。初回応答にはローカルDNS、接続先アドレスの名前解決、下位の接続、セキュリティハンドシェイクが影響します。継続的な転送速度には、経路の帯域幅、パケットロス、輻輳制御、接続先の負荷、端末の処理能力がより強く影響します。ページの初回表示が遅い設定でも、大容量ファイルの転送では正常なことがあります。比較する指標を決めてからテストし、ある設定でのページ読み込みと別の設定での速度テストを一度ずつ比べるのは避けましょう。

プロキシプロトコル自体の処理負荷は、接続経路全体の一部にすぎません。暗号アルゴリズムがプロセッサーの命令を利用できるか、外側にTLSを重ねるか、途中にリバースプロキシがあるかによって、CPU使用率や接続確立のコストは変わります。低消費電力の端末で確認できる差が、高性能なPCではごく小さいこともあります。ハードウェア条件を無視して、常に最も省リソースなプロトコルを決めることはできません。接続先の混雑が原因の低スループットを、端末の暗号処理が遅いせいだと説明することもできません。まずネットワークとサーバー負荷を確認し、その後でプロトコルの処理負荷を考えるのが適切です。

トランスポートのカプセル化と接続の多重化にはそれぞれ制約がある

直接TCP、WebSocket、gRPCの違いは、主にデータの運び方、中継設備との互換性、接続管理にあります。WebSocketではHTTP Upgradeと正しいパスが必要な場合があり、gRPCでは通常HTTP/2と一致するサービス名が必要です。中継設定もそれぞれに対応していなければなりません。こうした仕組みは構成の柔軟性を高める一方、管理するパラメーターも増やします。明確なサーバー側の要件に基づいて選び、カプセル化の層が多いほど性能が上がると考えないでください。パスやサービス名が誤っていると、下位のポートに到達できてもプロキシセッションを確立できないことがあります。

クライアントの「Mux（多重化）を有効にする」設定は、複数の論理リクエストで共有する下位接続を減らすことを目的とします。接続を頻繁に確立する負荷を減らせる一方、同じ接続上の輻輳や障害が複数のリクエストに影響することもあります。トランスポート自体の多重化機能と重ねても、効果が上がるとは限りません。プロトコル、flow、コアの組み合わせによっては、明確な制約もあります。まずは既定値を保ち、サーバーが対応していて短時間の接続が多い用途で必要な場合にテストしましょう。動作が重いときに必ず有効にすべき汎用の解決策ではありません。

単発の順位ではなく再現できるテストで判断する

まず一般的なWebページで初回応答を確認し、続いてテストが許可された安定したリソースで継続転送を測定し、最後に実際の用途で同時接続や長時間接続を確認します。テストを繰り返す際は、初回接続と再利用済み接続を分けてください。キャッシュやセッション再開で結果が変わることがあります。テスト中はほかの大容量通信を止め、ネットワーク切り替えやスリープが発生していないか記録しましょう。最も良かった1回の結果だけを残したり、アプリに表示される接続テスト時間をエンドツーエンドのダウンロード速度と見なしたりしないでください。テスト方法によって測定対象は異なります。

CPUとメモリの使用状況も、条件を踏まえて見ましょう。ルールデータベース、接続数、ログレベル、DNSキャッシュもリソースを消費するため、すべてをプロトコルのせいにしてはいけません。クライアントがアイドル時は正常で、ページを多数開いたときに使用量が増えるなら、同時接続数やルール処理を確認します。1つの継続転送だけで端末が大きく発熱するなら、暗号化やカプセル化の条件を比較しましょう。調査後は不要な詳細ログを無効にし、元の設定を記録しておくと、その後の変化を設定項目ごとに追跡できます。印象だけで判断するのは避けましょう。

リアルタイム通信では、UDP経路とジッターも確認が必要です。Webページが表示されても、一部のTCP通信が使えることを示すだけで、通話、ゲーム、名前解決に必要なUDPが通るとは限りません。通信がときどき途切れる場合は、プロトコル名だけを変えるのではなく、接続方式、サーバー側の転送、ネットワークのパケットロスを確認しましょう。長期利用では、実際の用途を安定してこなせることが、一度だけ記録した最大スループットより参考になります。選ぶ際は障害からの復旧しやすさと管理のしやすさも考慮しましょう。

Androidのバックグラウンド動作、ネットワーク切り替え、電池消費

電池消費は接続経路全体から発生する

Androidでの電池消費を、VMess、VLESS、Trojanの種類だけで判断することはできません。無線通信の起動、接続維持、DNSクエリ、バックグラウンドアプリの通信、暗号処理、詳細ログなどが電池に影響します。スループットが高い状態が続くと無線モジュールとプロセッサーの稼働時間が増えます。少量の通信でも、細切れのバックグラウンドリクエストで端末が頻繁に起動すれば、電池消費が目立つことがあります。プロトコルを比較するときは、プロキシ対象のアプリ、接続先サーバー、ネットワークの種類、画面の状態をそろえましょう。条件が異なると、プロトコル設計ではなく使い方の違いを測ることになります。

v2rayNGのVPNモードは、システムのVPNインターフェースで通信を受け取り、コアに渡して処理します。アプリごとのプロキシ設定では、処理対象となるアプリの範囲を絞れます。ただし「アプリを選択」が選択したアプリだけをプロキシ経由にするのか、選択したアプリを除外するのかは、現在のモードと画面の説明で確認してください。変更後は接続を張り直し、対象のアプリを実際に開いて動作を確かめましょう。プロキシのみのモードでは、アプリ自身がローカルのプロキシ接続先を使える必要があります。システムがすべてのアプリの通信を自動で転送するわけではありません。モードの不一致が、接続の不安定さと誤解されることがあります。

症状に応じてバックグラウンド制限を調整する

アプリをバックグラウンドにしたり画面を消したりすると接続がすぐ切れる場合は、まずシステムがクライアントのサービスを終了していないか、バックグラウンド実行が許可されているか、ほかのVPNアプリが現在の接続を置き換えていないかを確認します。Android端末によって電池管理の場所や名称が異なるため、アプリ情報にある電池とバックグラウンド権限から調べるとよいでしょう。最初からすべての省電力設定を無効にするのではなく、画面消灯後、ロック時のアプリ整理後、特定の省電力モード中のどの条件で発生するかを確認してから、必要な設定を変更してください。ネットワークには接続中なのに特定のアプリだけ通知を受け取れない場合は、そのアプリ自身のバックグラウンド制限も確認しましょう。

クライアントが動作中で、Wi-Fiからモバイルネットワークに切り替えた後だけ接続できなくなる場合は、元の下位接続が切断された可能性をまず考えます。同じプロトコル名だからといって、古い接続がネットワークをまたいで自動的に維持されるわけではありません。コアとアプリはセッションを再確立する必要があります。まず接続を停止して再起動し、復旧するか確認しましょう。復旧するなら、自動再接続の挙動、システムのネットワーク状態、接続先サーバーの接続処理を調べます。動画配信アプリや通話アプリが古いセッションを保持していることもあるため、状態表示だけで判断せず、アプリの画面を開き直して確認してください。

多重化、接続維持、DNSの設定をむやみに強化しない

接続維持のための通信は、無効な接続の検出や一部のネットワーク機器でのセッション維持に役立ちますが、確認頻度を上げると無線通信の起動が増えることもあります。アイドル時に切断する問題がなければ、間隔を極端に短くする必要はありません。Muxもプロトコルの組み合わせに応じて判断しましょう。スマートフォンの電力消費を気にしているからといって、接続を共有すれば必ず省電力になるとは限りません。大量のデータを継続転送する場合、ハンドシェイクを少し減らしても主な電力消費は変わらないことがあります。接続異常のたびに再試行を繰り返すと、かえって負荷が増える可能性もあります。設定変更後はスイッチの状態だけでなく、実際の使い方で確認しましょう。

DNS設定の誤りは、同じ問い合わせの繰り返し、タイムアウト、再接続を引き起こすことがあり、クライアントが動作しているのに有効な通信がないように見える場合があります。まず名前解決の失敗とセキュリティハンドシェイクの失敗を区別し、DNSサーバーに到達できるか、ルーティングが循環していないか、ドメインのルールで余計な名前解決が発生していないかを確認しましょう。ローカルDNSを有効にしても、すべてのアプリが同じ経路で名前解決するとは限りません。アプリ独自の暗号化DNSも結果に影響することがあります。関連する問題はFAQのトラブル対処カテゴリでも確認できます。DNS、セキュリティ層、ルーティングを一度に変更するのは避けましょう。

電池消費を比較するときは、同じ条件で2つの時間帯を設けます。まず画面を消して用途をほぼ停止した状態でバックグラウンド動作を確認し、次に同じ用途を実行して発熱と電池消費の傾向を見ます。接続が張り直されたか、ネットワークが切り替わったか、アプリが継続的にダウンロードしていたかを記録しましょう。端末条件を無視した一律の消費割合を示す必要はありません。アイドル時に問題があれば、起動、再試行、ログを重点的に確認します。高負荷時だけ問題が起きるなら、スループット、暗号処理、端末の放熱を調べましょう。この方法なら、実際の設定に役立つ結論が得られます。

V2Fly、Xray、クライアントの互換性

同じルーツを持っていても機能が完全に同じとは限らない

Project Vは、このエコシステムを理解する出発点です。V2FlyとXrayは、関連するコア群の中で異なる方向に発展しています。インバウンド、アウトバウンド、ルーティング、DNSの設定といった概念や歴史的な基盤の一部は共有していますが、プロトコル機能、トランスポートの実装、設定項目はそれぞれ独自に進化しています。「どちらもV2Rayのエコシステムに属する」というだけで、すべての設定が共通だと判断してはいけません。あるコアで有効な項目が、別のコアには存在しない、名前が異なる、または制約が異なる場合があります。設定全体をそのまま流用せず、項目ごとに確認しましょう。

v2rayNGは主にXrayコアを接続機能の基盤とし、v2flyNGはV2Flyコアの系統に対応します。v2rayNはPC向けのGUI管理機能と、それに応じたコアの実行設定を提供します。GUIの機能と実際に選択しているコアは、合わせて確認する必要があります。クライアントにインポート機能があっても、現在動作中のコアがインポート内容を処理できるとは限りません。エコシステムの関係についてはProject V、V2Fly、Xrayの系統についての解説もご覧ください。クライアント名だけを見て対応プロトコルの一覧だと判断しないようにしましょう。

プロトコル、設定、画面はそれぞれ異なる互換性を持つ

プロトコル互換性とは、双方が同じプロトコルでデータを交換できることです。設定互換性は、コアが設定の構造と項目を理解できることを指します。画面上の互換性は、クライアントで必要な項目を入力、保存し、コアに渡せることです。どれか1つが欠けても、利用できないことがあります。たとえばコアが機能に対応していても、GUIのインポーターが新しいパラメーターを保持できなければ、最終的な設定は不完全になります。反対に、画面が元の文字列を保持していても、実際のコアが認識できなければ機能は使えません。問題がどの段階で発生しているかを確認しましょう。

REALITYと一般的なVLESS Visionの組み合わせは、Xrayの対応状況と項目の不足を重点的に確認する必要があります。別のコアに同じ名前で同じ意味の実装があり、そのまま置き換えられると仮定しないでください。V2Fly系のプロトコルやトランスポート機能も、実際の実装に基づいて確認する必要があります。一方の系統を他方の機能の完全な下位集合として説明するべきではありません。コア選びは、どれが抽象的に優れているかを決めるのではなく、現在のサーバーが必要とする組み合わせを正確に動かせるか、クライアントでその設定を管理できるかを確認する作業です。

短い設定でも実行環境の確認が必要

以下はXray形式のルーティングの一部で、ルールの役割を説明するためのものです。単体で実行できる完全な設定ではありません。利用する際は適切な完全設定に組み込み、directとblockのタグを持つアウトバウンドと、対応するルール用リソースが設定されていることを確認してください。1つ目のルールは指定された広告ドメイン群をブロックし、後ろの2つはプライベートアドレスと指定ドメイン群をそれぞれ直接接続のアウトバウンドへ渡します。ルールは上から順に評価され、一度一致したルールを後のルールが上書きすることはありません。そのため、順序を変えると結果が変わる場合があります。

{
  "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"
      }
    ]
  }
}

IPIfNonMatchは、ドメインルールに一致しなかった場合にルーティング段階でドメインを解決し、その後IP条件を確認できることを示します。「すべてのドメインを最初からIPで振り分ける」という意味ではありません。ルール用リソースがない、アウトバウンドのタグが誤っている、DNSに到達できないといった問題があると、設定どおりに動作しないことがあります。設定互換性は項目名の一致だけでなく、リソース、タグ、名前解決の経路などの実行環境にも左右されます。通常の利用ではクライアントのルーティング画面でルールを管理し、生成される構造を理解している場合に限ってカスタム設定を使いましょう。

サブスクリプション、共有リンク、インポートの互換性

サブスクリプションURLと接続情報は別のもの

サブスクリプションURLは通常、設定一覧を取得するためのアドレスです。一方、個別の共有リンクには1つの接続設定が記載されています。個別の共有リンクをサブスクリプションURL欄に入力したり、サブスクリプションURLを接続設定としてインポートしたりすると、取得に失敗したり有効な項目が表示されなかったりすることがあります。サブスクリプションにはアクセストークンが含まれる場合があり、設定一式を閲覧できる権限を持つこともあるため、機密情報として扱ってください。トラブルの相談時に元のURLを公開してはいけません。ログやスクリーンショットでは、認証用クエリパラメーター、アカウント識別子、接続先のパスワードを隠し、接続設定一式が漏れないようにしましょう。

Base64はエンコード方式であり、暗号化プロトコルではありません。サブスクリプションの内容を保護する機能もありません。一般的なサブスクリプションでは、複数の共有リンクをテキストにまとめてからエンコードします。クライアントはテキストに戻してからリンクを個別に解析します。APIによっては、エンコードされていないリンク一覧や構造化設定を直接返すこともあります。サーバーからWebページ、ログイン画面、エラーメッセージが返されると、クライアントが有効なサブスクリプションとして認識できない場合があります。更新に失敗したら、単純にBase64のエンコードが壊れたと考えるのではなく、リクエストの失敗と内容形式の非互換を切り分けましょう。

同じプロトコルでも共有形式が異なることがある

VMessの共有データではエンコードされた構造化データ、VLESSやTrojanではクエリパラメーター付きURI、Shadowsocksでは別形式のユーザー情報エンコードがよく使われます。これらはクライアント間の共有形式であり、コアの設定形式と完全に同じではありません。基盤のプロトコルが利用できても、エンコード方式、パラメーター名、拡張項目が異なると、インポーターが内容を正しく認識できないことがあります。リンクの先頭部分を認識できるかだけでなく、インポート後にトランスポート、セキュリティ層、認証項目が正しい場所に設定されているかも確認しましょう。

リンク内のパス、メモ、クエリ値はパーセントエンコードされている場合があります。手動でコピーすると、改行や空白、チャットアプリによる自動切り詰め、繰り返しのデコードで元の値が変わる可能性があります。特にパスに疑問符、シャープ、アンパサンドが含まれる場合、URIの構造を表す記号なので、単なる文字として貼り付けてはいけません。まずはクライアントのクリップボードからのインポートやスキャン機能を使い、テキストエディターで何度も変換するのは避けましょう。インポート後は、メモが同じかではなく項目の意味を照合してください。

サブスクリプションの追加画面から更新し、結果を確認する

v2rayNGでは通常、「サブスクリプショングループ設定」からグループ名とサブスクリプションURLを追加して保存し、その後にサブスクリプションを更新します。v2rayNでは、サブスクリプショングループ関連のメニューでURLと更新を管理します。画面の変更によりメニュー名が変わる場合がありますが、「URLを保存する」操作と「内容を取得する」操作は別です。保存できても、接続先から内容がダウンロードされたとは限りません。詳しい操作はサブスクリプションの追加方法とBase64形式の解説をご覧ください。初めて使う場合は入門ガイドに沿って基本手順を進めましょう。

更新後は、設定が属するグループ、プロトコルの種類、主要なセキュリティパラメーターを確認してから接続を試します。更新前は使えていて更新後に失敗する場合は、クライアント全体をすぐにリセットするのではなく、接続先で認証、トランスポート、セキュリティ層が変更されていないかを比較しましょう。グループの更新で管理対象の項目が置き換わることがあり、サブスクリプション内の設定を手動で変更しても次回更新時に上書きされる場合があります。項目を一時的に検証する場合は、用途を明記した独立のテスト用コピーを作ります。検証後はサブスクリプション元の設定を修正し、内容の異なる2つの設定を長期にわたって管理するのは避けましょう。

形式変換ツールが変換できるのは、ツールが理解できる項目だけです。元のサブスクリプションに含まれるプラグイン、flow、REALITYのパラメーター、特殊なトランスポート項目を変換先の形式で表現できないと、インポート自体は成功しても重要な機能が失われる可能性があります。変換の手順を増やすと、機密設定を別の処理先に渡す機会も増えます。まずはサーバー提供元が用意した互換形式を使いましょう。変換が必要な場合は前後の項目を1つずつ確認し、「変換成功」を接続全体の互換性の証明と見なさないでください。サブスクリプションは設定を配布する仕組みであり、サーバーとコアの機能差を解消するものではありません。

用途に合わせた選び方と失敗段階の特定

まず必須条件を決めてから使用感を比較する

すでに接続先の設定がある場合、選択肢はまずサーバー側の条件で決まります。VMessを受け取ったら、対応する認証方式とトランスポートの組み合わせを扱えるクライアントを使います。VLESSとREALITYを受け取ったら、まずXrayの対応状況と必須項目を確認しましょう。サーバーが複数の完全な設定を提供している場合に限り、同じ条件で比較できます。PCではv2rayNを推奨し、OSとCPUアーキテクチャに合ったインストーラーを選びます。Androidでは通常v2rayNGから試し、V2Fly系の設定が必要な場合はv2flyNGの対応状況を確認してください。対応するファイルの説明はダウンロードページにまとめています。このページはインストーラー選びを目的としたものではありません。

日常のWeb閲覧やオフィス用途では、初回応答、証明書検証、長期的な安定性が重要です。理論上の処理負荷を理由に複雑なカプセル化を追加する必要は通常ありません。開発ツールやターミナルでは、アプリがシステムプロキシに従うか、プロキシ環境変数を個別に設定する必要があるかを確認しましょう。ブラウザーでは使えるのにターミナルで失敗する場合は、ローカルの接続方式が異なることが多く、接続先プロトコルがターミナルに不適切とは限りません。ブラウザーとターミナルを別々に確認する解説を参考にして、すでに利用できている接続設定の認証やセキュリティ項目を何度も変更しないようにしましょう。

リアルタイム通信、対話型サービス、UDPに依存するアプリでは、UDP対応を必須条件として扱います。まずクライアントの接続方式を確認し、次にコア、接続先の転送、ルーティングを調べ、最後に実際の用途でテストします。モバイルネットワークが頻繁に切り替わる環境では、短時間の最大スループットより再接続、バックグラウンド動作、セッションの復旧を重視します。長時間の転送では、継続速度、プロセッサー負荷、安定性を確認しましょう。ただし接続先とテスト用リソースはそろえる必要があります。条件が違えばネットワークとプロトコルの差を区別できません。

段階ごとに切り分けて問題の範囲を絞る

第1段階では設定を読み込めるか確認します。ログに未知の項目、無効な方式、必須パラメーターの不足が表示された場合は、ルーティングを変更する前にクライアントでのインポートとコアの互換性を確認しましょう。第2段階では接続先の名前解決と下位の接続を確認します。名前解決に失敗する場合はDNS、接続がタイムアウトする場合はアドレス、ポート、ネットワーク経路、接続先の待ち受け状態を調べます。ポートに到達できても、下位の入口が応答したことを示すだけで、プロキシ認証の成功までは確認できません。現在の段階で発生している問題だけを修正すると、無関係な変更による隠蔽を防げます。

第3段階ではセキュリティハンドシェイクと認証を確認します。証明書エラーが出たら時刻、サーバー名、証明書チェーンを調べます。REALITY関連の失敗では公開鍵、Short ID、フィンガープリント、名前のパラメーターを確認し、認証拒否の場合はUUID、パスワード、プロトコル固有の項目を照合します。第4段階ではリクエストが正しいアウトバウンドへ届いているか確認します。ハンドシェイクは完了しているのに宛先を開けない場合は、ルーティングの適用結果、DNSの結果、アウトバウンドのタグ、宛先サービスの状態を調べましょう。特定のアプリだけが失敗する場合は、システムプロキシ、アプリ別のプロキシ設定、アプリ独自の設定を再確認します。一部の障害を接続全体の失敗と決めつけないでください。

テスト結果を保守記録に残す

設定ごとに用途、必須項目、クライアントとコア、テストしたネットワーク、結果を記録すると便利です。公開される可能性のあるアカウント情報や秘密情報は記録しないでください。用途はWeb閲覧、開発ツール、リアルタイム通信など具体的に記載し、結果も初回応答が遅い、バックグラウンドで切断する、UDPだけ失敗するといった形で残します。「あるプロトコルは使いにくい」という感想より役立ち、端末を変更した後も適切な設定を再現できます。クライアントやサブスクリプションを更新した後は基準となる用途を再テストし、変化があれば段階ごとに比較しましょう。原因を調べる代わりにすべてをリセットするのは避けてください。

最終的な選択では、接続先の構成が完全にサポートされていること、セキュリティ検証が正しく行われること、対象端末で実際の用途が安定して動作することの3点を満たす必要があります。そのうえでリソース消費、管理のしやすさ、ネットワーク切り替え時の動作を比較しましょう。プロトコル名はこれらの検証の代わりにはなりません。すべての端末と用途に最適なものが1つだけあるわけでもありません。よくある症状への短い回答はFAQをご覧ください。インポート、接続、検証の手順を最初から確認する場合は、入門ガイドに戻って順番に進めましょう。