Clashのプロトコル・コア技術ガイド

1. プロトコル・通信方式・クライアントを区別する

3つの名前が示す3つの違い

設定を選ぶときは、まず接続を3つの層に分けて考えましょう。Shadowsocks、VMess、Trojan、VLESS、Hysteria 2、TUICはプロトコル名で、クライアントとサーバーの認証方法、リクエストの処理方法、必要な設定項目を示します。TCP、UDP、TLS、WebSocket、HTTP/2、gRPC、QUICは、接続に使う通信方式やカプセル化方式です。同じプロトコルでも通信方式の組み合わせは複数ありますが、すべてのコアが各組み合わせに対応しているわけではありません。Clash Plusなどのクライアントは、設定の読み込みや接続の切り替え、システム画面を提供します。設定を解析して接続を確立するのは、クライアントが採用するコアや実装です。アプリ名だけでは、特定のプロトコルが使えるかどうかは判断できません。

たとえば、VLESSと書かれた共有リンクを見つけたら、TCPとWebSocketのどちらを使うのか、TLSが有効か、追加のセキュリティ層があるか、必要な項目を利用するコアがサポートしているかまで確認します。Hysteria 2やTUICの場合は、QUICを利用するため、現在のネットワークでUDPが安定して使えるかを先に確認してください。プロトコル名が同じでも通信設定が違えば、互換性の結果も大きく変わります。「リンクを読み込める」ことと「接続できる」ことを分けて考えるのはそのためです。読み込み機能はテキストを設定項目に変換し、コアは設定項目を解釈して接続を試みます。

接続情報はサービス提供元の指定に合わせる

サーバーのアドレスとポート、パスワードまたはユーザーID、TLSのサーバー名、証明書の検証要件は、接続の提供元が案内する情報に合わせてください。アドレスとポートはサーバーへの接続に使い、パスワードやユーザーIDはプロトコル認証に使います。TLSのサーバー名は通常、サーバー証明書との照合に使われます。別々の設定から項目を寄せ集めても、接続できるとは限りません。特に「このプロトコルはTLSに対応している」を「TLSを有効にすれば接続が直る」と解釈しないでください。サーバー側も同じ方式で接続を受け付け、クライアント側の通信設定も一致している必要があります。

Clashの設定には、プロトコル以外の項目も含まれます。proxiesは利用可能なプロキシを定義し、proxy-groupsは選択方法をまとめ、rulesはリクエストの転送先を決めます。DNS設定はドメイン名の解決方法に影響します。プロトコルが正しくても、プロキシグループに該当するプロキシが登録されていない、あるいはルールの転送先がDIRECTになっていれば、期待した動作にならないことがあります。逆に、出力モードを変えてもノード自体のプロトコルは変わりません。設定を確認するときは、「設定を解析できる → 出力先を選べる → 接続できる → ルールが意図した出力先に一致する」の順で調べると、スイッチを何度も切り替えるより原因を見つけやすくなります。

プロトコルへの対応状況は、クライアントのバージョン、使用するコア、具体的な通信方式の組み合わせによって決まります。プロトコル名の横に常に付く単純な対応マークではありません。読み込みに失敗したらまず形式を確認し、読み込み後に接続できない場合は設定項目とネットワーク条件を確認してください。

比較する条件をそろえる

「このプロトコルのほうが速い」という比較は、サーバーの場所や回線、端末、ネットワーク、測定時刻が近い場合にのみ意味があります。モバイル回線と自宅のWi-Fiでは、パケットロスやUDPの到達性、スリープ時の挙動が異なります。同じ設定でも接続環境が変われば、結果の順位が入れ替わることがあります。普段の利用に合うかを判断するには、まず用途をはっきりさせましょう。短時間のWeb閲覧、継続的なダウンロード、動画再生、長時間のバックグラウンド待機などです。次に、接続が安定して復旧するか、最初のページがすぐ開くか、連続転送が途切れないかを確認し、最後にプロトコルを比較します。後述するリソース消費やバッテリーの話は仕組みに基づく定性的な説明であり、特定のiPhoneでの消費量を断定するものではありません。

2. Shadowsocks：設定項目が比較的少ない暗号化プロキシ

軽量な転送方式と複数の暗号化方式

Shadowsocksは、軽量なプロキシとして発展してきました。クライアントとサーバーで暗号化方式とパスワードを共有し、その間でトラフィックを転送します。設定の組み合わせは一種類だけではありません。実装によって、対応する暗号方式や認証方式、拡張機能が異なることがあります。そのため、設定のcipherは省略できず、任意の値に置き換えることもできません。一般的なAEAD方式は暗号化とメッセージの完全性保護を同時に行います。新しいShadowsocks 2022方式には、独自の鍵形式や実装要件があります。ある方式のShadowsocks設定をコアが認識できても、すべての方式に対応しているとは限りません。

Clash形式の設定では、基本的なShadowsocks出力先は通常type: ssとし、server、port、cipher、passwordを設定します。提供元が追加プラグインや通信ラッパーを指定している場合は、対応するプラグイン項目も必要です。プラグイン情報がなければ、基本項目がそろっていてもサーバー側の設定と一致しないことがあります。読み込む前に、標準の出力先設定なのか、ss://形式の共有リンクなのか、プラットフォーム固有の拡張を含むサブスクリプションなのかを確認してください。読み込み機能によって、リンクのパラメーターやプラグイン項目を変換できる範囲は異なります。

利用条件とトラブルシューティングの順序

Shadowsocksは確認する項目が比較的少なく、プロキシ設定の構造を理解する出発点として適しています。基本的な接続経路も比較的シンプルですが、実際の遅延はネットワークの往復時間、サーバーの負荷、DNS、通信状態に左右されます。「設定項目が少ない」からといって、どの環境でも最速とは限りません。暗号方式がサーバーと一致しなければ、ルールモードを切り替えても接続は通常復旧しません。プラグインが合わない場合は、パスワードだけを変更せず、双方のプラグインの種類とパラメーターを確認してください。iPhoneでは、選択したクライアントのコアがその暗号方式を実装しているか、サブスクリプションの変換時にプラグイン情報が失われていないかも確認します。

実用的な確認方法は、まず設定の詳細でアドレス、ポート、方式、パスワードの入手元を一つずつ確認し、プラグイン関連の項目があるかを見ることです。次に、プロキシグループに該当する出力先が登録されていることを確かめ、選択して接続し直します。「接続スイッチはオンなのに、リクエストがDIRECT経由のまま」という場合は、出力モードとルールを重点的に確認してください。暗号方式を変更し続ける必要はありません。同じ設定のほかの出力先は使えるのに、特定のShadowsocks出力先だけ使えない場合は、接続提供元の元の設定とその項目を優先して比較し、個別設定の問題をシステムのネットワーク権限の問題と取り違えないようにしましょう。

「プロトコルの種類」と「サービス提供元のサブスクリプション形式」は分けて考える必要があります。YAML形式のサブスクリプションに複数のプロトコルの出力先が含まれる場合もあります。一方、ss://で始まるリンクは通常、1つのShadowsocks接続だけを表します。前者にはルール、プロキシグループ、DNSが含まれることがありますが、後者は一般にクライアント側でプロキシグループに追加する必要があります。複数の接続をルールに沿って使いたい場合は、ファイル名だけで内容を判断せず、完全な設定ファイルなのか単一の共有リンクなのかを確認しましょう。

3. VMess：ユーザー情報と通信方式の組み合わせ

プロトコルの識別情報と通信方式は別

VMessはV2Rayエコシステムで生まれたプロトコルで、ユーザー識別情報などを使って接続を区別し、複数の通信方式と組み合わせられます。設定には通常、UUID形式のuuidがあり、場合によってはalterIdも含まれます。新しい設定ではalterIdが0であることが一般的ですが、サーバーの実際の設定に従ってください。古いサブスクリプションの値を機械的にゼロへ変更してはいけません。VMessの識別情報は接続の認証に使われ、TCPやWebSocketなどのネットワーク方式はデータの運び方を決めます。トラブルシューティングでは、両方の情報を確認する必要があります。

共有リンクでよく見かけるvmess://の内容は、直接読めるYAMLではなく、エンコードされた接続パラメーターの場合があります。クライアントに出力先の名前が表示されても、一定の範囲で解析できたことしか分かりません。アドレス、ポート、UUID、通信方式、TLSの有効・無効、パス、ホスト名がコア設定に正しく反映されているかを確認してください。特にWebSocketのパスとリクエストホスト名は、サーバー設定と一組になっていることが多く、一文字の違いでもハンドシェイクに失敗することがあります。TLSのサーバー名も提供元の指定に従い、出力先の表示名で代用しないでください。

接続全体を見て性能を比べる

設定項目の少ない基本的なShadowsocks接続と比べると、VMessではTLSやWebSocketなどの層が加わり、接続の確立に必要な手順が増えることがあります。ただし、待ち時間として目立つかどうかは、接続の再利用、ネットワークの往復時間、サーバーの実装によって変わります。WebSocketとTLSを有効にしたVMessを、それらの層を使わない接続と比べて、差をすべて「VMessは遅い」と説明するのは適切ではありません。同じ端末で実際の用途を比べましょう。ページを初めて開く時間、リソースを続けて読み込むときの挙動、Wi-Fiからモバイル回線に切り替えたあとの復旧状況を確認してください。

リソース消費もプロトコル名だけでは比較できません。暗号化処理、TLS、システムのネットワーク拡張、ログ記録、アクティブな接続数などが、CPUの起動やメモリ使用量に影響します。短時間のテストでは、画面の更新やシステムのバックグラウンド処理が差を覆い隠すこともあります。iPhoneでは、必要な設定がそろい、現在のコアが通信方式に対応し、接続が安定している構成を選ぶほうが、プロトコル名だけでバッテリー消費を予測するより確実です。読み込み後に通信方式の項目が欠けている場合は、よくあるWebSocketパスを推測で入力せず、元のサブスクリプションで変換結果を確認してください。

VMessの確認順：まずUUIDとサーバーアドレスを確認し、次にネットワーク方式を確認します。TLSを使う場合はサーバー名、WebSocketを使う場合はパスとリクエストホスト名を確認し、最後にプロキシグループとルールを確認してください。

同じサブスクリプションが別のクライアントでは使えて現在のクライアントでは使えない場合は、ノードの表示名だけでなく、両方のクライアントが認識した設定項目を記録して一つずつ比較しましょう。サブスクリプション変換ツールが実装ごとに異なる項目を生成し、表示名は同じでも実際の通信設定が変わることがあります。プロトコル項目の意味は用語集をご覧ください。接続スイッチ、設定の読み込み、ルールモードの順序を確認する場合は、クイックスタートに戻って手順を確認しましょう。

4. TrojanとVLESS：名前は似ていても必要な条件は異なる

TrojanのTLSとパスワード

TrojanはTLSを接続設計の中心に据えており、設定には通常、サーバーのアドレスとポート、パスワード、TLS用のサーバー名などが含まれます。クライアントの識別にはパスワードを使いますが、パスワードはTLS証明書の検証の代わりにはなりません。通常は提供元の情報に従い、証明書とサーバー名が一致するかも確認する必要があります。証明書の検証を無効にする方法を万能な修正策として使うと、本来必要な接続先の確認ができなくなります。証明書エラーが出たら、まず端末の時刻、入力したサーバー名、証明書の状態、サーバー設定を確認してください。

TrojanはWebSocketやgRPCなどの通信方式と組み合わせることもあります。その場合、「Trojanとパスワード」だけでは接続設定を再現できません。パスやサービス名、リクエストホスト名もサーバー側の設定に合わせる必要があります。モバイル端末ではTLSハンドシェイクが初回接続の処理量を増やすことがありますが、継続利用時の快適さはネットワークの安定性や接続の再利用に左右されます。TLSを使っているからといって、Trojanは必ずほかのプロトコルより電池を消費すると決めつけることはできません。頻繁に切断されてハンドシェイクを繰り返す場合は、安定した接続よりもその原因を優先して調べましょう。

VLESSの認証と外部セキュリティ層

VLESSもV2Ray関連のエコシステムで生まれましたが、VMessの単なる改名ではありません。VLESSはユーザー識別情報で接続を認証しますが、プロトコル自体では通信を暗号化しません。実際のセキュリティは、TLSなどの外部層や具体的な通信設定によって決まります。そのため、type: vlessを見たらUUIDだけでなく、通信方式、セキュリティ層、その設定項目も確認してください。特定のセキュリティ拡張を使うVLESS設定もあります。その拡張が使えるかどうかは、クライアントが採用するコアの対応状況によります。

この点はClashコアの種類を扱う際に特に重要です。オリジナルのClashとMeta、mihomoでは対応機能が異なります。YAMLファイルを開けたからといって、VLESS出力先が実際に動作するとは限りません。どちらのコアもVLESSを認識していても、特定の通信方式や拡張項目への対応状況は異なる場合があります。読み込む前に、クライアントの説明でコアの種類を確認してください。読み込み後は解析結果のメッセージ、出力先一覧、接続ログを確認します。「未対応のプロキシタイプ」や不明な項目が表示されたら、サーバーの認証情報を変更するのではなく、設定とコアの不一致をまず疑いましょう。

セキュリティ層と接続性を分けて確認する

TrojanとVLESSはどちらもTLSに関係する場合がありますが、確認する項目は異なります。TrojanではパスワードとTLS設定を、VLESSではユーザー識別情報、通信方式、外部セキュリティ層を確認します。どちらも、ポートに到達できてもハンドシェイクに失敗することがあります。Trojanではパスワードや証明書名の不一致、VLESSでは未対応の拡張項目や通信パスの不一致が原因かもしれません。まずサブスクリプションの元の項目を確認し、次に変換後のClash設定を調べ、最後にクライアントで編集できる設定を変更してください。この順で確認すれば、「読み込み時に項目が欠落した」問題を「プロトコル自体が使えない」問題と混同せずに済みます。

設定元が複数のプロトコルを提供している場合、より新しい名前のプロトコルに乗り換える必要はありません。サーバーから提供された設定一式、クライアントの対応範囲、利用するネットワークの安定性、自分の用途を基準に選びましょう。日常的な接続だけが目的なら、まずダウンロードページのClash Plus iOSからクライアントを確認し、読み込む設定がどのプロトコルに対応しているかを調べてください。プロトコル名の人気は、設定が有効である証拠にはなりません。

5. Hysteria 2とTUIC：まずUDPの利用条件を確認

QUICを使うと比較の前提が変わる

Hysteria 2とTUICはどちらもUDPベースのQUIC接続を利用しますが、別々のプロトコルであり、認証項目や設定形式は互換性がありません。QUICは接続の確立、セキュリティハンドシェイク、多重化などの機能をまとめています。適切なネットワークでは、一部の接続確立の待ち時間を減らし、単一のパケットロスで複数の通信ストリームがまとめて滞るのを避けられる場合があります。ただし、QUICを使うからといって、どの接続環境でも速くなるわけではありません。端末とサーバーの間でUDPが正常に通る必要があります。公衆Wi-Fiや企業ネットワーク、特殊な接続環境ではUDPが制限され、接続に失敗したり再試行を繰り返したりすることがあります。

Hysteria 2はHysteriaプロジェクトの効率的な通信を重視する設計を引き継いでおり、設定にはサーバーアドレス、認証情報、TLS関連の項目がよく含まれます。帯域幅や通信動作に関する設定もあり、それらを受け付ける方法はクライアントやコアのバージョンによって異なります。TUICもQUICを使ったプロキシ接続を確立し、通常はユーザーIDと認証情報が必要です。輻輳制御などのオプションが含まれる場合もあります。これらは接続動作を調整する項目であり、「数値を大きくすれば速くなる」設定ではありません。サーバーから指定されていない場合は、別の接続の値をコピーして試さないでください。

モバイル回線でのネットワーク切り替えと再接続

iPhoneでWi-Fiとモバイル回線を切り替えると、ネットワークアドレスやルート、システムのネットワーク拡張の状態が変わることがあります。条件によってはQUIC接続が比較的早く復旧する場合がありますが、クライアントの実装、サーバーの設定、システムのスケジューリングも重要です。プロトコル設計上の利点が必ず得られるとは限りません。ネットワーク切り替え後の最初のリクエストが成功するか、手動で再接続する必要があるか、長時間画面をロックした後に接続が復旧するかを確認しましょう。特定のWi-Fiだけで失敗し、モバイル回線では正常な場合は、サブスクリプション全体を変更する前に、そのWi-FiでUDPが使えるかを調べてください。

UDPを調べるときは、「サーバーに到達できない」のか「UDP経路が不安定」なのかを区別します。どのネットワークでも同じ設定で接続できない場合は、アドレス、ポート、認証、TLS情報を確認してください。特定のネットワークだけで失敗する場合は、ネットワーク条件を優先して比較します。証明書の検証要件をむやみに下げたり、認証項目を手当たり次第に変更したりしても、制限されたUDP経路は直りません。設定にTCP系とQUIC系のプロトコルが両方含まれる場合は、同じ場所・時間帯でそれぞれ試し、接続一覧で選択状態が表示されるかだけでなく、実際の用途をこなせるか確認してください。

設定の互換性について、Hysteria 2をHysteriaの旧形式と同じものとして扱うことはできません。TUICもQUICを使うからといって、Hysteria 2の設定方法を流用できるわけではありません。サブスクリプション変換サービスが一部の項目しか出力しないと、読み込み後に名前は表示されても接続できないことがあります。サブスクリプションの出力形式が利用中のコア向けかを確認し、プロトコルの種類、認証項目、TLS名が欠けていないかを調べてください。コアがプロトコルに対応していない場合、YAMLのインデントを直しても実装は追加されません。

6. 速度・リソース消費・iPhoneのバッテリー

初回応答・転送速度・安定性を分けて考える

「接続速度」には少なくとも3つの意味があります。接続の確立にかかる時間、新しいページを開いたときの初回応答時間、継続的な転送で維持できる速度です。これらの結果が同じ方向に変化するとは限りません。ハンドシェイクの手順が少ないプロトコルでも、サーバー回線が混雑していればページの表示は遅くなります。接続の確立に時間がかかっても、その後のリクエストで接続を再利用でき、連続した閲覧が安定するプロトコルもあります。比較するときは端末、ネットワーク、サーバーの条件をそろえ、最初のリクエストと連続したリクエストを分けて記録してください。DNSの待ち時間やアプリ自体の読み込み時間をプロトコルの遅延と取り違えないようにしましょう。

ネットワークの品質が変われば、比較結果の順位が逆転することもあります。パケットロスは再送や輻輳制御に影響します。TCPとQUICでは複数の並行リクエストの処理方法が異なりますが、どちらも実際に通信できる経路が必要です。UDPが不安定な場合、Hysteria 2やTUICがTCPベースの設定より快適とは限りません。Webページでは短いリクエストが多数発生し、動画再生では継続的な転送と中断後の復旧が重要です。プロトコルを選ぶ前に、普段どの問題が多いかを考えてください。最初の表示が遅いのか、長時間の接続が切れやすいのか、特定のネットワークで接続できないのかによって、確認の順番は異なります。

バッテリー消費はプロトコル名だけでは決まらない

iOSのクライアントは通常、システムのネットワーク機能を使って対象の通信を処理します。端末のバッテリー消費は、無線の状態、画面の明るさ、バックグラウンドアプリ、DNS問い合わせ、ログの詳細度、接続の再試行、暗号化処理などの影響を受けます。プロトコルの設定項目数から消費量を直接推定することはできません。少数の接続を安定して維持する設定は、頻繁に失敗して再試行を繰り返す「軽量なプロトコル」よりも省電力になる場合があります。一方、長時間の連続転送では無線機能とプロセッサーが動作し続けます。バッテリー消費を比べるときは、画面やアプリの使い方をできるだけそろえ、普段の利用に近い状態で一定時間観察してください。数分間の残量変化だけで結論を出さないようにしましょう。

バッテリー消費が多い場合は、まず実際の動作を確認します。出力先が何度も再接続していないか、接続エラーのログが出続けていないかを見ます。次に、サブスクリプションの自動更新間隔、DNS設定、バックグラウンドの通信を確認してください。特定の設定だけで問題が起きるなら、安定している設定と通信方式やエラー内容を比べます。すべての設定で同じ症状が出る場合は、システムのネットワーク拡張、ほかのアプリの通信、現在の接続環境を確認しましょう。省電力のためにTLS検証をむやみに無効にしたり、すべてのルールをDIRECTに変更したりしてはいけません。接続の意味が変わるだけで、消費の原因が解消したとは限りません。

実際の用途で小規模に比較する

再現性のある比較手順として、同じネットワークで設定に問題がない2つの出力先をそれぞれ選び、接続が確立するのを待ってから、普段使うWebサイトやアプリを順番に開きます。初回の読み込み、連続した読み込み、ネットワーク切り替え後の復旧を観察してください。DNS、ルール、プロトコル、サーバーを同時に変更すると、どの変更が結果に影響したのか分からなくなります。比較後は、用途に合い、より安定している設定を使えば十分です。速度測定の一回の最高値を追い求める必要はありません。DNSモードが初回リクエストに影響する理由は、Fake-IPとDNSマッピングの解説をご覧ください。

どの環境にも当てはまる「最速」や「最も省電力」なプロトコルはありません。まず接続できることを確認し、同じネットワーク・近い用途・同じ設定で比較してください。再試行が続く場合は、速度の順位を付ける前に問題を解決しましょう。

7. オリジナルのClash、Meta、mihomoの関係

オリジナルの設定形式から拡張コアへ

オリジナルのClashでは、幅広く使われるYAMLの設定構造が確立されました。出力先、プロキシグループ、ルール、DNSなどのトップレベル項目をまとめた設定をコアが読み込みます。その後、この仕組みを拡張したプロトコルやネットワーク機能を備えるClash.Metaが登場し、mihomoはこのコアの系譜で使われる名称となりました。設定には継承関係がありますが、「オリジナルの設定と完全に同じ」「拡張設定もそのまま旧版で開ける」とは限りません。設定ファイルを読み込むために必要な機能は、実際に使われている項目と出力先の種類によって決まります。

たとえば、基本的なShadowsocks出力先、一般的なプロキシグループ、ルールだけを使う設定は、VLESS、Hysteria 2、特定のDNS拡張を含む設定より、コア間で移行しやすい傾向があります。ただし、同じプロトコルでも拡張項目やルールの種類、デフォルトの動作が異なることがあります。オリジナルのClashが、Metaやmihomoで後から追加されたすべてのプロトコルに対応していると考えてはいけません。クライアントの画面に「Clash」と表示されていても、実際に使われるコアや内蔵プロトコルの対応状況を確認する代わりにはなりません。

設定の互換性は項目ごとに確認する

YAMLを確認するときは、まずトップレベルの構造を見てから、出力先のtypeと、その種類に固有の項目を確認します。proxy-groupsが参照する出力先の名前は、proxiesで定義された名前と一致していなければなりません。rulesが最終的に指定するプロキシグループや出力先も存在する必要があります。コアがプロキシの種類を認識しない場合、項目名を別の綴りに変えるだけでは互換性を確保できません。個別の設定項目名だけが変わっている場合は、対象コアの設定ドキュメントを参照し、デフォルト値の変更にも注意して調整してください。移行時は元のファイルを残し、コピー上で一項目ずつ変更するほうが、利用中の設定を直接上書きするより安全です。

以下は、構造を確認するための短いYAML例です。出力先、プロキシグループ、ルールの参照関係を示しています。例にあるドメイン名やパスワードは項目の説明用です。実際に接続するには、接続提供元から指定された設定一式に置き換えてください。この構造にはクライアントのシステム設定すべてが含まれているわけではなく、すべてのコアで任意の追加項目が使えることを示すものでもありません。

mode: rule
proxies:
  - name: Sample-SS
    type: ss
    server: proxy.example.net
    port: 443
    cipher: aes-128-gcm
    password: your-password

proxy-groups:
  - name: SELECT
    type: select
    proxies:
      - Sample-SS
      - DIRECT

rules:
  - MATCH,SELECT

例のMATCH,SELECTは、ほかのルールに一致しなかったリクエストをSELECTプロキシグループに渡す設定です。SELECTからは例の出力先またはDIRECTを選べます。これは参照関係を示す例であり、すべてのリクエストに同じルールを使うことを推奨するものではありません。実際のサブスクリプションには、より細かなドメインやネットワークのルールが含まれることが多く、ルールセットが更新される場合もあります。設定を読むときは最後に評価されるルールからさかのぼり、ルールがどのグループを参照しているか、グループにどの出力先が含まれるか、選択した出力先のプロトコル項目がそろっているかを確認しましょう。ノード名だけを見るより、参照の誤りを見つけやすくなります。

クライアントはOSとコアの対応状況で選ぶ

ダウンロードページでは、Windows、macOS、Android、iOS、Linux向けのクライアントを紹介しており、対応プラットフォームではClash Plusを最初に案内しています。ほかのクライアントの対応範囲は、それぞれの実装を確認してください。デスクトップではClash Verge RevやFlClash、AndroidではClash Meta for Androidなども選べますが、同じサブスクリプションでも読み込み結果はクライアントごとに確認が必要です。iPhone向けのクライアントを選ぶ際は、iOSのダウンロードページとクライアントの説明を確認し、サブスクリプションが必要とするプロトコルに現在のコアが対応しているかを調べてください。デスクトップ版の機能からスマートフォン版の対応状況を推測しないようにしましょう。

port、dns、proxiesからrulesまで、ファイル全体の構造を詳しく知りたい場合は、YAMLの構造を項目ごとに解説をご覧ください。この章で押さえておきたいのは、ファイルの拡張子やクライアント名ではなく、「対象のコアが、設定で実際に使われているすべての項目を認識し、正しく実行できるか」で互換性を判断することです。

8. サブスクリプション形式の互換性と用途別の選び方

完全な設定ファイルと単一の共有リンクを区別する

「サブスクリプション」は設定の取得・更新方法を指すもので、特定のプロキシプロトコルを指す言葉ではありません。サブスクリプションURLからClash形式のYAML全体が返る場合もあれば、共有リンクが複数並んだテキストや、別のクライアント向けの形式が返る場合もあります。ss://やvmess://などの単一リンクには、通常、1つの出力先の接続パラメーターだけが含まれます。完全なYAMLには、プロキシグループ、ルール、DNS、更新に必要なほかの情報が含まれることもあります。クライアントがURLから内容をダウンロードできても、現在の読み込み機能がその形式を正しく認識できるとは限りません。

読み込みに失敗したら、まずURLからファイルの内容が返っているかを確認してください。ログインページやエラーページが返っている場合もあります。次に、提供元が案内する出力形式がClash形式の設定に対応しているかを確認しましょう。読み込み後に出力先の数がおかしい、名前は表示されるのに通信項目が欠けているといった場合は、サブスクリプションの元データとクライアントの解析結果を確認し、必要に応じて現在のコアに合う形式での出力を依頼してください。別のクライアント向けファイルの名前をconfig.yamlに変えても、項目は変換されず、プロキシグループも追加されません。iPhoneで複数のProfileを追加・更新・切り替える方法は、設定ファイルの管理ガイドをご覧ください。

プロトコル名の順位ではなく、利用条件で選ぶ

初めて使う場合は、クライアントに完全に読み込めて、設定項目を提供元の情報と一つずつ照合できる構成を選びましょう。Shadowsocks、VMess、Trojanの出力先が安定して使えているなら、プロトコルを変えるためにルール全体を作り直す必要はありません。提供元からVLESSの設定が案内された場合は、通信方式とセキュリティ拡張を現在のコアがサポートしているか確認します。Hysteria 2やTUICの場合は、普段使うWi-Fiとモバイル回線のそれぞれでUDP接続を確認してください。ネットワークを頻繁に切り替える場合は、プロトコルの一般的な説明だけでなく、切り替え後の復旧状況も選ぶ基準に含めましょう。

Web閲覧では初回リクエストとDNSの応答が体感に影響しやすく、継続的な転送では接続の安定性が重要です。長時間の待機では、不要な再試行やバックグラウンドでの頻繁な起動がないかを確認しましょう。いずれの用途も、プロトコル名だけで一律の答えは出せません。選ぶ順序は、コアの対応状況を確認し、設定項目を照合し、普段使うネットワークで接続し、実際の用途を試し、復旧状況とバッテリー消費を観察するのが実用的です。一度に変更する条件は一つにし、比較できる結果を残してください。どこかの段階で失敗したら、その問題を解決してから速度を比べましょう。

元に戻せる設定を残す

設定を変更する前に、正常に動作しているProfileを保存してください。新しいサブスクリプションは別の設定として読み込み、出力先、プロキシグループ、ルールが正常に動くことを確認してから、普段使う設定に切り替えます。更新後に接続できなくなった場合は、以前の設定に戻し、更新前後のプロトコル、サーバー項目、プロキシグループの参照を比較すれば、設定内容の変更かネットワーク環境の変化かを判断しやすくなります。サブスクリプションを更新してもクライアントのコアが同時に更新されるわけではありません。新しい設定に未対応のプロトコル項目が含まれる場合は、対応する実装のクライアントを選ぶか、提供元から互換性のある形式で出力してもらう必要があります。

操作手順はクイックスタートで確認できます。インストール方法はクライアントを入手をご覧ください。接続スイッチ、設定の読み込み、ルールモードについて分からないことがあれば、ヘルプセンターをご利用ください。このガイドは各操作の際に繰り返し参照できます。問題がプロトコル、通信方式、コア、サブスクリプション形式のどれに当てはまるかを確認し、該当する章で項目を調べましょう。すべての設定を一度に変更する必要はありません。