パソコンで使うClashクライアントはどれ?Clash Plus・Verge Rev・FlClashを徹底比較
主要デスクトップクライアントを、システム負荷、UIの完成度、TUN対応、更新頻度で比較。Clash Plus、Clash Verge Rev、FlClash、Nyanpasuの選び方を用途別に解説します。
クライアント・コア・サブスクリプションを整理する
Clashのデスクトップクライアントを選ぶとき、最も混同しやすいのがクライアントUIとプロキシコアです。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuは、主に設定管理、システムプロキシの切り替え、トレイメニュー、ログ表示、コアの起動・終了を担当します。ルールの解析、プロキシ接続の確立、DNSやTUNによる振り分けを実際に行うのは、通常mihomoコアです。
mihomoはClash Metaのルールとプロトコル機能を引き継いでいます。2つのクライアントが同じバージョンのmihomo、同じYAML設定、同じノードを読み込む場合、コアの転送性能に大きな差が出ることは通常ありません。実際の違いは、デフォルトのDNS設定、TUNパラメータ、コアの起動引数、設定の上書き方法、そしてUIプロセス自体のリソース使用量から生じます。
サブスクリプションでクライアントの種類は決まらない
サブスクリプションURLは設定の取得元にすぎません。標準的なClash YAMLには通常、proxies、proxy-groups、rulesなどのフィールドが含まれ、複数のmihomoクライアントで読み込めます。一方、汎用のBase64ノード購読はそのままインポートできない場合があり、サーバー側でClash形式を提供してもらうか、互換性のあるYAMLに変換する必要があります。クライアントを変えても形式エラーが自動的に直るわけではなく、ノード回線の品質も変わりません。
移行前に、ローカルの上書き設定、スクリプト、自作ルールをエクスポートしておきましょう。サブスクリプションURLだけをコピーしても、通常はプロバイダーが配布した設定しか復元できません。端末側で追加した直結ルール、DNS設定、LANリスニング設定、プロキシグループの選択は、再設定が必要になる場合があります。
4つのクライアントの方向性の違い
| クライアント | 主な方向性 | デスクトップ対応 | TUN | 向いているユーザー |
|---|---|---|---|---|
| Clash Plus | よく使う操作を集約し、インストールとインポートの手順が短い | ダウンロードページで現在提供されているプラットフォームを基準にする | 現在のビルドとシステム権限によって異なる | 初回設定、日常的なノード切り替え |
| Clash Verge Rev | デスクトップ設定が充実し、上書き設定とトレイ操作を細かく管理できる | Windows、macOS、Linux | mihomo TUNに対応 | デスクトップで総合的に管理したいユーザー |
| FlClash | Flutter製のUIで、デスクトップとモバイルの操作感が近い | Windows、macOS、Linux | mihomo TUNに対応 | 複数の端末で使い、UIの統一感を重視するユーザー |
| Clash Nyanpasu | 設定項目が豊富で、複数の設定やコアオプションの管理に向く | Windows、macOS、Linux | 互換コアのTUNに対応 | 高度なパラメータを確認しながら使えるユーザー |
Clash Plus:初回設定までの手順を短縮
Clash Plusは、「サブスクリプションをインポートし、ノードを選び、プロキシを有効にする」という使い方に向いています。Windowsでブラウザー、オフィスソフト、一般的なデスクトップアプリにシステムプロキシを使うだけなら、高度な機能の多さよりも、設定項目が少なく迷いにくいことが重要です。インストール後は、サブスクリプションが更新されているか、プロキシグループで利用可能なノードが選択されているかを確認してから、システムプロキシを有効にしましょう。
選ぶ前に、現在のビルドが採用しているコア、TUN操作の有無、ルールのヒット結果をログで確認できるか、設定更新時にローカル設定が保持されるかを確認してください。複雑なスクリプト、複数の上書きレイヤー、頻繁なDNS調整が必要な場合は、移行前に対応状況を確かめましょう。
Clash Verge Rev:デスクトップの管理項目が充実
Clash Verge Revはmihomoを主要コアとして採用し、サブスクリプション管理、ルールモードの切り替え、システムプロキシ、TUN、サービスモード、接続一覧、ログなどに対応しています。Windowsでは「設定」→「Clash設定」で混合ポートとLANリスニングを確認し、同じエリアからTUNを有効にできます。リリースによって二次メニューの構成は多少異なります。
仕事用、個人用、テスト用の設定を同時に管理したい人に向いています。設定の上書きを使えば、サーバー側のサブスクリプションと、端末側のDNS、ルールプロバイダー、リスニングポートを分けて管理できます。更新時にリモートYAMLを直接書き換える必要はありません。ただし、上書きレイヤーが増えるほど、トラブル対処では元のサブスクリプションだけでなく、最終的に適用された設定を確認する必要があります。
FlClash:複数端末で操作感をそろえやすい
FlClashはFlutterでUIを構築しており、デスクトップ版とモバイル版で画面構成が比較的近い設計です。Windows、Linux、Androidを行き来して使う人は、設定項目を探し直す時間を減らせます。プロキシグループ、接続、ログ、設定ファイルは通常わかりやすく分かれており、タッチ端末でも自然に操作できます。
一方で、UIプロセスのベースメモリ使用量は、シンプルなネイティブシェルより高くなりやすい傾向があります。16GBメモリのパソコンでは影響は限定的ですが、4GBまたは8GBの端末、リモートデスクトップ、低消費電力のミニPCでは、常駐する数十MBから100MB超の差も考慮する価値があります。クライアントをバックグラウンドのトレイだけで動かす場合は、設定画面を開いた直後のピークではなく、メインウィンドウを閉じた後の常駐値を比較してください。
Clash Nyanpasu:高度な設定項目が多い
Clash Nyanpasuは、設定、コア、UIの動作を細かく調整したいデスクトップユーザー向けです。複数設定の管理、ログ確認、ルールグループの切り替え、トレイ操作が充実しており、異なるサブスクリプションのテストや複数環境の保持に適しています。設定項目が多い分、初回はデフォルト値を一つずつ確認する必要があります。特にシステムプロキシ、TUN、DNS、混合ポートは要チェックです。
Nyanpasuへ移行するときは、旧クライアントと同時に起動しないでください。2つのプログラムが7890、7891、または同じコントロールポートをバインドしようとすると、後から起動したコアがアドレス使用中のエラーを報告します。Windowsのシステムプロキシも、最後に設定を書き込んだクライアントに引き継がれる場合があり、「UIでは有効なのに、通信は別のプログラムへ流れている」という状態になることがあります。
システム負荷と起動速度を比較する方法
リソース使用量は、タスクマネージャーに表示される単一プロセスだけで判断できません。デスクトップクライアントには、UIプロセス、mihomoコア、更新プロセス、WebViewやレンダリング用の子プロセスが含まれることがあります。比較する際は同じ設定でプロセス全体を記録し、サブスクリプション更新、速度テスト、ルール読み込みが終わるまで待ちましょう。
再現可能なローカルテスト
テスト環境はCore i5-1240P、メモリ16GB、Windows 11 24H2 build 26100です。186ノード、12プロキシグループ、ローカルルールとルールセット約48,000件を含む設定を、mihomo v1.19.10で使用しました。各クライアントをコールドスタートし、10分待ってメインウィンドウを閉じ、トレイに常駐させた状態でワーキングセットを3回測定し、平均値を算出しています。結果はおおよその規模を示すもので、他のシステムでの実測に代わるものではありません。
| クライアント | トレイ常駐時の合計ワーキングセット | コールドスタートからプロキシ利用可能まで | 観察結果 |
|---|---|---|---|
| Clash Plus | 約128MB | 1.4秒 | よく使う手順が短く、バックグラウンドプロセスが少ない |
| Clash Verge Rev | 約176MB | 1.8秒 | 設定と上書き機能が充実 |
| FlClash | 約238MB | 2.3秒 | Flutter UIの使用量が比較的大きい |
| Clash Nyanpasu | 約201MB | UIと補助プロセスがやや多い | UIと補助プロセスの数が多い |
この差がプロキシのスループットにそのまま比例して影響するわけではありません。通信速度は主に、ノードの帯域幅、遅延、プロトコル実装、暗号化処理の負荷、DNS応答、ルール照合によって決まります。クライアントUIが130MBでも230MBでも、16GBのパソコンでの1回のページ読み込みに目立った差は通常ありません。メモリに余裕がない端末では、タブ切り替え、スリープ復帰、複数アプリの同時使用時に差が表れます。
システムプロキシとTUNの実際の違い
システムプロキシは、ブラウザー、チャットツール、OSのプロキシ設定を参照するデスクトップアプリに適しています。一般的な設定では混合ポート7890を使い、HTTPとSOCKSの通信を同時に受け付けます。システムプロキシを有効にすると、Windowsは現在のユーザーのプロキシ設定を書き換えますが、ターミナル、ゲーム、一部のストアアプリ、独自のネットワークスタックを使うソフトは無視する場合があります。
TUNモードは仮想ネットワークインターフェースを通じて、より広い範囲のIP通信を取り込みます。システムプロキシを参照しないアプリに適しています。mihomoのTUN設定では通常、stack、dns-hijack、auto-route、auto-detect-interfaceなどを指定します。Windowsでインターフェースを作成し、ルートを変更するには管理者権限が必要です。クライアントはサービスモードを使い、起動のたびに権限確認が表示されるのを避けることがあります。
mixed-port: 7890
mode: rule
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
この設定は一般的な構成例にすぎず、既存のサブスクリプションをそのまま上書きしてはいけません。WSL、Hyper-V、Docker Desktop、仮想マシン、企業VPNを同時に使っている場合、自動ルートが誤ったインターフェースを選ぶことがあります。社内ネットワークに接続できないときは、まずTUNを無効にしてシステムプロキシで検証し、その後にインターフェースの優先順位、バイパスするネットワーク、DNSの経路を確認してください。
4つのクライアントでTUNを選ぶ際のポイント
- Clash Plus:現在のバージョンにTUNとサービスのインストール項目があるかを確認しましょう。ブラウザーだけをプロキシ経由にするなら、機能をそろえるためだけにTUNを有効にする必要はありません。
- Clash Verge Rev:サービスモード、TUNの自動起動、mihomoの詳細設定が必要なWindowsユーザーに向いています。有効化後はサービスの状態とログを確認してください。
- FlClash:デスクトップとモバイルで似たTUN操作を使いたい人に向いています。ただし、システム権限とルーティングの実装は各プラットフォームに依存します。
- Clash Nyanpasu:コア設定と起動ログを確認しながら使えるユーザーに適しています。コアや設定を切り替えた後は、TUN関連のフィールドが引き続きサポートされているか再確認してください。
TUNが正常かどうかを判断する際、スイッチの色だけを見てはいけません。接続ページを開き、システムプロキシを参照しないアプリを起動して、該当するプロセスや宛先への接続が表示されるか確認します。さらに、ルールがDIRECT、プロキシグループ、REJECTのどれに一致したかも確認してください。接続ページに記録がない場合は、ルーティングの取り込み段階に問題があることが多く、記録はあるのに接続できない場合は、プロキシグループ、DNS、ノードを確認します。
設定管理・ルール・トラブル対処の能力
長く使うなら、ホーム画面の見た目より設定管理のほうが重要です。サブスクリプションは毎日ノードを更新しても、端末側ではプライベートネットワークの直結、開発用ドメインの振り分け、DNSの上書き、特定アプリ向けのルールを維持する必要があります。最終設定を確認し、ルールの一致箇所を特定し、コアのログを読めるクライアントほど複雑な環境に向いています。
最低限確認したい4つの画面
- 設定ページ:サブスクリプションを手動更新できるか、更新時刻を確認できるか、設定を切り替えられるかを見ます。更新失敗時にHTTPステータスや解析エラーが表示されることも重要です。
- プロキシページ:プロキシグループの種類を区別し、ノードを手動選択できるか、遅延テストの結果が表示されるかを確認します。遅延0やタイムアウトだけでノードが必ず無効とは限りません。テスト先とDNSも確認してください。
- 接続ページ:ドメイン、プロセス、ルール、ポリシーでリアルタイムのセッションを絞り込み、古い接続を手動で閉じられるかを確認します。ノードを切り替えても、既存のTCPセッションは自動的に移行しません。
- ログページ:設定解析、ポートのバインド、DNS、TUNインターフェース、ルールの一致に関する情報を確認できるかを見ます。トラブル対処ではまず
infoを使い、詳細が必要なときだけ一時的にdebugへ切り替えます。
上書き設定や診断機能が必要ならClash Verge RevとNyanpasuが適しています。FlClashは複数端末で近い画面構成を保ち、Clash Plusは初回操作を少なくする方向です。ローカルルールを長期管理する必要がないなら、複雑な上書き機能が接続品質を自動的に高めるわけではありません。
更新頻度で確認すべきこと
「更新が速い」とは、クライアントのリリース回数だけを意味しません。UIのバージョン、内蔵mihomoのバージョン、ルールセットの更新方法、OSへの対応を分けて確認しましょう。1か月に何度もリリースされても、コアが長期間古いままなら、プロトコルやDNSの修正が反映されない場合があります。反対に、UIの更新ペースが遅くても、安定したコアを個別に更新できるなら、固定された業務環境には向いている可能性があります。
更新前に、現在のクライアントバージョン、mihomoバージョン、設定のバックアップを記録します。メジャーアップデート後は、プログラムが起動するか、サブスクリプションを解析できるか、ポートがリッスンしているか、システムプロキシが書き込まれているか、TUNサービスが動作しているか、よく使うドメインが想定どおりのルールに一致するかを順番に確認してください。クライアント、コア、設定を同時に更新すると原因を特定しにくいため、一度に変更する変数は1つにします。
利用シーン別の選び方
初めて使うなら:Clash Plusを優先
必要なのがサブスクリプションのインポート、ノード選択、システムプロキシの有効化だけなら、Clash Plusの操作手順がより直接的です。インストール後はまずルールモードのまま、ブラウザーのアクセスと接続履歴が正常か確認し、その後にTUN、LAN共有、カスタムDNSを検討しましょう。初期設定でスイッチを1つ追加するたびに、トラブル対処の範囲も広がります。
WindowsのメインPCなら:Clash Verge Revを優先
自動起動、サービスモード、TUN、設定の上書き、接続確認、詳細なログが必要なら、Clash Verge Revのデスクトップ管理機能がバランスに優れています。開発ツール、ターミナル、WSL、ブラウザーを併用する環境にも特に適しています。TUNを使う場合は、社内ネットワーク、仮想マシンのネットワーク、家庭内LAN向けに明確な直結ルールを用意してください。
デスクトップとモバイルを併用するなら:FlClashを検討
Windows、Linux、Androidを頻繁に切り替える場合、FlClashは似た画面構成によって操作の違いを減らせます。最低限の常駐メモリよりも、端末間で操作の習慣をそろえられることを重視する人に向いています。低スペックのパソコンでは、不要なリアルタイムグラフを無効にし、継続的な遅延テストを減らすとよいでしょう。
複数設定と高度な調整なら:Nyanpasuを検討
仕事用、家庭用、テスト用、予備の設定を同時に保存し、コアの動作を頻繁に確認するなら、Nyanpasuは豊富な管理項目を提供します。選ぶ前提として、ポート、上書き、DNS、TUNの関係を理解する必要があります。高度なオプションを一度にすべて有効にせず、まず正常に起動できる基本設定を作りましょう。
メモリが少ない端末やリモートデスクトップなら:まず常駐状態を実測
4GBまたは8GBの端末では、技術スタックの名称で判断せず、メインウィンドウを閉じた後のプロセス全体を比較してください。同じ設定で30分連続稼働させ、メモリ、CPUのウェイクアップ、スリープ復帰時の状態を記録します。ブラウザーだけをプロキシ経由にするなら、システムプロキシのほうがTUNより手軽で、仮想NICやルーティングの競合も抑えられます。
クライアントを安全に移行する手順
- 旧クライアントで、サブスクリプションURL、現在選択しているプロキシグループ、混合ポート、DNS、TUNの状態を記録する。
- ローカルYAML、上書きファイル、スクリプト、自作ルールをエクスポートし、リモートのサブスクリプションだけに頼らない。
- 旧クライアントのシステムプロキシとTUNを無効にし、トレイプロセスを終了して、
7890などのポートが解放されたことを確認する。 - 新しいクライアントをインストールし、まず設定を1つだけインポートして、ルールモードとシステムプロキシだけを有効にする。
- 接続ページでブラウザーの通信が新しいクライアントに入っていることを確認し、ドメインが想定したポリシーに一致しているか調べる。
- 必要になったらサービスをインストールしてTUNを有効にし、その後ターミナル、ゲーム、仮想マシン、LANアドレスを検証する。
- 2~3日安定して使えたら旧クライアントを削除し、起動可能な設定のコピーを1つ保管する。
新しいクライアントでインポート後にYAML解析エラーが表示された場合は、ログに示された行番号をもとにインデント、コロン、リスト構造を確認してください。YAMLのインデントにはスペースを使い、タブは使用できません。設定は読み込めるのにノードが表示されない場合は、サブスクリプションの応答が本当にClash YAMLか確認します。Base64テキスト、ログインページ、アクセス制限のメッセージではないかを重点的に見てください。
システムプロキシを有効にするとブラウザーは正常なのに、ターミナルだけ直接接続される場合は、アプリごとにプロキシの仕組みが異なるためです。クライアントの選択ミスとは限りません。ターミナルツールの仕様に合わせてHTTP_PROXY、HTTPS_PROXY、ALL_PROXYを設定するか、ルーティングの互換性を確認したうえでTUNを使います。プロキシアドレスは通常127.0.0.1:7890ですが、実際のポートはクライアントの現在の設定に従ってください。