Clash Plus・Clash Verge Rev・FlClashの比較：開発終了後のクライアント選び

対応プラットフォームと用途から候補を絞る

Clash for Windowsの開発元プロジェクトはすでに更新を終了しています。現在の環境を維持することと、新しいPC用のクライアントを選ぶことは別の話です。前者では設定のバックアップと互換性の確認が必要です。後者では、プロジェクトが現在も保守されているか、インストーラーがOSに対応しているかを確認してから、サブスクリプションを正常に読み込めるかを調べましょう。画面が旧版CFWに似ているかどうかは、これらより優先度の低い条件です。

まず選択肢を絞りたい場合は、次の3つの利用シーンを参考にしてください。比較するのは使い方であり、通信速度のランキングではありません。同じ回線で画面だけ変えても、出口の帯域が自動的に増えるわけではありません。

• Windowsデスクトップが中心で、ルールや接続状況をよく確認する：まずはClash Verge Revを試し、サブスクリプション管理、接続の詳細、サービスモードが自分の操作方法に合うかを確認しましょう。
• スマートフォンとPCで近い操作感を求める：Clash PlusとFlClashシリーズを候補にできます。ただし、保守状況、必要な権限、機能の範囲はプラットフォームごとに確認してください。
• ブラウザーだけでプロキシを使う：まずはシステムプロキシで動作を確認しましょう。ゲームやコマンドラインツールなど、システムプロキシに従わないアプリがある場合にTUNを検討すれば十分です。最初からすべての詳細設定を有効にする必要はありません。

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

まず使用する端末を決めてから、機能を比べましょう。以下の対応プラットフォームは当サイトのダウンロードページの分類に基づくもので、すべてのプラットフォームで設定編集、バックグラウンド動作、トラフィック制御の機能が同じとは限りません。実際のインストール要件は各配布版のリリース情報を確認してください。

Windows：接続の詳細を確認できるか

デスクトップで問題を切り分ける際は、テーマカラーより接続一覧のほうが役立つことがよくあります。対象のWebサイトを開き、接続先のドメイン、適用されたルール、最終的なポリシーを確認しましょう。「接続済み」としか表示されず、どのノードを経由したか判断できないと、ルール振り分けの問題を調べるのに手間がかかります。Clash Verge Revでは、設定、プロキシ、接続、ログの順に確認すると効率的です。バージョンによって日本語メニューの名称が多少異なる場合があります。

スマートフォン：バックグラウンド動作とOSの制限を確認

Androidクライアントは通常、システムのVPNインターフェースを使って通信を制御するため、初回起動時に接続許可を求められます。iOSもネットワーク拡張機能やバックグラウンド動作の制限を受けます。スマートフォンにVPNアイコンが表示されても、すべての接続がリモートノードを経由するとは限りません。また、サブスクリプションが従来型の企業向けVPNサービスを提供するという意味でもありません。実際の経路はルーティングと振り分けルールによって決まります。

会社のVPNに接続する必要がある場合は、プロキシクライアントと同時に利用できるかを先に確認してください。特にスマートフォンでは、システムのVPN経路を使うアプリを2つ同時に期待どおり動作させるのは難しいことがあります。デスクトップでもルーティング、DNS、仮想ネットワークアダプターが競合する可能性があります。「TUN対応」を「どのVPNとも共存できる」と解釈しないでください。

画面の名称よりカーネルの互換性が重要

クライアントはウィンドウ表示、サブスクリプション管理、OSとの連携を担当し、プロキシカーネルはプロトコル接続、ルール照合、通信処理を担当します。mihomoはClash.Metaプロジェクトに由来するもので、旧版Clashカーネルと単純に同一視できません。Clash Verge Revと一般的なFlClash配布版はmihomoを使用していますが、実際に搭載されているカーネルのバージョンはインストールした版で確認してください。クライアント名だけでは判断できません。

Clash Plusについても、使用するプラットフォーム版で公表されているカーネルとプロトコルの対応状況を確認しましょう。Clash形式のサブスクリプションを読み込めるからといって、mihomoの拡張フィールドすべてに対応しているとは限りません。新しいプロトコル、転送パラメーター、ルール機能を含むサブスクリプションは、古いカーネルでは読み込みに失敗したり、一部の項目だけが反映されたりすることがあります。

1. アプリとカーネルの両方のバージョンを記録：クライアントの「バージョン情報」、カーネル情報、または起動ログで、アプリとカーネルそれぞれのバージョンを控えてください。問題を報告する際、アプリ名だけでは情報が足りません。
2. 読み込みログを確認：未対応のプロキシタイプ、フィールドの解析エラー、設定の検証エラーが表示されたら、まず該当するエラー行を確認してください。システムプロキシのスイッチを何度も切り替えても解決しません。
3. サブスクリプションの出力形式を確認：サブスクリプションサービスがClash形式とmihomo形式を分けている場合は、現在のカーネルに合った形式を選びましょう。URLのパラメーターを適当に変更しないでください。
4. 実際のノードを確認：プロキシグループが表示されても、ノードが使えるとは限りません。少なくとも1つのノードを選んで目的のサービスにアクセスし、接続が想定したポリシーに一致するかを確認しましょう。

システムプロキシとTUNは分けて考える

CFWユーザーにおなじみの設定項目はGeneral → System Proxyです。有効にすると、Windowsのシステムプロキシ設定に従うアプリがローカルのプロキシポートに接続します。新しいクライアントの「システムプロキシ」も目的はほぼ同じですが、ボタンの位置や初期ポートは異なる場合があります。旧環境の127.0.0.1:7890を、新しいクライアントの実際の待ち受けアドレスだと思い込まないでください。

システムプロキシ：まずブラウザーで動作確認

Windows 11で「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスとポートをクライアントに表示されるポートと比べます。たとえば、クライアントが7890で待ち受けているのに、システム設定が旧アプリの7897を指していると、クライアントが起動していてもWebページにアクセスできないことがあります。これらはトラブルシューティング用の例で、3つのクライアントに共通する初期値ではありません。

TUN：通信経路を取り込む機能であり、すべての通信をノード経由にする機能ではない

TUNは仮想ネットワークインターフェースを作成し、ルーティングと組み合わせて、対象となる通信をカーネルに送ります。カーネルに届いた後も、ルールに応じて直接接続、プロキシ経由、拒否を選択できます。つまり、「TUNが有効」と「グローバルプロキシモード」は別の設定です。また、TUNがすべての通信を自動的に取り込むわけではなく、ルーティングの除外設定、IPv6、ほかのネットワークアダプターが影響することがあります。

• Windows：サービスモードや権限補助コンポーネントがインストールされ、実行中かを確認してください。画面を一度管理者権限で起動しても、バックグラウンドサービスが正しくインストールされたとは限りません。
• DNS：現在の設定で、名前解決方式、DNSの横取り範囲、仮想ネットワークアダプターが連携しているか確認してください。ドメインにアクセスできないからといって、fake-ipとredir-hostをむやみに切り替えないでください。
• UDP：TUNを使うと一部のUDP通信をカーネルに通せますが、最終的に転送できるかどうかは、ノードのプロトコル、サーバー側の設定、ネットワーク環境にも左右されます。
• 動作確認：システムプロキシに従わないアプリを1つ選んで接続し、クライアントの接続一覧で通信を確認してください。スイッチの色が変わっただけで成功と判断しないでください。

クライアントを選ぶ際は、候補ごとに同じ手順で確認できます。まずTUNを無効にし、システムプロキシだけでブラウザーの動作を確認します。その後、そのバージョンのドキュメントに従ってサービスとTUNを有効にし、対象アプリでテストします。最初の段階で失敗した場合は、サブスクリプション、ポート、ノードを先に確認しましょう。すぐに仮想ネットワークアダプターの問題を調べる必要はありません。

CFWからの移行：設定は引き継ぎ、実行環境はそのまま移さない

旧環境では、Profilesで設定を管理し、Proxiesでポリシーを切り替え、Connectionsで接続を確認します。クライアントを変える際は、この3つに相当する機能を探しましょう。ただし、旧フォルダー全体を新しいプログラムのフォルダーに上書きしてはいけません。画面用データベース、サービスのパス、拡張スクリプトの形式が異なることがあります。コピーできても正常に動くとは限りません。

1. まずバックアップ：サブスクリプションの配布元、ローカルのYAML、自作ルール、旧版のMixinやParsersなどの変更内容を保存してください。機密情報を含む設定は、安全に管理できる場所に保管します。
2. 旧クライアントを停止：CFWでSystem ProxyとTUNを無効にしてから、プログラムを終了します。バックグラウンドサービスをインストールしたことがある場合は、ポートを占有したりルーティングを制御したりしていないか確認してください。
3. 元のサブスクリプションを読み込む：新しいクライアントにサブスクリプションを追加するか、ローカルファイルを読み込みます。まずは元の設定で起動し、上書き設定をすべて一度に移行するのは避けましょう。
4. モードとポリシーを確認：まずルールモードを選び、次にプロキシグループの選択を確認します。プロキシグループ名が変わると、旧クライアントに保存されていたノードの選択が引き継がれないことがあります。
5. カスタム設定は少しずつ戻す：一度に移行するのはルール1セット、または上書き設定1つに絞ります。サブスクリプションを更新した後も、設定が有効か確認してください。

ダウンロード時に生成された設定ファイルを直接編集すると、次回のサブスクリプション更新で上書きされることがあります。新しいクライアントが提供する上書き・マージ機能を使い、マージ後の実際の設定を確認しましょう。配列の置き換え、ルールの追加、フィールドの優先順位はクライアントごとに異なる場合があります。旧スクリプトをそのまま貼り付けると、画面上では保存できてもルールが反映されないことがあります。

新旧のプログラムがどちらも7890で待ち受けている場合、後から起動した側でポート競合が発生することがあります。旧クライアントを終了するか、新しいクライアントに未使用のポートを一時的に設定してください。変更後はシステムプロキシとコマンドライン環境変数も確認します。設定の数値だけを変更しても、すべてのアプリに反映されたとは限りません。

同じ条件で試す：安定性とトラブル対応の手間を比較

これらのクライアントに、回線条件を無視した共通の速度ランキングはありません。比較する際は、同じ端末、ネットワーク、ノード、接続先サービス、ルールモードにそろえてください。遅延テストの接続先も統一しましょう。異なるリクエストで測定された数値を、そのまま比較することはできません。

表に記載した回数と時間は試用手順の目安であり、当サイトで測定した結果ではありません。スループットを比較する場合は順番にテストし、複数のダウンロードを同時に実行して帯域を圧迫しないようにしてください。DNSモード、スニッフィング、ルール設定も両方でそろえましょう。設定が異なると、比較している通信経路そのものが違う可能性があります。

最終的な選択と元に戻す条件

• Windowsデスクトップで長期利用する：まずClash Verge Revを試しましょう。初回接続の成否だけで判断せず、サービスモード、接続の詳細、サブスクリプションの上書き設定、スリープからの復帰を確認項目に含めてください。
• スマートフォンとデスクトップの両方で使う：Clash PlusとFlClashシリーズを、それぞれのOS上で実際に操作して比較しましょう。ダウンロード元、プラットフォーム別パッケージ、カーネル情報を確認し、デスクトップの設定がすべてスマートフォンに同期されると思い込まないでください。
• 複雑なルールや新しいプロトコルが必要：画面を選ぶ前に、カーネルの対応状況を確認してください。設定の検証が通ること、ルールが適用されること、ログで問題を把握できることは、クライアント名より重要です。
• 旧CFWを特定の用途で使い続ける：設定のバックアップを保管し、新しいクライアントで個別に動作を確認してから移行してください。旧プロジェクトの更新終了後は、OSとの互換性やプロトコル対応が今後も修正されるとは限りません。

移行後は新しいクライアントを終了し、Windowsのプロキシ設定が元に戻っていることを確認してから、もう一度起動して動作を検証してください。終了後も127.0.0.1のプロキシ設定が残っていて、PC上で該当ポートを待ち受けるプログラムがない場合、通常のWebページも開けなくなることがあります。通信を正常に制御できること、接続先を説明できること、完全に終了できることの3点を確認してから、日常利用のクライアントに設定しましょう。フィールドを詳しく確認する場合は設定リファレンスを、対応プラットフォームとインストール要件はクライアント比較をご覧ください。