Clashプロトコルとmihomoカーネルの選定ガイド

再利用できるプロトコル選定モデルを作る

まずプロトコル、トランスポート、クライアントを区別する

Clashの設定画面に表示されるSS、VMess、Trojan、VLESS、Hysteria2、TUICはノードの接続方式です。一方、Clash Plus、Clash Verge Rev、FlClashなどはグラフィカルクライアントを指し、mihomoは設定の解析、接続の確立、ルールの実行を担うカーネルです。3者は異なる階層にあります。クライアントは操作画面とシステム連携の方式を決め、カーネルは設定構文とプロトコル機能を決め、プロトコルは個々のプロキシ接続におけるハンドシェイク、暗号化、多重化、データ転送を決めます。これらを混同すると、「クライアントを変えれば必ず速くなるのか」「サブスクリプションをインポートできればノードも使えるのか」といった誤判断につながります。グラフィカルインターフェースを変えても回線条件は通常変わりませんが、クライアントに含まれるカーネルのバージョン、デフォルトDNS、TUN実装、接続パラメータによって最終的な挙動が変わる場合があります。

プロトコル選びは、単純な速度ランキングではありません。実際の接続体験は、サーバーの処理性能、クライアント端末の性能、ネットワークの往復遅延、パケットロス、トランスポート層の挙動、ドメイン解決経路、ルールの適用結果によって決まります。プロトコルが制御するのはその一部です。たとえば安定した有線ネットワークでは従来型のTCPプロトコルが安定しやすく、基地局の切り替えが多くランダムなパケットロスがあるモバイルネットワークでは、UDPベースで輻輳制御を自律的に管理する方式のほうが早く復旧する場合があります。ただし、継続動作、キープアライブ、再送の方式によっては電池消費が増えることもあります。ネットワーク条件を離れて「最速のプロトコル」を語っても、再現性のある結論にはなりません。

4つの質問で候補を絞る

1つ目は、現在のクライアントカーネルが目的のプロトコルと必須フィールドをサポートしているか確認することです。原版Clashの機能範囲は早い段階で固定され、後から登場したVLESS、Hysteria2、TUICなどは主にMeta系統とmihomoによって拡張されました。2つ目は、サブスクリプションに完全なノードパラメータが含まれているか、それとも名前とサーバーアドレスだけなのかを確認します。同じプロトコル名でも設定をそのまま交換できるとは限りません。認証情報、TLSサーバー名、トランスポート種別、UDP対応、証明書検証のスキップなどがハンドシェイクに影響します。3つ目は主な利用プラットフォームを明確にすることです。デスクトップではシステムプロキシ、TUNによる全体接管、長時間の安定性が重視されます。モバイルではバックグラウンド維持、ネットワーク切り替え、バッテリー制限も評価が必要です。4つ目は、主な通信が短時間のウェブ閲覧、継続的なダウンロード、リアルタイム音声・動画、大量の同時リクエストのどれかを判断することです。接続方式によって、ハンドシェイクのコスト、ヘッドオブラインブロッキング、多重化への影響が異なります。

1. まず解析できることを確認する

   クライアントにインポートした後、ノード種別が認識されているか確認します。設定ログに未知の種別や不足フィールドが表示されていないことが必要です。

2. 次に接続できることを確認する

   同じネットワークでハンドシェイク、ウェブアクセス、継続転送をそれぞれテストし、1回の遅延測定だけで判断しないでください。

3. 最後に長時間運用への適性を確認する

   ネットワーク切り替え、スリープからの復帰、バックグラウンドでの電池消費、ルール適用を観察し、短時間のピーク値を安定した結論と混同しないでください。

テスト条件をそろえる

プロトコルを比較する際は、クライアント、カーネル、サーバー地域、テスト時間帯、DNS設定を固定し、帯域を継続的に消費する同期アプリも同時に動かさないでください。まず直結ネットワークの基礎状態を記録し、その後候補ノードを1つずつテストします。遅延テストは主に測定リクエストの往復時間を示すもので、ページの表示速度とは異なります。ダウンロードのピーク値も、低品質なネットワークからの復旧力を表しません。より信頼できる方法は、複数のリソースを含むウェブページを何度も開く、数分間安定してデータを転送する、Wi-Fiとモバイルネットワークを切り替えて接続の復旧を観察する、という3種類の作業を連続して行うことです。差が小さい場合は、理論上の機能のために設定を複雑化するより、設定が簡単でクライアントの対応が成熟しているほうを選ぶべきです。

SS、VMess、Trojan、VLESS、Hysteria2、TUICの設計上の選択

SS：シンプルな構造で幅広く対応

Shadowsocksは通常SSと略され、少ないプロトコル層で暗号化プロキシを実現する設計です。ノード設定は主にサーバー、ポート、パスワード、暗号化アルゴリズムで構成され、フィールド数も比較的少ないため、異なるクライアントやサブスクリプション形式へ移行しても整合性を保ちやすい特徴があります。現在の実装では通常AEAD系暗号化アルゴリズムを使います。アルゴリズムを選ぶ際はクライアントとサーバーの双方が対応していることを確認してください。名称が似ていても実装範囲の異なるアルゴリズムは、自由に置き換えられません。SSの利点は実装が成熟し、ハンドシェイクの負担が小さく、対応端末が多いことです。設定項目を減らしたい場面に適しています。一方、SS自体は複雑な通信偽装層を定義していません。追加プラグインや別のトランスポートカプセル化を使う場合は互換性の要件が増えるため、「SS対応」を「すべてのSS拡張に対応」と解釈してはいけません。

VMessとVLESS：一体型認証から軽量なプロトコル層へ

VMessはユーザー識別子、認証、接続処理をプロトコル内に組み込みます。一般的な設定にはUUID、トランスポートネットワーク、TLS、Host、Pathなどが含まれます。複数のトランスポート方式を統一的に管理するクライアントエコシステムから生まれたため、過去のサブスクリプションには今も多く残っています。問題は使えないことではなく、パラメータの組み合わせが多いことです。WebSocket、HTTP系トランスポート、gRPC、通常のTCPではフィールドの位置が異なり、サブスクリプション変換時にパス、ホスト名、サービス名が失われやすくなります。VMessを調べるときはトランスポート種別から照合し、UUIDとポートだけを比較しないでください。

VLESSはプロトコル層をより軽量にし、機密性とサーバー認証をTLSなどの外側の仕組みに任せる構成が一般的です。つまり、VLESSを選ぶだけで完全な暗号化が自動的に有効になるわけではありません。クライアント側でTLS、サーバー名、証明書検証、選択したトランスポートを正しく処理する必要があります。プロトコルのオーバーヘッドが明確で、さまざまなトランスポートと組み合わせやすい反面、設定の完全性への依存度が高い方式です。サブスクリプション変換ツールがサーバーとUUIDだけを残し、flow、server name、transport、Reality関連のフィールドを落とすと、ノードはインポートできてもハンドシェイクに失敗します。mihomoはVLESSを広くサポートしていますが、実際の設定フィールドと現在のカーネルが認識できる構文を基準に確認してください。

Trojan：TLS接続を基盤とする直接的なモデル

Trojanの一般的な設定は、パスワード、TLSサーバー名、証明書検証を中心に構成され、データはTLS接続上で運ばれます。確認手順も比較的わかりやすく、まずドメインと証明書の関係を確認し、次にパスワードとポート、最後にUDPの有効化を確認します。Trojanが「どんな状況でもVMessより速い」という意味ではありません。同じネットワーク経路と近いトランスポートを使う場合、差は回線の変動より小さいこともあります。実用上の価値は、設定モデルが明確で、主要なMetaおよびmihomoクライアントの対応が成熟していることです。IPアドレスで接続しながらTLSでドメインの識別を要求する場合は、正しいserver nameを保持してください。サーバーアドレスをすべてのTLSフィールドに機械的にコピーしてはいけません。

Hysteria2とTUIC：UDPトランスポートと低品質ネットワークからの復旧に対応

Hysteria2はQUIC体系を基盤に接続を構成し、アプリケーション側で輻輳制御とパケットロス環境でのスループット回復を重視します。往復遅延が大きい、帯域が変動する、断続的なパケットロスがあるネットワークに適していますが、効果はUDPの到達性、サーバーパラメータ、適切な帯域設定に左右されます。上りまたは下りの性能を実際のネットワークより大幅に高く設定しても速度が増えるわけではなく、キューイングや帯域の奪い合いを招く場合があります。設定時は、認証パスワード、TLSサーバー名、ポートホッピング、難読化などのオプションが双方で有効になっているかも確認してください。

TUICもQUICとUDPを基盤とし、多重接続、認証、ネットワーク変化時の接続継続性を重視します。mihomo互換設定でよく見られ、UUID、パスワード、輻輳制御アルゴリズム、UDPリレーモード、証明書オプションなどのフィールドを含むことがあります。TUICとHysteria2は、どちらもUDPを使うからといって互換プロトコルではありません。ハンドシェイク、認証、パラメータ名、サーバー実装が異なります。選択時はサーバーが実際に提供している方式を確認し、クライアント上でノード種別を手動変更しないでください。モバイルネットワークでは接続復旧が速い場合がありますが、継続的なキープアライブ、活発なUDPセッション、システムのバックグラウンド制御も電池消費に影響します。

接続速度、安定性、リソース使用量を正しく比較する方法

ハンドシェイクの速さと継続スループットは別の指標

ウェブページの初回表示は、DNS検索、TCPまたはQUIC接続、TLSハンドシェイク、最初のリクエストへの応答時間の影響を受けやすくなります。一方、大容量ファイルの転送は、輻輳制御、回線容量、継続的なパケットロスの状態に大きく左右されます。SSはプロトコル層がシンプルで、通常は複雑な追加ハンドシェイクを発生させません。Trojan、TLSを有効にしたVMessやVLESSではTLS処理が必要ですが、接続の再利用とセッション再開により後続リクエストのコストを下げられます。Hysteria2とTUICはQUICで安全な接続を確立し、初回接続には同様にハンドシェイクが必要ですが、確立後は1本の接続で複数のストリームを運べます。したがって、「遅延テストを1回実行する」だけではごく一部の挙動しか見られず、継続ダウンロードや複数リソースを含むページの体験を完全には表せません。

TCPのヘッドオブラインブロッキングでは、同じ接続内のパケットロスによって後続データが再送待ちになることがあります。QUICはストリーム単位で転送を処理するため、1つのストリームのロスが他のストリームへ及ぼす影響を抑えられます。ただし、基盤ネットワークのUDP品質が低ければ、理論上の利点が現れない場合もあります。ネットワークによってはUDPセッションの保持時間が短く、アイドル後に再度ハンドシェイクが必要になることがあります。また、大量のUDPセッションを処理しきれないルーターもあります。選定時は実際のアプリケーションを観察してください。短時間の接続が頻繁に失敗する、長時間転送の速度が変動する、スリープからの復帰が遅い、といった症状はそれぞれ異なる問題を示しており、すべてをプロトコル名のせいにすることはできません。

CPU、メモリ、接続数

リソース使用量はまずカーネルの実装とルール規模に左右され、プロトコルはその次です。大量のルールセット、複雑なDNS処理、TUNによるトラフィックの接管、接続スニッフィング、ログレベルは、プロトコル暗号化そのものより多くのリソースを使うことがあります。SSで最新のAEADアルゴリズムを使う場合、デスクトップCPUなら通常は効率よく処理できますが、古い低消費電力端末ではアルゴリズムのハードウェアアクセラレーション対応がCPU使用率に影響します。VMessはプロトコル処理と多層トランスポートの組み合わせによって、特にWebSocket、TLS、多重化を重ねた場合に処理量が増えることがあります。TrojanとVLESSのコストはTLS実装と選択したトランスポートに密接に関係します。Hysteria2とTUICはQUICの状態、確認応答、輻輳制御を維持するため、高速環境やパケットロス環境ではCPUを多く使う場合がありますが、スループット回復が優れていればタスク完了までの時間を短縮できることもあります。

メモリ使用量はクライアントのメインプロセスだけで判断できません。グラフィカルインターフェース、WebView、システムトレイ、ログキャッシュ、カーネルが同時に動作している場合があります。Clash Plus、Clash Verge Rev、FlClashを比較する際は、同じ設定、同じ稼働時間、同じ接続数で観察し、UIプロセスとmihomoカーネルプロセスを区別してください。アイドル時の使用量が少ないクライアントでも、数十万件のルールを読み込んだ後に同じとは限りません。1接続あたりのプロトコル負荷が小さくても、大量の同時接続では累積コストが発生します。ルーターや小型サーバーでは、ルールプロバイダーの数を減らし、不要な詳細ログを無効にし、接続の多重化と同時実行数を制御するほうが、プロトコルを何度も変更するより効果的です。

再現性のある3段階テスト

第1段階は接続確立のテストです。古い接続を切断してから複数の異なるドメインへ連続アクセスし、初回の待ち時間や断続的なハンドシェイク失敗がないか記録します。第2段階は安定転送のテストです。数分間の速度推移、CPU使用率、接続リセットを観察し、一瞬のピーク値だけを記録しないでください。第3段階は復旧のテストです。端末をスリープさせて復帰するか、Wi-Fiとモバイルネットワークを切り替え、ノードが自動復旧するか、DNSが継続して機能するか、古い接続が正しく整理されるかを確認します。各候補プロトコルは少なくとも2回繰り返し、ルールモードをそろえてください。異常値が出た場合は、ログのtimeout、TLS、DNS、UDPエラーの種類を先に確認してから、比較結果に含めるか判断します。

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

電池消費は暗号化だけでなく、継続的な処理から生じる

モバイル端末でClash系クライアントを動かす場合、電池消費はネットワーク通信、CPUのウェイクアップ、VPNまたはTUNによる接管、DNS検索、ルール照合、ログ書き込み、システムのバックグラウンドスケジューリングによって決まります。プロトコル暗号化はその一要素にすぎません。アプリが大量の接続を維持し続けたり、頻繁にヘルスチェックを行ったり、短い間隔で複数ノードをテストしたりすると、実際の通信量が少なくても端末が低消費電力状態から何度も復帰することがあります。反対に、計算量が多少多くても接続を安定維持できるプロトコルは、頻繁に切断と再接続を繰り返すシンプルなプロトコルより実際の消費電力が少ない場合があります。そのため、数分間のシステム電池残量だけで判断せず、1回の完全な利用サイクルで観察してください。

SS、Trojan、VMess、VLESSは、TCPまたはTCPベースのトランスポートで動作することが多い方式です。システムはTCP接続の状態管理に成熟しており、アイドル接続は比較的低活動状態に移行しやすい一方、モバイルネットワークの切り替え後は古い接続がタイムアウトするか、再確立されるまで待つことがあります。Hysteria2とTUICはUDPとQUICを基盤とし、一定の条件ではネットワーク変化をより速く処理できますが、より活発な確認応答、キープアライブ、輻輳制御によってセッションを維持する場合もあります。消費電力はクライアント実装、keep-aliveパラメータ、ネットワーク品質、システムのUDP処理に左右され、特定のプロトコル系統が必ず省電力、または必ず高消費電力だと一概には言えません。

Androidのバッテリー最適化とバックグラウンド制限

Androidでは、メーカーによってバックグラウンドアプリ、VPNサービス、自動起動の扱いが大きく異なります。画面ロック後にクライアントがシステムによって停止されると、通知が消える、ネットワークにアクセスできない、アプリを再び開くと復旧するといった症状が現れます。この場合は、すぐにノードプロトコルを変えるのではなく、まずシステムのバッテリー最適化、バックグラウンド動作、VPN常駐通知、自動起動の権限を確認してください。Clash Plus、Clash Meta for Android、FlClashでは画面の場所が異なりますが、判断手順は同じです。カーネルが動作しているか、VPNインターフェースが存在するか、ノード接続ログに問題がないかの順に確認します。カーネルが繰り返し再起動する場合は、ヘルスチェックの頻度を下げ、一時的に詳細ログを無効にし、設定に過大なルールセットが含まれていないか確認します。

プロキシグループもよくある電池消費の原因です。url-testは設定した間隔で複数の候補ノードを測定します。ノード数が多く、間隔が短いと、ネットワークのウェイクアップが継続的に発生します。fallbackは利用可能性を監視し、load-balanceはより多くの接続を同時に維持する場合があります。モバイル端末で主に固定ノードを使うなら、候補数を減らし、テスト間隔を適度に延ばしてください。これらの方式の違いについては、Clashプロキシグループの種類を詳しく解説した記事も参照できます。ルールプロバイダーの更新間隔も適切に設定し、短時間に変化の少ないリストを繰り返し取得する必要はありません。

iOSとシステムVPNのライフサイクル

iOSクライアントはシステムが提供するネットワーク拡張機能を通じて動作するため、アプリの画面を閉じても必ずしもプロキシ接続が停止したとは限りません。実際の状態はシステムのVPN表示とクライアントカーネルの状態で確認してください。Clash PlusはiOS版をApp Storeから提供しています。設定時は、システムが初めてVPNを確立する際に表示する許可を確認してください。Wi-Fi切り替え後に一時的にドメインを解決できない場合は、まずシステムのネットワーク経路が安定するまで待ち、その後DNSとノードの再接続を確認します。頻繁に手動でオン・オフを切り替えると、問題の再現が難しくなることがあります。バックグラウンド動作はシステムが一元管理し、ユーザーが調整できる項目はAndroidより少ないため、設定をシンプルに保ち、高頻度の測定と不要なログを減らすことを優先してください。

システム統計で長期的に観察する

プロトコルの電池消費を評価する際は、日常の利用強度が近い2つの時間帯を選び、それぞれ候補プロトコルを動かします。画面の明るさ、ネットワーク種別、プロキシグループ、バックグラウンドアプリをおおむねそろえてください。システムのバッテリー画面で、前面・バックグラウンドの稼働時間とネットワーク活動を確認し、総残量の割合だけを比べないようにします。異常な消費が見られた場合は、クライアントの再起動、接続失敗、ノード測定の増加、電波の弱さを伴っていないかを確認します。電波が弱いと携帯通信モデムの送信出力が増え、プロキシプロトコルそのものより大きな影響を与えることがあります。詳しい確認手順はClashモバイル版の異常な電池消費を調べる方法をご覧ください。

原版Clash、Meta、mihomoのカーネル系統

原版Clash：設定の基礎と互換性の基準

原版Clashは、proxies、proxy-groups、rules、DNS、ルールプロバイダー、コントロールインターフェースなどを含む、広く使われてきたYAML設定構造を確立しました。多くのサブスクリプション変換ツールやグラフィカルクライアントも、これらのフィールドを互換性の基準としています。SS、VMess、Trojanなど主要な種別には成熟した構文がありますが、プロジェクトのメンテナンス状態と機能範囲はすでに固定されています。後発プロトコルや複雑なネットワーク機能が標準で存在すると考えてはいけません。ある設定が「Clash形式」と表示されていても、それはこの設定系統を採用していることを示すだけで、原版カーネルがすべてのノードを解析できる保証にはなりません。

原版の構文にも重要な価値があります。基本的なプロキシグループ、ドメインルール、IPルール、MATCHルールは移植性が高く、これらの汎用機能だけを使う設定なら、派生カーネル間の移行も比較的スムーズです。問題が起きやすいのは、拡張ノード種別、ルール構文、高度なDNSオプション、TUNパラメータ、プロトコル固有フィールドです。そのため互換性は、ファイル拡張子がYAMLかどうかや、トップレベルのキー名だけで判断できません。ノードのtype、プロキシグループの挙動、拡張ルールをカーネルが個別に認識できるか確認してください。

Clash Meta：新しいプロトコルと高度なネットワーク機能に対応する系統

Clash Metaは原版の設定モデルを拡張し、VLESS、Hysteria、Hysteria2、TUIC、WireGuardなどの種別に対応するとともに、DNS、ルール、TUN、スニッフィング、トランスポートパラメータを強化しました。古い資料では、これらの機能を持つカーネルをまとめてMetaと呼ぶことがあります。ユーザーにとって重要なのは系統の歴史を暗記することではなく、Metaの設定には原版が認識できないフィールドが含まれる可能性を理解することです。原版Clashしか対応しないクライアントにMetaのサブスクリプションをインポートすると、一部のパラメータが無視されるか、読み込み時にエラーになる場合があります。逆方向の移行は通常容易で、基本的な原版設定の多くはMeta系カーネルで読み込めますが、デフォルト動作が異なる場合はあります。

mihomo：現在広く使われている継続実装

mihomoはMeta系の機能を引き継いで保守しており、Clash Plus、Clash Verge Rev、FlClashなど現代的なクライアントでよく採用されるカーネルです。Clash設定の主要な構成方式を維持しながら、新しいプロトコル、ルールセット、TUN、DNS関連機能にも対応しています。名称が変わったからといって設定を最初から書き直す必要はなく、多くのMeta設定を継続利用できます。ただし「通常は互換性がある」ことは、過去のすべてのフィールドが永久に同じ意味を持つことを意味しません。クライアントを更新したり設定を移行したりした後は、起動ログの非推奨通知、未知のフィールド、解析エラーを確認し、変換ツールにファイル全体を書き換えさせるのではなく、現行ドキュメントに合わせて調整してください。

グラフィカルクライアントとカーネルは、必ずしも固定の組み合わせではありません。カーネルを切り替えたりカーネルコンポーネントを更新したりできるクライアントもあれば、カーネルをアプリのパッケージに同梱しているクライアントもあります。トラブルシューティングでは、「バージョン情報」「カーネル」「ログ」などの画面で実際に動作している実装を確認し、クライアント名だけで推測しないでください。Clash for WindowsとClashX Metaはメンテナンスが終了しており、一部の古い設定は読み込める場合がありますが、新しいプロトコルの互換性を検証する唯一の環境としては適しません。VLESS、Hysteria2、TUICが必要な場合は、mihomoまたはMetaの機能に明確に対応するクライアントを優先してください。

mixed-port: 7890
mode: rule
ipv6: false

profile:
  store-selected: true
  store-fake-ip: true

上記の断片は一般的なトップレベル設定だけを使っており、YAMLのインデントとカーネル読み込みを確認するための最小例です。ノード、サブスクリプションURL、ルールは含まれていないため、これだけでプロキシ接続を完了することはできません。完全な設定には、信頼できるサブスクリプションまたは明示的な手動パラメータを追加してください。プロジェクト間の関係については、Clashオープンソースエコシステムの関係と原版、Meta、mihomoの機能互換性比較も参照してください。

サブスクリプション形式、YAMLフィールド、変換互換性

インポートできてもフィールドが完全とは限らない

サブスクリプションは通常、2つの形でクライアントに取り込まれます。1つはノード、プロキシグループ、ルール、DNSをすでに含む完全なClash YAMLです。もう1つはノードリンクの集合で、クライアントまたは変換サービスが解析してローカル設定を生成します。完全なYAMLはプロキシグループの構造を保ちやすい一方、特定のカーネル拡張を使っている場合があります。ノードリンクは異なるソフト間で渡しやすいものの、高度なフィールドをすべて表現できるとは限りません。インポートに成功したことは、ファイルを読み取れたことを示すだけで、各ノードの元のトランスポートパラメータがすべて残っている証拠ではありません。特にVMess、VLESS、Hysteria2、TUICはフィールドが多く、変換経路が長いほど欠落しやすくなります。

SSノードリンクには通常、暗号化アルゴリズム、パスワード、サーバー、ポートが含まれ、構造は比較的直接的です。TrojanではTLSサーバー名、ALPN、証明書関連オプションも確認する必要があります。VMessとVLESSには、ネットワーク種別、Host、Path、service name、flow、フィンガープリント、TLS設定などが含まれる場合があります。Hysteria2では認証、サーバー名、ポート、任意のトランスポートパラメータ、TUICではUUID、パスワード、輻輳制御、UDPリレー設定がよく使われます。変換後もノード名は残っているのに接続できない場合は、更新ボタンを何度も押すのではなく、変換前後の重要フィールドを並べて比較してください。

Clash YAMLの3つの層

第1層はノード定義で、proxies内に各接続の種別とパラメータを記述します。第2層はプロキシグループで、proxy-groupsがノードを組み合わせ、手動選択または自動測定を決めます。第3層はルールで、rulesがドメイン、IP、その他の判定結果をどのプロキシグループへ渡すかを決めます。3つの層は相互参照します。ルールにはプロキシグループ名を書き、プロキシグループはノードまたは別のグループを参照し、ノードにサーバー接続情報を記述します。名前を変更する場合は参照先も同時に変更しないと、プロキシグループがノードを見つけられない、またはルールが存在しない対象を指すエラーが発生します。

proxies:
  - name: "HY2-example"
    type: hysteria2
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    skip-cert-verify: false

proxy-groups:
  - name: "手動選択"
    type: select
    proxies:
      - "HY2-example"
      - DIRECT

rules:
  - MATCH,手動選択

この例は、ノード、プロキシグループ、最終ルールの参照関係を示しています。サーバーとパスワードは明確な例示値です。実際の設定では実際に提供されたパラメータへ置き換え、空白によるインデントを維持してください。YAMLではタブを階層インデントに使えません。特殊文字を含む名前には引用符を付けることを推奨します。クライアントが解析エラーを表示した場合は、まずインデント、コロン後の空白、重複キーを確認し、その後プロトコルフィールドを確認します。設定を読み込めてもノードのハンドシェイクに失敗する場合は、YAMLのレイアウトをさらに変更するのではなく、サーバーアドレス、認証、TLS、トランスポートパラメータを確認してください。

サブスクリプション変換の限界

サブスクリプション変換は、形式の整理、ノードの絞り込み、名前の処理、基本的なプロキシグループ生成には適していますが、不足しているパラメータを推測する用途には向きません。変換ツールは通常のSSリンクからVLESSのUUIDやTLS構造を導き出せず、typeを書き換えるだけでHysteria2ノードをTUICに変換することもできません。元と先が同じClash設定系統に属していても、変換先のテンプレートが原版フィールドを基準にしていれば、mihomo拡張が除外される可能性があります。変換後は照合用に元の設定を保存し、ノード数、プロトコル種別、TLSフィールド、プロキシグループの参照、ルール末尾のMATCHを重点的に確認してください。

リモートルールプロバイダーとリモートサブスクリプションでは、更新に失敗した後の挙動も問題になります。クライアントは通常、直近に正常取得できた設定を保持しますが、具体的なキャッシュ方式は実装によって異なります。更新後にノードが大量に消えた場合は、まだ動作しているローカルコピーをすぐ上書きせず、まず設定の更新時刻とダウンロードログを確認してください。サブスクリプションURLは機密性の高い設定情報なので、公開ページやログのスクリーンショットに載せないでください。調査が必要な場合は、URLのパラメータを隠し、エラー状態、レスポンスタイプ、クライアントのメッセージだけを残します。

クライアント、OS、プロトコル機能の組み合わせ

グラフィカルクライアントはまずシステム連携を担う

クライアントを選ぶときは、画面の好みより先に、対応OS、カーネル種別、システムプロキシ、TUN連携を確認します。Clash PlusはWindows、macOS、Android、iOSをカバーし、複数の端末で似た操作感を保ちたいユーザーに適した、当サイトの各プラットフォーム向け推奨エントリーです。Clash Verge RevはWindows、macOS、Linuxのデスクトップ環境に適し、mihomo設定の管理、システムプロキシ、TUNでよく使われます。FlClashはデスクトップとAndroidをカバーするクロスプラットフォームの選択肢です。Clash NyanpasuはWindows向け、Clash Meta for AndroidとSurfboardはAndroid向けです。ClashX MetaとClash for Windowsはメンテナンスが終了しており、既存環境の利用には使えますが、新しいプロトコル選定を担わせるのは適切ではありません。

クライアントが特定のプロトコルに対応しているとは、通常、そのクライアントに搭載されたカーネルが該当種別を解析して接続できることを意味します。ただし、グラフィカルインターフェースがすべてのパラメータを表示できるとは限りません。手動でノードを追加する画面は一般的なフィールドしか扱えなくても、YAMLをインポートすれば高度なパラメータを保持できる場合があります。フォームにflow、sni、udp relay mode、輻輳制御の項目がない場合、意味が近い別フィールドで代用しないでください。完全な設定をインポートし、ログで確認する方法を選びます。各プラットフォームのインストールパッケージとクライアントの順序はダウンロードページをご覧ください。ダウンロードに関する問題はダウンロードページのよくある質問で確認できます。

Windows：システムプロキシ、TUN、アプリごとの違い

Windowsのシステムプロキシは、システム設定に従うアプリに主に影響します。一部のプログラムは独自のネットワークスタックを使います。より広範囲を接管する必要がある場合はTUNを利用できますが、通常は追加の権限と仮想ネットワークインターフェースが必要です。どのアプリがシステムプロキシに従うかを変えるのはプロトコルではなく、クライアントの動作モードです。ブラウザーは正常なのにMicrosoft Storeアプリだけ異常な場合は、アプリのループバック制限とプロキシ経路を確認し、Windows UWPアプリでClashを使えない場合の対処手順を参照してください。TUNを有効にしてLANへのアクセスが変わった場合も、先にSSやVLESSを変えるのではなく、ルーティング、DNS、除外項目を確認します。

macOSとLinux：権限、システムサービス、アーキテクチャ

macOSのシステムプロキシは一般的なデスクトップアプリに適していますが、TUNや拡張モードではシステムネットワーク拡張と権限の確認が必要です。Apple SiliconとIntelではインストールパッケージのアーキテクチャが異なりますが、設定ファイルのプロトコル構文は通常同じです。LinuxデスクトップではClash Verge RevまたはFlClashを利用できます。サーバーやルーター環境では、mihomoカーネルを直接実行し、設定ファイルとコントロールインターフェースで管理する方法が適しています。サービス、権限、起動スクリプトを自分で管理する必要がない一般ユーザーは、グラフィカルクライアントを使うほうが手順を減らせます。カーネルパッケージのCPUアーキテクチャは端末と一致している必要があり、AMD64、ARM64、ARMv7、MIPSは互換ではありません。

AndroidとiOS：システムVPNインターフェースを優先

AndroidとiOSのClash系クライアントは、通常システムVPNインターフェースを通じて通信を接管します。この場合、「システムプロキシ」の意味はデスクトップと異なり、アプリごとの設定、システムVPNの制限、ローカルネットワーク権限によって接管範囲も変わります。AndroidではClash Plus、Clash Meta for Android、FlClash、Surfboardから選べます。mihomo拡張プロトコルが必要な場合は、実際のカーネルとインポート結果を確認してください。iOSではClash Plusが主な入口です。大量のルールを含むデスクトップ用設定をモバイルにインポートする前に、メモリ使用量と更新時間を評価し、必要ならより簡潔なルールセットを使います。

クライアントを変更する前に、現在の設定をエクスポートまたはバックアップし、手動で変更したDNS、TUN、プロキシグループ、ルールを記録してください。移行後はまずルールモードで基本的なウェブアクセス、DNS、単一ノードを確認し、その後に複雑な設定を戻します。クライアント、カーネル、サブスクリプションテンプレート、プロトコルを一度に変更すると、原因の特定が難しくなります。より安全な移行方法は、一度に1つの層だけを変えることです。まず設定を変えずにクライアントを変更して動作を確認し、次にカーネル機能を更新し、最後に新しいプロトコルのノードをインポートします。

利用シーン別にプロトコルとカーネルを選ぶ

日常のデスクトップ利用：成熟した設定を先に選び、プロトコルを比較する

WindowsまたはmacOSでウェブ閲覧、オフィスアプリ、通常のダウンロードが中心なら、まずmihomo対応クライアントを選び、サブスクリプション内でフィールドが完全かつ接続が安定しているプロトコルを使います。SS、Trojan、適切に設定されたVMessやVLESSはいずれも候補になります。同じサービスが複数のプロトコルを提供している場合は、同じ回線で初回表示、数分間の継続転送、スリープからの復帰をテストしてください。差が明確でなければ、フィールドが少なく、更新後もエラーが起こりにくいものを選びます。クライアントはClash Plusを第一候補とし、デスクトップ管理の要件に応じてClash Verge RevまたはFlClashを選べます。

モバイルネットワークと頻繁な切り替え：復旧とバックグラウンド状態を確認する

スマートフォンがWi-Fiとモバイルネットワークを頻繁に切り替える場合は、Hysteria2またはTUICをテスト候補に含めてもよいでしょう。QUIC系の接続は、ネットワーク変化やパケットロスのある条件で復旧性能に優れる場合があります。ただし、現在のネットワークがUDPを安定してサポートし、クライアントカーネルが設定を完全に解析でき、サーバーパラメータも正しいことが前提です。画面ロック後に切断される場合は、まずシステムのバックグラウンド制限を処理します。アイドル後の初回アクセスが遅い場合は、接続のキープアライブとDNSを確認します。電池消費が増えた場合は、すぐにプロトコルが使えないと判断せず、ヘルスチェックと候補ノードを減らしてください。

高遅延またはパケットロスのある回線：スループットと公平性を同時に見る

往復遅延が大きく、帯域の変動が目立つネットワークでは、Hysteria2とTUICの輻輳制御が一般的なTCP接続より速くスループットを回復する場合があります。ただし、テストでは単一タスクが最大速度に達するかだけでなく、他のアプリが明らかに影響を受けていないか、ルーターのCPU使用率が継続的に上昇していないか、アイドル後に頻繁な再接続が起きていないかも観察します。帯域パラメータは継続的に確保できる能力に近づけ、アクセス回線の公称上限を実測値の代わりに使わないでください。UDP経路が不安定なら、設定が成熟したTrojan、VLESS、SSのほうが予測しやすい場合があります。

旧端末、ルーター、小型サーバー：変数を減らす

リソースが限られた端末では、まずルール数、ログレベル、DNSの複雑さ、同時接続数を抑えます。プロトコルは実装が成熟し、パラメータが少ないSSまたは既存の安定したTCP方式から始め、必要に応じて他の種別をテストしてください。mihomoカーネルを実行する場合はCPUに合ったパッケージをダウンロードし、最小設定でサービスが起動することを確認してから、DNS、ルールプロバイダー、TUNを段階的に追加します。デスクトップ用の大規模な設定を低メモリ端末へそのままコピーしないでください。画面が存在しなくても、ルールと接続状態にはリソースコストがあります。

既存のサブスクリプション：サーバーが実際に提供する種別を尊重する

プロトコル名を追い求めて、ユーザーが自分でノードを書き換える必要はありません。サブスクリプションがSSを提供するならSSのパラメータを使い、VLESSならTLSとトランスポートのフィールドを確認し、Hysteria2またはTUICならmihomoの対応とUDP環境を確認します。サーバー側に該当プロトコルが導入されていなければ、クライアント側で種別を変更しても一致するハンドシェイクは確立できません。同じサブスクリプションに複数のプロトコルが含まれている場合は、手動選択グループと個別テストグループを作り、既知の安定ノードを基準として残したうえで他のノードを比較します。

障害発生時は層ごとに確認する

第1層は設定が読み込まれているかです。YAML解析、未知の種別、不足フィールドのエラーが出る場合、問題は形式またはカーネル互換性にあります。第2層はノードのハンドシェイクです。ログに認証、TLS、timeout、UDPのエラーが出る場合は、ノードパラメータとネットワーク条件を照合します。第3層はシステムの接管です。ノードには接続できるのにアプリがアクセスできない場合は、システムプロキシ、TUN、VPN権限、DNSを確認します。第4層はルールです。一部のドメインだけ異常なら、ルールの順序、プロキシグループの選択、MATCHの転送先を確認します。層ごとに調べることで、システムプロキシの問題をプロトコルの問題と誤認したり、ノードパラメータが誤っているのにルールを何度も調整したりするのを防げます。

• 初回利用を早く完了したい

  クイックスタートへ進み、サブスクリプションのインポート、モード選択、システムプロキシの有効化、接続確認の順に操作してください。

• インストールパッケージを選びたい

  ダウンロードページへ進み、Windows、macOS、Android、iOS、Linuxからクライアントを選択してください。

• カーネルを比較したい

  現在のクライアントで実際に動作しているカーネルを先に確認し、カーネル互換性の比較を参考に移行してください。

• プロキシグループを最適化したい

  url-test、fallback、load-balanceの違いを読み、測定動作と実際の目的が合わない設定を避けてください。

最終的な選択基準は、「設定が必要な情報を完全に表現でき、クライアントが安定して解析でき、現在のネットワークで再現性をもって動作する」ことです。プロトコル名は設計の方向性を示すもので、環境から切り離された固定ランクを示すものではありません。多くのユーザーにとって、安定したmihomoクライアント、構造が明確なサブスクリプション、適切なルール、再現可能なテスト手順のほうが、1回の遅延値を追いかけたりプロトコルを頻繁に変更したりするより重要です。検証済みの設定を基準として残し、一度に1つの変数だけを変更し、ログの具体的なエラーを記録することで、今後の更新とトラブル対策を制御しやすくなります。