V2Rayプロトコルと
コア技術ガイド

01 / CONFIGURATION LAYERS

プロトコル・伝送方式・セキュリティ層

ノード名だけでは設定内容は分からない

クライアントのノード一覧に表示される接続先は、連携して動作する複数の設定値で構成されています。プロトコルは認証とプロキシ要求の形式、伝送方式はデータをサーバーに届ける方法、セキュリティ層は接続先の認証と保護を担います。アドレス、ポート、ユーザーIDは接続条件です。一方、パス、リクエストヘッダー、サーバー名は別の階層に属する場合があります。選ぶ際は略称だけで速度や互換性を判断せず、まず設定一式を確認してください。利用できる組み合わせはサーバー側が決め、クライアントは対応範囲内で正しく再現します。

たとえばVLESSは、同じプロトコルでも伝送方式やセキュリティ設定を変えられます。通常のTCPを使う設定をWebSocketに変更しただけでは接続できません。サーバー側にも対応する待ち受け設定とパス処理が必要です。TLSも、どのノードにもスイッチを追加すれば有効になるわけではありません。サーバーが適切なハンドシェイクを提供し、証明書の名前が一致し、クライアントが証明書チェーンを信頼できる必要があります。プロトコルが同じでも、ほかの設定値が異なれば接続方法は大きく変わります。

アドレス・サーバー名・リクエスト先を区別する

サーバーアドレスは、クライアントが接続する機器を示します。ドメイン名の場合も、IPアドレスを直接指定する場合もあります。TLSのサーバー名は通常SNIとして送信され、証明書名の検証にも使われます。WebSocketのHostはアプリケーション層のリクエスト項目です。これらは同じ値の場合もあれば、構成に応じて異なる場合もあります。ドメイン名に見えるからといって、相互にコピーしないでください。トラブル時は、名前解決、ポートへの接続、ハンドシェイクと認証、接続先サイトへのアクセスの順に確認すると、名前解決の問題をプロトコルの問題と誤認しにくくなります。

接続方式と出口プロトコルは別の設定

システムプロキシは、システムやアプリにローカルのプロキシ接続先を提供する機能です。対応する設定に従うプログラムだけが利用します。TUNは仮想ネットワークインターフェースで通信を受け取るため、より広い範囲をカバーできますが、ルーティング、権限、除外設定にも左右されます。どちらも接続先のプロトコルを変更するものではありません。ノードをインポートできても一部のアプリが接続できない場合は、まずその通信が実際にクライアントを経由しているか確認し、その後に出口ログを確認してください。VLESSをVMessに変更しても、アプリがシステムプロキシを迂回する問題は解決しません。

ルーティングとDNSもそれぞれ別の階層です。ルーティングは通信の出口を直結、プロキシ、ブロックなどから選択し、DNSは名前解決とその関連ポリシーを担います。特定のサイトが直結されていても、ノード認証の失敗とは限りません。ドメインを解決できないからといって、TLS設定に問題があるとも限りません。問題を記録するときは、クライアント、コア、プロトコル、伝送方式、セキュリティ層、接続方式を併記してください。ログを共有する前に、サブスクリプションURL、ユーザーID、認証情報を削除し、エラーの種類と発生順だけを残しましょう。

インポート画面で成功と表示されても、通常はテキストを解析して一覧に追加できたことを示すだけで、サーバーが接続を受け付けたことを意味しません。動作確認では、コアの起動、セッションの確立、接続先へのアクセスまで確認してください。操作の流れはv2rayN設定ガイドをご覧ください。以降の各章では設定階層ごとの選択範囲を解説します。

02 / VMESS & VLESS

VMessとVLESSの設計上の違い

VMess：プロトコルに認証と暗号化の仕組みを含む

VMessはProject Vのエコシステムで早くから使われてきたプロキシプロトコルです。ユーザー認証、リクエスト情報の保護、データの暗号化をプロトコル自体に組み込んでいます。クライアントでは正しいユーザーIDを指定し、サーバー側の設定に合わせてセキュリティ項目を選ぶ必要があります。現在の設定では通常、AEADベースの認証方式を使います。古い資料にある追加IDの項目は、過去との互換性に関するものです。古い手順を参考にして任意の値を入力しないでください。サーバーの設定に合わせてクライアントを構成し、新しい設定では管理者が提示する現行のパラメーターを優先しましょう。

プロトコル自体に保護機能があっても、外側のTLSが不要になるとは限りません。外側の接続とプロキシプロトコルでは解決する問題が異なり、構成によってはWebSocketなど別の伝送方式を使うこともあります。VMessノードを評価するときは、ローカル接続、プロトコルのカプセル化、外側の伝送、接続先への出口まで、接続経路全体を考慮してください。負荷は経路上の各段階で発生します。プロトコル名だけで負荷を見積もることはできず、暗号化が一段増えたからといって、普段の利用で必ず速度が目に見えて落ちるとも限りません。

VLESS：プロトコル自体のデータ暗号化を簡素化

VLESSはプロキシプロトコルの構造を簡素化し、データの保護をより多く、組み合わせて使うセキュリティ層に委ねる設計です。クライアント設定の暗号化項目には、通常noneを指定します。これはVLESS自体が該当するデータ暗号化を行わないという意味であり、接続全体に保護がないという意味ではありません。安全性を確認するには、TLSまたはREALITYが正しく有効か、サーバーの身元を検証しているか、ローカルと接続先の信頼境界が適切かを確認してください。この項目を別のプロトコルの暗号方式に変更すると、設定が受け付けられなくなることがほとんどです。

VLESSはXrayのエコシステムで、フロー制御やセキュリティ層の機能と組み合わせて使われることが多いものの、すべてのVLESS実装がそれらに標準対応しているわけではありません。たとえばVisionのフロー制御には、対応するコアと接続方式の組み合わせが必要です。基本的なVLESS項目だけを含む共有リンクでは、これらの機能が自動的に有効になるわけではありません。サーバーから指定されていない場合、性能向上を期待して手動で追加しないでください。設定項目は多ければよいのではなく、サーバーから提示された設定を正確に再現することが大切です。

時刻・ユーザーID・移行時の注意点

VMessでは時刻の同期が重要です。端末の時刻が大きくずれていると、認証に影響することがあります。トラブル時はユーザーIDを何度も作り直すのではなく、システムの日付と時刻、自動同期の状態を確認してください。VLESSに切り替えても、時刻に関する問題がすべて解決するわけではありません。外側の証明書検証にはシステム時刻が影響します。どちらのプロトコルもユーザーIDにUUIDを使う場合がありますが、形式が同じだからといって相互に置き換えられるわけではありません。クライアントの選択欄だけを変更しても、サーバー側の設定は変わりません。

既存のVMess構成からVLESSへ移行するには、サーバー側に新しい接続先を用意してもらうか、変更内容を明確に確認し、伝送方式、セキュリティ層、フロー制御の要件も合わせて確認してください。移行前に現在使える設定を残し、新しい接続先は別のグループでテストします。対象アプリとUDP通信が正常に動くことを確認してから切り替えましょう。唯一使えるノードの設定を一度に何項目も上書きすると、問題の原因を特定しにくくなります。認証方式と保護方式の違いは、VMessとVLESSの違いもご覧ください。

インポート後はノードのメモだけで比較せず、プロトコル、ユーザーID、アドレス、ポート、伝送方式、セキュリティ層、フロー制御を一つずつ確認してください。メモは共有者が入力したもので、技術的な条件を保証するものではありません。設定の解析エラーなら、まず項目とコアの互換性を確認します。認証エラーなら、サーバー側のアカウントと設定値を確認します。スループットや応答速度を比較するのは、接続が安定してからにしましょう。

03 / TROJAN & SHADOWSOCKS

TrojanとShadowsocksの設定上の注意点

Trojan：TLSを標準的な接続基盤として利用

Trojanは、パスワード認証とTLS接続を組み合わせた設計です。クライアントでは通常、アドレス、ポート、パスワード、サーバー名を設定します。UUIDを使うプロトコルとは認証情報の形式が異なりますが、どちらもクライアントとサーバーの設定を一致させる必要があります。パスワードが正しくても接続できるとは限りません。証明書名、証明書チェーン、システム時刻、外側の伝送方式に問題があると、認証に進む前に接続が終了することがあります。トラブル時は、TLSハンドシェイクとプロトコル認証のどちらで失敗したかをまず確認してください。

信頼できるネットワーク環境で正しく検証できていれば、TLSは接続の暗号化とサーバー認証を提供します。Trojanを使う場合、証明書検証を無効にする設定を標準にしたり、原因不明の証明書エラーをクライアントの制限と決めつけたりしないでください。ドメイン証明書と直接接続するサーバーアドレスが異なることはありますが、サーバー名は構成の要件に従う必要があります。IPアドレスで直接接続するときは、特にサーバー名の設定を確認してください。クライアントが証明書に対応するドメインを自動で推測することは期待できません。

Shadowsocks：暗号方式も互換性を左右する

Shadowsocksはクライアント上でSSと略されることが多く、主な設定項目はサーバー、ポート、パスワード、暗号方式です。比較的シンプルな暗号化プロキシ接続を目指した設計ですが、「SS対応」という表示だけでは互換性を判断できません。従来のAEAD方式と後続の拡張方式では、鍵の要件、実装状況、リンクの解析方法が異なる場合があります。設定の方式名は一字一句一致させてください。クライアントの別の選択肢が新しそうに見えても、自己判断で置き換えないでください。

パスワード欄の値を、どの方式でも一般的な短いパスワードと同じように扱えるとは限りません。方式によっては、鍵の長さやエンコード形式が指定されています。末尾を誤って削除したり、大文字と小文字を変えたり、二重にデコードしたりすると、認証に必要な条件が崩れます。共有リンクをコピーするときは内容を完全に保ち、手入力の場合はサーバーの説明に従ってください。ほかのプロトコルのUUIDをSSのパスワード欄に入力しても自動変換されません。また、リンク内でエンコードされた認証情報を、そのまま最終的なパスワードとして使わないでください。

プラグイン・UDP・伝送方式の拡張にも注意

SSの共有情報にプラグインの設定が含まれる場合があります。GUIクライアントがリンクを認識できても、実行環境に対応するプラグインがあるとは限りません。また、コアが同じ機能を標準で実装しているとも限りません。当サイトのクライアント一覧とダウンロードページの案内を確認し、プラグインが必要なサービスでは、現在のクライアントに対応する別の接続先があるか確認してください。プラグイン不足をパスワードの誤りと取り違えたり、出所不明の案内に従って追加コンポーネントをインストールしたりせず、まずサービス管理者に接続方法を確認しましょう。

UDPが使えるかどうかは、プロトコルの実装、サーバー側の転送、クライアントの接続方式、対象アプリを合わせて確認する必要があります。Webサイトが表示できても、音声通話やリアルタイム通信が正常とは限りません。こうした通信では別の種類のトラフィックが使われることがあります。システムプロキシでは、すべてのアプリのUDP通信を自動的に処理できるとは限りません。TUNを使っても、サーバー側にない機能を補うことはできません。TrojanとSSを比較するときは、同じネットワークと同じ用途でそれぞれ試してください。Webページを一度開けた結果だけで、互換性全体を判断しないようにしましょう。

標準的なTrojanまたはSSの設定だけを提供する既存サービスでは、必要な項目をすべて設定できるクライアントを使い、不要な伝送オプションを追加しないようにしましょう。デスクトップではv2rayNにテスト用のノードを作成し、Androidではv2rayNGで暗号方式とセキュリティ設定を確認できます。v2flyNGを使う場合は、搭載コアが該当方式や拡張に対応しているかも確認してください。画面に同じプロトコル名が表示されるだけで検証を省略してはいけません。

どちらのプロトコルにも、固定の速度ランクがあるわけではありません。サーバーの負荷、ネットワーク経路、暗号化の実装、接続の再利用方法のほうが、使い心地の違いを左右することもよくあります。設定は、認証、必要な機能、保守条件を満たしたうえで、実際の用途に応じてリソース消費を比べて選びましょう。インポート後に接続できない場合は、ヘルプセンターのインストール・設定、トラブル対処の項目を確認してください。

04 / TLS & REALITY

TLS・REALITY・Visionのフロー制御

REALITYはVLESSと同じ階層のノードプロトコルではない

クライアントのノード情報では、VLESS、REALITY、Visionが同じ設定に記載されることがあり、同じ階層の用語だと誤解されがちです。実際には、VLESSはプロキシプロトコル、REALITYはXrayのエコシステムにおけるセキュリティ機能、Visionは特定の接続構成で使うフロー制御です。それぞれ役割は異なりますが、連携して動作します。REALITYを選んでもプロトコル認証は必要ですし、Visionを選んでもセキュリティ層の代わりにはなりません。画面の各項目は、サーバーが提示した組み合わせに合わせて設定してください。

通常のTLSでは、証明書、サーバー名、証明書チェーンをもとに信頼性を確認します。クライアントはこれらの条件から接続先の身元を検証し、証明書の有効期間の判定にはシステム時刻も使います。REALITYは異なる認証とハンドシェイクの仕組みを使い、公鍵、短いID、サーバー名などの設定が必要です。両者の項目は相互に使い回せません。通常のTLSの証明書設定をREALITYの公鍵の代わりにすることはできません。また、通常のTLSノードに短いIDを入力してもREALITYノードにはなりません。

公鍵・短いID・フィンガープリントを個別に確認

REALITYの公鍵は、サービス管理者が提供するクライアント設定から取得してください。任意の値を生成して使ったり、サーバーの秘密鍵をクライアントに入力したりしてはいけません。短いIDも、サーバー側で許可された設定に合わせる必要があります。トラブル時は、値を完全にコピーできているか、余分な空白や改行がないかをまず確認し、次に使用中のコアが該当する項目形式に対応しているかを確認してください。コアの世代によって項目名や解析方法が変わることがあります。古い設定例をそのまま使わず、実行中のコアのドキュメントとクライアントの出力を基準にしてください。

サーバー名には、よくあるWebサイトのドメインを適当に選ぶのではなく、サーバー管理者が明示した値を指定してください。フィンガープリントはクライアントのハンドシェイク特性に関する設定です。特定のセキュリティ構成で必要になることはありますが、速度を選ぶ設定ではありません。変更しても、アドレスに接続できない、公鍵が一致しない、ユーザー認証に失敗するといった問題は解決しません。サーバー側に推奨値がある場合は、まずその値に合わせます。互換性を確認するときは、一度に一項目だけ変更し、コアのログに記録された失敗段階を確認してください。

Visionには接続方式の組み合わせが必要

xtls-rprx-visionは一般的なフロー制御の識別子ですが、どの伝送方式でも使える汎用の最適化スイッチではありません。サーバー側で該当するユーザーのフロー制御が設定され、クライアントのコアもその組み合わせに対応している必要があります。特定のパスを必要とする伝送方式をTCPに変更したり、既存のWebSocket設定にVisionを追加したりすると、構成が合わなくなることがあります。フロー制御に関するエラーが出た場合は、設定全体を確認してください。すべてのセキュリティ項目を順番に有効にして試すのは避けましょう。

同じサービスが通常のTLSとREALITYの両方を提供している場合は、それぞれ別のノードとして登録し、個別にテストしてください。各ノードの認証と伝送条件はそのまま維持します。クライアントの対応状況、サービスの保守方法、証明書の管理条件、実際のネットワーク環境を考慮して選びましょう。どちらか一方がすべての用途に適するとは限りません。ハンドシェイクの細部を暗記する必要はありませんが、どの項目をセットで維持する必要があるか、検証を無効にしても解決しないエラーは何かを理解しておきましょう。

ログにハンドシェイクエラーが記録されている場合は、サーバー名の不一致、証明書が信頼されていない、接続先による切断、認証情報の不一致などを区別してください。まずクライアントが想定したアドレスとポートに接続しているか確認し、その後にセキュリティ層の設定を調べます。ルーティングルールを何度も変更しても、ハンドシェイク自体の問題は通常解決しません。具体的な確認手順はTLSハンドシェイクエラーの対処法をご覧ください。システム時刻とサーバー名でよくある誤りも解説しています。

サポートを依頼するときは、REALITYやVisionの使用有無、クライアントとコアの種類、エラーが発生した段階を伝えると役立ちます。共有リンク全体、公鍵以外の秘密情報、サーバー設定は公開しないでください。公開可能な設定もすべて載せる必要はありません。設定一式を貼るより、原因の特定に必要な技術情報を残すほうが判断しやすくなります。

05 / PERFORMANCE & BATTERY

接続速度・リソース消費・モバイル端末の電池消費

接続の確立と継続的な通信を分けて測定する

「速い」には、ページを開くまでの待ち時間が短いことも、大容量ファイルを継続して転送するスループットが高いこともあります。この2つには異なる要因が影響します。接続の確立には、名前解決、ネットワーク接続、セキュリティハンドシェイク、プロキシ認証が必要です。継続的な転送では、利用可能な帯域、混雑、サーバーの転送能力や処理能力がより大きく影響します。あるプロトコルで一部のカプセル化が減っても、遠距離のネットワークで初回応答が必ず速くなるわけではありません。大容量ファイルのダウンロードを一度試しただけで、対話型アプリの使い心地を判断することもできません。

プロトコルを比較するときは、サーバーの場所、ネットワークの入口、テスト先、接続方式をできるだけそろえてください。サーバー間の差がプロトコルの差を上回ることもよくあります。プロトコル、DNS、ルーティング、伝送方式を同時に変更して、結果をどれか一つの要因に結びつけないようにしましょう。同じアプリで短いリクエストと継続的な転送を数回試し、問題が再現するか確認してから、ログとシステムリソースを調べます。クライアントの接続テストは初期確認に使えますが、テスト先への経路が実際の通信経路と一致するとは限りません。

カプセル化・多重化・端末性能が負荷を左右する

暗号化処理にはCPUリソースが必要ですが、実際の負荷はアルゴリズムの実装とハードウェア性能によって変わります。VMess、VLESS、Trojan、SSに固定の優劣を付けることはできません。外側の伝送方式、接続数、ログの詳細度、トラフィックの複製もリソース使用量に影響します。伝送層の追加処理は、導入しやすさや互換性につながる場合があります。まずサービスの要件を満たす設定を選び、現在の端末で負荷が問題になるかを確認してください。

接続の多重化によって、接続を何度も確立するコストを減らせる場合があります。一方で、並行する通信同士の影響が変わることもあります。有効にする場合はサーバーとコアの対応を確認し、実際のアプリでテストしてください。すべての通信を少数の接続にまとめれば、どの用途でも快適になるわけではありません。短いリクエストを頻繁に行う用途と、大容量データを長時間転送する用途では条件が異なります。通信が不安定な場合は、すぐにプロトコルの性能不足と決めつけず、共有接続の混雑が原因でないか確認しましょう。

Androidの電池消費は通信の起動頻度と対象範囲を確認

モバイル端末の電池は暗号化だけで消費されるわけではありません。無線通信の頻繁な起動、バックグラウンドアプリからの継続的な通信、ネットワーク切り替え後の再接続、過剰に頻繁な接続確認も電池消費を増やします。VPN接続でより多くのアプリの通信を取り込むと、一部のネットワーク活動がプロキシクライアントの消費として表示される場合があります。そのため、電池使用量に占める割合をそのままプロトコルの処理コストとみなすことはできません。異常があるか判断する前に、同じ時間帯、近いネットワーク条件、同じバックグラウンドアプリで比較してください。

v2rayNGのアプリごとのプロキシ機能を使うと、接続対象のアプリを限定できます。ただし、現在の一覧が許可リストか除外リストか、保存後に接続の再起動が必要かを確認してください。システムの電池最適化とメーカー独自のバックグラウンド制限も分けて考えます。制限が厳しすぎるとプロセスが終了し、再起動を繰り返したり接続が切れたりすることがあります。制限をすべて解除すると、制限するはずだったバックグラウンド通信が続く可能性があります。必要な機能を安定して動かすことを目標にし、全アプリやシステムの制限を一律に解除しないでください。

TUNモードでは、仮想インターフェース、ルーティング処理、DNSの取り込みも関係します。電池消費がシステムプロキシの消費に単純に加算されるわけではありません。アプリがプロキシに対応していれば、システムプロキシで十分な場合があります。プロキシ設定に従わないアプリの通信を取り込む必要がある場合は、TUNの追加処理が必要なコストとなることがあります。デスクトップで比較する際は、ほかの仮想ネットワークソフトも同時に動いていないか確認してください。ルーティングの競合や通信の二重処理を、コアの性能問題と誤認するおそれがあります。

テスト後は通常のログレベルに戻し、大量の接続情報を記録し続けないようにしてください。性能は一度の最大値ではなく、用途を安定して完了できるかで評価します。特定のドメインだけが極端に遅い場合は、DNS、ルーティング、接続先までの経路を確認してください。すべてのアプリに影響する場合は、端末の負荷、ネットワーク品質、サーバーの状態を調べます。プロトコル選びは最適化の一要素であり、あらゆるボトルネックを説明するものではありません。

06 / CORE COMPATIBILITY

V2Fly・Xrayとクライアントの関係

GUIは管理を担い、コアは接続を実行する

Project VはV2Rayのエコシステムを理解するうえでの背景です。V2FlyとXrayは、関連する開発の流れから生まれたコアの系統です。GUIクライアントはノードの管理、設定の編集、プロセスの起動、システムへの接続を担います。v2rayN、v2rayNG、v2flyNGは、特定のプロトコルを意味するものではありません。接続を実際に処理するのは、クライアントが呼び出すコアです。そのため、画面に設定項目があることから分かるのは、GUIがその項目を入力できるということだけです。現在のコアで実行できるかどうかは、別途確認してください。

Xrayは独自の開発の中で、REALITYやVisionなどの機能を提供しています。V2Flyにも独自の保守方針と設定拡張があります。両者は歴史や設定概念の一部を共有していますが、項目が常に完全一致するわけではありません。対応機能、既定の動作、伝送方式の実装はコアの更新によって変わることがあります。特定の機能を使う場合は、現在のコアの説明を確認してください。一方の系統の設定項目一覧を、もう一方でも永久に使える互換リストとして扱わないようにしましょう。

用途に応じた3つのクライアント

デスクトップではv2rayNを推奨します。ダウンロードページにあるOSのアーキテクチャとファイル形式に従って、Windows、macOS、Linuxにインストールしてください。OSごとに画面やメニューの位置が異なる場合がありますが、プロトコル設定を実行するのは選択したコアです。Androidでは、Xrayをコアに採用するv2rayNGを推奨します。V2Fly系の構成に合わせる必要がある場合は、v2flyNGも検討できます。名前が似ているからといって、2つのモバイルクライアントの機能やコア拡張が同じとは限りません。

設定が似ていても、そのままコピーして使えるとは限らない

ネイティブ設定の外側の構造が同じでも、内側の項目に違いが隠れていることがあります。特に伝送方式の名称、DNSオプション、フロー制御、セキュリティ層を確認してください。Xrayの設定をそのままV2Flyで動かす場合も、逆の場合も、まず対応範囲を調べましょう。解析時に未知の項目が表示されるなら、設定形式が合っていない可能性があります。起動できても接続に失敗する場合は、項目が無視されていないか、既定値が変わっていないか、サーバー側が受け付けているかも確認してください。

コアを切り替える前に、ノード、サブスクリプショングループ、カスタムルールをバックアップしてください。まずクライアントが生成できる標準設定を選び、動作確認済みのノードを一つ使ってテストします。その後、カスタム項目を段階的に戻しましょう。ネイティブ設定全体を一度に移行すると、古いパス、旧ルールファイルへの参照、元のコアだけにある設定も一緒に引き継ぐ可能性があります。起動に失敗した場合は、互換性の設定を増やし続けるのではなく、不要な拡張を外し、最小構成から接続を確認してください。

v2rayNで選ぶCoreの種類はノードの構成に合わせてください。設定項目の場所は、現在の画面で確認しましょう。クライアントがコアを自動選択する機能を使う場合は、一覧のメモだけで判断せず、起動ログで実際のプロセスを確認してください。クライアントの更新によって、画面とコアの連携方法が変わる場合もあります。動作する設定のバックアップとテスト記録を残しておけば、更新による挙動の変化とサーバー側の変更を区別しやすくなります。

接続トラブルが起きるたびに、2つのコアを何度も切り替えないでください。解析、起動、ハンドシェイク、認証、接続先へのアクセスのどの段階で失敗したかを特定し、実装の対応状況を確認します。通常の名前解決エラー、システム時刻のずれ、ローカルプロキシポートの競合は、一般にコアを変更する理由にはなりません。クライアントのインストールや入れ替えが必要な場合は、クライアントのダウンロードページから適切なものを選び、OSのアーキテクチャの問題とプロトコルの問題を混同しないようにしましょう。

07 / SUBSCRIPTION FORMATS

共有リンク・サブスクリプション・ネイティブJSON

形式によって保存できる情報が異なる

共有リンクは通常、1つの接続先を記述します。サブスクリプションURLは更新可能な接続先の一覧を取得するためのもので、ネイティブJSONではコアの実行設定を記述できます。これらは同じ内容のファイル形式違いではありません。共有リンクはノードの受け渡しに便利ですが、すべてのルーティング、DNS、カスタム出口を含むとは限りません。ネイティブJSONはより詳細な設定を表現できますが、特定のコアやローカルファイルが必要になることがあります。インポート方法を選ぶ前に、提供された形式を確認してください。

一般的なテキスト形式のサブスクリプションでは、1行ごとの共有リンクをBase64でエンコードすることがあります。ただし、これはよくある形式の一つであり、すべてのサブスクリプションに共通する仕様ではありません。設定ドキュメントや別のクライアント用形式を返すURLもあり、何度デコードしても当サイトのクライアント向けの内容にはなりません。サブスクリプションの取得に成功しても、解析が成功したとは限りません。サーバーがログインページ、エラーページ、空の応答を返すこともあります。クライアントのエラーを確認し、取得失敗、形式の不一致、個別ノードの非対応を切り分けてください。

エンコードを変えても不足している設定は補えない

Base64はエンコード方式であり、秘密を保護するものではありません。デコード後のユーザーID、パスワード、サーバー情報も引き続き機密として扱ってください。リンクのパーセントエンコードにも独自の規則があり、文字列全体を何度もデコードしてはいけません。特にパスワード、メモ、パスに特殊文字が含まれる場合、余計な変換で元の値が変わることがあります。コピーにはクライアントの共有・エクスポート機能を使い、リッチテキストエディターを経由して改行、全角記号、見えない空白が混入しないようにしましょう。

共有リンクをネイティブ設定に変換するには、プロトコル、伝送方式、セキュリティ層の各項目をどう対応付けるか把握する必要があります。元のリンクに含まれない拡張設定の値を、変換ツールが正確に推測することはできません。逆に、複雑なネイティブ設定を1つの共有リンクに圧縮すると、カスタムDNS、複数の出口、ルーティングルールが失われることがあります。変換後は重要な設定値を確認し、実際に接続して検証してください。「変換成功」は、完全に同等であることの証明ではありません。

短い例で確認するネイティブJSONの範囲

以下はコア設定内のルーティング部分であり、単独で起動できる完全な設定ではありません。広告ドメインのカテゴリに一致した場合、blockという名前の出口を使います。完全な設定でその出口が定義され、実行環境から該当するルールデータを読み込めることが前提です。この例は項目同士の参照関係を示すもので、全体をクライアントの共有リンクインポート欄に貼り付けないでください。

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

ここでのドメインポリシーは、ルーティング判定でどの条件のときに名前解決を試みるかを決めます。DNSサーバーのアドレスを指定するものではなく、すべてのDNSリクエストがプロキシ経由になることを保証するものでもありません。ルール内の出口名は完全な設定と一致させる必要があります。一致しない場合、JSONの構文が正しくても想定外の動作になることがあります。ルールデータの有無、カテゴリ名の利用可否、コアが該当項目に対応しているかも実行条件です。各項目の意味は用語ガイドでご確認ください。

サブスクリプションの更新とローカル編集は分けて管理

サブスクリプショングループのノードは、更新時に置き換えられたり再生成されたりすることがあります。直接編集した内容は、次回の更新で失われる可能性があります。ローカルの変更を長期的に保持する場合は、クライアントが対応する個別設定や管理方法を使い、サブスクリプション元の内容との違いを記録してください。更新前に古いグループをすぐ削除せず、新しいノードが接続できるか確認してから、重複や無効な項目を整理しましょう。問題が起きたときに元の状態へ戻しやすくなります。

サブスクリプションURLにはアクセス用トークンが含まれることが多いため、アカウント情報と同様に管理してください。出所不明のオンライン変換サービスに渡したり、トークン付きのURL全体を公開の問い合わせに記載したりしないでください。移行にはクライアントの標準機能を優先し、移行先がその形式に対応していることを確認してからインポートしましょう。形式の違いや変換時の問題は、サブスクリプション形式と変換方法をご覧ください。互換性は、設定値が保たれるか、コアが受け付けるか、実際に接続できるかで判断します。

08 / SCENARIO SELECTION

用途に応じた選択と動作確認

既存サービスでは、まず設定全体の互換性を確認してからプロトコルを比較

利用できるサブスクリプションがある場合、クライアント選びではサーバー側のプロトコル構成と端末のプラットフォームを優先して確認します。デスクトップではv2rayN、Androidではv2rayNGを推奨します。V2Fly系の機能が必要な場合はv2flyNGも検討してください。別のプロトコルのほうが簡潔そうだという理由だけで、ノード設定を書き換えないでください。元のサブスクリプションを保管し、必要な項目をすべてインポートできることを確認します。まずノードを一つテストし、その後グループ、ルーティング、複数アプリへと段階的に広げましょう。

サービスが複数の接続先を提供している場合は、テスト用のグループに分け、Web閲覧、継続的な転送、実際のアプリでそれぞれ確認します。接続方式、DNS、接続先を固定し、一度に一つの条件だけを比較してください。既存の構成が安定して要件を満たしているなら、移行は明確な互換性要件、管理のしやすさ、再現可能な使用感の改善がある場合に検討しましょう。プロトコル名の新旧だけで移行する必要はありません。テスト結果が不安定なときは、結論を急がず、サーバーまでの経路とネットワークの変動を確認してください。

デスクトップ作業とモバイルのバックグラウンドで確認点を変える

デスクトップのブラウザーやシステムプロキシに従うツールでは、まずシステムプロキシを使い、ローカルの待ち受けポートとアプリの設定が一致しているか確認してください。より多くの通信を取り込む必要がある場合は、TUNと必要な権限を検討します。有効にした後は、ローカルネットワーク、名前解決、ほかの仮想ネットワークソフトが正常に動作するか確認してください。接続範囲を広げたことでアプリの挙動が変わっても、すべてを接続先のプロトコルの問題と考えないでください。単に、そのアプリの通信が初めてクライアントを経由した可能性があります。

モバイル端末では、ネットワークの切り替え、バックグラウンドでの動作維持、通信対象の範囲を重視します。まず安定したノードを一つ使い、画面をロックした後も必要な処理が続くか確認してください。次にWi-Fiからモバイル通信へ切り替えた後、正常に復帰するかを確認します。アプリごとのプロキシで不要なバックグラウンド通信を減らし、実際の動作に応じて電池制限を調整してください。特定のアプリを起動したときだけ電池消費が増えるなら、プロトコル全体を変更する前に、そのアプリの通信状況を確認しましょう。

DNSとルーティングも接続確認に含める

接続できた後は、アプリの通信が想定した出口を通っているかも確認してください。ドメインポリシー、ルーティングルールの順序、直結の対象範囲、DNSの経路によって、Webサイトごとに結果が大きく異なることがあります。出口IPの確認だけではすべての通信を把握できず、Webページを一つ試しただけでほかのアプリの動作を判断することもできません。DNSの動作を調べる際は、クライアントのログ、アプリ独自の名前解決の有無、システム側の接続範囲を合わせて確認してください。特定の確認ページで得た結果を、すべての用途に当てはめないようにしましょう。

たとえば、ルーティングルールで直結が選ばれているのにプロキシを使いたい場合、プロトコルを変更してもルールの優先順位は変わりません。アプリが独自に暗号化DNSを使う場合、クライアントの通常のDNS設定ではリクエストを処理できないこともあります。設定手順はDNSの確認・設定方法をご覧ください。変更前の設定を保存し、どの通信をどの経路に通すかを決めてから動作を確認しましょう。DNSに関係しそうな項目を一度にすべて有効にするのは避けてください。

失敗した段階から次の確認項目を決める

インポートに失敗したら形式とエンコード、コアの起動に失敗したら設定構造と対応範囲、ハンドシェイクに失敗したらセキュリティ層、認証に失敗したらユーザー情報を確認します。接続を確立できた後に接続先へアクセスできない場合は、ルーティング、DNS、接続先の出口を確認してください。この順番で進めると、同じ試行を繰り返しにくくなります。一度に一項目だけ変更し、必要なプロセスを再起動してから再テストし、簡単な記録を残しましょう。エラーの種類が変わった場合は、接続が次の段階へ進んだことを示すため、確認する箇所も切り替えてください。

新しいサービス構成を作るときは、対応するクライアント、伝送環境、認証方式、保守条件を整理してからプロトコルの組み合わせを決めましょう。証明書を管理する構成では、サーバー名と証明書の更新計画が必要です。REALITYを使う場合は、公鍵と許可された設定値の管理方法を決めてください。どの構成も設定の一貫性を保つ必要があり、一度インストールすれば確認不要というものではありません。クライアントやコアを更新した後は、起動できるかどうかだけでなく、同じテスト内容でもう一度動作を確認しましょう。

検証済みの設定を基準として残し、実験用の設定は別の項目に分けてください。最初から設定する場合はクイックスタートへ、特定のエラーを調べる場合はヘルプセンターへ、プラットフォームの変更やクライアントのインストールはダウンロードページをご覧ください。プロトコルとコアの選択は、設定を分かりやすくし、問題を特定しやすくするためのものです。説明できない設定を増やすことが目的ではありません。