Clashクライアントを比較

UI・カーネル・サブスクリプションを分けて考える

ClashのGUIクライアントを選ぶときは、テーマやトレイアイコンより先に、役割の異なる3つの要素を確認しましょう。クライアントは設定のインポート、プロキシノードの切り替え、システム権限の要求を担当します。カーネルは通信プロトコル、DNS、ルール判定を処理し、サブスクリプションはノードや設定一式を提供します。ダウンロード案内では一緒に記載されることがありますが、それぞれ別のものです。

たとえば、Clash Verge Revはクライアント名で、mihomoはそのクライアントが使用するカーネルです。サブスクリプションを画面上で保存できても、カーネルが含まれるすべてのプロトコルに対応しているとは限りません。逆に、カーネルが設定項目に対応していても、画面に切り替え項目がなく、オーバーライドや設定ファイルから指定する必要がある場合もあります。

• クライアントのバージョン：画面、サービス管理、設定編集の動作を左右します。通常は「バージョン情報」で確認できます。
• カーネルのバージョン：プロトコルや設定項目が使えるかを左右します。カーネル情報または起動ログで確認し、クライアントのバージョンと混同しないようにしましょう。
• サブスクリプションの形式：Clash YAML一式、ノード情報のみ、その他の形式は互換ではありません。インポート前に、提供元が示す形式を確認してください。

主要クライアントの比較ポイント

ここではよくある使い方に沿って比較します。ボタンの数が多いから高機能とは限らず、異なるプラットフォーム向けのアプリを同じプロジェクトとして扱うこともできません。インストーラーやメンテナンス状況は変わるため、ダウンロード時には対象プラットフォームのリリース履歴、同梱カーネル、既知の問題を確認しましょう。特定のバージョンを「最新版」として固定して紹介することはしません。

名前が似ているフォークや派生版を混同しないでください。特にFlClashやFlClashsなどは、ダウンロード元のリポジトリと公開者を確認しましょう。スクリーンショットが似ているからといって、同じ更新元を使えるとは限りません。iOSにはAndroid APKを直接インストールできません。別のプロキシクライアントを選ぶ場合は、「プロキシ対応」の表示だけで判断せず、サブスクリプション形式、ルール構文、システムのネットワーク拡張に必要な権限も確認してください。

OSから候補を絞る場合は、クライアント比較もご覧ください。LinuxではDEBとRPM、CPUアーキテクチャの違いにも注意が必要です。DebianやUbuntu向けのパッケージを、Fedoraのパッケージマネージャーでそのままインストールできるわけではありません。

カーネルの機能とメンテナンス状況

プロトコル対応は画面の名前ではなくカーネルで確認

mihomoはClashのルール設定の考え方を引き継ぎながら、プロトコルやネットワーク機能を拡張しています。ただし「mihomoベース」というだけでは十分ではなく、使える設定項目はカーネルのバージョンによって異なります。ノードをインポートできても、接続時に不明な項目、ハンドシェイク失敗、トランスポートパラメーター非対応などのエラーが出る場合は、画面のテーマやテストボタンを何度も変えるのではなく、まずカーネルログを確認してください。

1. クライアントの「バージョン情報」、カーネル管理画面、または起動ログで、クライアントとカーネルのバージョンをそれぞれ記録します。
2. 失敗するノードのtype、トランスポート方式、TLS設定を確認し、そのカーネルのバージョンに対応する設定ドキュメントと照合します。
3. 「設定を読み込めない」場合と「設定は読み込めたが接続できない」場合を分けて考えましょう。前者は構文と対応範囲を優先して確認し、後者はサーバー、DNS、ネットワークを調べます。

メンテナンス状況はリリース日だけで判断しない

直近数回のリリースノートで、カーネル更新、OS対応、権限関連の修正があるか確認しましょう。利用するプラットフォーム向けのパッケージが継続して提供されているかも重要です。画面部分の開発が続いていても、Linuxのサービスインストールに関する問題が解決済みとは限りません。リリース間隔が長いという理由だけで、メンテナンス終了と判断するのも早計です。

• 以前の状態に戻せるか：更新前に旧インストーラーと設定をバックアップし、上書きインストール以外の復旧手段も確保しましょう。
• 利用中の問題が修正されているか：リリースノートで、DNS、スリープ復帰、TUN、サブスクリプション更新に関する修正を重点的に確認します。
• 配布元に一貫性があるか：クライアントの更新元、カーネルの入手元、手動ダウンロード先を確認し、出所不明の実行ファイルに置き換えないでください。

TUNとシステムプロキシの使い分け

システムプロキシは、その設定に従うアプリに対し、リクエストをローカルのプロキシポートへ送るよう指示します。TUNは仮想ネットワークインターフェースとルーティングを使って、より広範囲のIP通信を処理します。システムプロキシを参照しないアプリで使われることがあります。TUNは通信速度を上げるためのスイッチではありません。ルーティング、DNS、権限が適切でないと、かえってトラブルシューティングが複雑になります。

Linuxデスクトップではサービスの権限を確認

TUNを使うために、GUI全体をroot権限で常時実行しないでください。クライアントにサービスのインストールや権限付与の手順が用意されている場合は、その方法を優先し、権限が必要な処理は該当するサービスに任せましょう。認証エージェント、サービス管理、パッケージの方式はディストリビューションごとに異なるため、「TUNボタンがある」だけで、そのPCで実行できるとは限りません。

Linuxではip linkでネットワークインターフェースを、ip routeで通常のルーティングを確認できます。ポリシールーティングを使っている場合は、ip ruleと該当するルーティングテーブルも調べてください。仮想インターフェースが表示されただけでは、すべての通信がプロキシ経由になったとは確認できません。リクエストを送信した後、クライアントの接続画面で該当する接続、適用ルール、出力先を確認するのが確実です。

サブスクリプションは更新後の動作も確認

サブスクリプションのインポートは最初の一歩です。クライアントの使い勝手を見極めるには、更新後もノード選択が保持されるか、ローカルルールが上書きされないか、複数のProfileを切り替えたときにポートやDNS設定も切り替わるかを確認しましょう。継続利用を決める前に、手動更新と設定の切り替えを一度ずつ試してください。

リモート設定とローカルの変更を分けて管理

リモートの設定一式には、通常ノード、プロキシグループ、ルールなどが含まれています。ダウンロードしたファイルを直接編集すると、次回の更新で変更が失われることがあります。クライアントのオーバーライド、マージ、スクリプト機能を優先し、最終的にカーネルへ渡される設定も確認してください。配列の処理方法はクライアントによって異なり、置換、追加、先頭への挿入などがあります。確認せずに同じオーバーライドファイルをすべてのクライアントへ流用しないでください。

• ルールの順序：ルールは通常、上から順に評価されます。カスタムのDIRECTルールを最後のMATCHより後ろに置くと、意図したとおりに適用されません。
• プロキシグループの参照：ローカルルールで参照するグループ名が、現在の設定に存在することを確認してください。サブスクリプションの切り替え後に参照先が無効になることがあります。
• 更新間隔：個人で日常利用する場合は、まず24時間に設定し、提供元の指定に応じて調整しましょう。「すぐ更新したい」からといって、毎分リクエストする必要はありません。
• プライバシー：サブスクリプションURLにはアクセストークンが含まれることがあります。スクリーンショット、公開ログ、問い合わせ内容に載せる際はURL全体を隠してください。

複数の設定を保存しても自動で統合されるわけではない

家庭用、仕事用、テスト用の3つのProfileを保存しても、通常はそのうち1つを選んで使えるだけで、3つのルールが同時に動くわけではありません。共通ルールを適用したい場合は、クライアントにグローバルオーバーライドがあるか、個別設定のオーバーライドとどの順序で適用されるかを確認しましょう。バックアップにはサブスクリプションの取得元、ローカルルール、スクリプトも含めてください。現在のノード一覧だけでは、元の動作を復元できないことがあります。

同じ手順で操作性を比較

画面のスクリーンショットだけでは、日常の操作にかかる手間はわかりません。候補の各クライアントで、同じ設定をインポートする、同じプロキシグループを切り替える、接続を1つ探す、サブスクリプションを更新する、完全終了後にネットワークが復旧するか確認する、の5項目を試してください。既定の配色ではなく、実際の作業手順を比較できます。

1. 待ち受けポートを確認：以下の例では混合ポートを7890としていますが、すべてのクライアントの既定値を示すものではありません。画面に表示された実際の値に合わせて、コマンドを変更してください。
2. プロキシを明示してテスト：まずTUNを無効にし、コマンドでプロキシを指定して、ローカルポート、カーネル、出力先が一連の通信経路として動作するか確認します。
3. ルールを確認：接続画面で、テストリクエストに適用されたルールとプロキシグループを確認してください。HTTPリクエストが成功しても、意図したノードを経由しているとは限らず、DIRECTが選ばれている場合もあります。
4. 次に通信制御を有効化：コマンドから明示的なプロキシ指定を外し、システムプロキシまたはTUNがどこまで通信を処理するか、それぞれテストします。
5. 終了後の復旧を確認：終了、再起動、スリープ復帰のそれぞれでネットワークを確認します。終了後に、システムプロキシが停止済みのローカルポートを参照していないことも確認してください。

# 例：ローカルの混合ポートは7890に設定済み
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 \
  --max-time 20 --head https://example.com/

# SOCKSテスト：ドメイン名の解決はプロキシ側で実行
curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 \
  --max-time 20 --head https://example.com/

上の接続タイムアウト10秒、全体の制限時間20秒は、テストが長時間停止するのを防ぐための設定で、速度測定の結果ではありません。ノード一覧に表示される遅延は、特定のテスト先へのリクエスト時間を示すことが多く、テストURL、ノードの出口、回線状況によって変わります。ダウンロード帯域の目安としてそのまま扱わないでください。2つのクライアントを比較する際は、ノード、テスト先、ルール、DNS設定を同じ条件に揃えましょう。

PC・スマートフォン別の選び方

Linux・Windows・macOS

Linuxに新規導入する場合は、まずClash Verge Revにディストリビューションとアーキテクチャに合ったパッケージがあるか確認し、サービスの権限設定、トレイ、ログイン時の自動起動を試しましょう。別の画面構成が好みなら、FlClashsの実際のプラットフォーム向けパッケージを入手し、同じ手順で動作を比較できます。WindowsではClash Nyanpasuも候補になります。macOSでは通常のウィンドウ操作とClashX Metaのメニューバー操作を比較し、Appleシリコン向けかIntel向けかも確認してください。

ルールを頻繁に調整する人は、最終設定の表示、ログの絞り込み、オーバーライド管理を重視しましょう。ノードを切り替えるだけなら、わかりやすいプロキシグループ画面、安定したトレイ表示、終了後のネットワーク復旧が重要です。Clash for Windowsから移行する場合は、まず旧設定を保存してください。ただし、古いサービスのパス、キャッシュディレクトリ、システム権限の設定をそのまま引き継がないようにしましょう。

Androidではバックグラウンド動作とネットワーク切り替えを重視

Androidクライアントは通常、VpnServiceを通じてシステムにVPN権限を要求します。この権限はアプリがローカルVPNインターフェースを作成することを許可するもので、リモートVPNサーバーへの接続を意味するわけではありません。通常、同じユーザーや仕事用プロファイルではVPN接続を同時に使用できない場合があります。他のVPNや一部のローカルフィルタリングアプリを併用する際は、競合の有無を確認してください。

• システムの「設定」→「アプリ」→対象クライアント→「バッテリー」で、バックグラウンド動作の制限を確認します。項目名はメーカーによって異なる場合があります。
• Wi-Fiとモバイルデータの両方でテストし、画面をロックした状態でもしばらく待って、バッテリー節約機能によって停止されないか確認してください。
• アプリごとに通信を振り分ける場合は、「選択したアプリのみをプロキシする」と「選択したアプリを除外する」のどちらになっているか確認してください。意味は正反対です。
• 新しい端末では、古い画面に慣れているという理由だけで、メンテナンスが終了したClash for Androidを優先して導入しないようにしましょう。