Clash for Windows終了後の移行ガイド｜代替クライアントの選び方と設定の引き継ぎ

移行の結論：クライアントを替えて、サブスクリプションとルールを引き継ぐ

WindowsではClash Verge RevとFlClashを比較し、macOSではClashX Metaも検討します。Linuxはディストリビューションに合ったパッケージを選び、AndroidはFlClashから試すとよいでしょう。古いCFWは先にアンインストールする必要はありません。まずバックアップを取り、新しいクライアントにインポートしてルール、DNS、プロキシの適用を確認してから、旧アプリの自動起動を無効にします。

Clash for Windowsは通常CFWと略され、元のプロジェクトは2023年に開発を終了しました。最終期の代表的なバージョンは0.20.39です。CFWはGUIクライアントであり、Clashのすべてのコアやサブスクリプションサービスと同じものではありません。画面を切り替えてもプロバイダーは変わらず、同じサブスクリプションを使う場合、利用できるプロキシは引き続き提供元に依存します。

移行時は3つの層を切り分ける

クライアント：サブスクリプション、システムプロキシ、サービス権限、設定のオーバーライドを管理します。メニューやファイル構成はクライアントごとに異なります。
コア：YAMLの解析やプロキシプロトコル、ルール、DNSの処理を担います。Clash Metaはその後mihomoとして開発が続いています。新しいクライアントが特定の項目に対応するかは、実際に搭載されているコアを確認してください。
サブスクリプション：ノードまたは設定一式を提供します。ノード一覧とClash設定一式は入力形式が異なるため、インポート前に形式を確認してください。

代替クライアント：OSと設定機能で選ぶ

リリースが継続しており、コアのバージョンが明記され、設定のエクスポートやログ確認に対応するプロジェクトを優先しましょう。開発状況は変わるため、以下は移行先の候補であり、今後の保守を保証するものではありません。インストール前にプロジェクトのリリースページで最新版、OS要件、既知の問題を確認してください。入手先はクライアントのダウンロードページから探せます。

OS	移行先の候補	移行時の確認事項
Windows	Clash Verge Rev、FlClash	オーバーライドの方式、サービスモード、システムプロキシ、TUNの権限を確認します。CFWのユーザーディレクトリを丸ごとコピーしないでください。
macOS	Clash Verge Rev、FlClash、ClashX Meta	Apple Silicon用とIntel用のインストーラーを区別し、ネットワーク制御に必要なコンポーネントを再度許可します。
Linux	Clash Verge Rev、FlClash	DEBやRPMなどのパッケージ形式とディストリビューション要件を確認します。デスクトップのプロキシ設定とTUNのルーティングは分けて検証してください。
Android	FlClash	端末のアーキテクチャに合ったパッケージを選び、VPNの許可、アプリごとの振り分け、バックグラウンド実行の制限を確認します。
iOS	対応するサブスクリプション形式に対応したiOSクライアント	設定形式とネットワーク拡張機能を先に確認してください。デスクトップ版CFWはインストールできず、CFWのスクリプトがそのまま動くとも限りません。

オーバーライドが必要なら、まず設定方法を確認

サブスクリプションのインポートと手動でのプロキシ選択だけでよければ、選択の手間は少なくて済みます。カスタムルール、DNS、スクリプトを使う場合は、ローカルの変更をサブスクリプション更新後も維持できるか、事前に新しいクライアントで確認してください。Clash Verge Revの設定マージやスクリプト処理は、CFWのParsersとは別の仕組みです。FlClashの設定処理も、CFWのファイル構成から推測できません。機能名はインストールしたバージョンの画面で確認してください。

「mihomo内蔵」だからといって、「CFWの全機能と完全互換」とは限りません。コアが認識できるYAML項目と、画面上で設定を保存・更新して設定を生成する方法は別の問題です。ほかの選び方の違いはクライアント比較をご覧ください。

バックアップ項目：サブスクリプションURL、最終設定、ローカル変更

整理中に設定が変わらないよう、まず旧CFWのサブスクリプション自動更新を無効にします。Profiles（プロファイル）を開き、現在有効な設定、サブスクリプションの提供元、更新日時を記録します。Proxies（プロキシ）では手動選択している各グループの設定を控えます。General（一般）とSettings（設定）では、ポート、システムプロキシ、TUN、設定処理の項目を記録してください。

サブスクリプションURLを保存：クエリパラメーターを含め、URL全体を控えます。URLにアクセストークンが含まれる場合はパスワードと同様に扱い、公開フォーラムなどに貼り付けないでください。
元のYAMLを保存：使用中の設定を複製し、サブスクリプションから取得した元ファイルか、処理後のファイルかを明記します。画面上の編集機能で、実際に動作する最終設定が表示されるとは限りません。
オーバーライドの設定元を保存：Parsersの設定、外部スクリプト、カスタムルール、ルールプロバイダーのURL、ローカルファイルをそれぞれコピーします。
実行時の設定を記録：実際に使用しているmixed-port（例：7890）、待ち受けアドレス、プロキシモード、DNSモード、TUNの有効・無効を控えます。7890はよく使われるポート番号で、すべての端末で固定とは限りません。
特殊な用途を記録：ブラウザー拡張機能、ターミナルの環境変数、LAN内の端末、開発ツールが旧プロキシのポートに明示的に接続していないか確認します。

ユーザーディレクトリはバックアップ用に保管し、新アプリへ上書きしない

WindowsでCFWのユーザー設定が保存される一般的な場所は%USERPROFILE%\.config\clashです。ポータブルモードやカスタムディレクトリでは異なる場合があります。旧クライアントに表示された実際のパスを確認してください。ディレクトリ全体をロールバック用にコピーしておくのは構いませんが、中のデータベース、キャッシュ、クライアント設定を新しいクライアントのフォルダーに直接上書きしないでください。

サブスクリプションの移行：元の設定を検証してからオーバーライドを追加

初回インポート時は、新しいクライアントのシステムプロキシとTUNを無効にし、すぐにネットワークを制御しないようにします。サブスクリプションまたは設定のインポート機能から、元のURLを登録してください。サブスクリプションに一時的にアクセスできない場合は、バックアップしたYAMLをオフライン検証用にインポートできますが、その場合は以後のノード更新が自動で反映されません。

インポートログを確認し、読み込まれた内容がYAML設定であることを確かめます。ログインページやエラーページ、プロキシリンクだけを含むテキストではないか確認してください。
プロキシ数、グループ名、ルール数を照合し、以前手動で選んでいたグループが残っているか確認します。
この設定を有効にし、まずコアの設定チェックを実行します。起動ログで、未対応項目、存在しない参照先、ファイルの読み込み失敗がないか確認してください。
実際に生成された設定を確認します。クライアントの全体設定が、サブスクリプションに含まれるポート、DNS、TUNの項目を上書きする場合があります。
元の設定が起動することを確認してから、オーバーライドを一つずつ追加します。一度に移行する変更は1種類に絞ってください。

サブスクリプションをインポートできても、同じ動作になるとは限らない

以前の設定がCFW固有の前処理に依存していると、プロバイダーから取得した元データにはその変更が含まれていない場合があります。また、サブスクリプションに新しいコアが対応するプロトコルが含まれ、旧クライアントでは正しく認識できていないこともあります。mihomoに移行した結果、プロキシ一覧が変わる場合もあります。移行完了の判断は「インポート成功」だけに頼らず、実際に生成された内容を比較してください。

プロバイダーが提供する互換サブスクリプションのURLは保管してください。形式変換が必要な場合は、プロバイダーまたはクライアントが明示的にサポートする方法を優先します。トークン付きURLを見知らぬオンライン変換サイトに渡すと、サブスクリプション情報が漏れるリスクが高まります。

カスタムルールとスクリプト：処理内容を移し、インターフェースは引き継がない

CFWのParsersは、サブスクリプションURLとの照合、項目のマージ、JavaScriptによる設定の書き換えに対応します。新しいクライアントでは、スクリプトの引数、戻り値、実行環境が異なる場合があります。同じJavaScriptでも、旧ファイルがそのまま動くとは限りません。まずスクリプトの処理を、ルールの追加、グループの変更、DNSの差し替え、プロキシ名の変更などに分けて整理してください。

ルールはコピーする数より順序が重要

ルールは通常、上から順に照合され、一致した時点で指定の動作が適用されます。具体的なドメインルールは広範囲に一致するルールより前に置き、最後のフォールバックとなるMATCHは末尾に配置します。以下は、ローカル名とプライベートIPv4アドレスを直接接続するため、設定全体に追加できるルール例です。プロキシノードは含まず、サブスクリプション全体でもありません。

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

移行時は、これらの項目を既存ルールの適切な位置に挿入してください。この断片でrulesリスト全体を置き換えてはいけません。配列が末尾に追加されるか、先頭に挿入されるか、全体が置き換わるかは、新しいクライアントのオーバーライド方式によって異なるため、生成後の設定で確認してください。

ポリシーグループの参照：元のルールが参照するグループ名が、設定全体のproxy-groupsに存在する必要があります。名前と大文字・小文字を一致させてください。
ルールプロバイダー：rule-providersを移行する際は、behavior、形式、URL、ローカルパスも確認してください。RULE-SETの項目だけをコピーしないでください。
ローカルファイル：旧ディレクトリの絶対パスは、新しいクライアントでは通常使えません。相対パスも、どの設定ディレクトリを基準にするか確認してください。
重複ルール：サブスクリプションにプライベートネットワークへの直接接続ルールが含まれている場合、重ねて追加する必要はありません。重要なのは照合位置と動作先が正しいことです。

スクリプトは機能ごとに分けて書き直す

まずYAMLだけで表現できる変更を移し、スクリプトが必要な部分は後から対応します。実行するたびにポリシーグループ、ルール、DNSを比較し、スクリプトがノード名を変更した結果、グループが古い名前を参照したままになっていないか確認してください。旧スクリプトのファイルアクセス、ネットワークリクエスト、外部依存機能が新しい環境でも使えるとは限りません。

サブスクリプションを更新した後にも、もう一度確認してください。カスタムルールが消えた場合、変更が一時的な生成ファイルにしか反映されず、永続化されるオーバーライド層に追加されていません。関連項目はYAML設定ガイドをご覧ください。

ポート、DNS、TUN：切り替え時は二重起動を防ぐ

設定が起動することを確認してから、ネットワーク制御を切り替えます。まずCFWのシステムプロキシとTUNを無効にし、CFWを通常の手順で終了してください。バックグラウンドサービスや残留プロセスがポートを使い続けていないことを確認してから、新しいクライアントのシステムプロキシを有効にします。2つのアプリがシステムプロキシやルートを同時に制御すると、接続が不安定になることがあります。

mixed-portを変更したら、アプリ内のプロキシ設定も変更

旧クライアントの待ち受け先が127.0.0.1:7890で、新クライアントが実際に127.0.0.1:7897で待ち受けている場合、ブラウザー拡張機能、ターミナル、開発ツールに手動で設定したプロキシも更新が必要です。旧ポートを引き続き使うこともできますが、旧プロセスがポートを解放していることが条件です。以下は待ち受け設定の例です。実際の値は、新クライアントで最終的に動作している設定に合わせてください。

mixed-port: 7897
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

mixed-portはHTTPとSOCKSのプロキシ接続口を兼ねるもので、外部コントロールAPIのポートとは別です。移行のために外部コントロールインターフェースをすべてのネットワークインターフェースに公開しないでください。LAN内での共有が必要な端末では、待ち受け範囲、ファイアウォール、アクセス制限を別途確認してください。

DNSは古いキャッシュごと移行しない

旧設定でfake-ipとredir-hostのどちらを使っていたか、上流DNS、ドメインごとのポリシー、フィルターリストとあわせて記録し、新しいクライアントで上書きされていないか確認します。移行後に「ノードには接続できるのにサイトが開かない」場合は、すぐにノードを変更するのではなく、DNSリクエストとルールの適用状況を確認してください。キャッシュの消去やモードの変更は、根拠のあるトラブルシューティングとして行い、設定確認の代わりにしないでください。

TUNは最後に有効化

まずシステムプロキシでブラウザーを確認し、その後TUNを有効にして、システムプロキシを使わないアプリを検証します。Windowsではクライアントのサービスと管理者の許可、macOSでは対応する権限コンポーネント、Linuxでは十分なネットワーク管理権限が必要な場合があります。AndroidではシステムのVPN許可を使います。社内VPN、ほかのプロキシアプリ、仮想マシンのネットワークを使っている場合は、ルートとDNSの競合も確認してください。

動作確認とロールバック：CFWのアンインストールは更新確認の後

移行完了の基準は、これまでの用途を再現できることです。遅延テストの数値だけでは判断できません。以下のチェック項目を一つずつ確認し、結果を記録してください。成功の証明として架空の速度測定値を作らないでください。同じノードでも測定時刻によって遅延は変わり、ルールやDNSが正しく動いている証明にはなりません。

Web接続：直接接続するサイトとプロキシ経由のサイトをそれぞれ開き、ログや接続一覧で適用されたルールとポリシーグループを確認します。
ローカルリソース：ルーターの管理画面、LAN内のサービス、社内ネットワークに想定どおりアクセスできるか確認します。
アプリの接続：ブラウザー以外の開発ツールやアプリも確認し、システムプロキシ、手動設定のプロキシ、TUNのどれを使っているか切り分けます。
サブスクリプション更新：手動で一度更新し、カスタムルール、ポリシーグループの変更、DNSのオーバーライドが維持されるか確認します。
再起動後の確認：新しいクライアントを再起動し、設定、選択中のプロキシ、サービス権限、自動起動の状態を確認します。
権限と旧環境の整理：旧CFWの自動起動とサービスを無効にし、オフラインバックアップを保管します。新しいアプリを終了した後、システムプロキシが正常に解除されることを確認してください。

問題が起きたら、層ごとに切り戻す

新しいアプリが起動しない場合は、まずオーバーライドを外して元のサブスクリプションを検証します。起動するのにインターネットへ接続できない場合は、TUNを無効にしてシステムプロキシだけを確認します。ブラウザーは正常で特定のアプリだけ失敗する場合は、そのアプリのプロキシ設定とルーティングを調べます。ログは操作した時刻に合わせて確認し、最初の設定エラーまたは接続エラーを探してください。後続のタイムアウトが繰り返されても、それに惑わされないようにします。

短期間だけ旧クライアントに戻す必要がある場合は、新クライアントのネットワーク制御を無効にして終了してから、バックアップした旧環境を起動してください。システムプロキシやTUNを2つ同時に有効にしないでください。バックアップにはサブスクリプショントークン、コントロールインターフェースのキー、プロキシ認証情報が含まれるため、安全な場所に保管します。新しい設定が安定し、更新と再起動の検証にも通った後で、旧インストールを整理してください。

移行で特に重要なのは、サブスクリプションの提供元を保管すること、オーバーライドの出どころを追跡できること、ポートとネットワーク制御の設定が一致していること、更新後もルールが有効なことです。この順に進めれば、クライアントの入れ替えが設定全体の再構築に発展するのを防げます。