クライアント・カーネル・サブスクリプションの違い
Clash クライアントを選ぶ際は、設定を管理する画面、ルールを実行するカーネル、システム通信を取り込む方法の3つを見極めましょう。FlClash と Clash Verge Rev はGUIクライアント、mihomo はカーネルであり、単独で動作するコマンドラインプログラムでもあります。サブスクリプションはノードや設定一式を提供するもので、クライアントとは別物です。また、システムプロキシが有効かどうかを決めるものでもありません。
同じサブスクリプションを2つのクライアントで使っても、接続結果が異なることがあります。ノードの品質が変わったとは限りません。カーネルのバージョン、DNSのオーバーライド、ルールの適用順、TUNの状態、プロキシグループの選択によって、実際の通信経路は変わります。比較する前に条件をそろえ、ホーム画面の遅延値だけで判断しないようにしましょう。
結論から言うと、デスクトップとAndroidで近い操作感を求めるならFlClash、デスクトップで複数のサブスクリプションやオーバーライドを管理するならClash Verge Rev、Linuxサーバーならmihomoの単独導入をまず検討できます。対応状況は、利用するディストリビューションのインストーラー、カーネルのバージョン、リリースノートで確認してください。
この記事では各ツールの使い方を比較します。特定の画面バージョンだけを根拠に、長期的な評価を決めることはしません。インストール前に「クライアントのバージョン」と「カーネルのバージョン」をそれぞれ記録しましょう。番号の付け方は異なるため、クライアントのバージョン番号だけでプロトコルの対応状況は判断できません。
対応プラットフォームとメンテナンス状況
| 候補 | 主な対応プラットフォーム | 適した管理方法 | 選定時の確認ポイント |
|---|---|---|---|
| FlClash | Windows、macOS、Linux、Android | 統一感のある画面で設定のインポート、プロキシグループの選択、動作状況の確認が可能 | 対象アーキテクチャのインストーラー、モバイル版のVPN権限、実際に使用されるカーネルのバージョン |
| Clash Verge Rev | Windows、macOS、Linux | デスクトップでのサブスクリプション管理、設定の拡張、サービスモード | オーバーライドの適用範囲、サービスのインストール状況、システムプロキシとTUNの設定 |
| Clash Nyanpasu | Windows、macOS、Linux | デスクトップでの設定管理とカーネル関連の設定 | 各ディストリビューションのメンテナンス状況、カーネルの選択、設定拡張の動作 |
| mihomo | 対応するLinuxなどのOSとアーキテクチャ | 設定ファイル、コマンドライン、システムサービス | サービスの権限、ネットワークルーティング、コントローラーインターフェース、アップデートとロールバック |
| Clash for Windows | 過去に提供されていたデスクトップ版 | 既存環境からの移行時の参考 | メンテナンス終了。新規導入の第一候補には適しません |
対応OSが同じでも、インストール条件まで同じとは限りません
- Windows：x64とARM64を区別してください。通常、システムプロキシの設定に管理者権限は不要ですが、サービスのインストール、TUN仮想NICの作成、ルーティングの変更には昇格権限が必要な場合があります。
- macOS：Apple SiliconとIntelを区別してください。アプリの初回起動とネットワーク関連コンポーネントの有効化は別の手順です。システム権限の確認が表示されても、ただちにインストール失敗とは限りません。
- Linuxデスクトップ：パッケージ形式と実行時の依存関係を確認してください。インストール後は、デスクトップ環境がシステムプロキシを参照するか、TUNに必要な権限があるかも確認します。
- Android：FlClashはAndroidのVPNインターフェースを使って通信を取り込むため、ユーザーによる許可が必要です。通常、同じユーザー環境で同時に有効にできるVPNは1つです。他のVPN、パケットキャプチャ、ファイアウォールアプリが使用中でないか確認してください。
iOSでは、デスクトップ版と同じクライアント名を前提にインストール方法を選ばないでください。FlClashとClash Verge Revの一般的な配布対象にiOSは含まれません。他のiOS向けプロキシアプリで特定のサブスクリプション形式が使えるかは、個別に確認が必要です。一部のノードをインポートできても、mihomoの設定一式に対応しているとは限りません。
比較ポイント1：カーネルの更新とプロトコル互換性
mihomoはClash Metaの技術路線を引き継いでいます。クライアントにmihomoが組み込まれていても、常に同じビルドのカーネルが同梱されるとは限りません。新しいプロトコルのフィールド、DNSオプション、ルールの挙動が使えるかどうかは、ソフト名だけで判断せず、インストール済みの実際のカーネルを確認してください。
インストール後に記録する3項目
- クライアントの「バージョン情報」や「カーネル管理」などの画面で、UIとカーネルのバージョンを記録します。メニュー名は配布版によって異なるため、すべてのクライアントで同じ操作手順が使えるとは限りません。
- 設定をインポートしたら起動ログを確認し、未対応のプロキシタイプ、ルールの解析エラー、リスナーの起動失敗がないか確認します。
- 新しいプロトコルで必要なパラメーターを一通り確認してください。ノードの
typeだけを別の名称に変更しても、プロトコルの変換にはなりません。
FlClashは、カーネルとUIの連携をクライアント側でまとめて管理したいユーザーに向いています。Clash Verge Revでは、カーネルの更新画面とリリースノートもあわせて確認しましょう。カーネルを切り替えられる配布版では、事前に設定をバックアップし、更新後のDNS、UDP、TUNの動作を検証してください。開発版カーネルは特定の修正を検証する用途に適していますが、バージョン番号が新しいというだけで、すべての作業環境に導入するのは避けましょう。
mihomoを単独で使う環境では、まず設定のテストを実行できます。以下はローカル設定ファイルの例です。コマンドはmihomoをインストール済みの環境で実行してください。
mihomo -v
mihomo -t -f ./config.yaml-tは、現在のカーネルが設定を受け付けるかテストするオプションです。ノードへの接続、DNSの利用可否、ルールの判定結果まで検証するものではありません。GUIクライアントでは起動前に設定ファイルを生成する場合もあるため、元のサブスクリプションファイルをテストしても、最終的な実行設定の確認にはなりません。
比較ポイント2：UIと通信の取り込み方法
FlClashの実用面での利点の1つは、デスクトップとAndroidで操作の考え方が近いことです。設定のインポート、接続の開始、プロキシグループの選択、接続ログの確認を同じ感覚で行えます。Clash Verge Revは、トレイ操作、システムプロキシ、サービスモード、設定管理など、デスクトップでの作業フローを重視する場合に検討するとよいでしょう。設定項目の数をスクリーンショットで比べるのではなく、日常的に行う操作を基準に選んでください。
システムプロキシとTUNは分けて検証する
システムプロキシは、OSの設定に従うアプリをローカルのプロキシポートへ接続します。一部のターミナルアプリやゲームはシステムプロキシを自動で参照しません。TUNは仮想NICを使って、ルーティング条件に合う通信を取り込みますが、権限、ルート、DNS、除外ルールの影響を受けます。「有効にすればすべての通信が必ずプロキシを通る」という意味ではありません。最終的な接続先はルールとプロキシグループによって決まります。
- ブラウザーを使った作業では、まずシステムプロキシを試します。通常のアクセスとルールのマッチを確認してから、TUNが必要か判断しましょう。
- コマンドラインツールはプロキシを明示的に指定して接続し、「アプリがシステムプロキシを参照していない」可能性を切り分けられます。
- ゲーム、UDPを使うアプリ、プロキシ設定に従わないソフトは、TUNを試してください。ノードと接続経路が対象の通信に対応していることも確認します。
たとえば、現在有効な設定でmixed-portが実際に7890の場合に限り、以下のコマンドを使用できます。7890は例示用のポート番号であり、すべてのクライアントに共通する既定値ではありません。
curl --proxy http://127.0.0.1:7890 https://example.com/プロキシを明示すると接続できるのに、直接アクセスでは失敗する場合は、まずアプリのプロキシ設定と通信の取り込み方法を確認してください。ローカルポートにも接続できない場合は、カーネルが起動しているか、ポートが使用中でないかを調べます。すぐにサブスクリプションを変更する必要はありません。
比較ポイント3：サブスクリプションとオーバーライドの管理
サブスクリプションの更新と、ローカルでカスタマイズした設定の境界は、長く使ううえで見落とされがちな違いです。サブスクリプションから生成されたファイルを直接編集すると、次回の更新で変更が上書きされることがあります。リモートのサブスクリプションはノードや基本設定を管理し、ローカルのオーバーライドはルールの追加、DNS、リスナーアドレス、個人設定を管理する構成が安全です。
オーバーライド機能を比べる際の4つの確認事項
- 適用範囲：変更は現在の設定だけに適用されますか、それともすべての設定に適用されますか？別のサブスクリプションに切り替えた後も、DNSの設定は有効ですか？
- 適用順：ローカルルールはサブスクリプションのルールより前に挿入されますか、それとも最後に追加されますか？
MATCHの後に追加すると、通常は意図したルール判定が行われません。 - マージ方法：オブジェクトのフィールドはマージされる場合がありますが、配列は置き換えまたは追加されることがあります。具体的な動作はクライアントのオーバーライド機構によって異なり、YAMLの見た目だけでは判断できません。
- 確認しやすさ：最終的な実行設定や、ルールのマッチ記録を確認できますか？エディターで保存できたことだけでは、カーネルに設定が読み込まれた証拠にはなりません。
Clash Verge Revの設定拡張ワークフローは、ローカル設定のマージやスクリプト処理を行うデスクトップユーザーに向いています。利用できる画面や適用順は、インストールしたバージョンで確認してください。FlClashでも、使用中のバージョンにあるオーバーライド機能と適用範囲を確認しましょう。特に、デスクトップとAndroidで設定の保存場所が完全に同じだと思い込まないようにしてください。
以下はルールの適用順を説明する例であり、そのままインポートできる完全な設定ではありません。社内ネットワークへの通信を優先してDIRECTにし、それ以外の通信を既存のPROXYプロキシグループへ送る例です。使用前にグループが存在することを確認し、例示用ドメインを実際の社内ドメインに置き換えてください。
rules:
- DOMAIN-SUFFIX,office.example.com,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,PROXYこの
rulesを判断せずにルール全体のオーバーライドとして使用しないでください。クライアントが配列を置き換える方式の場合、既存のルールがすべて置き換わる可能性があります。「先頭に追加」「末尾に追加」「置き換え」の違いを確認してから設定してください。
サブスクリプションURLにはアクセス用の認証情報が含まれていることがあります。移行、問題の報告、スクリーンショットの共有時は、URL全体、ノードのパスワード、コントローラーインターフェースのキーを隠してください。出所のわからないオンライン変換サイトに、実際のサブスクリプションを送信しないでください。
比較ポイント4：条件をそろえて性能と安定性を検証
クライアントの画面が異なるだけでは、通信速度の優劣は判断できません。カーネル、ノード、ルート、DNS、テスト先が同じ場合、GUIの違いが主に表れるのは操作性、設定生成、リソース使用量です。デバイス、バージョン、ネットワーク条件が明確でない速度ランキングは掲載しません。
再現性のある比較手順
- クライアントは1つだけ起動し、もう一方のクライアントとバックグラウンドサービスは終了してください。ローカルポートの競合やTUNルートの重複を防げます。
- 同じノードに固定し、自動切り替えによる影響を避けます。
mode: rule、DNS設定、テスト先も統一してください。 - まずシステムプロキシを測定し、その後TUNを個別にテストします。それぞれの条件で3回連続して測定し、接続成功回数と所要時間を記録してください。1回の変動だけで結論を出さないようにしましょう。
- アイドル状態で5分間動作させた後、メモリとCPUの使用量を記録します。UIプロセスとカーネルプロセスを分け、ログレベルもそろえてください。
- サブスクリプションの更新、ネットワークの切り替え、スリープからの復帰をそれぞれ1回行い、接続が復旧するか、プロキシグループの選択が維持されるかを確認します。
遅延テストではURLとタイムアウト設定も統一してください。クライアントによって測定先が異なる場合があります。一方が80ミリ秒、もう一方が150ミリ秒と表示しても、測定先や方法が異なれば有効な比較にはなりません。ここで示した数値は表示例であり、実測結果ではありません。
通信が途切れたときは、発生時刻、接続先ドメイン、マッチしたルール、アウトバウンド名を記録してください。「特定のクライアントが遅い」という情報だけでは、DNSのタイムアウト、ノードへの接続失敗、ルールによる誤った接続先への振り分けを区別できません。
用途に合わせて候補を絞り込む
| 用途 | 優先して検討する候補 | 確認ポイント |
|---|---|---|
| デスクトップとAndroidを併用 | FlClash | 両方の端末でのサブスクリプションのインポート、プロキシグループの選択、VPN権限、バックグラウンド動作 |
| 複数の設定とローカルルールを使うデスクトップ作業 | Clash Verge Rev。FlClashとの比較もおすすめです | 設定拡張の適用順、トレイ操作、スリープ復帰、社内ネットワークへの直接接続 |
| デスクトップ向けの別の操作方法を比較したい | Clash Nyanpasu | 配布版のメンテナンス状況、設定の移行、実際のカーネルとの互換性 |
| GUIのないLinuxサーバー | mihomoの単独運用 | サービスの起動、リスナーのバインド先、権限、ログローテーション、ロールバック |
| 旧Clash for Windows環境からの移行 | メンテナンス中のデスクトップクライアント | 設定を解析できること、ポートが一致していること、プロキシグループ名とルールの適用順 |
サーバーでClashを使うために、デスクトップ環境をインストールする必要はありません
Linuxサーバーでは、mihomoをsystemdなどのサービスマネージャーから起動できます。設定ファイルのパス、実行ユーザー、再起動ポリシー、ログの保存方法を明確にしてください。ローカルアプリからの利用だけなら、プロキシポートはループバックアドレスへのバインドを優先します。LAN内にプロキシを公開する必要がある場合に限り、allow-lan、認証、ファイアウォールのルールを検討してください。
external-controllerは管理用インターフェースであり、通常のプロキシポートではありません。127.0.0.1:9090を指定すると、ローカルマシンからのみアクセスできます。リモート管理には、アクセスを制限したトンネルを利用できます。接続を簡単にするために管理用インターフェースをインターネットへ直接公開しないでください。また、secretを設定してください。
旧クライアントからは「設定」を移行し、フォルダーを丸ごとコピーしない
サブスクリプションの取得元、個人ルール、DNS設定、プロキシグループの選択を先に保存し、新しいクライアントにあらためてインポートしてください。プロジェクトごとにデータベース、キャッシュ、サービス設定の形式は異なります。フォルダー全体をコピーすると、古いパスや状態まで引き継ぐおそれがあります。新しいクライアントの初回起動前に、旧クライアントのシステムプロキシ、TUN、バックグラウンドサービスを停止してください。終了後、プロキシ設定が元に戻っていることを確認します。
インストール前後に確認する選定チェックリスト
- インストール前：OSとCPUアーキテクチャを確認し、リリースノートを読み、旧設定と復旧用のインストーラーを保存します。
- 初回起動：クライアントとカーネルのバージョンを記録し、設定を1つインポートします。ログに解析エラーやポートの競合がないか確認してください。
- 初回接続：ルールモード、実際のmixed port、現在のプロキシグループを確認します。まず通信の取り込み方法を1つだけ検証し、その後でTUNなどの設定を追加してください。
- 初回のサブスクリプション更新：ローカルルールとDNSの設定が保持されているかを確認し、編集画面だけでなく最終的な実行設定もチェックしてください。
- 継続利用：スリープからの復帰、Wi-Fiとモバイル通信の切り替え、社内ネットワークへのアクセス、クライアント終了後のネットワーク復旧をテストします。
FlClash、Clash Verge Rev、mihomoの単独運用は、同じ種類のツールを置き換えるものではありません。前者2つはGUIでの設定や日常的な切り替えを簡単にし、mihomoはサービスとして直接運用できます。設定の内容を把握できること、ログから問題を特定できること、更新を元に戻せること、実際のプラットフォームとネットワーク権限に合うことを基準に選びましょう。設定項目を確認するには設定項目リファレンス、インストールと初回接続の手順は入門ガイドをご覧ください。