V2Rayのプロトコルとコア

接続の各レイヤー：クライアント、コア、プロトコル

まず各レイヤーの役割を把握する

GUIクライアントは設定の保存、サブスクリプションの取り込み、出口の切り替え、ログの表示を担います。コアは接続を実行し、プロトコルを解析してルーティングを処理し、実際のデータ経路を確立します。この2つは、同じソフトウェアの別名ではありません。クライアントにはコアが内蔵されている場合もあれば、独立したコアプロセスを起動する場合もあります。そのため、画面上で設定を保存できても、実行中のコアがすべての項目に対応しているとは限りません。互換性を判断するには、クライアントで設定を表現できるか、使用中のコアで実行できるかの両方を確認する必要があります。

接続は、プロキシプロトコル、トランスポート、安全層に分けて考えられます。プロキシプロトコルは認証情報や宛先、データの形式を定めます。トランスポートはデータの運び方を決め、ストリーム接続を直接使う方法や、別のアプリケーション層の通信に載せる方法などがあります。安全層は、暗号化や認証を担います。VMess、VLESS、Trojan、Shadowsocksはプロキシプロトコルに分類されますが、暗号化の仕組みとの組み合わせはそれぞれ異なります。REALITYは安全機構であり、ほかのプロトコルと自由に置き換えられる汎用プロトコル名ではありません。

設定名だけでは互換性を判断できない

サービス提供元が設定に「高速」「モバイル」「予備」などの名前を付けていても、それはメモにすぎません。接続を決めるのは、アドレス、ポート、認証情報、トランスポートの種類、安全設定です。どちらもプロトコル欄に VLESS と表示されていても、安全機構やトランスポートのパラメーターが異なれば、必要なコア機能も異なる場合があります。画面上で似た名前が付いていても、2つのプロジェクトがまったく同じ設定項目を使うとは限りません。メモから推測せず、実際のパラメーターを確認してください。

設定を確認するときは、まずサーバー側が求める組み合わせを書き出し、クライアントの項目と照合します。アドレスは接続先、ポートは対応する待ち受けサービスを示します。ユーザーIDやパスワードは認証に使い、サーバー名は通常、安全なハンドシェイクに関わります。トランスポートのパスやホスト名は、アプリケーション層の転送条件に使われる場合があります。同じ設定画面に並んでいても、それぞれの役割は異なります。サーバー名を接続先アドレスに入力したり、Webのパスをホスト名に入力したりすると、下位の接続は確立しても、その後のハンドシェイクに失敗することがあります。

アプリの通信からリモート出口まで

アプリの通信をクライアントに渡す方法も必要です。システムプロキシは通常、対応する設定を参照するアプリにプロキシのアドレスを提供するもので、すべてのプログラムの通信を捕捉するとは限りません。TUNは仮想ネットワークインターフェースで通信を受け取るため、システムルート、権限、名前解決も関係します。どちらも通信の入口であり、リモート側のプロトコルではありません。TUNを有効にしてもVMessがVLESSに変わるわけではなく、サーバー側で不足している安全設定が補われるわけでもありません。接続トラブルを調べる際は、まず通信がクライアントに入っているかを確認し、その後で出口への接続を調べてください。

認証情報などの機密値を含めない設定一覧を作り、前述のレイヤーごとに設定元と用途を記録しておくと便利です。初回接続では必要な設定だけに絞り、検証後にルーティング、マルチプレクシング、仮想インターフェースなどを追加しましょう。問題が起きたときに、入口、ルール、リモート側のハンドシェイクを切り分けやすくなります。用語を手早く確認するには用語集、症状から原因を調べるにはよくある質問をご覧ください。選定の出発点は、名前を先に選んで設定を足すことではなく、サーバー側から提供された組み合わせを把握することです。

VMess：認証、暗号化、時刻条件

設計の背景と用途

VMessは、Project Vのエコシステムで早くから採用されてきたプロキシプロトコルです。ユーザー認証、リクエスト情報、データ保護をプロトコル設計に含み、長年にわたりクライアント設定やサブスクリプションで使われてきました。主な用途は、すでに構築されているサービスへの接続であり、ユーザーが新しい安全機構の組み合わせを自分で組み立てることではありません。理解する際は、プロトコル自体のデータ保護と、外側に追加する安全層を区別しましょう。VMessを使うからといって、すべてのトランスポートに同じ安全機構を重ねる必要があるわけではありません。また、サーバー側で指定された設定を省略できるわけでもありません。

ユーザーIDは認証対象を識別する重要な項目で、UUID形式がよく使われます。サブスクリプションのメモでも、リモートサーバーの機器番号でもありません。コピーする際は内容をそのまま保ち、引用符、空白、改行を追加しないでください。接続先にはドメイン名またはアドレスを使いますが、名前解決とユーザー認証の正しさは別々に確認する必要があります。接続できないときは、ユーザーIDを何度も変えるより、まず名前解決とポートへの到達性を確認し、続いて認証と安全なハンドシェイクを調べるほうが原因を絞り込みやすくなります。

旧式の項目と現代の認証方式

過去のVMess設定では、追加IDの数を示す項目がよく使われ、一部の共有形式では aid と表記されます。現在のAEAD方式では、通常この旧式の追加IDの仕組みを使わず、設定値はゼロであることが一般的です。ただし、この項目を変更すれば何でも直るわけではありません。古いサーバー、旧式のインポーター、現在のコアの間には互換性の制限がある場合があります。提供元から過去のパラメーターが案内された場合は、異なる世代の画面を見て項目を一つずつ変更するのではなく、サーバー側で実際に対応している方式を確認してください。

時刻の同期は、VMessのトラブルシューティングで個別に確認したい項目です。認証の仕組みに時刻条件が含まれるため、システム時計が大きくずれていると認証に失敗することがあります。確認すべきなのは実際の時刻と自動同期の状態であり、タイムゾーン表示だけでは判断できません。タイムゾーンが違っても時刻そのものが誤っているとは限らず、表示を別地域の時刻に合わせて手動変更すると、正しい時計を狂わせるおそれがあります。デスクトップがスリープから復帰したとき、仮想マシンを一時停止して再開したとき、モバイル端末で自動時刻を無効にしたときは、時刻が正確か改めて確認してください。

暗号化オプションとトランスポート設定

クライアントには、自動または個別のデータ暗号化方式を選べる場合があります。利用できる範囲は、双方の実装とコアの対応状況によって決まります。ハードウェアアクセラレーション、CPUアーキテクチャ、通信負荷によってアルゴリズムの実コストは変わるため、方式名だけから通信速度の順位を推定することはできません。既存の設定では、まず提供元のパラメーターをそのまま使ってください。暗号化方式の違いを比較する場合は、サーバー、トランスポート、テスト負荷を固定したうえで、CPU使用率や継続的な転送性能を比べましょう。複数の項目を同時に変更するのは避けてください。

VMessは複数のトランスポートと組み合わせられますが、アドレス、パス、ホスト名、安全層のサーバー名はサーバー側の設定と一致させる必要があります。リバースプロキシを経由する接続では、接続先のポートに到達できても、アプリケーション層のパスが正しいとは限りません。パスの大文字・小文字、先頭のスラッシュ、転送条件が一致しないと、後続の段階で拒否されることがあります。安全層のサーバー名も、メモの内容をそのままコピーすべきとは限りません。導入後に表示されるトランスポートの種類が元の設定と異なる場合は、接続を試す前に共有形式が正しく読み取られているか確認してください。

VMessを選ぶ根拠になるのは、既存サービスが明確に対応し、必要なパラメーターを確認でき、使用中のクライアントとコアがすべての設定を実行できることです。古くからある方式だからといって使えないとは限らず、対応クライアントが多いからといって、すべての端末に最適とも限りません。現在の接続が安定しているなら、アップグレードや移行は、新しい安全機構が必要、または保守する構成を減らしたいなど、具体的な要件に基づいて検討してください。移行時は元の設定を残し、新しい設定を追加して個別に検証すると、比較の基準を失わずに済みます。認証エラーやログの読み方については、トラブルシューティングQ&Aもご覧ください。

VLESSとREALITY：プロトコルと安全層の組み合わせ

シンプルなプロトコルでも安全設計は必要

VLESSの設計方針の一つは、プロトコル層の役割を絞り、適切な外部の安全機構にデータ保護を任せることです。認証とプロキシリクエストを表現しますが、プロトコル名だけで通信経路の保護まで完了すると考えてはいけません。画面に表示される暗号化オプション none は、通常VLESS層の設定を示すもので、接続全体が暗号化されていないという意味ではありません。実際の安全性は、TLSやREALITYが正しく設定されているか、認証が要件どおり完了しているかなど、外部設定にも左右されます。

レイヤーごとに分けて考えると設定の役割を理解しやすくなりますが、組み合わせの確認はより重要になります。ユーザーIDはプロトコルの認証情報、サーバー名や公開鍵関連のパラメーターは安全なハンドシェイク、トランスポートの種類はデータの伝送方式を担います。フロー制御の項目は、プロトコル、安全層、コアの実装に左右されます。画面にすべての項目があるからといって、自由に組み合わせられるわけではありません。見慣れない項目はまず適用条件を調べ、別の設定の値を不足分として流用しないでください。

REALITYのパラメーターと適用範囲

REALITYは特定の実装機能に関わる安全機構で、XrayのVLESS設定でよく使われます。クライアントでは通常、接続先アドレス、ポート、ユーザーIDに加えて、サーバー名、公開鍵、ショートIDなどの関連パラメーターが必要です。画面によって項目名が異なることはありますが、それぞれの役割が入れ替わるわけではありません。公開鍵は対応するハンドシェイクの検証に使うもので、サブスクリプションURLではありません。ショートIDもユーザー向けのメモではありません。パラメーターが足りない場合は、信頼できる設定元から完全な情報を取得してください。適当な値を生成しても、リモート側の認証エラーは解決できません。

サーバー名はサーバー側で許可された条件に合わせる必要があり、よく知られたWebサイトのドメインに安易に置き換えるべきではありません。接続先アドレスとサーバー名は異なる場合があります。前者はネットワーク接続先を指定し、後者は安全なハンドシェイクに使われます。両方を同じ値にすればよいとは限りません。公開鍵、ショートID、サーバー名も、互いに置き換えられる項目ではありません。トラブルシューティングでは、プロトコル欄にVLESSと表示されているかだけでなく、関連項目をまとめて照合し、インポーターによる欠落や誤った割り当てがないか確認してください。

フロー制御、フィンガープリント、トランスポートの互換性

設定によっては、画面にVision関連の項目として表示される特定のフロー制御方式を使います。すべてのVLESS接続で有効にする汎用の高速化スイッチではなく、サーバー、トランスポート、安全層の組み合わせによって適用可否が決まります。別の設定にこの項目がない場合、独自に追加して流用しないでください。同様に、クライアントフィンガープリントの設定は安全なハンドシェイクに影響しますが、変更しても帯域幅が増えるわけではありません。まずサーバー側が求める組み合わせ、またはクライアントが明確に対応する組み合わせを使い、調整が必要かどうかを判断しましょう。互換性の問題を性能の問題と取り違えにくくなります。

クライアントで設定を導入できても、起動直後に安全方式非対応や不明な項目のエラーが出る場合は、まず実行中のコアを確認してください。GUIがREALITYの接続パラメーターを認識していても、選択中のコアが対応しているとは限りません。別のコアに切り替えると、同じ設定項目が記録に残っていても、実際に生成される実行設定が変わることがあります。切り替える前にバックアップし、切り替え後は起動結果とログを確認して、パラメーターが実際にコアへ渡されているかを確かめましょう。カード上のプロトコル表示だけで判断しないでください。

この組み合わせを選ぶには、サーバーが明確に対応していること、クライアントがすべての項目を保存できること、使用するコアが該当機能を実行できることが前提です。他の組み合わせより速いと保証されるわけでも、証明書の仕組み以外に必要な運用確認が不要になるわけでもありません。モバイル端末ではネットワーク切り替え、長時間接続、バックグラウンド動作も考慮してください。既存のサブスクリプションを日常的に使うだけなら、項目を手作業で追いかけるより、設定をすべて導入して内容を変えずに使うほうが確実です。プロトコルとコアの役割については、XrayとV2Flyのコアの違いもご覧ください。

TrojanとShadowsocks：安全性と方式の指定

TrojanとTLSの組み合わせ

Trojanは、プロキシ認証とリクエストをTLS接続の内側で扱います。一般的な設定ではパスワードを認証情報として使います。設計上の選択はVLESSとは異なり、項目数だけでどちらが軽いかを判断することはできません。アドレス、ポート、パスワードは接続設定の一部にすぎず、サーバー名、証明書の検証、トランスポートもサーバー側の条件を満たす必要があります。導入後にパスワードが表示されても、証明書チェーンが信頼できるとは限りません。ポートに接続できても、安全なハンドシェイクやプロキシ認証が成功したとは限りません。

証明書の検証は接続相手の身元を確認するためのものです。サーバー名の不一致、証明書の期限切れ、信頼チェーンの異常が発生した場合は、設定上のサーバー名、システム時刻、サーバー側の証明書設定を確認してください。検証を無効にすると接続の安全性が変わるため、恒久的な解決策として扱うべきではありません。企業ネットワークで独自の信頼設定を使う場合も、すべての設定で一律に検証を省略するのではなく、実際の管理ルールに従ってください。目指すべきはエラー表示を消すことではなく、検証できない原因を解消することです。

Shadowsocksでは暗号化方式が互換性を左右する

Shadowsocksは、比較的シンプルなプロキシと暗号化の組み合わせで接続します。主な設定項目はアドレス、ポート、暗号化方式、パスワードです。暗号化方式は任意に選べる好みの設定ではなく、プロトコルのネゴシエーションとは別に、接続する双方で一致させる必要があります。世代の異なる方式では、鍵の要件、セッション処理、実装の対応状況に大きな違いがある場合があります。クライアントにサーバー側より多くの方式が表示されても、その中から自由に選べるわけではありません。

新しい方式では鍵の形式に厳しい要件がある場合があり、読みやすい短いパスワードをそのまま有効な鍵として使えるとは限りません。古い共有リンクには異なるエンコード形式が使われていることもあります。方式とパスワードをまとめてエンコードする形式もあれば、認証情報とアドレスを別々に表す形式もあります。解析に成功した後も、方式名とパスワードが完全に保持されているか、特にリンク内の特殊文字が正しく復元されているか確認してください。出所が明らかなサブスクリプションでは、何度も手動でデコードや再エンコードを行わず、クライアントから直接導入するのがおすすめです。

拡張項目とデータグラムの対応

一部のShadowsocks設定は追加の拡張機能に依存しますが、GUIクライアントや現在のコアがその機能に対応していない場合があります。基本プロトコルだけが認識されても、接続には失敗することがあります。プロトコル名が同じというだけで設定全体に互換性があるとは限りません。拡張機能が必要か、どのコンポーネントがその処理を担うか、現在のソフトウェアが実際に対応しているかを確認してください。この記事では紹介する3つのクライアントの選び方を扱います。共有リンクに合わせるためだけに、出所不明の追加プログラムを安易にインストールすることはおすすめしません。

音声通話、ゲーム、その他のデータグラム通信を使う場合は、経路全体でUDPに対応しているか確認する必要があります。クライアントの入口がデータグラムを受け取れるか、プロトコル実装が転送できるか、サーバーが転送を許可しているか、アプリの通信が実際にその入口へ流れているか。どれか一つでも欠けると、Webサイトは表示できても特定のアプリだけ動作しないことがあります。この現象をすぐにプロトコルの「速度不足」と決めつけないでください。ログとアプリの挙動から通信の種類を確認し、クライアントの入口モードとサーバーの対応状況を調べましょう。

これら2種類のプロトコルを選ぶ場合も、既存サービスの設定条件に従う必要があります。適切に証明書を管理している既存のTrojanサービスは、指定されたパラメーターで利用できます。対応方式が使われ、設定内容が明確なShadowsocksサービスにも適した用途があります。認証を無効にしたり、暗号化方式を置き換えたり、拡張項目を削除したりして、互換性のない設定を無理に「導入できる」状態に変えないでください。移行する場合は、サーバー側で新しい接続設定一式を用意してもらい、独立した設定として検証しましょう。元の設定は切り戻し用に残してください。

コアの種類：Xray、V2Fly、クライアントとの連携

共通のルーツがあっても互換性が続くとは限らない

このエコシステムの背景を理解するうえで、Project Vは重要な存在です。V2FlyはV2Ray関連の実装を保守し、Xrayは分岐したプロジェクトとして独自の機能を発展させています。ルーツが共通のため、概念や設定構造が似ている部分はありますが、2つは同じプログラムの別テーマではありません。分岐後は機能、安全機構、トランスポートの実装、設定項目がそれぞれ進化する可能性があります。あるプロトコルに対応していても、そのすべての拡張機能との組み合わせまで対応しているとは限りません。コアを比較する際は、プロジェクト名を性能ランクとして見るのではなく、具体的な設定要件を基準にしてください。

REALITYや特定のフロー制御が必要な場合は、使用するXray実装とクライアントの連携状況を確認してください。既存のV2Flyサービスや設定を使う場合は、対応するコアが実際に必要な機能を備えているか調べましょう。基本的なプロトコルはどちらでも使える場合がありますが、同じ名称の設定項目でも、パラメーター、既定値、制約が異なることがあります。新しいトランスポートでは、古い解説だけを根拠に別のコアの対応状況を判断しないでください。「この設定に含まれる各項目を現在の環境で正しく実行できるか」と具体的に確認するほうが、「どちらのコアが先進的か」と大まかに尋ねるより正確です。

3つのクライアントの役割

デスクトップでは、Windows、macOS、Linuxの設定管理に使える v2rayN が第一候補です。ただし、画面構成、システム連携、配布パッケージごとの機能は実際の環境で確認してください。Androidでは、Xrayコアを使う v2rayNG が有力です。V2Fly系が必要な場合は、v2flyNGも検討してください。3つのクライアントは、同一アプリの各OS版ではありません。インポーター、ルーティングの編集方法、設定メニューは異なる場合があります。移行時は、同じメニュー名を探すのではなく、設定の意味を引き継いでください。

クライアントに表示されるコアの切り替え機能にも限界があります。コアを選べても、すべての設定が意味的に同じ内容へ自動変換されるとは限りません。一部の項目が片方のコアだけで有効だったり、異なる形式の設定をクライアントがコアごとに生成したりする場合があります。カスタム設定では違いがより顕著です。あるコアで読み込める設定ファイルを、別のコアにそのまま渡しても同じ結果になるとは限りません。移行前に元のファイルと実行ログを保存しておきましょう。

コアを切り替えるときの確認手順

まずサブスクリプションの入手元、手動で追加した設定、カスタムルートをバックアップし、項目が明確な設定を一つ基準として選びます。マルチプレクシングや複雑なルーティングなど、検証に関係のない機能はいったん無効にします。新しいコアを起動してエラーを確認してください。起動時に不明な項目が出たら設定構造を、ハンドシェイク時に認証や安全性のエラーが出たらリモート側のパラメーターを確認します。Webは使えるのにアプリで問題が起きる場合は、通信の入口、名前解決、データグラムへの対応を調べてください。段階ごとに原因は異なるため、「コアを変える」ことを繰り返しても解決にはつながりません。

ルーティングルールも別途確認が必要です。ドメイン一覧、アドレス一覧、リソースファイルの形式や読み込み場所は、クライアントとコアの両方に左右される場合があります。切り替え後、接続自体は正常なのに、本来ダイレクト接続する通信がプロキシに流れる場合は、プロトコル認証を変更するのではなく、実際に生成されたルールの順番と既定の出口を確認してください。ルールファイルの不足、分類名の違い、名前解決方法の変化も、マッチ結果に影響することがあります。コアの移行では、接続レイヤーの互換性だけでなく、ルーティング動作も再確認してください。

継続して保守する場合は、特定のコアに依存する設定、クライアントが生成するルール、手動変更した項目を記録しておくと便利です。アップグレード前に復元可能な設定のコピーを保存し、アップグレード後は少数の設定で接続を確認してから、日常使いのルーティングに戻しましょう。ダウンロード先はクライアントのダウンロードにまとめています。コアの種類の解説は、別のプログラムを入手するための手順ではありません。エコシステムについてはProject Vのエコシステム解説、プラットフォームと画面の選び方は3つのクライアントの比較をご覧ください。

性能と電池消費：ハンドシェイク、スループット、バックグラウンド負荷を分けて考える

「速度」には少なくとも3つの観点がある

プロトコルの比較で混同されやすいのは、接続確立時間、リクエストの応答時間、継続的なスループットです。接続確立には名前解決、下位の接続、安全なハンドシェイク、認証が関係します。応答時間はリモートの接続先や経路の往復時間にも左右されます。継続的なスループットは帯域幅、輻輳、サーバー負荷、ローカルの処理能力によって決まります。ある組み合わせで最初のページが速く開いても、長時間のデータ転送でスループットが高いとは限りません。プロトコル名から分かるのは構造コストの一部だけであり、実際の通信状況の確認に代わるものではありません。

短いリクエストで接続を何度も確立する場合は、ハンドシェイクのコストが目立ちます。大量のデータを長時間転送する場合は、安定したスループットと暗号処理のコストが重要です。カプセル化を追加すると処理手順やデータ量が増えることがありますが、サーバーの構成、転送経路、接続の再利用方法によって結果は変わります。こうした条件を無視して、VMess、VLESS、Trojan、Shadowsocksに常に当てはまる速度順位を付けることはできません。同じプロトコルでも、端末、トランスポート、サーバーが異なれば、その差はプロトコル間の差より大きくなることがあります。

リソース使用量は負荷の構成で変わる

CPU負荷は暗号化方式、ハードウェアアクセラレーション、データコピー、同時接続数に左右されます。メモリ使用量にはルールデータ、キャッシュ、バッファー、クライアントの画面も影響します。GUIを起動したときの合計使用量を、すべてプロトコルの負荷とみなすことはできません。比較する際は、2つの設定でルールと通信の入口をそろえ、アイドル時と負荷時の違いを観察してください。一方で複雑なルールや仮想インターフェースを有効にし、もう一方でシンプルなシステムプロキシだけを使う場合、純粋なプロトコル性能の比較にはなりません。

マルチプレクシングは接続確立にかかるコストを減らせる場合がありますが、どの場面でも有効とは限りません。パケットロス、サーバー側の制限、異なる通信どうしの影響があると、接続を集約したことで待ち時間や復旧の問題が生じる場合があります。フロー制御とマルチプレクシングの組み合わせに実装上の制約がある場合もあるため、双方の対応が前提です。スレッド数や接続数を増やし続けても、常に速くなるわけではありません。まず既定値か提供元が明示した設定を使い、再現性のある問題が見つかった場合に限り、一度に一つの項目を調整してください。

モバイル端末の電池消費は主に動作状況で変わる

モバイル端末の電池は暗号化処理だけでなく、無線通信の起動、バックグラウンドでの接続維持、頻繁な再接続、名前解決、データ転送でも消費されます。アイドル時にも通信を続ける設定は、処理が少し重くても接続が安定した設定より電池を消費することがあります。Wi-Fiとモバイルデータを切り替える際、古い接続が切れた後にどう復旧するかも使い勝手に影響します。画面の明るさ、電波の強さ、ほかのバックグラウンドアプリも結果に影響するため、一度の電池残量の減少だけで特定のコアが省電力だと判断しないでください。

v2rayNGまたはv2flyNGを比較する際は、似たネットワーク環境とアプリの負荷を使い、前面での利用、画面ロック中の待機、ネットワーク切り替え後の動作をそれぞれ確認してください。OSのバッテリー管理によってバックグラウンド動作が制限され、画面ロック後の切断や復旧の遅れが起きることがあります。制限を緩和するかどうかは実際の用途と消費電力を踏まえて決め、すべての省電力機能を一律に無効にしないでください。サブスクリプションの頻繁な更新、自動テスト、異常な再試行がないかも確認しましょう。これらのバックグラウンド処理は、プロトコル間の小さな差より電池消費に大きく影響することがあります。

実際に選ぶ際は、性能を比べる前に明らかな非互換性や異常な再接続を解消してください。孤立した遅延値を一つ保存するより、テスト条件、設定の組み合わせ、問題が起きた段階を記録するほうが役立ちます。結果が当てはまるのは、その端末とネットワークに限られ、プロトコルの恒久的な順位を示すものではありません。通常のWeb閲覧と継続的なデータ転送が安定していて、特定のアプリだけ問題が起きる場合は、通信の入口とルーティングを確認してください。すべての設定で同時に遅くなった場合は、プロトコルを次々に変更するのではなく、共通するネットワーク環境を調べましょう。

サブスクリプションの互換性：共有リンク、エンコード、設定項目の保持

リンクの見た目だけでは中身の形式は分からない

単一の共有リンクは一つの接続設定を表します。サブスクリプションURLは、更新される可能性のある複数の設定を取得するためのものです。どちらもクリップボードにコピーできますが、管理方法は異なります。共有リンクには通常、プロトコルを示すプレフィックスが付いています。サブスクリプションURLは一般にリクエスト可能なネットワークアドレスで、リンクの一覧、エンコードされたテキスト、その他の形式を返す場合があります。URLがHTTPSで始まっていても、現在のクライアントが返された内容を解析できるとは限りません。導入する前に、提供元が案内する用途を確認してください。

VMessの共有形式では、エンコードされた構造化データがよく使われます。VLESSやTrojanでは認証情報、アドレス、クエリーパラメーターを組み合わせたリンクが一般的です。Shadowsocksには認証情報の異なるエンコード形式があります。これらは広く使われていますが、すべてのインポーターが全種類に対応するとは限りません。解析できない場合は、リンクが途中で切れている、エンコードが壊れている、またはクライアントが未対応の項目を含む可能性があります。不要な変更を避けるため、まず形式の段階でのエラーか、実行時のエラーかを切り分けてください。

導入後も設定を確認する

クライアントは通常、リンクを内部設定に変換してから、コアが実行する設定を生成します。その過程で未知の項目が失われたり、不足している項目に既定値が設定されたりする場合があります。「導入成功」は最初の確認にすぎません。プロトコル、アドレス、ポート、認証、トランスポート、安全層、追加パラメーターを確認してください。特にREALITYのパラメーター、フロー制御、サーバー名、トランスポートのパスに注意が必要です。元のリンクに項目が含まれているのに画面に対応する内容が見当たらない場合は、リモートサービスをすぐに変更するのではなく、その項目が保持されたか確認してください。

特殊文字はよくある問題の原因です。パスワードの区切り文字、パスに含まれるクエリー文字列、メモの非ラテン文字は、正しいパーセントエンコードが必要な場合があります。チャットで何度も転送したり、リンク全体を一般的なWebページのURLとして処理したりすると、内容が切れたり誤って復元されたりすることがあります。エンコードの段階が分からないまま、リンク全体を何度もデコードしないでください。元の内容をコピーし直し、クライアントに対応した導入方法を使い、貼り付けた内容に説明、空白、改行が混ざっていないか確認しましょう。

サブスクリプション更新とローカル変更の競合

サブスクリプションの更新では通常、リモートから取得した内容が使われます。重複項目の判定、メモの保持、設定の上書き方法はクライアントごとに異なります。サブスクリプション内の設定を手動で変更すると、更新後に元へ戻ったり別の内容に置き換わったりする場合があります。テスト用の設定を長期間残したい場合は、クライアントが対応していれば独立した設定として複製し、用途を明記してください。ただし、複製した設定はリモート側のアドレスや認証情報が自動更新されないため、定期的な確認が必要です。サブスクリプションの管理と手動設定にはそれぞれ異なる手間があります。設定元が追えない記録をひとまとめにしないようにしましょう。

サブスクリプションURLにはアクセス用の認証情報が含まれることがあるため、機密情報として扱ってください。スクリーンショット、ログ、問い合わせ内容を共有するときは、URL全体、ユーザーID、パスワード、関連する非公開パラメーターを隠しましょう。取得に失敗した場合は、接続エラー、応答の種類、解析メッセージを記録すれば、たいてい原因を調べられます。URL全体を公開する必要はありません。ログインページ、エラーページ、空のテキストが返ってきた場合、クライアントが解析エラーを表示することがあります。これはプロトコルが非対応なのではなく、想定した設定一覧が取得できていない可能性があります。

クライアントを移行する際は、提供元が明確に対応しているサブスクリプション形式を使い、代表的な設定を一つ選んで内容を照合しましょう。設定の件数が同じでも、重要な項目が欠けている可能性があるため、件数の比較だけでは移行が完全だとは判断できません。一括導入後はまず一つの設定を検証し、続いて異なるプロトコルやトランスポートの代表的な設定も確認してください。設定のコピー、サブスクリプションの追加・更新については入門ガイドをご覧ください。形式の違いと導入方法については共有リンクとサブスクリプションURLの違いを参照してください。設定項目が正しく保持されてはじめて、その後の性能や安定性を比較できます。

利用シーン別の選び方：最小構成と検証手順

条件をもとに組み合わせを絞り込む

既存サービスを使う場合、最初にプロトコルを比べるのではなく、サーバー側が提供する組み合わせ、端末のプラットフォーム、実際の用途を整理してください。デスクトップではまず v2rayN を選び、設定に必要なコアとトランスポートを確認します。Androidでは v2rayNG から始め、V2Fly系が必要なら v2flyNG を検討してください。サーバーが完全な設定一式を一つだけ提供し、それがクライアントでサポートされているなら、認証情報や安全設定を変更せず、その組み合わせに合わせて設定しましょう。サーバー側の構成を自分で選べる場合は、保守体制と更新コストも判断材料に含めてください。

ネットワークを頻繁に切り替えるモバイル利用では、再接続やバックグラウンド動作を重視します。デスクトップで長時間データを転送する場合は、スループットの安定性とCPU負荷を確認してください。複数のアプリで出口を分けたい場合は、ルーティング設定と通信の入口に注目します。データグラムを使う場合は、経路全体で対応しているかを先に確認してください。プロトコルが担うのは、その一部にすぎません。すべての要望を「どのプロトコルが最速か」にまとめると、アプリがシステムプロキシを参照していない、名前解決が想定どおりルーティングに入っていないなど、本当の制約を見落としやすくなります。

まず最小構成で接続を確認する

初回の検証では、パラメーターが明確なリモート設定を一つだけ有効にし、ルーティングはシンプルなモードにして、動作が分かっているアプリからクライアントへ通信を送ります。まずコアが正常に起動することを確認し、次に普段使うWebサイトへ接続して、ログの接続先と出口を確認してください。Webページが開けても、すべてのアプリ、ドメイン、通信種別が使えるとは限りません。その後、ルール、仮想インターフェース、その他の機能を一つずつ戻し、追加するたびに比較できる結果を残しましょう。

ルーティングの問題は、範囲を絞ったルールで動作を確認できます。以下はXrayまたはV2Ray形式の設定に使うルーティング部分です。完全な設定に direct というタグのダイレクト接続アウトバウンドが存在することが前提であり、単独で起動できるファイルではありません。例では、予約済みのサンプルドメインに完全一致したリクエストだけをその出口に渡します。それ以外のリクエストは、完全な設定内の別ルールまたは既定の出口に従います。クライアントのGUIルーティング編集画面では別の形式を使う場合があります。この断片を共有リンクの入力欄に貼り付けないでください。

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

失敗した段階に応じて原因を調べる

コアが起動しない場合は、リモートの帯域を測る前に、設定項目、構造、コアの対応状況を確認します。名前解決に失敗する場合は、アドレスの入力ミスと名前解決の経路を調べてください。接続がタイムアウトする場合は、ネットワークの到達性、ポート、サーバーの待ち受け状態を確認します。安全なハンドシェイクに失敗した場合は、システム時刻、サーバー名、証明書または公開鍵のパラメーターを調べてください。認証エラーでは、ユーザーID、パスワード、双方のプロトコル設定を確認します。接続後に一部のアプリだけ異常が起きる場合は、通信の入口、ルーティング、データグラムへの対応を調べましょう。この順序なら、変更するたびに明確な目的を持てます。

複雑なルーティングを戻すときは、通常ルールが上から順に評価され、前方の広い条件が後方の細かい条件に優先することを理解しておきましょう。ドメインルールやアドレスルールに一致するかどうかは、名前解決の方式やデータセットにも左右されます。地域分類が常に正確な用途別分類になるとは限りません。同じアプリでも、複数のドメインやアドレス範囲にアクセスすることがあります。まずどの出口へ通信を流したいかを決め、実際に一致した条件を確認してください。ルールの仕組みや競合の確認方法は、geositeとgeoipによるルーティング設定をご覧ください。

切り戻し手段を残してから、継続的な設定変更を行う

一度に変更するのは一つのレイヤーだけにしてください。リモート設定を切り替える、通信の入口を変える、コアを変更する、といった変更を一つずつ行い、プロトコル、ルーティング、名前解決を同時に変えないようにします。元の設定元、変更の目的、確認結果を記録し、公開されると困る認証情報は記録しないでください。新しい組み合わせが安定したことを確認してから日常使いの設定を置き換え、元の設定は新しい経路の検証が終わるまで残しておきましょう。更新後に問題が起きた場合も、すべてのサブスクリプションを再導入するのではなく、変更した範囲から見直してください。日常の設定手順はクイックスタートへ、個別のトラブルはよくある質問へ。本ガイドが示すのは判断材料であり、すべてのサーバーに共通する設定を指定するものではありません。