移行・代替 読了時間：約12分

Clash for Windowsのサポート終了後にClash Verge Revへ移行する方法｜サブスクリプション・ルール・ショートカット設定

サポート終了したクライアントからの移行先を整理し、サブスクリプションのエクスポート、設定項目の確認、オーバーライドスクリプトの移行、システムプロキシの再設定まで順を追って解説します。

移行範囲：クライアント設定とコア設定は分けて対応

Clash for Windows（以下、CFW）はすでにサポートを終了しています。Clash Verge Revへの移行は、単にアプリを入れ替えるだけではありません。画面や設定の管理方法、バックグラウンドサービスが変わるうえ、サブスクリプションの解析、ルールの適用、接続を担うコアも確認し直す必要があります。Clash Verge Revはmihomoを使用するため、CFWのユーザーディレクトリを丸ごと上書きして、設定がすべてそのまま使えると考えるのは避けてください。

移行前に、CFWの「General」に表示されるバージョン、ポート、動作モードと、「Profiles」で選択中の設定名を記録します。旧環境がCFW 0.20.39の場合、これはクライアントのバージョンを示すだけで、サブスクリプションで使われているプロトコルや、現在のmihomoがすべての項目に対応していることを意味しません。新しいクライアントとコアの実際のバージョンは、それぞれ現在の画面と起動ログで確認してください。

移行項目推奨する対応再確認が必要な点
サブスクリプションURLまたはYAMLファイル新しいクライアントで再インポート取得内容、プロトコル、グループ名
カスタムルール独立したオーバーライドまたは設定のマージに変更ルールの順序、振り分け先、リソースのパス
CFW Parsersとスクリプト元の目的に合わせて再実装スクリプトの実行方法、実行環境、マージの仕様
ポートとシステムプロキシ新しいクライアントで再設定ポートの競合、プロキシの除外設定、アプリの設定
TUNとバックグラウンドサービス新しいクライアントから再インストールして権限を付与権限、ルーティング、DNS、仮想ネットワークアダプター
ショートカットキーとスタートアップ項目ごとに再設定旧スタートアップタスクが動作し続けていないか

手順1：サブスクリプション、ルール、ローカル設定をバックアップ

現在のノード一覧だけでなく、元データを保存する

CFWの「Profiles」を開き、使用中のリモートサブスクリプションURLを記録します。メニューにURLのコピーや編集機能があれば、該当する項目から確認してください。ローカルファイルを使っている場合は、そのYAMLファイルをコピーします。サブスクリプションURLにはアクセストークンが含まれることが多いため、アクセスを制限したローカルフォルダーに保存し、公開リポジトリにアップロードしたり、トークンが見えるスクリーンショットを公開の場に投稿したりしないでください。

ユーザーディレクトリは通常 %USERPROFILE%\.config\clash にありますが、ポータブルモードやカスタムディレクトリでは場所が異なる場合があります。CFWの「General」にある「Home Directory」から実際の場所を確認してください。クライアントを終了してからディレクトリ全体をコピーし、ファイル名は変更せずに保管します。移行時はコピーから必要なデータだけを取り出し、新しいクライアントのデータディレクトリとして流用しないでください。

元のサブスクリプションと実際に使う設定を分けて保存

元のサブスクリプションにはノードとプロキシグループしか含まれず、実際に使う設定にはクライアントが追加したポート、DNS、TUN、スクリプトの処理結果が含まれる場合があります。元のサブスクリプションだけではカスタムルールが失われる可能性があり、実行時の設定だけでは旧PCのパスやポートを新環境へ持ち込むおそれがあります。用途をファイル名に記して両方を保存しておくと、画面のスクリーンショットだけを残すより確実です。

実行時の設定には、プロキシのパスワードやコントローラーAPIキーなどの機密情報が含まれることがあります。バックアップへのアクセスを制限し、トラブルシューティングのために共有するときは必要な項目だけを抜き出してください。リモートサブスクリプションを読み込むために、URLを不明な変換サイトへ渡すのも避けましょう。

手順2：サブスクリプションをインポートし、mihomoの設定互換性を確認

  1. クライアントのダウンロードページから、使用するシステムのアーキテクチャに合ったClash Verge Revのインストーラーを選びます。インストール後は、システムプロキシとTUNをオフにしたままにしてください。
  2. 新しいクライアントの「サブスクリプション」画面から元のサブスクリプションURLをインポートするか、ローカルファイルの読み込み機能でYAMLを追加します。バージョンによってボタン名が異なる場合があるため、画面の表示に従ってください。
  3. 新しい設定を選び、設定の検証結果とコアのログを確認します。まず解析エラーを解消し、その後で接続の問題に対応してください。
  4. 「プロキシ」画面でプロキシグループとノードが表示されていることを確認し、接続できると分かっているノードを選んでからルールモードを有効にします。

mihomoは多くのClash形式の設定を読み込めますが、「読み込める」ことと「動作が完全に一致する」ことは別です。旧サブスクリプションに含まれるプロトコルのパラメーター、ルールセットの形式、クライアント固有の拡張機能は確認が必要です。特に旧設定の script: による振り分けは、CFW ParsersのJavaScriptとして扱うことはできず、mihomoでそのまま動くとも限りません。現在のコアのドキュメントを確認し、対応するルールまたは論理ルールに書き換えてください。

不明な項目を一括削除せず、エラー箇所に応じて修正する

YAMLを直接テストする場合は、クライアントと同じバージョンのmihomoで設定を検証できます。以下はWindows PowerShellの例です。コマンドを実行するディレクトリにコアのファイルとテスト用設定があることが前提です。検証に通っても、設定を読み込めることが分かるだけで、リモートノードへの接続を保証するものではありません。

.\mihomo.exe -t -f .\migration-test.yaml

手順3：ルールのオーバーライドを再構築し、サブスクリプション更新後の消失を防ぐ

長期的に使うカスタムルールを、リモートサブスクリプションのキャッシュへ直接書き込まないでください。次回の更新で変更が上書きされることがあります。「リモートのノードとプロキシグループ」と「ローカルで維持する設定」を分け、前者はサブスクリプションの更新に任せ、後者はClash Verge Revの設定マージまたはスクリプト機能で処理し、現在の設定に適用されていることを確認します。

静的ルールを先に移し、スクリプトは後から移行する

CFW Parsersはクライアント側の前処理を記述するもので、汎用的なコア設定ではありません。条件と処理手順を含むParsersファイルを新しいクライアントのマージ用エディターに貼り付けても、通常は同じ結果になりません。まず各処理の目的（例：「特定のドメインをDIRECTにする」「期限切れのノードを削除する」「プロキシグループにフィルター条件を追加する」）を整理し、静的ルール、設定マージ、スクリプトから適切な方法を選んで一つずつ再構築してください。

以下はローカルのオーバーライドに使えるルール例で、サブスクリプション全体ではありません。example.com はドキュメント用のサンプルドメインなので、実際の用途に合わせて置き換えてください。ここでは組み込みポリシーの DIRECT を使うため、サブスクリプション内のプロキシグループ名には依存しません。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

動的な処理が必要な場合は、スクリプトの実行方法を確認する

現在のバージョンのスクリプトエディターが main(config) を入口としている場合は、以下の形式でルールを先頭に追加できます。エディターに別のテンプレートが用意されている場合は、そちらに従ってください。スクリプトは設定オブジェクトを返す必要があります。このコードはスクリプトエディター専用であり、YAMLとしてインポートできません。

function main(config) {
  const localRule = "DOMAIN-SUFFIX,example.com,DIRECT";
  const existingRules = Array.isArray(config.rules) ? config.rules : [];
  config.rules = [
    localRule,
    ...existingRules.filter((rule) => rule !== localRule)
  ];
  return config;
}

このスクリプトは既存ルールの相対順序を保ちながら、サンプルルールの重複を防ぎます。実際の環境では、より広い範囲に一致する先行ルールがないか、ルールプロバイダーに依存していないか、後続のマージ処理で結果が再び上書きされないかも確認してください。移行中はオーバーライドを一度に一つだけ有効にし、最終設定を確認してから次へ進むと、問題の切り分けが容易になります。

手順4：システムプロキシを切り替え、ポートとショートカットを再設定

旧コアを停止してから、新しいクライアントに切り替える

  1. CFWの「General」で「System Proxy」をオフにします。TUNを有効にしている場合はそれもオフにしてから、タスクトレイからCFWを終了してください。
  2. タスクマネージャーを開き、旧コアのプロセスが終了していることを確認します。ポートがまだ使用中の場合は、まず使用しているプロセスを特定してください。不明なシステムプロセスをそのまま終了しないでください。
  3. Clash Verge Revの「設定」でポートとシステムプロキシの項目を確認します。ポート設定、システム設定、高度な設定など、バージョンによって項目の場所が異なる場合があります。
  4. 新しいクライアントのシステムプロキシを有効にし、テストするアプリを開いて、「接続」画面にリクエストが表示されるか確認します。

たとえば、旧アプリの接続先を 127.0.0.1:7890 に手動設定していて、新しいクライアントが 7897 で待ち受けている場合、システムプロキシを切り替えてもアプリのポートは自動で変わりません。新しいクライアントで旧ポートを使うか、ブラウザー拡張機能、ターミナルの環境変数、開発ツールの手動プロキシ設定を一つずつ変更してください。ここでの 7890 と 7897 はトラブルシューティング用の例であり、特定バージョンのデフォルト値を示すものではありません。

netstat -ano | findstr ":7890"
netstat -ano | findstr ":7897"

出力のうち LISTENING 状態の行から待ち受けプロセスを特定でき、最後の列にPIDが表示されます。そのPIDをタスクマネージャーの「詳細」タブで確認してください。コントローラーAPIのポートとプロキシのポートは用途が異なります。たとえば設定の external-controller を、ブラウザーのHTTPプロキシに指定することはできません。

ショートカットキーとスタートアップ項目を手動で再設定

手順5：最後にTUNとDNSを移行し、段階ごとに接続を検証

まずシステムプロキシを検証し、その後でTUNを有効にします。システムプロキシはアプリがプロキシ設定に従う必要がありますが、TUNは仮想ネットワークアダプターとルーティングで通信を処理するため、影響範囲が異なります。コア、ルール、DNS、TUNを同時に変更すると、問題がどの層で発生したのか判断しにくくなります。

新しいクライアントの「設定」で必要なサービスをインストールまたは有効化し、案内に従って管理者権限を許可してから「TUNモード」をオンにします。旧クライアントのサービスディレクトリや仮想ネットワークアダプターのファイルはコピーしないでください。移行中は、別のVPNや旧TUNサービスがデフォルトルートを同時に制御しないようにします。

DNS設定では最終的な適用結果を確認

旧環境で fake-ip を使っている場合は、新しい実行時設定の dns.enable、dns.enhanced-mode、フィルターリストを確認します。サブスクリプションファイルにこれらの項目があるだけで、クライアントがそのまま適用すると判断しないでください。画面上の設定、グローバルオーバーライド、サブスクリプションが組み合わさって、実行時設定が生成されることがあります。

mihomoのTUNでは、dns-hijack により対象となる従来型DNS通信を横取りできますが、ブラウザー内蔵の暗号化DNSまで自動的に処理するわけではありません。ブラウザーの「セキュアDNS」、OSの暗号化DNS、他のVPNによる名前解決も個別に確認してください。変更後も古い名前解決結果が使われる場合は、該当アプリを終了して再度試します。Windowsの ipconfig /flushdns が消去するのはOSのDNSキャッシュのみで、すべてのアプリやコアのキャッシュが消えるわけではありません。

確認段階確認内容合格の目安
設定の読み込みサブスクリプションを選択してコアを起動設定解析エラーがログになく、ノードとプロキシグループが表示される
システムプロキシシステムプロキシに従うアプリでアクセス「接続」画面にリクエストが表示され、適用ルールと出口が想定どおり
カスタムルールルールの対象にアクセス指定したルールに一致し、先行する別のルールに振り分けられていない
サブスクリプション更新現在のサブスクリプションを手動で更新ローカルのオーバーライドが保持され、プロキシグループへの参照も有効
TUNによる通信の処理これまでシステムプロキシを使っていないアプリを確認ルーティングと接続ログが想定どおりで、社内ネットワークにもアクセスできる
再起動後の復元クライアントを終了して再起動ポート、サービス、スタートアップ項目、プロキシグループの選択が想定どおりに復元

よくある移行トラブルと元に戻す手順

サブスクリプションをインポートできても、ブラウザーでWebページを開けない

まずコアが動作しているか確認し、次にシステムプロキシの接続先アドレスとポートを調べます。「接続」画面にリクエストがまったく表示されない場合は、ノードをすぐに切り替えるのではなく、アプリがシステムプロキシを使っているか、手動プロキシが旧ポートを指したままになっていないか確認してください。接続ログがある場合は、一致したルール、プロキシグループの選択、エラーログから出口側の問題を判断します。

ノードの遅延テストは成功するのに、実際のアクセスに失敗する

遅延テストで分かるのは、指定したテスト先からその時点で応答があったことだけです。すべてのWebサイト、UDP、DNSが正常に動作する保証にはなりません。DIRECTになるはずの接続先とプロキシ経由になるはずの接続先をそれぞれ試し、適用ルールと出口を確認してください。一度の遅延値だけで移行全体の検証を済ませないようにしましょう。

サブスクリプション更新後にルールが消える

変更をリモート設定のキャッシュに直接書き込んでいないか、オーバーライドが別のサブスクリプションにだけ適用されていないか確認します。マージ順序を見直し、後続の配列置換でカスタムルールが消えていないこと、MATCH の後ろに置かれていないことを確認してください。ルールは上から順に照合されるため、配置によって結果が変わります。

一時的にCFWへ戻す手順

  1. 新しいクライアントでシステムプロキシとTUNをオフにし、クライアントを終了します。
  2. 新しいコアが停止し、関連するポートが使われていないことを確認します。2つのクライアントでシステムプロキシを何度も奪い合わないようにしてください。
  3. 保管しておいた旧環境を起動し、元の設定と通信の制御方法を復元します。新環境で失敗した際の具体的なログを記録してください。
  4. 記録をもとに新しい設定を修正し、同じ手順でもう一度切り替えます。

旧環境への切り戻しは一時的なトラブルシューティングであり、旧クライアントのサポートが終了している事実は変わりません。サブスクリプション更新、ルールの適用、DNS、社内ネットワークへのアクセス、再起動後の復元を確認してから、旧スタートアップ項目とバックグラウンドサービスを削除してください。システムプロキシとTUNの基本設定は使い方ガイドで確認できます。mihomoの設定項目はプロトコルマニュアルを参照し、画面上の項目名からコアの動作を推測しないでください。

Clash をダウンロードプラットフォームとクライアントを選択