Clash for Windows終了後の移行ガイド：Clash Verge Rev・FlClashなど代替クライアント

移行するもの：クライアント・カーネル・設定を分けて考える

Clash for Windows（以下、CFW）の開発元プロジェクトは2023年にメンテナンスを終了しました。インストール済みのアプリがすぐに使えなくなるとは限りませんが、今後のOS互換性やプロトコル対応、問題修正を旧プロジェクトに期待することはできません。移行ではインストールフォルダー全体をコピーするのではなく、サブスクリプションの取得先、通信を振り分ける意図、必要な設定を引き継ぎ、新しいクライアントで動作環境を再構築します。

クライアントは画面表示、サブスクリプション管理、システムプロキシ、サービス制御を担当し、カーネルは設定の解析、接続の確立、ルールの適用を担います。CFWでは複数のカーネル利用方法が存在したため、クライアント名だけで旧設定の対応状況を判断することはできません。移行前に実際に使っているカーネルの種類とバージョンを記録し、新しいクライアントに搭載されたカーネルを確認してください。異なるソフトのクライアントバージョン同士を比べても判断材料にはなりません。

• 優先して移行：サブスクリプションURL、ローカルYAML、カスタムルール、ポリシーグループ名、ルールセットの取得元。
• 個別に再設定：システムプロキシ、自動起動、サービス権限、TUNアダプターとルーティング。
• 必要に応じて引き継ぐ：ポリシーグループの選択状態、速度テストの設定、DNS設定、アプリごとに指定したプロキシポート。
• そのまま上書きしない：旧クライアントのデータベース、カーネル実行ファイル、キャッシュフォルダー、仮想ネットワークアダプターのドライバー。

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

Windowsのデスクトップで使う場合は、Clash Verge RevとFlClashを比較するとよいでしょう。どちらもmihomoカーネルを利用して設定を管理しますが、画面構成、設定拡張機能へのアクセス方法、OSとの連携は異なります。LinuxとmacOSではインストーラーのアーキテクチャを確認し、AndroidではWindows用インストーラーやシステムプロキシの設定方法を使わないようにしてください。

カーネルのバージョンは、実際の端末で確認してください

クライアントとカーネルのバージョンは別々に管理されており、同じクライアント内でカーネルを切り替えられる場合もあります。まずクライアントのカーネル情報画面やログでバージョンを記録してください。実際のカーネルファイルを特定できる場合は、ターミナルからバージョンを確認できます。以下のコマンドは該当する実行ファイルがあるディレクトリで実行します。ファイル名はインストール内容に合わせてください。

# Windows PowerShell
.\mihomo.exe -v

# macOS / Linux
./mihomo -v

新しいバージョン番号を表示させるために、旧クライアント内のカーネルを安易に置き換えないでください。制御インターフェース、起動オプション、ディレクトリ構成が合わない可能性があります。クライアントを選ぶ際は、まずサブスクリプションが必要とするプロトコルを確認し、次に移行先クライアントの実際のカーネルが対応しているか調べます。「Clash設定をインポートできる」ことは、mihomoの拡張項目すべてに対応するという意味ではありません。

移行前のバックアップ：元ファイルと最終的な有効設定を保存

旧クライアントに表示されるサブスクリプションファイルが、カーネルの最終的な読み込み内容とは限りません。CFWではParsers、Mixin、手動編集によって、サブスクリプション取得後にポート、ルール、ポリシーグループが変更されている場合があります。サブスクリプションURLだけを保存すると、後から追加したルールが新しいクライアントで失われるおそれがあります。

1. 現在の状態を記録。クライアントとカーネルのバージョン、現在の設定名、動作モード、システムプロキシとTUNの有効・無効を保存します。
2. サブスクリプションの取得元をバックアップ。元のサブスクリプションURLと提供元の名前を保存します。URLにはアクセストークンが含まれることが多いため、公開メモやスクリーンショットに載せないでください。
3. ローカルファイルをコピー。旧クライアントから設定ファイルの場所を開き、YAML、参照先のローカルルールセット、カスタム処理スクリプトを別のバックアップフォルダーへコピーします。
4. 処理後の設定を記録。旧クライアントに実行中の設定を表示する機能があれば、最終設定も別途保存し、元のサブスクリプションとの差分を明記します。実行設定にはノードの認証情報が平文で含まれる場合があるため、機密ファイルとして扱ってください。
5. システム設定を保存。HTTP/SOCKSポート、LAN共有、バイパスリスト、ブラウザーやコマンドラインツールに個別設定したプロキシアドレスを記録します。

Windowsでは「設定」→「ネットワークとインターネット」→「プロキシ」から、現在の手動プロキシを確認できます。旧設定が127.0.0.1:7890を使っていた場合は、アドレスとポートを記録してください。これはよくある例で、すべてのPCで7890が使われているわけではありません。macOSでは「システム設定」→「ネットワーク」→使用中のネットワークサービス→「詳細」→「プロキシ」で確認できます。メニュー名はOSのバージョンによって多少異なる場合があります。

サブスクリプションをインポート：接続を確認してから拡張機能を戻す

新しいクライアントの設定またはサブスクリプション画面で元のURLを追加し、更新後にその設定を選択します。配布版によって「設定」「サブスクリプション」「Profiles」など画面の名称は異なります。重要なのは、ダウンロードとカーネルの読み込みが成功し、ノード一覧が空でないことを確認することです。提供元へのログイン後にURLを再発行する必要がある場合は、新しいURLの形式がmihomoに対応しているか先に確認してください。

1. 旧クライアントのシステムプロキシ、TUN、バックグラウンドサービスを無効にしてから、アプリを終了します。ウィンドウを閉じただけでは、タスクトレイにプロセスが残ることがあります。
2. 新しいクライアントに設定を1つインポートし、まずはルールモードで使います。TUN、LAN共有、自動起動はまだ有効にしないでください。
3. 接続できることがわかっているノードを選び、接続ログを確認してからシステムプロキシを有効にし、普段使うWebサイトへアクセスします。
4. 基本の接続が正常なことを確認してから、カスタムルール、DNS設定、ルールセット、設定拡張機能を追加します。
5. サブスクリプションを手動で一度更新し、拡張した設定が維持されることを確認します。現在のファイルだけに変更が反映されている状態を避けるためです。

ポート競合は設定を何度も変えず、まず競合プロセスを確認

旧カーネルと新カーネルが同じアドレス・ポートを同時に待ち受けることはできません。ログにaddress already in useと表示された場合は、ポート7890を使用中のプロセスを先に確認してください。ポートを次々に変更する必要はありません。以下は診断例です。

# Windows PowerShell
Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7890'

7891に変更する場合は、ブラウザー拡張機能、ターミナルの環境変数、ほかの手動プロキシ設定もすべて同じポートに変更してください。システムプロキシの設定が反映されるのは、通常、システム設定に従うアプリだけです。すべてのアプリが自動で切り替わるとは限りません。

ルールとカスタム設定：参照先・順序・上書き関係を確認

mihomoはClash形式の設定を幅広く扱えますが、移行時にすべての項目をそのままコピーできるとは限りません。まずproxies、proxy-providers、proxy-groups、rulesの間で名前の参照が一致しているか確認します。ポリシーグループ名を変更しても、ルールの転送先が古い名前のままでは読み込みに失敗することがあります。ルールは上から順に評価されるため、既定のMATCHは最後に置いてください。先に置くと、その後のルールが適用されません。

最小構成でローカル設定の読み込みを確認

以下は新しいクライアントで読み込みを確認するための最小YAMLです。直接接続のみを含み、プロキシノードはなく、実際のサブスクリプションの代わりにはなりません。カーネルで読み込めることを確認したら、実際のノードやプロバイダーをポリシーグループに追加します。このひな形でサブスクリプションファイルを上書きしないでください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 業務用出口
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,業務用出口

ここでは業務用出口がポリシーグループ名とルールの転送先の両方に登場します。両方の名前を一致させてください。mixed-portは1つのポートでHTTPとSOCKSのプロキシ接続を受け付けます。この例ではexternal-controllerを設定していないため、制御インターフェースは追加で公開されません。クライアントが制御インターフェースを管理する場合は、クライアントが生成した設定に従ってください。

サブスクリプションの拡張とルールセットを個別に移行

• ParsersとMixin：クライアント側の処理機能であり、汎用的なカーネル設定項目ではありません。新しいクライアントのマージ機能やスクリプト機能に合わせて処理内容を書き換えてください。旧スクリプトがそのまま動くとは限りません。
• ルールセット：rule-providersの取得元、behavior、format、更新間隔を引き継ぎ、RULE-SETで参照している名前も確認します。
• ローカルパス：旧ディレクトリからの相対パスは、新しい作業ディレクトリでは無効になることがあります。ローカルのルールファイルを移行した後、カーネルが実際に参照するパスと読み取り権限を確認してください。
• 旧スクリプト方式：旧設定がClash Premiumのスクリプト機能に依存している場合、mihomoでも同じ方法で動くとは限りません。通信の振り分け要件を、移行先カーネルが対応するルールまたはクライアント側の処理に置き換えてください。
• ポリシーグループの状態：グループ定義を移行できても、現在の選択状態が引き継がれるとは限りません。出口を選び直し、自動速度テストやフェイルオーバーが想定どおり動くか確認してください。

DNSとTUN：最後に有効化して個別に検証

まずシステムプロキシで接続とルールを確認し、その後でTUNを有効にします。DNS、ルーティング、権限の問題を同時に調べる手間を減らせます。TUNは仮想ネットワークアダプターを通じて通信を制御するため、通常はシステム権限またはバックグラウンドサービスが必要です。Windowsのサービス登録、macOSのネットワーク許可、AndroidのVPN許可はそれぞれ異なる仕組みなので、移行先OSで設定し直してください。

DNS設定は一式まとめて移行してください。fake-ipモードはドメイン名に対応付けるアドレスを返す機能であり、DNSリクエストが必ずプロキシ経由になることを保証するものではありません。DNSの上流サーバー、nameserver-policy、関連するルーティング、TUNのDNS横取り設定も確認してください。ブラウザー内蔵のセキュアDNS、アプリ内のDoH、ほかのVPNによって名前解決の経路が変わる場合もあります。

• LAN内のサービス：ルーターの管理画面、NAS、プリンターへの接続を確認します。ローカルドメインの名前解決にルーターのDNSを使う場合は、該当する問い合わせが適切なローカルDNSサーバーに届くことを確認してください。
• 職場のネットワーク：社内ドメインとVPNをテストします。複数の仮想ネットワークアダプターがデフォルトルートを書き換える場合は、1つずつ無効にして競合元を特定してください。
• DNSキャッシュ：Fake-IPモードや名前解決の設定を切り替えた後は、テスト対象のアプリを再起動します。Windowsでは必要に応じてipconfig /flushdnsを実行し、システムのDNSキャッシュを消去してください。
• 待ち受け範囲：ほかの端末からの接続が必要な場合に限り、LAN共有を有効にしてファイアウォールのルールを確認します。1台の端末だけで使う場合、プロキシポートをLANに公開する必要はありません。

システムプロキシでは正常なのにTUNを有効にすると問題が起きる場合は、サブスクリプションを変更する前に、権限、ルーティング、DNSを確認してください。ノードの速度テストに成功しても、テスト用の通信が完了したことしか示しません。アプリの通信が正しく処理されているとは限りません。

移行確認とロールバック：サブスクリプション更新後に旧環境を停止

移行後は、通常のブラウザー、プロキシを手動指定したツール、TUNが必要なアプリを少なくとも確認してください。以下の表は確認項目と期待結果を示すもので、実測済みの結果ではありません。同じ対象に対して操作を3回連続で行い、時刻、適用されたルール、出口を記録します。一度だけ接続に成功したことを移行完了の根拠にしないでください。

失敗した場合は逆の手順でロールバック

新しいクライアントのTUNとシステムプロキシを無効にし、次にバックグラウンドサービスを停止して、待ち受けポートが解放されたことを確認します。その後、旧クライアントを起動し、元の設定とプロキシ状態に戻してください。2つのクライアントでシステムプロキシやTUNルートを同時に使用しないでください。新しいクライアントを終了した後もブラウザーがインターネットに接続できない場合は、サービスが待ち受けていない127.0.0.1:7890を指す手動プロキシ設定がシステムに残っていないか確認してください。

サブスクリプションの更新、OSの再起動、普段使うアプリの動作確認が終わってから、旧クライアントの自動起動項目を削除し、アプリをアンインストールします。オフラインの設定バックアップと移行記録を残し、新しいクライアントのバージョン、実際のカーネルバージョン、ポート、設定拡張機能の場所を記録してください。サブスクリプション変更やOS更新後に問題が起きても、クライアント、カーネル、設定のどこに原因があるか切り分けやすくなり、通信経路を一から推測せずに済みます。