Clash Plus・Clash Verge Rev・FlClashの選び方：プラットフォームと使い方で比較

まず対応デバイスで使えないクライアントを絞り込む

Clash クライアントを選ぶとき、最初に比べるべきは画面ではなく、どのデバイスをカバーする必要があるかです。Clash Plus は Windows、macOS、Android、iOS に対応し、Clash Verge Rev は主に Windows、macOS、Linux のデスクトップ向けです。FlClash は Windows、macOS、Linux、Android をカバーします。1台のパソコンだけで使うなら3製品の重なりは大きい一方、パソコンとスマートフォンを一緒に管理するなら、対応プラットフォームが選択肢を直接左右します。

クライアント、コア、サブスクリプションサービスは、それぞれ異なる層のものです。クライアントはGUI、設定ファイル管理、システムプロキシの切り替え、TUN権限、ログへの入口を担います。mihomo などのコアは YAML の解析、接続の確立、ルールに基づくトラフィック処理を担当します。サブスクリプションサービスはノード、プロキシグループ、ルール設定を提供します。クライアントをインストールしただけで利用可能なサブスクリプションが自動生成されるわけではなく、サブスクリプションを読み込んでも端末の通信がすぐに引き継がれるわけではありません。

よくあるデバイス構成からすばやく判断する

• Windows 10 または Windows 11 の単独利用：3つとも次の比較候補にできます。設定編集、TUN、更新方法を重点的に確認しましょう。
• macOS のパソコン：まず「Apple メニュー」→「この Mac について」でチップを確認します。Apple Silicon は通常 arm64、Intel モデルは x64 を選びます。
• Ubuntu、Debian、Fedora などの Linux デスクトップ：Clash Verge Rev と FlClash を優先して比較します。Debian、Ubuntu では .deb、Fedora、RHEL 系では .rpm が一般的です。
• Android スマートフォンと Windows パソコン：Clash Plus または FlClash なら同じクライアント構成にしやすいですが、両方の端末で設定を個別に読み込み、更新する必要があります。
• iPhone または iPad：3製品の中では、まず Clash Plus の iOS インストール方法と現在のシステム要件を確認します。Windows 向けのインストール手順を iOS にそのまま適用しないでください。

設定管理の習慣で選ぶ：調整を少なくするか、頻繁に調査するか

サブスクリプションを1つ読み込み、ノードを選んでシステムプロキシを有効にするだけなら、設定項目の多さではなく、入口が分かりやすいかを基準にします。基本的な流れは「サブスクリプション」または「設定」→「追加」→サブスクリプションURLを貼り付け→設定をダウンロード→現在の設定として適用し、その後「プロキシ」画面でプロキシグループを選択します。バージョンによっては Profile が「設定」「サブスクリプション」「設定ファイル」などと訳されている場合があります。機能の場所は同じでも、名称が完全に一致するとは限りません。

ルール、DNS、オーバーライドを頻繁に調整する場合は、リモートサブスクリプションとローカル変更を明確に分けられるかを確認します。サブスクリプションの更新では通常、リモート YAML が再取得されます。ダウンロード後の設定を直接編集すると、次回更新で変更が上書きされる可能性があります。より安全なのは、クライアントのオーバーライド、マージ、スクリプト機能を使うか、ローカル設定として複製して自動更新を止める方法です。対応機能はインストールしているバージョンの設定画面で確認してください。

Clash Plus：複数デバイスでの利用を優先

Clash Plus を選ぶ主な理由は、対応プラットフォームの広さです。Windows、macOS、Android、iOS で似た操作手順を使いたい場合、クライアントの構成を覚え直す負担を減らせます。ただし、実際の利用では各端末で個別に権限を設定する必要があります。デスクトップではシステムプロキシ設定を参照するアプリに作用し、モバイル端末では通常、システムVPNインターフェースを通じて通信を引き継ぎます。両者は同じ仕組みではありません。

日常の操作がサブスクリプションの更新、プロキシグループの選択、接続だけなら、3か所を確認します。現在有効な設定、プロキシグループの選択内容、通信の取り込みスイッチです。ノードの遅延値だけを見ないでください。遅延テストで結果が返っても、テスト先に到達できたことを示すだけで、ブラウザー、ターミナル、その他のアプリがプロキシを経由しているとは限りません。

Clash Verge Rev：デスクトップ設定と診断を優先

Clash Verge Rev は、パソコンを主な操作端末として使うユーザーに向いています。デスクトップ環境では、サブスクリプション、プロキシグループ、接続履歴、コアのログを同時に確認できます。ルールが一致しない、DNSに失敗する、ポートが使用中といった問題では、接続スイッチだけでなく調査用の入口が重要です。Linux ユーザーは、デスクトップセッションがシステムプロキシを読み取っているかも確認してください。コマンドラインのプログラムは通常、デスクトップのプロキシ設定を自動継承しません。

コアのパラメーターを変更する場合は、まず設定が属する層を見分けます。たとえば「設定」→「Clash 設定」にあるポートやモードは通常、コアの動作に影響します。一方、「設定」→「システム設定」にある自動起動やウィンドウ動作はクライアント自体の設定です。メニューの文言はバージョンによって変わるため、変更前に元の値を記録し、一度に1項目だけ変更すると安全です。

FlClash：デスクトップと Android の操作統一を優先

FlClash は、デスクトップOSと Android を併用し、似た画面構成で操作したいユーザーに向いています。ただし、端末間で接続状態を自動共有するわけではありません。各端末には独立した設定のコピー、権限、ローカルポートがあります。モバイル端末でネットワークを変更した後は、VPNの状態、DNSの名前解決、バックグラウンド動作の制限も確認してください。

Android のインストーラーをダウンロードするときは、アーキテクチャを区別する必要があります。近年の主流スマートフォンは通常 arm64 ですが、メーカー名だけで判断しないでください。システム情報ツールまたは端末の仕様ページで ABI を確認できます。universal パッケージがあれば複数のアーキテクチャをカバーできますが、ファイルサイズは大きくなる場合があります。デスクトップでは Windows、macOS、Linux に対応する形式を選びます。

システムプロキシと TUN の違いが最終的な選択を左右する

システムプロキシと TUN は、単純な「通常モード」と「強化モード」の関係ではありません。システムプロキシは通常、OSの HTTP および SOCKS プロキシ設定に値を書き込みます。ブラウザーやシステム設定に従うデスクトップアプリはその値を読み取ります。TUN は仮想ネットワークインターフェースを作成し、より広い IP トラフィックをコアへ送ります。TUN が必要かどうかは、アプリがプロキシに対応しているか、UDP 通信があるか、システムプロキシを読み取らないプログラムを処理する必要があるかで決まります。

まずポートでコアが実際に待ち受けているか確認する

多くの設定では HTTP ポートに 7890、SOCKS ポートに 7891 が使われます。また、HTTP と SOCKS を同時に受け付ける mixed-port 7890 を使うクライアントもあります。ポート番号は固定規格ではないため、現在の設定またはクライアントの設定画面に表示される値を基準にしてください。ターミナルで一時的に HTTP プロキシを確認する場合は、ポートを確認してから次を実行します。

curl -x http://127.0.0.1:7890 https://example.com/

ここで 127.0.0.1:7890 への接続失敗が表示されたら、まずコアが起動しているか、ポートが変更されていないか、別のプロセスに使われていないかを確認します。リクエストは成功するのに通常の curl が失敗する場合、問題はサブスクリプションではなく、ターミナルがシステムプロキシを使っていないことにあるのが一般的です。Linux と macOS のターミナルでは、必要に応じて一時的に次を設定できます。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5h://127.0.0.1:7891

socks5h は、接続先ホスト名の名前解決を SOCKS プロキシ側で行うことを示します。確認が終わったらターミナルを閉じるか、unset HTTP_PROXY HTTPS_PROXY ALL_PROXY を使って現在のセッション変数を削除できます。Windows PowerShell の環境変数構文は異なるため、Bash のコマンドをそのままコピーしないでください。

TUN を有効にする前に確認する4項目

1. まずシステムプロキシで、サブスクリプション、ノード、基本ルールが機能することを確認します。設定ミスを TUN の障害と誤認するのを防げます。
2. 他のVPN、仮想ネットワークアダプター、コンテナネットワーク、企業向けセキュリティクライアントが同時に動いていないか確認します。これらのツールがデフォルトルートやDNSを共同で変更する場合があります。
3. Windows では管理者権限とサービスのインストール状態を確認します。macOS では「システム設定」→「ネットワーク」→「VPNとフィルタ」の許可を確認します。Android では、システムステータスバーにVPNマークが表示されているか確認します。
4. 有効にした後は、DNS、LAN内デバイスへのアクセス、プロキシが必要なアプリを再テストします。クライアントのホーム画面に「実行中」と表示されているかだけで判断しないでください。

ルール、プロキシグループ、コアの機能はクライアント名だけでは判断できない

Clash Plus、Clash Verge Rev、FlClash はいずれも設定と実行の入口であり、実際にルールを処理するのは組み込まれている、または呼び出されるコアです。設定を読み込めるかどうかは、YAML ファイルの拡張子が同じかではなく、コアのバージョンが該当フィールドに対応しているかで決まります。クライアントを移行するときは、起動ログに出る設定エラーを確認し、特に DNS、プロキシプロトコル、ルールプロバイダー、TUN のフィールドに注意します。

ルールモードでは上から順に評価され、最初に一致したルールで行き先が決まります。次の例は順序の関係を示すものですが、PROXY はサブスクリプションまたは利用者がプロキシグループ内で定義する必要があり、単独でコピーしてもそのまま使えません。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN,blocked.example,REJECT
  - MATCH,PROXY

DIRECT は直接接続、REJECT はリクエストの拒否、MATCH はそれまでのルールに一致しなかった場合の最終的な行き先を示します。no-resolve は、この IP ルールを照合するときにドメインのアドレスを積極的に解決しないことを示すだけで、すべての DNS を無効にするものではありません。クライアントを切り替えて同じサイトの経路が変わった場合は、現在のモード、実際に読み込まれた設定、ルールの順序、プロキシグループで選択された出口を順に確認します。

遅延ランキングを設定確認の代わりにしない

ノード一覧の遅延は通常、クライアントが指定されたテストURLへ1回リクエストして得た値です。テスト先、ネットワークの揺らぎ、DNS、接続の再利用によって数値は変わります。あるノードが 80 ms と表示されても、120 ms のノードより必ずダウンロード速度が速いとは限りません。より確実なのは、実際の接続先を継続的にテストし、接続画面で対象ドメインが想定したルールとプロキシグループに一致していることを確認する方法です。

ルールを頻繁に調査するユーザーにとっては、接続履歴、ルール名、プロキシチェーン、エラーログを表示できるかどうかが、ホーム画面の簡潔さより重要です。基本的な閲覧だけなら、少数の高度な項目のために追加のメンテナンス負担を抱える必要はありません。選択は機能数を一律の点数に置き換えるのではなく、日常の操作頻度を基準にします。

更新、移行、バックアップの方法が長期的な管理コストを左右する

クライアントの更新とサブスクリプションの更新は別物です。クライアント更新ではアプリ本体と、場合によっては付属するコアが置き換わります。サブスクリプション更新ではリモート設定だけが再ダウンロードされます。問題が起きたら、まず最近変わった層を判断します。アプリのアップグレード後に起動できないなら、クライアントのログとシステム権限を確認します。サブスクリプション更新後にプロキシグループが消えたなら、リモート設定の内容を確認します。特定のノードだけ失敗するなら、同じ設定内で別のノードに切り替えて検証します。

移行前に保管しておく情報

• サブスクリプションURL、またはサービス提供元が用意した再インポート用の入口。クライアントのキャッシュだけに頼らないでください。
• ローカル YAML、オーバーライドルール、スクリプト、カスタム DNS 設定。
• HTTP、SOCKS、mixed-port、LANアクセスの許可スイッチの現在値。
• よく使うプロキシグループの選択内容。手動ノード、自動選択、直接接続など。
• TUN の有効・無効、サービスのインストール状態、LANとプライベートネットワーク範囲の除外設定。

あるクライアントから別のクライアントへ移行するときは、まず旧クライアントを残したまま、システムプロキシと TUN を無効にしてから新しいクライアントを起動します。2つのコアで 7890 を同時に取り合ったり、システムプロキシを同時に変更したりしないでください。新しいクライアントへの読み込みが終わったら、ブラウザーのリクエスト、ターミナルのリクエスト、TUN が必要なアプリを1つずつテストし、その後で旧クライアントを削除するか判断します。

サブスクリプションにはアクセス認証情報が含まれるため、公開ログ、スクリーンショット、質問文に貼り付けないでください。障害情報を共有するときは、ルールの種類、エラー行番号、ポート、コアのバージョンを残し、サブスクリプションURL、ノードサーバーのアドレス、認証フィールドは隠します。これなら問題の層を説明しながら、そのまま使える設定内容の漏えいを防げます。

ワークフロー別に選び方を整理する

Clash Plus を選ぶケース

• iOS もカバーしたい、または Windows、macOS、モバイル端末で似た操作手順を使いたい。
• 主な操作はサブスクリプションの読み込み、プロキシグループの切り替え、接続の開始・停止で、複雑なオーバーライドを頻繁に編集しない。
• 各端末でシステム権限、VPN設定、サブスクリプション管理を個別に行える。

Clash Verge Rev を選ぶケース

• 主に Windows、macOS、Linux のデスクトップで使い、設定、接続、ログの確認を重視する。
• システムプロキシと TUN を区別し、ポート、DNS、ルール一致の問題を頻繁に特定する必要がある。
• システムアーキテクチャに合うインストーラーを選び、アップグレード後にコアと設定の互換性を確認できる。

FlClash を選ぶケース

• Android とデスクトップOSを組み合わせて使い、プラットフォーム間の画面差を減らしたい。
• Windows、macOS、Linux、Android のうち複数のプラットフォームで利用したい。
• 各端末の設定は独立していることを理解し、Android のVPN権限とデスクトップのプロキシ設定を個別に確認できる。

まだ決められないときの20分テスト

1. 現在のシステムとチップアーキテクチャに合うクライアントをインストールする。
2. 同じサブスクリプションを読み込み、設定のダウンロードにかかる時間と、エラー表示の分かりやすさを記録する。
3. 同じノードを選び、システムプロキシを有効にして、ブラウザーと curl でそれぞれテストする。
4. 接続履歴に対象ドメイン、適用されたルール、最終的なプロキシ設定が表示されるか確認する。
5. 必要な場合だけ TUN を有効にし、UDP アプリ、LAN内デバイス、DNS をテストする。
6. サブスクリプションを1回更新し、ローカルのオーバーライドとプロキシグループの選択が想定どおりか確認する。

最終的な選択はシンプルです。モバイル端末への対応を優先するなら Clash Plus または FlClash、デスクトップでの診断と設定管理を重視するなら Clash Verge Rev、Android とデスクトップで操作を揃えたいなら FlClash を重点的に比較します。クライアントはサブスクリプション自体の品質を変えず、ルールや権限の確認に代わるものでもありません。まずプラットフォームで候補を絞り、システムプロキシ、TUN、ログ、メンテナンス頻度で選ぶほうが、テスト条件のない点数を比べるより通常は有効です。