Clash for Windows 終了後の対応:代替クライアント選定と移行手順

なぜ Clash for Windows の継続利用はおすすめできないのか

Clash for Windows(略称 CFW)は、Windows 向けとして早くから普及していたGUIクライアントで、オリジナルの Clash コアに依存しています。オリジナル Clash コアが2023年に開発終了となった後、CFW の更新も止まりました――現在ダウンロードできるバージョンの多くは古いコア分岐のままで、プロトコルの互換性修正も新しいルール記法への対応も行われていません。

旧版の CFW を使い続けると、いくつかの実際的な問題に遭遇します。新しく配布されたサブスクリプションノードのプロトコル(独自のトランスポート層パラメータなど)が正しく解析できないケースがある、ルールセット内の新しい記法(RULE-SET の遠隔ルール組み合わせやプロセス名マッチングなど)が旧コアでは無視されたりエラーになったりする、新しいOSバージョンでの TUN モードのドライバ互換性も誰も修正を追いかけていない、といった点です。これらの問題は短期的には目立たないこともありますが、サブスクリプション事業者が設定フォーマットを更新するたびに、旧クライアントの負担は増えていきます。

現在 Windows 向けで積極的にメンテナンスされている代替策は、主に mihomo コアを中心に展開されています――これはコミュニティがオリジナルの Clash コアをベースに開発を継続しているフォークで、プロトコル対応を補完し、多くの過去の不具合を修正しています。本記事で紹介する3つのクライアントも、いずれもこのエンジンを採用しています。

代替クライアント3選を比較

移行は「とりあえず使えるものを入れればいい」というものではなく、クライアントごとに操作ロジック、ルール編集方式、リソース消費に少なくない違いがあります。以下は実際に使用した感触に基づく簡単なレビューで、具体的なバージョン番号やコアのパラメータはダウンロードページの最新情報を参照してください。

Clash Plus

画面がシンプルで導入の敷居が低く、サブスクリプション管理とノード切り替えも簡略化されているため、設定ファイルをいじりたくないユーザーに向いています。ルール編集はビジュアルパネル方式で、YAML を手書きしなくても日常的な調整の大半は完了できますが、深い部分のカスタマイズ性は相対的に限られます。CFW から移行しつつも設定の記法を深く追求する予定のないユーザーに向いています。

Clash Verge Rev

コミュニティの活発度が最も高い選択肢の一つで、mihomo コアをベースに構築されており、ルールエンジンの動作も安定しています。設定ファイルのビジュアル編集と手動編集の両モードを切り替えられるため、GUI を使いたいけれど設定ファイルの制御権も手放したくないユーザーに向いています。デスクトップ3プラットフォーム(Windows/macOS/Linux)でほぼ同じ操作感が得られ、CFW からの移行で互換性の問題が最も少ないルートの一つです。

FlClash

対応プラットフォームの範囲がさらに広く、デスクトップとモバイルで操作体験が統一されています。画面デザインは軽量志向で、複数デバイス間で操作の一貫性を保ちたいユーザーに向いています。ルール編集も同様にグラフィカルな操作に対応し、コアの更新追随ペースも安定して継続しています。

3つとも オープンソースかつ無料で、コアはいずれも mihomo に統一されています。つまりプロトコル互換性の観点では移行リスクは低いということです――本当の違いは操作感と設定管理の方式にあるので、自分でルールを手書きする必要があるかどうかを基準に選ぶとよいでしょう。

移行手順:サブスクリプション・ルール・設定の引っ越し方法

移行作業の中心は「新しいソフトを入れる」ことではなく、旧クライアントに積み上げてきたサブスクリプションのアドレス、カスタムルール、使い方の癖をそのまま持って行くことです。以下の順序で進めれば、基本的に一度で完了します。

ステップ1:サブスクリプションのリンクをそのまま保存する

CFW のサブスクリプション管理画面を開き、各サブスクリプションの完全なアドレスをコピーして別途保存します(メモ帳でもメモアプリでも構いません)。サブスクリプションのアドレス自体はクライアントに依存しないため、新しいクライアントではこれらのリンクを再度取り込むだけで済みます。CFW が生成したローカルキャッシュファイルを直接移行する必要はなく、また推奨もされません。

ステップ2:カスタムルールとポリシーグループを記録する

CFW 内で手動で追加したルール(特定のドメインにだけ個別のプロキシポリシーを指定したり、ある種の広告ドメインをブロックしたりなど)がある場合、こうした内容は通常サブスクリプション設定の上書きレイヤーやローカルのルールファイルに書かれています。移行前に1つずつスクリーンショットを取るかテキストをコピーしてバックアップし、新クライアントのインストール完了後に手動で追記するのがおすすめです。設定ファイルがクライアントをまたいでそのまま読み込めることを期待しないでください――クライアントごとに設定項目の拡張記法が完全には一致しておらず、ファイルをそのまま再利用するとフィールドの衝突が起きやすくなります。

ステップ3:新しいクライアントをインストールしてサブスクリプションを取り込む

1. ダウンロードページから対応プラットフォームのインストーラーを取得し、案内に従ってインストールを完了させます。
2. クライアントのサブスクリプション管理画面を開き、先ほど保存したサブスクリプションのアドレスを貼り付けて取得します。
3. ノードリストの読み込みが完了したら、まず接続テストを行い、遅延データが正常に返ってくることを確認します。
4. 先に記録したカスタムルールを、新クライアントのルール編集画面に手動で再登録します。
5. プロキシモード(ルール / グローバル / ダイレクト)と TUN モードのスイッチを確認し、移行前の使い方と一致しているか確かめます。

ステップ4:システムプロキシと自動起動を確認する

新クライアントのインストールが完了したら、システムプロキシのスイッチや自動起動の設定はもう一度やり直す必要があります――これらはシステムレベルの設定であり、クライアントを切り替えても自動的には継承されません。移行完了当日は CFW をアンインストールせずに残しておき、新クライアントを1〜2日運用して安定を確認したうえで旧バージョンをアンインストールすると、切り替えの空白期間を避けられます。

移行でよくあるトラブルと解決の考え方

実際に移行を行う中で特にはまりやすい問題は以下の数種類に集中しています。事前に把握しておくと、原因調査の時間をかなり節約できます。

• サブスクリプション取り込み後にノードリストが空になる: サブスクリプションのアドレスに旧クライアント専用のパラメータが付いている可能性が高いです。リンク末尾の余分なパラメータを外して再取り込みするか、サブスクリプション提供元にリンク形式が変わっていないか確認しましょう。
• カスタムルールを移行しても機能しない: ルールのマッチタイプの記法が新クライアントのルールエンジンの文法と一致しているか確認してください。例えばドメインマッチルールの記述順序やプロセス名マッチの大文字小文字の扱いなど、クライアントごとに細部が異なる場合があります。
• TUN モードを有効にするとネットに接続できない: 新クライアントで初めて TUN モードを有効にする際は、通常追加のシステム権限確認(管理者権限や仮想NICドライバのインストール)が必要です。クライアントに表示される案内に従って権限を許可していけば問題ありません。権限申請の手順を飛ばさないようにしてください。
• 2つのクライアントが同時にシステムプロキシのポートを占有する: 旧版 CFW をアンインストールする前に、必ずそのシステムプロキシのスイッチをオフにしてください。そうしないと新旧クライアントが同じポートを取り合い、プロキシが断続的になります。見た目は「ネットワークが不安定」に見えますが、実際はポートの競合です。
• ルールセット更新後に遅延データが消える: 一部のクライアントはルールセットの更新中に遅延テストの結果を一時的にクリアします。自動で再計測が完了するのを待てば問題なく、クライアントを再起動する必要はありません。

総じて見ると、CFW から mihomo コアベースのクライアントへの移行で中心となる作業は「サブスクリプションの引っ越し+ルールの補完+システムレベル設定の再許可」の3点に集中しており、プロトコルの互換性自体は障害になりません。手順どおりに30分ほど作業すれば、基本的にスムーズに切り替えが完了し、その後もコアとルール文法の更新サポートを継続して受けられます。