選び方の基本：GUIとプロキシコアを分けて考える

ClashのGUIクライアントは、サブスクリプションの追加、ノード選択、システムプロキシの切り替え、稼働状況の表示を担います。一方、プロキシコアは設定の読み込み、ルール判定、接続の確立を担います。使いやすい画面だからといってすべてのプロトコルに対応するとは限らず、設定を読み込めても全項目が反映されるとは限りません。クライアントを比較する際は、まずOSとCPUアーキテクチャを確認し、実際に動作しているコアを特定してから、サブスクリプションとネットワーク接続方式を確認しましょう。

Clash Metaはこのコア系列の旧称で、後継プロジェクト名はmihomoです。Clash Verge Rev、ClashX Meta、FlClashはいずれもこのコア系列をGUIで管理できますが、コアの更新頻度、設定の上書き方法、権限の扱いはそれぞれ異なります。旧Clashコアの機能をそのままmihomoに当てはめることもできません。サブスクリプションにVLESS、Hysteria2、TUICが含まれる場合は、実際に使うコアの対応状況とサーバー側のパラメーターを個別に確認してください。

以下は機能や設計方針の比較であり、特定バージョンのベンチマーク順位ではありません。ポート番号や速度の数値は設定・判断の例で、各クライアントの初期値や実測値を示すものではありません。

対応プラットフォームと操作性を比較

4種類のクライアントを選ぶポイント
クライアント 対応プラットフォーム 画面と設定の使い方 インストール前の確認事項
Clash Plus ダウンロードページの現行リリースを確認 プロジェクトとビルドの説明を個別に確認 OS、アーキテクチャ、コア名、機能へのアクセス方法
Clash Verge Rev Windows、macOS、Linux デスクトップの管理画面で、サブスクリプション、プロキシグループ、設定をまとめて操作 サービスモード、TUNの権限、設定のマージ方法
ClashX Meta macOS メニューバーから操作。設定ファイルやプロキシグループの切り替えを重視 CPUアーキテクチャ、OSとの互換性、ビルドごとの機能
FlClash Windows、macOS、Linux、Android デスクトップとスマートフォンで、設定・プロキシ・操作の流れが共通 プラットフォームごとの接続方法、バックグラウンド動作、権限の違い

デスクトップの管理画面とmacOSのメニューバー

接続状況を頻繁に確認したり、複数のサブスクリプションを切り替えたり、設定を変更したりするなら、デスクトップ用の管理画面が充実したClash Verge Revが候補になります。macOSで主に1つの設定を使い、普段の操作がプロキシグループの切り替えとシステムプロキシのオン・オフ程度なら、メニューバー中心のClashX Metaを試してみるとよいでしょう。違いは主に操作手順であり、通信速度の差に直結するものではありません。

PCとAndroidで操作感をそろえる

PCとAndroidで似た操作感を求めるなら、FlClashが候補になります。ただし、画面が似ていても設定が自動同期されるわけではありません。サブスクリプションURL、プロキシグループの選択、自動更新、ローカル設定の上書きなどは、通常それぞれの端末で設定が必要です。AndroidはシステムのVPN権限を使い、デスクトップではシステムプロキシまたはTUNを利用します。スマートフォンの「接続済み」とデスクトップのプロキシ切り替えは、同じ仕組みではありません。

  • Windowsではx64とARM64を確認します。インストーラー名に記載されたアーキテクチャが、使用する端末と一致している必要があります。
  • macOSではIntelとAppleシリコンを確認し、ユニバーサルビルドの有無と最低対応OSも調べましょう。
  • Linuxではアーキテクチャに加え、パッケージ形式、デスクトップ環境、サービスのインストール要件も確認してください。
  • iPhoneとiPadは上記の対応プラットフォームに含まれていません。別途、対応クライアントを選ぶ必要があります。

コアの種類：まず設定を検証し、接続状況を比較

クライアントのバージョンとコアのバージョンは別々の情報です。GUIの更新では、画面やサブスクリプションの操作、システム連携だけが変更される場合があります。プロトコルの実装、DNSの挙動、ルール機能に関わるのは、コアの更新です。利用環境を記録するときは、クライアント名とそのバージョン、コアのバージョン、OS、アーキテクチャを併記しましょう。メイン画面のスクリーンショットだけでは情報が足りません。

実際に使うコアでYAMLを検証

mihomoの実行ファイルを単体で使える環境では、まずバージョンを確認し、続けて設定ファイルをテストできます。以下では、カレントディレクトリにある実行ファイルと設定ファイルを使います。クライアント内蔵の実行ファイルは名称やパスが異なる場合があるため、実行前に実際のファイルを特定してください。テストに通っても、ノード、DNS、接続先サーバーへの通信が確認できたわけではありません。

# Linux / macOS：カレントディレクトリのmihomo
./mihomo -v
./mihomo -t -f ./config.yaml

# Windows PowerShell：カレントディレクトリのmihomo.exe
.\mihomo.exe -v
.\mihomo.exe -t -f .\config.yaml

GUIクライアントでは、元のサブスクリプションに設定をマージしたり、上書きしたり、スクリプトで処理したりする場合もあります。トラブルシューティングでは、実際に動作している設定を確認してください。元ファイルのmixed-port: 7890が、現在の待ち受けポートとは限りません。画面上でポートが7897に上書きされている場合、ブラウザーやターミナルが7890へ接続しても失敗します。

1回の速度テストではなく、同じ条件で比較

  1. 同じサブスクリプション、同じノード、同じテストURLを使い、ルールモードとプロキシグループもそろえます。
  2. ポート、システムプロキシ、仮想ネットワークインターフェースの競合を避けるため、プロキシクライアントは一度に1つだけ起動します。
  3. まず接続の安定性を比べ、次に継続的なダウンロード速度を確認します。テスト中はネットワーク環境を一定に保ちましょう。
  4. 失敗時のログを保存し、DNSのタイムアウト、接続拒否、認証エラー、プロトコルパラメーターの誤りを切り分けます。

たとえばURLテストで85 ms、別のテストで110 msと表示された場合、これは2回の往復時間の例にすぎません。サーバー負荷、コネクションの再利用、ネットワークの揺らぎによって結果は変わるため、GUIの速さの違いを示すものではありません。複数回の結果、失敗回数、実際の作業にかかった時間を記録するほうが有用です。

TUN対応：コアの機能、システム権限、クライアントとの連携

TUNは仮想ネットワークインターフェースでIP通信を受け取る仕組みです。システムプロキシ設定を参照しないアプリもネットワークに接続させたい場合に適しています。一方、システムプロキシは、設定に従うアプリにHTTPまたはSOCKSで接続を提供します。どちらかが単純に「普通」で、もう一方が「上級」という関係ではありません。ブラウザーの利用で足りるなら、システムプロキシのほうが問題を切り分けやすいでしょう。ゲーム、コマンドラインツール、一部のサンドボックスアプリにも接続が必要な場合は、TUNを検討してください。

クライアント TUNを確認するポイント 主な確認項目
Clash Plus リリースノートと実際の設定項目を確認 コアの機能、サービスのインストール、システム権限
Clash Verge Rev TUNの管理機能に対応 使用するプラットフォームでサービスや権限昇格の仕組みが正常に動作するか
ClashX Meta Metaという名称だけでTUN連携の全機能を判断しない 使用するビルドに設定項目があり、必要な権限を扱えるか
FlClash プラットフォーム固有の仕組みで通信を取り込む デスクトップの権限、またはAndroidのVPN権限

TUNを有効にしたら、次の3点も確認

  • インターフェースとルート：画面のスイッチが切り替わるだけでなく、仮想インターフェースが実際に作成され、必要なルートが設定されているか。
  • DNS：ドメイン名の問い合わせが想定した経路で処理されているか。TUNを有効にしても、すべてのDNS設定の問題が自動的に解決するわけではありません。
  • 競合：別のVPN、社内ネットワークツール、ほかのTUNが同時にデフォルトルートを制御していないか。

Androidでは通常、システムのVpnServiceで確立できるVPN接続は同時に1つです。ほかのVPNアプリが動作している場合は、どちらの接続機能を使うか先に決めてください。バッテリー最適化やバックグラウンド制限によって、画面ロック後に接続が切れることもあります。これはノードのプロトコルとは別の問題です。

サブスクリプション管理：追加・更新とローカル編集の注意点

クライアントを選ぶ際は、「追加・有効化・更新・再起動」を一通り試してください。ノード一覧に表示されるだけでは不十分です。サブスクリプションの取得後、対象の設定を選び、プロキシグループが正しいノードを参照しているか確認しましょう。サブスクリプションが別ソフト向けの形式で生成されている場合、URLを取得できても、YAMLの構造やプロトコル項目の違いで使えないことがあります。

実際に試しておきたい4つの操作

  1. 追加：サブスクリプションまたは設定の追加画面を開き、URLを貼り付けます。取り込み結果に想定したノード、プロキシグループ、ルールが含まれているか確認してください。
  2. 有効化：設定を選び、プロキシグループでノードを指定します。接続ログにそのポリシーが表示されるか確認しましょう。
  3. 更新：手動で1回更新し、ノード数と更新時刻を記録します。カスタムルールが保持されるかも確認してください。
  4. 再起動：クライアントを終了して再度起動し、選択中の設定、ポート、接続スイッチが想定どおりか確認してください。

Clash Verge Revのマージ機能やスクリプト機能は、一部の設定変更を管理するのに便利ですが、最終的な結果は稼働中の設定で確認してください。ClashX Metaのファイル管理は、YAMLに慣れたユーザーに向いています。ダウンロードした設定を編集する前に、更新時に変更内容が上書きされないか確認しましょう。FlClashは、複数の端末で同じ管理手順を繰り返す場合に便利です。エクスポートやバックアップの対象範囲は、使用中のバージョンで確認してください。Clash Plusの同様の機能は、実際のビルドで検証が必要です。

端末ごとの設定とサブスクリプションの内容を分けて管理

ポート、LANからの接続許可、TUNの設定は端末に依存するため、すべての端末にそのままコピーするのは避けましょう。以下は端末ごとの設定例です。allow-lan: falseは、LAN上のほかの端末からプロキシへのアクセスを許可しない設定です。サブスクリプションのノード、プロキシグループ、ルールと組み合わせて、全体の設定を構成します。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

サブスクリプションURLには、アクセス用トークンが含まれていることがよくあります。スクリーンショット、ログ、エクスポートファイルからURLやノードの認証情報が漏れるおそれがあるため、問い合わせ前に機密情報を削除してください。リモート設定をマージスクリプトで処理する場合は、スクリプトの入手元と変更範囲も確認しましょう。ノード一覧だけでなく、DNS、ルール、待ち受け設定にも影響する可能性があります。

使い方に合わせてクライアントを選ぶ

初心者：まず1台で基本設定を済ませる

WindowsまたはLinuxのデスクトップでは、まずClash Verge Revを検討できます。macOSでは、管理画面を使うClash Verge Revと、メニューバー中心のClashX Metaから選べます。初回はサブスクリプションを1つ追加し、ルールモードを有効にしてノードを1つ選んでから、システムプロキシをオンにしましょう。ブラウザーで安定して接続できることを確認してから、TUNや設定の上書きを追加します。一度に複数の要因を増やさないことで、問題を切り分けやすくなります。

Clash Plusも候補にできますが、プロジェクトの実体、インストーラーのアーキテクチャ、コアの情報を先に確認してください。リリースノートが不明確な場合は、名称が似ているという理由だけで、ほかのクライアントの画面操作や設定手順を流用しないようにしましょう。

複数端末：形式の互換性と操作の重複を確認

PCとAndroidを併用するなら、画面や操作が似ているFlClashは、端末間の操作の違いを減らすのに役立ちます。そろえるべきなのは、サブスクリプションの入手元、プロキシグループ名、ルールの意図です。システム権限、ポート、バックグラウンド動作の設定は端末ごとに行ってください。デスクトップアプリのデータフォルダーをスマートフォンにそのままコピーしたり、あるクライアントの完全バックアップを別のクライアントに読み込めると想定したりするのは避けましょう。

上級者：稼働中の設定とトラブルシューティング機能を重視

ルールの上書き、接続の確認、サービス管理が必要なら、Clash Verge Revの設定管理機能を詳しく確認しましょう。macOSのメニューバー操作を好み、YAMLを管理できるユーザーには、ClashX Metaが候補になります。デスクトップとAndroidで近いワークフローを求めるなら、FlClashを検討できます。選ぶ前に、稼働中の設定のエクスポート、ログの確認、コア情報の表示、権限の復旧手順を実際に確認してください。画面のスクリーンショットだけで比較するのは不十分です。

  • まず現在のプラットフォームに対応するクライアントを選び、将来追加するかもしれない端末はその後に考えます。
  • 画面の配置を比べる前に、必要なプロトコルと設定項目を検証します。
  • まずシステムプロキシで足りるか確認し、そのうえでTUNを使うか判断します。
  • ローカルの変更が更新で失われないことを確かめてから、普段使いの設定を移行します。

クライアント変更前の移行チェックリスト

移行前に、サブスクリプションの入手元、必要なカスタムルール、旧クライアントの設定を記録します。新旧のクライアントでシステムプロキシやTUNを同時に有効にしないでください。ポートが別でも、システムルートが競合する可能性があります。まず旧クライアントのネットワーク接続を停止して終了し、その後、新しいクライアントで一通り動作を確認しましょう。

  1. 現在の待ち受けポートを記録します（例：127.0.0.1:7890）。ブラウザー拡張、ターミナルの環境変数、ほかのアプリにこのアドレスが固定されていないか確認してください。
  2. 新しいクライアントにサブスクリプションを追加し、プロキシグループ名とルールの参照先を確認します。存在しないプロキシグループをルールが参照していないことも確認してください。
  3. まずシステムプロキシを有効にし、ブラウザーと接続ログで動作を確認します。接続できたら、必要に応じてTUNを有効にしてください。
  4. プロキシ経由にする接続、直接接続する接続、LANアクセスが必要な接続をそれぞれテストし、ルールの動作を確認します。
  5. クライアントまたはシステムの再起動後にも確認し、自動起動、権限、ポートに予期しない変更がないことを確かめましょう。

ブラウザーは使えるのにターミナルから接続できない場合は、次のコマンドでプロキシを明示します。「アプリがプロキシを使っていない」のか、「プロキシ自体に接続できない」のかを切り分けられます。このコマンドは、実際の混合ポートが7890で、テスト先がこのサイトのトップページであることを前提としています。テスト先がプロキシ経由になるかどうかは、現在のルールによって決まります。

curl --proxy http://127.0.0.1:7890 -I https://clash-packet.com/

同じサブスクリプションでも2つのクライアントで動作が異なる場合は、まずコアのバージョン、最終的な設定、プロキシグループの選択、接続方式を比較してください。これらを確認してからクライアント自体の違いを検討すると、再現可能な原因をより早く特定できます。用語は用語集、ルールの順序やコアの違いは技術リファレンスをご覧ください。