プロキシプロトコルとコアの選び方

設定の階層：プロトコルだけでは接続を定義できない

ノード設定を4つの要素に分ける

クライアントのノードは、単一のプロトコル名ではなく、連携して動作する接続設定のまとまりです。1つ目は接続先を決めるサーバーアドレスとポート。2つ目は相手を識別するプロキシプロトコルと認証情報。3つ目はプロキシデータを運ぶ伝送方式。4つ目は接続を暗号化し、相手を認証するセキュリティ層です。サブスクリプションを使えばこれらをまとめて取り込めますが、手入力の手間が省けるだけで、各層の依存関係がなくなるわけではありません。

たとえばVLESSは複数の伝送方式と組み合わせられ、TLSやREALITYを使う構成もあります。「VLESS」と表示されているだけでは、どのセキュリティ層を使うかはわかりません。「TCP」も、内部で動作するプロキシプロトコルを示すものではありません。クライアントによって伝送方式を「ネットワーク」「伝送プロトコル」などと表示する場合がありますが、プロトコルの種類とは区別が必要です。トラブル時は元の設定を残し、層ごとに確認しましょう。プルダウンをむやみに切り替えるより、原因を特定しやすくなります。

画面の設定から実際の接続をたどる

伝送方式には固有の設定項目があります。WebSocketではパスやHost、gRPCではサービス名がよく使われます。これらは単なるメモではなく、ドメイン名を見ただけで推測できる項目でもありません。サーバーアドレスは下位の接続先、Hostは上位のリクエストの振り分け、SNIはTLSハンドシェイクで通知するサーバー名です。3つが同じ場合もあれば、構成によって異なる場合もあります。サブスクリプションに含まれる値は、そのまま保持してください。すべてを「サーバーアドレス」で統一するのではなく、項目ごとに確認しましょう。

システムプロキシとルーティングルールは、さらに別の階層です。システムプロキシは、システム設定を参照するアプリのリクエストをクライアントに渡すかどうかを決めます。ルーティングルールは、クライアントに届いたリクエストを直接接続するか、プロキシに通すかを決めます。ノード設定が正しくても、すべてのアプリが利用しているとは限りません。システムプロキシを有効にしても、ルールが対象の通信を現在のノードに送るとは限りません。問題が起きたら、まずリクエストがクライアントに届いているかを確認し、その後にプロトコルのハンドシェイクを調べましょう。アプリ側の接続経路の問題を、プロトコル非対応と誤認しないためです。

設定をむやみに変更せず、エラーを読み解く

ログに「接続が拒否されました」とある場合は、まず接続先と待ち受け状態を確認します。名前解決に失敗する場合はDNS、証明書関連のエラーならセキュリティ層、認証エラーならプロトコルの項目を確認しましょう。必ずしもエラーと原因が一対一で対応するわけではありませんが、最初に調べる場所の目安になります。再試行のメッセージだけを切り取らず、同じ接続の前後を含むログを保存し、PCとスマートフォンの結果は分けて記録してください。異なるコアを使う端末では、同じノード名でも実際の処理経路が異なる場合があります。

問い合わせ時は、クライアント名、コア名、プロトコルの種類、伝送方式、セキュリティ層、個人情報を伏せたエラー情報を伝えると役立ちます。ユーザーID、パスワード、サブスクリプションURL全体、共有用QRコードは公開しないでください。ノード名は自由に付けられますが、実際の設定内容を示すものではありません。確認に役立つのは、編集画面に表示された各項目と、コアが設定を読み込んだ後の動作です。この後の章も同じように、まずプロトコルを説明し、次に伝送方式、セキュリティ層、クライアントでの実装を解説します。

VMessとVLESS：認証と暗号化の違い

VMessの設計背景と既存設定

VMessは、Project Vの初期から使われている主要なプロキシプロトコルです。ユーザー認証、リクエスト情報のカプセル化、データ保護をプロトコル自体の設計に含み、クライアントとサーバーはユーザーIDなどの取り決めに基づいて接続を識別します。さまざまな伝送方式との組み合わせにも対応しています。長年利用されてきたため設定資料やサブスクリプションの例が多くありますが、異なる実装段階の情報が混在しています。古い解説では、項目名が同じだからといって、認証設定が現在のクライアントでも使えるとは限りません。

現在のVMess設定では、AEADによる認証方式を確認しましょう。旧形式の設定にある追加ID項目は、過去との互換性に関わるものです。古い記事をまねて、根拠なく0以外の値を入力しないでください。ユーザーIDはサーバー側と一致させ、システム時刻も正確に保つ必要があります。認証に失敗したら、サブスクリプションの期限とIDの欠落を確認し、時刻の同期やクライアントの対応範囲も調べましょう。伝送方式を変更しても、認証情報の不一致は通常解決しません。

VMessのデータ暗号化設定とTLSは、別の設定項目です。前者はプロキシプロトコル内部、後者は接続を保護する外部のセキュリティ層に属します。画面に「自動」とある場合、通常は実装が端末の機能に応じて対応する方式を選ぶという意味です。サーバーが任意の組み合わせを受け入れるという意味ではありません。サブスクリプションの設定で問題なく使えているなら、暗号化層を減らすためだけに設定を無効にする必要はありません。負荷を抑えたい場合は、まずサーバー側が対応する構成全体を確認し、条件をそろえて比較してください。

VLESSで外部のセキュリティ層が重視される理由

VLESSは、簡潔な認証とリクエスト表現を重視し、VMessと同じプロトコル内蔵のデータ暗号化機能は備えていません。そのため、VLESSの安全性を評価する際は、どのセキュリティ層と組み合わせているかも確認する必要があります。インターネット経由で使う場合は、通常、サーバー側が明示的に対応するTLSまたはREALITYを利用します。プロトコル名が簡潔だから安全、あるいは高速だと判断するのは早計です。外部のセキュリティ層、伝送方式、サーバー側の実装も性能と安全性に関係します。

VLESS設定のユーザーID、暗号化項目、フロー制御項目には、それぞれ異なる役割があります。よく使われる暗号化項目の値はnoneです。これはVLESSプロトコル内の暗号化方式を示し、接続全体がTLSで保護されていないという意味ではありません。フロー制御は、たとえばサーバーが要求するVisionのように、特定の実装に依存する追加機能です。クライアントとコアの両方が対応している必要があります。汎用の高速化スイッチではないため、すべての伝送方式に同じ値を設定しないでください。

実際にはどちらを選ぶべきか

現在のVMess設定が安定していて、互換性や性能にも問題がないなら、そのまま使うのが合理的です。新しい設定でVLESSと最新のセキュリティ層が提供されている場合は、まず現在のコアで一式をサポートできるかを確認しましょう。比較時は、サーバー、伝送経路、テスト内容をできるだけそろえてください。そうしないと、プロトコルではなく接続先の違いを測ってしまう可能性があります。別々の提供元のノードを比べて、特定のプロトコルが必ず速いと結論づけることはできません。

移行時は、サブスクリプションと端末間の設定差にも注意してください。PCでVLESSの構成を取り込めても、スマートフォンの古いパーサーがすべての項目を認識できるとは限りません。まず1台で元のノードを残したまま新しい設定を追加し、認証、ドメインへのアクセス、必要なアプリの動作を確認してから他の端末に展開しましょう。特定のクライアントだけで失敗する場合は、ユーザーIDをすぐに再発行せず、フロー制御、セキュリティ層、フィンガープリントの違いを比べてください。最終的には、設定一式を両端で正しく実行できるかどうかが選択の基準です。

TrojanとSS：異なるセキュリティ保護の方式

TrojanでTLSが必要な理由

Trojanは、TLSで保護された接続上でプロキシ通信を行い、パスワードで認証する方式です。暗号化をプロトコル内部に持たせる設計とは異なり、実績のあるTLS実装を直接利用します。そのためTrojanノードでは、証明書名、信頼チェーン、システム時刻は付随的な項目ではなく、接続の成立を左右する重要な条件です。パスワードが正しくても、TLSのハンドシェイクに成功したとは限りません。

サーバーアドレスと証明書に記載された名前は、異なる場合があります。サーバー側がSNIを指定している場合、クライアントには指定された名前を入力してください。信頼できる証明書を使う場合は、システムが正しく証明書を検証できる必要があります。証明書エラーの際、「証明書の検証をスキップ」を有効にすると表示が変わる場合がありますが、重要な相手確認も無効になるため、通常の修正方法として使うべきではありません。まず名前、システム時刻、証明書チェーン、サブスクリプションが正しいサーバーを参照しているかを確認しましょう。

Trojanは複数の伝送方式と組み合わせられるため、「Trojanノード」に必要な設定がアドレス、ポート、パスワードだけとは限りません。サブスクリプションにパス、Host、サービス名が含まれている場合は、それらも保持してください。クライアントにプロトコル名が表示されても、追加項目が抜けていると、インポートは成功して接続に失敗することがあります。互換性は、対応一覧にTrojanがあるかだけでなく、具体的な組み合わせで判断しましょう。ハンドシェイクの問題はTLS・証明書エラーの対処法も参考に、項目ごとに確認してください。

SSは暗号化方式によって互換性が決まる

SSはShadowsocksの一般的な略称で、シンプルな暗号化プロキシ転送を目的としています。通常はサーバーアドレス、ポート、パスワード、暗号化方式が必要です。暗号化方式はプロトコルの仕様に関わる項目で、クライアント側の好みで変更できるものではありません。サーバー側の方式に対応した実装をクライアントで選ぶ必要があります。パスワードが同じでも方式が違えば通信できません。サブスクリプションの方式名は、ハイフンや数字も含めてそのまま使い、似た名前を推測で選ばないでください。

よく使われる設定にはAEAD系の方式があり、独自の鍵やセッション設計を持つ新しい方式もあります。方式によってパスワードや鍵素材の要件が異なるため、ある方式の一般的なパスワードを、別の方式が求める形式の鍵として使うことはできません。古い方式が現在の実装で削除または制限されている場合もあります。クライアントでSSの編集画面を開けても、一部の設定に対応していることがわかるだけで、過去の方式やすべての拡張機能を利用できるとは限りません。

伝送方式の拡張にも注意が必要です。一部のSS共有リンクには追加の拡張項目が含まれていますが、ここで紹介するクライアントや選択したコアがその拡張に対応しているとは限りません。その場合は、追加項目を削除して同じ動作になると考えるのではなく、設定の提供元に互換性のある接続方式を確認してください。項目を削除するとエラーが消えても、接続に必要なカプセル化方式が変わることがあります。取り込み後は元の設定と照らし合わせ、特に暗号化方式と追加の伝送設定を確認しましょう。

設定がシンプルでも、負荷が小さいとは限らない

設定のシンプルさで見ると、基本的なSSは項目が少なく、サーバー側の方式が明確で標準的なプロキシ転送を行う場合に向いています。Trojanは、TLS設定と証明書を適切に管理できるサーバーに適しています。どちらも日常のウェブ閲覧に使えますが、特定のアプリで利用できるかはUDP対応、クライアントへの接続方法、ルーティング設定によって異なります。項目が少ないからスマートフォンの電池が長持ちするとは限りません。電池消費は接続数やバックグラウンド動作の影響を大きく受けます。

選ぶ前に、リアルタイム通話、ゲームなどUDPを使う用途があるかを確認し、クライアント、コア、サーバー、伝送経路がすべて対応しているか調べましょう。ウェブページが開けるだけでは、UDPが使える証明にはなりません。現在のSS設定で必要な用途を満たせているなら、別のプロトコル名が新しいという理由だけで移行する必要はありません。使いたい機能を現在のコアがサポートしていない場合は、ローカル設定を何度も変更するより、互換性のある設定を使う方が効果的です。

TLSとREALITY：セキュリティ層の設定確認

TLSが確認するのは接続相手の正当性

TLSは通信内容を直接読めない形にするだけでなく、接続相手を認証する役割もあります。通常の検証では、証明書の有効期間、名前の一致、発行元の信頼性などを確認します。システム時刻がずれていると、有効な証明書がまだ有効でない、または期限切れと判断されることがあります。サーバー名が間違っていれば、名前の不一致が発生します。問題を調べる際は、エラーを無視する設定で一括して回避せず、時刻と設定の入手元をまず確認しましょう。

SNIはハンドシェイク時に接続先のサーバー名を伝えるために使われ、証明書の検証にも正しい名前が必要です。GUIクライアントでは「サーバー名」「SNI」などの項目として表示されます。接続先アドレスがドメインでもIPアドレスでも、SNIを同じ値にするとは限りません。同じ接続先で複数のサービスを提供している場合、名前によってリクエストの振り分けが変わることもあります。サブスクリプションに記載された値を使い、アドレス欄とセキュリティ設定の名前欄を機械的に同じ値にしないでください。

ALPNは上位プロトコルのネゴシエーションに使われ、フィンガープリント設定はクライアントのハンドシェイクの挙動に影響します。どちらも汎用の高速化設定ではありません。サーバー側が特定の組み合わせを要求する場合は一致させ、指定がない場合は別のノードの設定を流用しないようにしましょう。一部のクライアントではフィンガープリントをプリセット名で選べますが、実際に使える範囲は実装によって異なります。設定名を保存できても、現在のコアが実行できるとは限りません。起動に失敗したら設定の読み込みエラーを、ハンドシェイクに失敗したらサーバーとのネゴシエーションを確認してください。

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

REALITYはセキュリティ層の方式です。VMess、VLESS、Trojanのようなプロキシプロトコルと同じ階層に並べて、相互に置き換えるものではありません。一般的な構成ではVLESSと組み合わせますが、対応する組み合わせは利用するコアの実装によって異なります。ノードを確認するときは「プロキシプロトコル、伝送方式、フロー制御、セキュリティ層」を一式として読み取りましょう。ノード名にREALITYと書かれているだけでは必要な設定がすべてわからず、他のクライアントで使えるとも判断できません。

REALITYのクライアント設定には通常、サーバー名、サーバーが提供する公開鍵情報などの認証項目、ショートID、ハンドシェイクのフィンガープリントが含まれます。クライアントやコアの更新に伴って項目名が変わることがあるため、現在の設定説明に従って対応づけてください。ショートIDはノード名ではなく、公開鍵情報を通常のパスワードで代用することもできません。値が不足している場合は、設定の提供元から再取得してください。サーバーの秘密鍵を一般ユーザー向けのサブスクリプションに含めてはいけません。トラブル報告の画像で公開するのも避けてください。

セキュリティ層の問題は最小限の変更で調べる

まずサブスクリプションを更新し、接続に失敗したノードの編集画面でセキュリティ層の種類を確認しましょう。本来REALITYの設定なのに通常のTLSとして取り込まれている場合は、サーバー名を手動で足すだけで済ませず、パーサーの互換性を疑ってください。次にフィンガープリント、認証情報、ショートID、フロー制御を確認します。根拠のある項目を一度に1つだけ変更し、元の設定も残してください。複数の項目を同時に変えると、たまたま接続できても原因を特定しにくく、他の端末で再現するのも困難になります。

同じサブスクリプションがPCでは使えてスマートフォンでは使えない場合、コアの対応状況と項目が保持されているかを比較しましょう。設定が一致し、実装も対応していると確認してから、接続ネットワークの違いを調べてください。REALITYはあらゆる接続エラーを解決する万能策ではなく、TLSも古い方式とは限りません。管理・検証しやすく、実際の構成に合っていることが、セキュリティ層を選ぶ基本です。

性能と電池消費：初回応答、転送速度、バックグラウンド負荷を分けて考える

接続速度はひとつの指標ではない

ユーザーが感じる「速さ」には、少なくとも3つの要素があります。接続を開始して最初の有効な応答が届くまでの時間、継続的に通信するときのスループット、長時間使ったときの切断の少なさです。最初の応答はDNS解決、ネットワークの往復時間、ハンドシェイクに影響されます。転送速度は回線帯域、混雑、サーバー負荷、端末の処理能力によって決まります。簡易テストで良い結果が出ても、大容量ファイルの転送が速いとは限らず、通話中の揺らぎが小さいとも限りません。

プロトコルの設計は認証、カプセル化、暗号化の負荷に影響しますが、その負荷が全体の所要時間に占める割合は一定ではありません。ネットワークの往復時間が長い環境では、ローカルの暗号化処理より接続のやり取りが1回増えることの方が目立つ場合があります。処理能力の低い端末では、大量のデータ転送時に暗号化やメモリコピーがボトルネックになることもあります。すべての端末に当てはまる、永久に有効なプロトコル速度ランキングはありません。回線とサーバーの違いを切り分けてから、実際の用途で設定一式を比べる方法が確実です。

伝送方式も通信の挙動を変えます。WebSocketでは対応するカプセル化とリクエスト処理が加わり、gRPCでは独自の伝送とネゴシエーションを使います。TCPを直接使う構成は、一般に仕組みがよりシンプルです。ただし、途中のネットワーク設備が特定の伝送方式にしか対応していない場合、追加のカプセル化は構成上必要なもので、無駄として削除できません。最適化の前に、サーバー側の制約を確認してください。パスや上位での転送をサーバーが要求している場合、クライアントをTCP直結に変えると、接続に失敗する可能性があります。

システム負荷は使い方全体で判断する

CPU負荷は暗号化だけでなく、ログ、通信量の集計、ルール判定、多数の短時間接続から生じることもあります。ハードウェアによって暗号アルゴリズムへの対応は異なるため、同じ方式でも端末によって処理コストは変わります。メモリ使用量には、接続バッファー、DNSキャッシュ、ルールデータ、GUIも影響します。クライアントを比較するときは画面側のプロセスとコアのプロセスを分けてください。タスクマネージャーで一度見た合計値を、プロキシプロトコル固有の負荷とみなすことはできません。

接続の多重化は、接続を繰り返すコストを抑えられる一方、複数のリクエストが同じ接続を共有することで、パケットロス時に互いに影響する場合があります。プロトコルやフロー制御の組み合わせによっては、多重化に特定の制約があるため、常に有効にすればよいわけではありません。設定の提供元とコアの対応状況を確認し、複数タブの閲覧、連続ダウンロード、実際のアプリでそれぞれ検証しましょう。ひとつのテストだけ改善しても、普段の接続が不安定になれば有効な最適化とはいえません。

モバイル端末の電池消費は通信の使い方に左右される

スマートフォンの電池消費は、個々のパケットの暗号化コストだけで決まりません。無線通信の起動、頻繁な再接続、過度なキープアライブ、継続的な速度測定、多数のバックグラウンドDNSリクエストも消費を増やします。電波が弱い環境では、通信自体の負荷も高まります。省電力を優先するなら、不要な自動テストや再試行を減らし、サブスクリプションの更新間隔が適切か確認してからプロトコルを検討しましょう。キープアライブを強めるために、すべての接続を常時アクティブにする必要はありません。

Androidでは、システムの電池管理によってクライアントのバックグラウンド動作が制限されることがあります。ノードの切断に見えても、実際にはプロセスやネットワーク通信が一時停止されている場合があります。端末の電池設定でv2rayNGまたはv2flyNGのバックグラウンド動作権限を確認し、それでも切断が起きるか観察してください。すべてのアプリの制限を解除する必要はありません。まずプロキシ接続を担うクライアントが必要な範囲で動作できるようにし、同程度の利用状況で1日を通した電池の変化を比べましょう。

実際に比較するときは、似たネットワーク環境と同じテスト内容を使い、初回起動、継続使用、待機後の復帰をそれぞれ記録してください。一度に変更する主要な項目は1つにし、元の設定も残しておきましょう。テスト前には一括速度測定を停止し、ほかのダウンロードを減らしてください。ルーティングやDNSを同時に変更するのも避けます。異なるサーバーを使う2つの設定を比較した場合は、「現在の環境におけるこの2つの設定の結果」として記録し、特定のプロトコルが常に省電力または安定だと一般化しないでください。

V2FlyとXray：コアの種類と設定の互換性

クライアントの画面とプロキシコアの役割

Project Vはこの種のツールの背景となるエコシステムで、V2FlyとXrayは関連するプロキシコアのプロジェクトです。コアは設定の解析、プロキシ接続、ルーティング、通信の処理を担います。GUIクライアントはサブスクリプション管理、設定編集、コアの起動、動作状況の表示を行います。両者は異なる階層です。画面にプロトコル名が表示されても、現在のコアが関連機能すべてに対応しているとは限らず、生成された設定が読み込まれたとも限りません。

v2rayNは当サイトが優先しておすすめするデスクトップクライアントで、Windows、macOS、Linuxに対応しています。利用できるコアや機能は、実際のインストーラーと画面で確認してください。Androidでは、v2rayNGは主にXrayコアを使う選択肢で、v2flyNGはV2Flyコアを使う場合の代替候補です。3つのクライアントはメニューや編集できる項目が異なるため、PCの項目位置をスマートフォンでの操作手順としてそのまま使うことはできません。インストール用ファイルは4プラットフォーム向けクライアントのダウンロードをご覧ください。

共通の技術背景があっても、設定をそのまま相互利用できるとは限らない

V2FlyとXrayには共通の技術的な背景があり、基本設定にも入出力、ルーティング、DNSなど似た概念があります。しかし、プロジェクトごとに開発が進むにつれて、プロトコルの拡張、伝送方式の実装、既定値、項目の意味に違いが生じることがあります。REALITY、特定のVLESSフロー制御などの拡張機能は、移行先のコアが明確にサポートしているか確認してください。どちらもJSON形式だからといって、設定ファイルをそのまま相互利用できるわけではありません。

JSONの構文が正しいというのは、括弧、カンマ、文字列が形式に沿っているという意味にすぎません。コアはさらに、項目が有効か、組み合わせが許可されているか、必要な機能が実装されているかを確認します。以下はXray設定のoutboundオブジェクト全体で、プロトコル項目の位置を示す例です。これは直接接続するアウトバウンドで、プロキシノードでも単独で起動できる完全なクライアント設定でもありません。outbounds配列に含める場合も、ほかの設定が必要です。

{
  "tag": "direct",
  "protocol": "freedom",
  "settings": {}
}

このオブジェクトのprotocolはアウトバウンドの動作を示し、tagはルーティングから参照するためのラベルです。ラベルだけを変更してもプロトコルは変わりませんが、ルーティング側が古いラベルを参照していると設定が機能しなくなることがあります。同様に、プロキシのアウトバウンドにある伝送方式やセキュリティ層の項目も、対象コアの形式に従う必要があります。通常のサブスクリプション利用者は、異なるコアの設定例を混ぜてコピーするのではなく、クライアント上で管理することをおすすめします。

コアの変更前に移行範囲を決める

コアを切り替える前に、サブスクリプションのグループとカスタム設定をバックアップし、動作が確認できているノードを1つ選んで小規模に試してください。プロトコル、セキュリティ層、伝送方式、フロー制御、DNS、ルーティング、UDPの要件が移行先で表現できるか確認します。切り替え後は、メイン画面に「実行中」と表示されるかだけでなく、ログに未対応項目、ルールの読み込み失敗、アウトバウンドの初期化エラーがないかも調べてください。コアのプロセスが起動していても、すべての機能が正常とは限りません。

DNSとルーティングの設定は、コアごとに細かな違いが出やすい項目です。ドメイン解決の方針、ルールの順序、データファイルの要件などが、完全に置き換えられるとは限りません。クライアントが設定の一部を変換する場合もあれば、プリセットを選び直す必要がある場合もあります。移行後はプロキシ経由にする宛先と直接接続する宛先をそれぞれ確認し、ドメイン解決と必要なUDPアプリもテストしましょう。ウェブページが1つ開いただけで移行完了とすると、ルーティングの誤りやバックグラウンドアプリの不具合を見落とす可能性があります。

1つの機能を使うためだけに、複数のコアを頻繁に切り替えるのは避けましょう。主な用途を決め、必要な機能を一式でカバーできる安定した設定を選び、元に戻せる設定も残してください。ノードがXray固有の拡張に依存するなら、対応が明確なクライアントを選びます。現在のV2Fly設定で問題なく使えているなら、そのまま利用を続けても構いません。コアを選ぶ基準は機能と設定の整合性であり、プロジェクト名が新しく見えるかどうかではありません。

サブスクリプション形式：取り込み成功だけでは項目がそろっているとは限らない

サブスクリプションURL、共有リンク、設定ファイルを見分ける

サブスクリプションURLは設定一式を取得するための入口です。共有リンクは通常、単一のノードを表します。設定ファイルにはノード以外に、受け入れ設定、ルーティング、DNSが含まれる場合があります。いずれも設定の移行に使えますが、同じ種類のデータではありません。サブスクリプションURLを単一ノードのリンクとして取り込んだり、設定ファイル全体を共有リンクの入力欄に貼り付けたりすると、空の結果や解析エラーになることがあります。手元のデータの種類を確認してから、対応するインポートメニューを選びましょう。

共有リンクには、vmess://、vless://、trojan://、ss://などのプレフィックスがよく使われます。プレフィックスは解析に使う形式を示しますが、すべての拡張項目が標準化されているとは限りません。VMessリンクにはエンコードされた構造化データがよく使われ、VLESSやTrojanでは伝送方式やセキュリティ設定をクエリパラメーターで表すことが多く、SSにも複数の表現方法があります。あるツールでリンクを認識できても、すべてのクライアントが同じように解析するとは限りません。

サブスクリプションサービスは、エンコードされた複数のリンクを返す場合も、特定のクライアント専用形式を返す場合もあります。ブラウザーで開いて長い文字列が表示されても、それだけでは現在のクライアントに適した形式か判断できません。ログイン画面、エラー説明、期限切れの通知が返されていても、ダウンロード自体は成功したように見える場合があります。クライアントが解析した項目とログを確認しましょう。更新後にノードが表示されない場合は、元のグループを残し、使える設定に戻す手段を失わないようにしてください。

取り込み後に確認したい主な項目

アドレス、ポート、ユーザーIDは比較的目立ちますが、フロー制御、フィンガープリント、セキュリティ層の名前、WebSocketのパス、Host、gRPCのサービス名、REALITYの認証情報は見落とされがちです。特に新しい形式を古いパーサーで読み込む場合、未知の項目を含むリンク全体を拒否せず、認識できない項目だけを無視することがあります。その結果、ノードが画面に表示され編集画面も開ける一方で、接続に必要な情報が欠けている場合があります。

サブスクリプションの更新では、通常、設定元から内容を読み直します。サブスクリプション管理下のノードを直接編集すると、次回の更新で変更が上書きされる場合があります。動作はクライアントによって異なるため、一度の手動変更を恒久的な修正と考えないでください。設定を比較したいときは、クライアントが対応していれば独立したテストノードにコピーし、区別できる名前を付けましょう。サブスクリプション元に問題があると確認できたら、設定元を修正するか互換性のあるURLを使います。更新のたびに同じ項目を直す方法は避けてください。

サブスクリプションの更新経路と複数端末での同期

サブスクリプションの更新にプロキシを使うかどうかは、現在の接続状況に応じて決めます。v2rayNには「すべてのサブスクリプションを更新（プロキシを使用しない）」などのメニューがあります。利用可能なプロキシがないのに、更新をそのプロキシに依存させると、接続が循環して失敗することがあります。一方、環境によっては直接更新できない場合もあるため、クライアントが提供する更新方法を比較してください。更新方法を変更したらエラーの内容を確認し、接続、認証、解析のどこで失敗したかを切り分けましょう。更新ボタンを何度も押すだけでは解決しません。

複数端末で同じサブスクリプションを使っても、ローカル設定すべてが共有されるわけではありません。通常、サブスクリプションが管理するのはノード一覧で、システムプロキシ、アプリの接続方法、ルーティング、DNSは端末ごとに設定が必要です。PCのカスタムルールは、スマートフォンで同じURLを読み込んでも自動では反映されません。QRコードのエクスポートも、単一ノードだけを含む場合があります。移行方法はPCとスマートフォンでサブスクリプションを同期する方法、更新の問題はサブスクリプション更新に失敗したときの確認リストをご覧ください。

用途別の選び方：要件に合う構成に絞り込む

PCとスマートフォンでの日常利用

PCで初めて使う場合はv2rayNを選び、OSとCPUアーキテクチャに合ったインストーラーを使いましょう。プロトコル名から先に選んで設定を探すのではなく、まずサーバー側で利用できる構成一式を確認し、現在のコアが対応していないものを除いてから安定性を比較します。ウェブ閲覧、文書作成、一般的なアプリが中心なら、理論上のプロトコル差より、DNSの安定性、適切なルーティング、確実な接続復帰が重要です。

Androidではv2rayNGを主な選択肢とし、V2Fly設定との互換性が必要な場合にv2flyNGを検討してください。スマートフォンでは、バックグラウンド動作、電池管理、ネットワーク切り替え後の復帰を確認してから、継続的なデータ転送を試します。Wi-Fiとモバイルネットワークの切り替え後に問題が起きたら、まずクライアントが接続を再確立するか確認してください。すぐにパスワードやユーザーIDを変更する必要はありません。接続復帰は動作上の問題であり、通常、認証情報はネットワークの切り替えで変わりません。

名前で順位を付けず、用途に合わせて選ぶ

既存のVMessまたはSS設定で用途を満たせているなら、クライアントを互換性のある状態に保ちながら使い続けるのが低コストです。VLESS、REALITY、特定のフロー制御を使うには、サーバー側の対応パラメーターを入手し、利用するコアがサポートしていることを確認してください。TrojanではTLSの名前と証明書の条件が重要です。すべての人に当てはまるプロトコルの順位はありません。同じプロトコルでも伝送方式、セキュリティ層、サーバーの組み合わせによって使い心地は大きく変わります。

UDPを使う用途では特に慎重な確認が必要です。プロトコルがUDPに対応していても、クライアントの接続方法、サーバー側の転送、接続先のネットワークがすべて対応しているとは限りません。また、システムプロキシを使っても、すべてのアプリの通信がクライアントに届くわけではありません。アプリ独自のプロキシ設定や独立した接続方式を使う場合もあります。まず入門にある接続と動作確認の手順で通信の入口を確認し、実際に使うアプリでテストしてください。ブラウザーでページを開けただけで、用途に必要な動作を確認したことにはなりません。

選定から元に戻すまでの手順

手順1：プラットフォーム、アプリの種類、UDPの要否、バックグラウンドで常時動かす必要があるかなど、必須要件を書き出します。手順2：設定元のプロトコル、伝送方式、セキュリティ層、追加項目を記録し、クライアントとコアが対応しているか確認します。手順3：テスト用の設定を取り込み、起動ログを確認したうえで、ドメインへのアクセス、ルールによる振り分け、実際の用途をそれぞれ検証します。手順4：簡易速度テスト1回だけに頼らず、似たネットワーク環境で接続復帰とリソース消費を確認します。

失敗した場合は、「リクエストがクライアントに届いているか」「接続先に到達できるか」「セキュリティ層のハンドシェイクが成功するか」「プロキシ認証が完了しているか」「ルーティングとDNSが正しいか」の順に原因を絞り込みます。根拠のある項目を1つずつ変更し、変更前後の状態を記録してください。ドメインのリクエストに問題がある場合はDNSの確認とルーティング設定、基本用語がわからない場合はサブスクリプション・ノード・コアの初心者向け10問も参考になります。設定を無作為に組み合わせて試すのは避けましょう。

本番利用に切り替える前に、元のサブスクリプショングループまたは独立した設定を残し、新しい構成で主なアプリが使えることを確認してから重複項目を整理しましょう。クライアントを更新した後も簡単な動作確認を行い、特にカスタムルーティング、DNS、コアの選択が意図どおりか確認してください。新しい構成でテスト結果が1つ改善しても、バックグラウンドの切断や互換性の負担が増えるなら、元に戻す判断も妥当です。管理しやすい設定とは、重要な項目の入手元を説明でき、他の端末でも同じように再現できるものです。