Clash for Windowsのサポート終了後の移行方法｜Verge Rev・FlClashなど代替クライアントと設定の移行手順

サポート終了後の移行で押さえるポイント：クライアント・カーネル・設定を分けて考える

Clash for Windows（通常はCFWと略称）は、2023年11月にメンテナンスが終了しました。旧バージョンは起動する場合がありますが、今後のOS変更や依存コンポーネントの問題、プロトコル互換性について、元のプロジェクトによる修正は期待できません。移行の目的は、新しいクライアントで旧画面を再現することではなく、サブスクリプションの取得元、ノード、プロキシグループ、ルーティングの意図を引き継ぎ、システムプロキシと通信制御の設定を改めて整えることです。

まず、次の3つを区別しましょう。CFWはGUIクライアント、Clash・Clash Premium・Clash Meta・mihomoはカーネル関連のプロジェクト、YAMLはプロキシやルール、実行パラメーターを記述する設定形式です。Clash Metaはmihomoという名称で開発が続いています。mihomoベースのクライアントをインストールしても、旧CFWの画面設定がすべて自動で変換されるわけではありません。

移行前に記録しておく6項目

現在有効なProfileの名前と、サブスクリプションURLまたはローカルYAMLのどちらから読み込んだか。
HTTP・SOCKS・混合ポートの実際の番号（例：7890）。初期設定の値だと思い込まず、実際の設定を確認してください。
モードがRule・Global・Directのどれか、プロキシグループで現在選択されているノード。
System Proxy、TUN、スタートアップ、バックグラウンドサービスを有効にしているか。
Parsers、カスタムルール、DNSの変更など、設定を加工する仕組みを使っているか。
ブラウザー、ターミナル、開発ツールでプロキシアドレスを個別に指定しているか。

代替クライアントを比較：Verge Rev・FlClash・Nyanpasu

選ぶ際は、画面より先にOSと設定機能を確認しましょう。以下の対応プラットフォームは、各プロジェクトが通常提供しているクライアントを示します。OSの最低要件、CPUアーキテクチャ、カーネルのバージョンは、ダウンロードページにある各リリースの説明を確認してください。「Windows対応」とあっても、過去のすべてのWindowsで動くとは限りません。

クライアント	主な対応プラットフォーム	カーネルとの関係	移行時の確認ポイント
Clash Verge Rev	Windows、macOS、Linux	mihomoベース	デスクトップでのサブスクリプション管理に適しています。オーバーライド、サービス、システムプロキシは再設定が必要です
FlClash	Windows、macOS、Linux、Android	mihomoベース	デスクトップとAndroidの併用に便利です。通信を制御する方法はプラットフォームごとに異なります
Clash Nyanpasu	Windows、macOS、Linux	Clash系カーネルを管理できます。利用できるオプションはバージョンによって異なります	実際に有効なカーネルを確認してください。クライアント名だけで構文への対応を判断することはできません

使い方に合わせて選ぶ

デスクトップでの設定管理が中心：Clash Verge Revを候補にし、サブスクリプションの更新、オーバーライド、ログへのアクセスが現在の運用に合うか確認しましょう。
PCとAndroidを併用：FlClashを候補にできます。ただし、Windowsのサービスモードの手順をAndroidにそのまま適用しないでください。Androidでは通常、システムVPNの許可を通じて通信を制御します。
カーネルを確認・切り替えたい：Clash Nyanpasuを候補にできます。インポート前にカーネルの選択とバージョンを確認し、サブスクリプションの設定項目が使えるか判断してください。

CFWは名前にWindowsを含みますが、過去のリリースにはほかのデスクトップ向けもありました。移行先を名前の似た製品に限る必要はありません。設定を読み込めるかどうかを左右するのは、画面がCFWに似ているかではなく、移行先のカーネル、サブスクリプションの出力形式、クライアントのオーバーライド機能です。

サブスクリプションとローカルYAMLをバックアップ：取得元と使える設定を両方残す

サブスクリプションURLと現在の設定のスナップショットは、役割が異なります。URLは今後の更新に使い、YAMLのスナップショットは現在使えるノードやカスタム設定を残すために保存します。URLだけでは、上書きされた手動編集のルールを復元できません。YAMLだけでは自動更新できなくなる可能性があります。

CFWのProfilesページで現在の設定を確認します。リモート設定なら元のサブスクリプションURLを記録し、ローカル設定なら元ファイルを保存してください。表示名だけで取得元を推測しないようにしましょう。
クライアントのデータフォルダーを開く機能を使って、実際の保存先を確認します。ポータブル版を使っていた場合、フォルダーはインストール先によって異なることがあるため、ユーザーホームだけを探さないでください。
設定フォルダーを別のバックアップ用フォルダーにコピーし、サブスクリプションURL、設定名、対応関係も個別に保存します。
Parsersの内容、手動で追加したルール、ローカルのリソースファイルを保存します。YAMLが相対パスを参照している場合は、参照先のファイルも一緒にバックアップしてください。
バックアップ時のポート、モード、プロキシグループの選択状態を記録します。関連画面を撮影してもかまいませんが、スクリーンショットはYAMLやサブスクリプションURLの代わりにはなりません。

providerの参照先と相対パスを確認

設定内のproxy-providersやrule-providersは、リモートURLまたはローカルのpathを参照している場合があります。メインのYAMLをコピーしただけでは、すべての依存ファイルがそろうとは限りません。新しいクライアントでデータフォルダーが変わると、同じ相対パスでも参照先が変わることがあります。移行先クライアントの作業ディレクトリを基準に、パスを確認してください。

インポートと切り替えの手順：まずRuleモード、次にシステムプロキシ

初回の移行では、通常のアプリの通信だけを制御し、TUNは一時的に無効にすることをおすすめします。「設定が正しいか」と「システムのルーティングが正しいか」を分けて確認できます。作業中はシステムプロキシを操作するクライアントを1つだけにし、複数のバックグラウンドプロセスが同じ設定を繰り返し変更しないようにしてください。

旧クライアントによる通信制御を停止します。CFWのGeneral → System Proxyでシステムプロキシを無効にし、TUNを使っている場合はそれも停止します。その後CFWを終了し、スタートアップによって再度起動していないことを確認してください。
移行先クライアントをインストールします。クライアントのダウンロードページからOSとアーキテクチャを選びます。初回起動時はまずカーネルが利用できることを確認し、その後でサービスモードなどの追加機能を設定してください。
設定を1つインポートします。リモート設定には元のサブスクリプションURLを、ローカル設定には保存したYAMLを使います。クライアントによってメニュー名が「設定」または「サブスクリプション」など異なるため、インストールしたバージョンの画面で確認してください。
インポートした設定を有効にします。一覧に表示されているだけでは、カーネルで使用中とは限りません。現在の設定を示す表示と読み込みログを確認し、YAMLの解析エラーや未対応の項目がないことを確かめてください。
Ruleモードを選びます。該当するプロキシグループを開き、まず利用可能なノードを手動で選択します。プロキシグループ名が同じでも、以前の選択状態が引き継がれるとは限りません。
待ち受けポートを確認します。移行先クライアントが実際に使用しているポートを確認してから、システムプロキシを有効にします。ブラウザーにプロキシ拡張機能がある場合は、拡張機能による制御を停止するか、システム設定に従うようにしてください。

ポートの移行例：7890から17890へ変更

旧クライアントが127.0.0.1:7890を使い、新しいクライアントが127.0.0.1:17890を使う場合、旧アドレスを固定で指定している環境変数やツールの設定もすべて更新する必要があります。以下はmihomoの一部パラメーターの例であり、ノードやルールを含む完全なサブスクリプションではありません。実際の設定には、クライアントが対応する設定機能またはオーバーライド機能を使ってください。

mixed-port: 17890
allow-lan: false
mode: rule
log-level: info
tun:
  enable: false

mixed-portはHTTPとSOCKSの両方のプロキシ接続を受け付けます。カーネルのコントローラー用ポートとは別のものです。コントローラー用ポートは管理に使うため、ブラウザーのHTTPプロキシ欄には入力しないでください。アプリでSOCKS専用の待ち受けポートを個別に指定している場合も、新しい設定で改めて確認してください。

ルール・オーバーライド・TUN：そのまま引き継げない設定

CFWのParsersは再設定が必要

ParsersはCFW独自の設定加工機能であり、mihomo YAMLで共通して使えるトップレベル項目ではありません。Parsersの内容をサブスクリプションに貼り付けても、同じ動作にはなりません。まず、LAN向けのDIRECTルール追加、DNS変更、プロキシグループ追加など、実際に行っている処理を洗い出します。そのうえで、移行先クライアントが対応するマージ設定やスクリプトによるオーバーライドを使い、1つずつ再設定してください。

元のサブスクリプションを保存してから、カスタム設定も別に保存します。ダウンロードしたリモートYAMLを直接編集すると、次回の更新で変更が上書きされる可能性があります。確認方法は簡単です。カスタムルールを1つ記録し、サブスクリプションを更新してから、実行中の設定にそのルールが残っているか、正しい位置にあるかを確認してください。

ルールの順序とプロキシグループ名をセットで確認

ルールは通常、記載された順に照合され、最初に一致したルールで後続の処理が決まります。優先する例外ルールは、フォールバック用のルールより前に配置してください。
MATCHはよく使われるフォールバックルールです。ファイル内にノードがあるかだけでなく、実際にどのポリシーグループを参照しているか確認してください。
ルールが参照するプロキシグループ名は、定義と完全に一致させる必要があります。大文字・小文字、空白、記号も確認してください。プロキシグループの名前を変更した場合は、参照元も修正します。
サブスクリプションにClash形式とClash Meta形式がある場合、mihomoでは提供元が推奨する互換形式を確認してください。別形式の内容をファイル名だけ.yamlに変えてインポートするのは避けましょう。

TUNとDNSは最後に個別設定

TUNは仮想ネットワークインターフェースを作成し、ルーティングやDNSの処理方法を変更する場合があります。「強化版のGlobalモード」ではありません。TUNで通信を制御していても、Ruleモードは引き続き利用できます。まず通常のシステムプロキシが動作することを確認し、移行先クライアントの要件に応じてサービスを有効にするか権限を付与してから、最後にTUNを有効にしてください。

TUNを有効にした後、社内ドメイン、会社のVPN、ローカル機器へのアクセスに問題が出た場合は、ルーティングの除外設定、DNSポリシー、ほかのVPNとの競合を確認してください。fake-ipはDNSの処理モードです。関連するフィルターやルールを無視して、設定スイッチだけを移行しないでください。どちらが速いかを調べるために、2つのクライアントで同時にTUNを有効にするのも避けましょう。問題の原因を特定しにくくなります。

移行後の動作確認：設定読み込み・プロキシ接続・更新を個別にテスト

ノードの遅延時間が表示されても、特定の条件でテスト先から応答があったことしか分かりません。ブラウザー、ターミナル、ルールがすべて正常とは限りません。以下はWindows PowerShellでの例です。新しいクライアントの混合ポートを17890としています。別のポートを使う場合は、コマンドも合わせて変更してください。

1. ローカルポートとプロキシを明示して確認

Get-NetTCPConnection -State Listen -LocalPort 17890
curl.exe --proxy http://127.0.0.1:17890 --connect-timeout 10 --max-time 20 -I https://example.com/

1つ目のコマンドで、そのポートを待ち受けているプロセスを確認できます。出力にあるOwningProcessから、プロセスの詳細を調べられます。2つ目はHTTPプロキシを明示し、接続タイムアウトを10秒、全体の制限時間を20秒に設定して接続します。一部のPowerShell環境でコマンドのエイリアスが異なるため、curl.exeを使用しています。

HTTP応答があればリクエストが完了したことは分かりますが、プロキシノードを経由したとは限りません。RuleモードでもDIRECTに一致する場合があります。クライアントの接続ログも確認し、一致したルール、ポリシーグループ、最終的な通信経路が想定どおりか確かめてください。プロキシを明示した接続は成功するのにブラウザーで使えない場合は、システムプロキシ、ブラウザー拡張機能、プロキシの除外リストを確認しましょう。

2. 環境変数とシステム設定を確認

Get-ChildItem Env:*proxy*
netsh winhttp show proxy

1つ目のコマンドで、古いポートを参照しているプロキシ環境変数を確認できます。2つ目に表示されるのはWinHTTPのプロキシ設定のみで、Windowsユーザーのシステムプロキシ設定全体を示すものではありません。Windows 11では「設定 → ネットワークとインターネット → プロキシ」も開き、現在の手動プロキシのアドレスとポートを確認してください。ターミナルツールがシステムプロキシを使うかどうかはツールによって異なります。クライアントのスイッチを有効にしただけでは判断できません。

3. 更新と再起動後の動作を確認

サブスクリプションを手動で1回更新し、ノード一覧が読み込まれること、カスタムルールが消えていないことを確認します。
DIRECTで接続するはずの宛先と、プロキシ経由で接続するはずの宛先にそれぞれアクセスし、接続ログで適用されたポリシーを確認します。
新しいクライアントを終了して再起動し、現在の設定、モード、プロキシグループの選択が想定どおりか確認します。
TUNが必要な場合は、個別に有効にしてからローカルネットワーク、DNS、普段使うアプリをテストします。
システムを再起動し、新しいクライアントだけが自動起動すること、旧クライアントがポートやシステムプロキシを変更しないことを確認します。

よくある移行トラブルと元に戻す方法

サブスクリプションをインポートできたのにノード一覧が空です。まず何を確認すればよいですか？

まずサブスクリプションのリクエストと設定の読み込みログを確認してください。有効なYAMLではなく、ログインページやエラーメッセージ、非対応形式が返されている可能性があります。また、proxy-providerを使っていても、プロバイダーのダウンロードに失敗している、またはプロキシグループのuseで参照されていない場合があります。元のサブスクリプションが有効か確認してから、移行先カーネルの対応状況を調べましょう。設定の問題を隠すためにシステムプロキシを何度も切り替えるのは避けてください。

新しいクライアントでポートの競合が表示されました。ポートを変更してもよいですか？

変更できますが、まずポートを使用しているプロセスを確認してください。旧CFWや残っているバックグラウンドサービスが使用している場合は、該当クライアントを正常に終了するかサービスを停止します。17890など別のポートに変更する場合は、ブラウザーの手動プロキシ、ターミナルの環境変数、開発ツールの設定もすべて更新してください。用途の分からないシステムプロセスを終了しないでください。

移行に失敗した場合、旧設定に戻すにはどうすればよいですか？

まず新しいクライアントのシステムプロキシとTUNを無効にして終了し、その後で旧クライアントとバックアップした設定を有効にしてください。旧環境への切り戻しは一時的な復旧手段であり、旧プロジェクトのサポートが終了している事実は変わりません。プロキシを一時的に使わない場合は、終了したポートを参照し続けている手動プロキシ設定や環境変数も削除し、アプリの接続失敗を防いでください。

移行完了の目安は、元のサブスクリプションを更新できること、ローカルの変更を維持できること、ルールの適用結果を説明できること、システム再起動後も想定どおりに通信を制御できることです。これらを確認してから、旧クライアントのスタートアップ項目とサービスを削除し、アクセスを制限した場所にバックアップを保管してください。設定項目を確認する場合はプロトコルリファレンス、システムプロキシの問題を調べる場合はヘルプセンターをご覧ください。