Clash for Windows終了後の乗り換えガイド｜Clash Verge Revへのサブスクリプション・オーバーライド移行

1. クライアント・コア・サブスクリプションの違い

Clash for Windows（CFW）は開発が終了しています。既存の設定で接続できる場合でも、クライアントとの互換性調整、依存コンポーネントの更新、問題の修正は今後行われません。移行では、古いフォルダーを新しいアプリに丸ごと上書きするのではなく、サブスクリプションの取得元、独自ルール、システムへの通信経路をそれぞれ復元します。旧クライアントのデータベースやサービスコンポーネントは、新しいクライアントでは使えません。

Clash Verge Revはデスクトップ向けのGUIクライアント、Mihomoは設定の解析、ルール判定、接続を担うコアです。MihomoはClash Metaの技術系統を引き継いでおり、対応する設定項目は初期のClashコアと同じとは限りません。サブスクリプションはリモート設定の取得元で、プロキシノード、グループ、ルール、DNS設定などが含まれる場合があります。3つを個別に確認し、「サブスクリプションを読み込めた」だけで移行完了と判断しないでください。

2. 代替クライアントの選び方：設定の扱い方を確認

Windowsでは、Clash Verge Rev、Clash Nyanpasu、FlClashなど、Mihomoを採用するクライアントを候補として検討できます。移行時点で開発が続いているかは、リリース履歴、課題への対応、コアの更新状況で判断してください。ダウンロードページの「最新版」という表示だけでは判断できません。名前が似たフォークを同じプロジェクトとみなさないよう注意してください。

候補クライアント	移行時に確認したいポイント	インストール前の確認事項
Clash Verge Rev	サブスクリプション管理、ローカルMergeやスクリプト処理、デスクトップのシステムプロキシ、TUN	現行バージョンでのオーバーライド適用方法、サービスのインストール状態、コアのバージョン
Clash Nyanpasu	デスクトップ設定の管理方法と設定処理の流れ	現行バージョンで使用するコアと、ローカル設定の処理機能
FlClash	デスクトップとモバイル端末で、できるだけ同じ操作感を使いたい	対応プラットフォーム、設定の読み込み方法、ローカルルールの編集方法

旧CFWで管理していたのがサブスクリプションと少数のYAML設定だけなら、Verge RevのMergeを使うと移行内容を比較しやすいでしょう。複雑なParsersスクリプトに依存している場合は、画面の類似性よりも、スクリプトのインターフェース、実行順序、更新時の動作を重視して選んでください。対応プラットフォームはクライアント比較で確認できます。

3. 旧CFWからバックアップする項目

旧クライアントを起動できるうちにバックアップを済ませます。CFWの「Settings」にある設定フォルダーへのリンクから、ユーザーデータの保存先を開いてください。インストール方法や旧バージョンによって保存場所が異なるため、インストールフォルダーだけを探すのは避けましょう。まずユーザー設定フォルダー全体をオフラインの場所にコピーし、その後、以下の移行項目を個別に整理します。

元のサブスクリプションURL：各サブスクリプションの名前、URL、更新間隔を記録します。トークンを含むURLはアクセス認証情報にあたるため、公開サポートチケットに貼り付けないでください。
Parsersの内容：適用条件、YAMLの変更内容、スクリプトの原文を残し、それぞれどのサブスクリプションに適用していたか記録します。
ローカルルール：ルールの順序、参照しているプロキシグループ名、ルールセットのURL、ローカルファイルへの依存関係を記録します。
ポートとシステムへの接続：HTTP、SOCKS、混合ポート、LANアクセスの許可状態、システムプロキシとTUNの設定を記録します。
個人設定：ルールモード、よく使うプロキシグループで選択しているノード、DNSの独自設定を記録します。

サブスクリプションから一時的に生成されたノード一覧だけをバックアップにしないでください。更新によりノード名や認証情報、プロキシグループが変わることがあります。現在のYAMLだけをコピーすると、以後の更新に対応できなくなるおそれがあります。元のURLが見つからない場合は、手元のYAMLをローカル設定として読み込んで動作を確認し、サブスクリプション提供元に更新URLを問い合わせてください。

バックアップ後、CFWのシステムプロキシ、TUN、自動起動を無効にしてからアプリを終了します。旧サービスがまだネットワークを制御している場合は、先に停止してください。旧アプリは切り戻し用に残しておき、2つのクライアントでシステムプロキシや仮想NICのルートを同時に取り合わないようにします。

4. サブスクリプションの読み込み：まずオーバーライドなしで確認

Clash Verge Revを起動し、「サブスクリプション」ページで新規作成またはインポートから元のサブスクリプションURLを追加します。ボタンの名称はバージョンによって異なる場合があります。
サブスクリプションを更新し、現在の設定として選択します。プロキシグループとノードが表示されることを確認してください。サブスクリプション名だけが表示され、ノードがない状態では読み込み完了とはいえません。
「プロキシ」ページでルールモードを選び、主要なプロキシグループの選択内容を確認します。自動選択グループと手動選択グループでは動作が異なり、旧クライアントでの選択状態が自動的に引き継がれるとは限りません。
TUNは一時的に無効にし、システムプロキシだけを有効にします。ブラウザーでプロキシ不要のサイトと必要なサイトを開き、「接続」ページでルールと通信先を確認してください。

読み込みに失敗した場合はエラーの種類に応じて対処

HTTP 401または403の場合は、トークン、アカウント権限、サブスクリプションURLを確認します。タイムアウトの場合は、DNS、ネットワーク到達性、ダウンロード経路を切り分けてください。YAMLの解析エラーが出たら、取得した内容がHTMLページやエラーメッセージではないか確認します。プロキシグループの不足や存在しないノードの参照などは、コアのログを確認してください。システムプロキシを何度も切り替えても解決しません。

元のサブスクリプションを安易にオンライン変換サービスへ送らないでください。変換が必要な場合は、提供元がMihomo形式の設定を直接サポートしているか先に確認しましょう。第三者の変換サービスを使うと、サブスクリプションの認証情報も外部に送信することになります。基本動作を確認するまでは、DNS、ルール、TUNの変更を重ねないでください。

5. ParsersからMergeへ移行：変更内容に合わせて設定

CFWのParsersはクライアント側の設定処理機能であり、コア共通の設定項目ではありません。旧ファイルのparsers:、適用条件、JavaScript関数をMihomoのメイン設定にそのまま貼り付けることはできません。まず「何を変更していたか」を確認し、Verge RevのMergeまたはスクリプト処理に置き換えます。

旧Parsersの処理	移行方法	重点的に確認する点
スカラー値またはオブジェクト項目の上書き	Mergeを優先し、目的の設定に合うYAML構造で記述	項目の階層、値の型、実行時の最終値
ルールの先頭または末尾への追加	現行バージョンで正式にサポートされているリスト操作を使う。対応していない場合はスクリプトを使用	サブスクリプションの元ルールを残すか、ルールの挿入位置
ノード名の変更、条件に応じたプロキシグループの変更	新しいクライアントのインターフェースに合わせてスクリプトを書き直す	名称を参照する設定も更新し、スクリプトから完全な設定を返す
サブスクリプションURLに応じた処理の切り替え	該当するオーバーライドを対応するサブスクリプションに紐付ける	サブスクリプションの切り替え時に、別の設定へ誤適用されないか

Mergeの例：ログレベルとDNSキャッシュ方式の移行

以下のYAMLは、使用中のコアがcache-algorithmに対応している場合の例です。変更するのは明示した2項目だけで、サブスクリプション元のDNS、プロキシグループ、ルールは書き換えません。旧Parsersでこの2項目を設定していた場合は、「サブスクリプション」ページでMerge形式のローカル処理を作成し、現行バージョンの管理画面から対象のサブスクリプションに紐付けます。

log-level: info
dns:
  cache-algorithm: arc

保存後に設定を再適用し、実行時設定のlog-levelがinfo、dns.cache-algorithmがarcになっていることを確認します。コアが不明な項目を報告した場合は、実際のコアバージョンと設定ドキュメントを確認してください。エラーを無視して移行を完了させてはいけません。元のサブスクリプションでDNSが有効になっていなければ、この例を追加してもDNSは有効になりません。

ルール配列は通常の設定項目のようにそのまま移せない

YAMLのrulesは順序のあるリストで、通常は上から順に最初に一致したルールが適用されます。2つのルールだけを含むrules:をMergeに追加しても、先頭に2件追加されるとは限りません。リストの処理方法はクライアントの実装やバージョンに依存し、元のリストを上書きすることもあります。旧Parsersのprepend-rulesも、Mihomoにそのまま渡せる設定項目ではありません。

まずはDOMAIN,example.com,DIRECTのような、適用範囲を限定したテストルールで確認します。最初から全体に適用されるフォールバックルールを変更しないでください。
最終的なルール一覧を確認します。テストルールが意図した位置にあり、サブスクリプション元のルールが残っていて、MATCHが末尾にあることを確認してください。
サブスクリプションのプロキシグループを参照する場合は、グループ名を完全に一致させます。空白、大文字・小文字、記号が異なると参照に失敗することがあります。
旧スクリプトに条件分岐が含まれている場合は、新しいクライアントのスクリプト仕様に合わせて書き直します。CFWの引数、ヘルパー関数、戻り値の形式をそのまま再利用できると思い込まないでください。

6. ポートの移行：接続方法を維持し、既定値を鵜呑みにしない

旧CFWではHTTPポートに7890、SOCKSポートに7891がよく使われますが、実際の値は変更されている場合があります。Verge Revの既定ポートも、バージョンや既存データによって異なることがあります。「設定」のポート項目と実行時設定を確認してください。移行時は旧ポートを維持するか、利用するすべてのアプリの設定を新しいポートに更新します。

たとえば混合ポートを127.0.0.1:7890に統一する場合は、クライアントの対応するポート設定に入力し、最終的な設定項目も確認します。混合ポートはHTTPとSOCKSの両方を受け付けますが、旧来の個別ポートから自動転送されるわけではありません。

mixed-port: 7890
allow-lan: false

この設定が示すのは、ローカルマシン上の混合ポートだけです。GUI管理の項目がMerge内の同名設定より優先されることがあるため、まずクライアント側の該当設定で変更してください。通常のローカル利用ではLANアクセスを有効にする必要はありません。他の端末にプロキシを提供する必要がある場合は、待ち受けアドレス、認証、ファイアウォールの範囲を別途設定してください。

Windowsで確認する2項目

netstat -ano | findstr :7890
curl.exe --proxy http://127.0.0.1:7890 https://example.com/ -I

1つ目はポートの使用状況とプロセスIDを確認するコマンドです。旧クライアントがポートを使用している場合は、先に旧プロセスを停止します。2つ目はHTTPプロキシを明示してリクエストを送り、「プロキシの接続先が使えるか」と「アプリがシステムプロキシを使っているか」を切り分けます。HTTPの応答ステータスは接続先サイトの状態も踏まえて判断してください。コマンドが終了しただけでプロキシ経路が正常とは限りません。

ターミナルの環境変数、Gitのプロキシ設定、ブラウザー拡張機能、ダウンロードツールに古いポートが残っている場合があります。システムプロキシを変更しても、各アプリの独自設定は通常更新されません。外部コントローラーのexternal-controllerは管理APIであり、インターネット接続用のプロキシポートではありません。ブラウザーのプロキシアドレスに設定せず、移行のためにすべてのネットワークインターフェースへ公開することも避けてください。

7. 最後にTUNとDNSを戻し、二重の通信制御を防ぐ

システムプロキシは、アプリがOSのプロキシ設定に従う場合に使われます。TUNは仮想NICとルートを使って、より多くの通信を制御します。両者は同じスイッチではありません。基本設定とオーバーライドが安定してから、クライアントの案内に従って必要なサービスをインストールまたは起動し、TUNを有効にします。仮想NIC、ルート、ログを確認してください。Windowsでサービス権限の問題が起きた場合は、サービスの状態を確認して対処し、旧CFWのサービスファイルを流用しないでください。

旧CFWのTUNが無効になっていることを確認し、デフォルトルートを制御する可能性のある他のVPNツールを終了します。社内VPNを利用する環境では、組織のネットワーク要件に従ってください。
Verge RevのTUNを有効にし、まず通常のWebサイトを確認してから、以前はシステムプロキシに従わなかったアプリをテストします。
接続ページに対象のプロセス、宛先、ルールが表示されるか確認します。リクエストがコアに届いていない場合は、ノード設定ではなく通信の制御範囲を先に調べてください。
ドメイン名では失敗する一方、IPアドレスには接続できる場合は、DNSの上流設定、DNSハイジャックの設定、ログを確認します。名前解決方式とサーバーを一度にすべて変更しないでください。

Fake-IPを使うと、アプリに合成アドレスが返る場合があります。一般的なアドレスプールは198.18.0.1/16ですが、実際の設定を確認してください。これは接続先の実IPアドレスではなく、この表示だけでDNS汚染を判断することもできません。以前のDNSモードから切り替えたあともWindowsに古い結果がキャッシュされている場合は、ipconfig /flushdnsを実行し、影響を受けたアプリを再起動します。

LAN内のプリンターやNAS、社内ドメインで問題が起きる場合は、内部名をDNSで解決できるか、ルールがDIRECTになっているか、TUNのルートに対象のネットワークが含まれているかを個別に確認します。DIRECTルールを1つ追加しただけで、内部DNSがすぐ使えるようになるとは限りません。設定項目の詳細は高度な使い方をご覧ください。

8. 移行完了前の確認と切り戻しチェックリスト

旧環境を削除する前に、サブスクリプションを少なくとも1回更新し、クライアントを1回再起動してください。更新でオーバーライドが個別に保持されるか確認でき、再起動ではサービスの自動起動、ポート設定の保存、システムプロキシの復元などを確認できます。以下の項目をすべて満たしたら移行完了です。

サブスクリプションを更新でき、ノードとプロキシグループがそろっていて、意図したサブスクリプションが選択されている。
ルールモードで、直接接続とプロキシ接続がそれぞれ正しいルールと送信先に一致する。
ローカルのMergeまたはスクリプトがサブスクリプション更新後も適用され、元のルール一覧も失われていない。
ブラウザー、ターミナル、普段使うダウンロードツールが新しいポートを使用し、旧プロセスがポートを待ち受けていない。
TUNが必要な場合は、再起動後もサービスと仮想NICが正常に動作する。不要な場合は無効のままにする。
一時的に有効にしたデバッグログを通常のレベルに戻します。ログを共有する前に、サブスクリプションのトークン、ノードの認証情報、機密性の高いドメイン名を削除してください。

安定して動作しない場合は、新しいクライアントのシステムプロキシとTUNを無効にして終了します。ルートとプロキシ設定が元に戻ったことを確認してから、比較のために旧クライアントを起動してください。切り戻し中は、通信を制御する仕組みを常に1つだけにします。2つのクライアントを同時に動かして偶然接続できる状態を正常とみなさないでください。ポートやルートの競合が隠れている可能性があります。