Clash for Windowsのサポート終了後の移行方法｜サブスクリプション・スクリプト・設定の引き継ぎガイド

移行する4種類のデータを把握する

Clash for Windows（以下、CFW）のサポート終了後、移行時に大切なのは旧アプリのフォルダーを丸ごと新しいクライアントへコピーすることではありません。サブスクリプションの取得元、設定を加工する処理、プロキシ設定、Windowsとの連携を個別に移行しましょう。この記事ではClash Verge Revへの移行を中心に説明します。mihomoを採用する他のクライアントでも確認手順は参考になりますが、メニュー名やスクリプトの設定場所、データ保存先はそのまま当てはめられません。

クライアントとコアは別のソフトウェア層です。クライアントの画面ではサブスクリプションのダウンロードや自動起動、システムプロキシの切り替えを管理します。mihomoコアは最終的な設定を読み込み、ポートを待ち受け、通信を振り分けます。旧クライアントの画面設定ファイルは、新しいコアで読み込めるYAMLファイルとは異なります。

旧クライアントに保存された項目	移行方法	再確認が必要な項目
Profilesのサブスクリプション	元のサブスクリプションURLを再登録	有効期限、レスポンス形式、ノード、グループ
Parsersとカスタムルール	意図を整理し、新クライアント用の上書き設定に書き換える	実行順、ルールの順序、グループ名
System Proxyと待ち受けポート	新クライアントで設定し直す	実際の待ち受けアドレス、HTTP・SOCKSポート
Service Mode、TUN、自動起動	対応機能を再インストールまたは有効化	サービスの権限、DNS、ルーティング、起動方法

移行先クライアントの選び方

デスクトップでのサブスクリプション管理と上書き設定を引き継ぎたい：まずClash Verge Revを検討し、利用するバージョンのスクリプト、設定のマージ、サービスモードに関する説明を確認しましょう。
複数デバイスで操作をそろえたい：FlClashなどのクライアントと比較できます。ただし、上書きスクリプトがCFWのParsersと互換性があるとは限りません。
通常のサブスクリプションとルールモードだけ使いたい：まずサブスクリプションの登録、グループの選択、システムプロキシの設定から始めましょう。移行のためだけにTUNをすぐ有効にする必要はありません。

各クライアントの入手先はクライアント比較をご覧ください。インストール前にWindowsのアーキテクチャとリリースノートを確認し、インストール後は「バージョン情報」でクライアントとコアのバージョンを控えておきましょう。問題が起きた際、「最新版」とだけ伝えるより、この2つの情報が役立ちます。

旧設定をバックアップし、いつでも戻せる状態にする

まずCFWが使える状態のままバックアップします。一般的なインストールでは、データはユーザーディレクトリ内の .config/clash に保存されますが、ポータブルモードやカスタム起動オプションでは場所が異なることがあります。旧クライアントの設定フォルダーを開く機能から実際の保存先を確認し、ネット上で見つけたパスだけを頼りに探さないでください。

サブスクリプションの元URLを保存し、名前、最終更新日時、更新間隔も記録します。URLには認証情報が含まれることが多いため、安全なローカル環境にのみ保管してください。
ローカルのYAML、Parsersの内容、関連スクリプトをバックアップします。また、各処理の目的、たとえば「開発用サイトを指定グループに追加」といった内容も記録しましょう。コードだけではなく、何を実現する設定なのかを残すことが大切です。
現在のモード、選択中のグループ、HTTP／SOCKSポート、LANからの接続許可、TUNやDNSのカスタム設定を記録します。
自動起動、サービスモード、システムプロキシの状態も記録します。画面のスクリーンショットを撮ってから旧クライアントを終了し、ディスクに書き込まれていない設定を読み損ねないようにします。
バックアップは別のフォルダーにコピーしてください。新クライアントに旧クライアントのデータフォルダーを直接使わせず、最初の動作確認が終わるまでは旧アプリをアンインストールしないでください。

新クライアントのテストを始める前に、CFWのシステムプロキシと自動起動を無効にし、コアのプロセスが終了したことを確認します。ポートが異なっていても、両方のクライアントがWindowsのシステムプロキシ設定を交互に書き換えることがあります。TUNを同時に2つ動かすと、ルーティングやDNSの挙動も判断しにくくなります。

元のサブスクリプションを登録してから生成設定を確認する

Clash Verge Revの「サブスクリプション」画面から登録機能を開き、元のサブスクリプションURLを貼り付けて、追加した設定を選択します。リリースによってボタン名は「インポート」や「新規作成」など異なる場合があるため、使用中のバージョンに合わせてください。この段階では旧スクリプトを追加せず、サブスクリプションを新クライアントが取得でき、mihomoが読み込めることを確認します。

3種類のURLを混同しない

サブスクリプションURL：ノードまたは設定一式を返すURLです。通常はトークンを含み、更新元として使えます。
サービス提供元のマイページ：ログイン画面が表示されます。サブスクリプション欄に貼り付けると、HTMLの解析エラーになることがあります。
ローカルにエクスポートしたYAML：オフラインでの調査に使えますが、通常は元のサブスクリプションとの自動更新連携は復元されません。

登録後、ノード数、グループ、ルールが存在するかを確認します。ノード数が異なっても、必ずしも欠落とは限りません。レスポンスはサブスクリプションのパラメーター、User-Agent、サービス提供元のテンプレートによって変わる場合があります。まず元のレスポンスと比較し、必要であればリクエストヘッダーを調整してください。認証情報を含むURLを、信頼できないオンライン変換サービスに渡してはいけません。

3段階で動作を確認する

取得：サブスクリプションの更新が成功し、ログイン画面や期限切れの案内、空のレスポンスではないことを確認します。
設定：コアが正常に起動し、ログに未知のフィールド、存在しないグループの参照、YAMLの型エラーがないことを確認します。
接続：利用可能なノードを1つ選び、実際のリクエストでテストします。遅延テストの成功はテスト先へ到達できたことを示すだけです。ブラウザーでのアクセスや通信の振り分け確認も行いましょう。

元のサブスクリプションを使うのにCFWのParsersが必要な場合は、「形式の変換」と「ルールの追加」を切り分けて考えます。通常のルール追加は次の手順で再構築できます。レスポンス形式そのものがmihomoに適さない場合は、旧フォルダーのコピーに頼らず、サブスクリプションの提供元に対応形式を問い合わせてください。

Parsersの移行：処理内容を引き継ぎ、呼び出し構文は持ち込まない

CFWのParsersはサブスクリプションURLに応じて処理を適用し、YAMLの変更やJavaScriptの実行ができます。Clash Verge Revの設定マージやスクリプト設定は、それぞれ独自の呼び出し方と適用範囲を持ちます。旧コードの parsers、reg、yaml などの外側の構造を、通常のmihomoフィールドとして最終設定に貼り付けることはできません。

まず旧処理を、ルールの追加・削除、DNSなどのトップレベル項目の変更、ノードやグループの再構成の3種類に分けましょう。一度に1種類だけ移行し、適用後にクライアントが表示する最終設定または実行中の設定を確認してから次に進みます。フィールドの詳しい仕様はルール構文とDNS設定をご覧ください。

例：GitHubのドメインを既存のグループに追加する

以下は function main(config) をエントリーポイントとするClash Verge RevのJavaScriptスクリプト設定例です。CFW Parsersの設定ファイル全体を置き換えるものではありません。サブスクリプションに「ノード選択」というグループがあることを前提としています。使用前に実際のグループ名を確認してください。大文字・小文字やスペースも含めて一致させる必要があります。

function main(config) {
  const groups = Array.isArray(config["proxy-groups"])
    ? config["proxy-groups"]
    : [];

  if (!groups.some(group => group.name === "ノード選択")) {
    throw new Error("グループが見つかりません：ノード選択");
  }

  if (!Array.isArray(config.rules)) {
    throw new Error("設定にrulesリストがありません");
  }

  const customRule = "DOMAIN-SUFFIX,github.com,ノード選択";
  config.rules = [
    customRule,
    ...config.rules.filter(rule => rule !== customRule)
  ];

  return config;
}

このスクリプトはルールを先頭に追加し、同一の項目が重複して登録されるのを防ぎます。対象は github.com とそのサブドメインのみです。GitHubが利用する他のリソースドメインは自動的に対象になりません。移行時は対象範囲を明確に保ち、検証していないサイト全体のルールセットへ拡張しないでください。

ルールの順序とマージ方法に注意する

ルールは通常、上から順に評価されます：最終的なフォールバックである MATCH より後ろにカスタムルールを置くと、通常は実行されません。
配列が自動で追加されるとは限りません：設定のマージ方法によっては、rules 配列全体が置き換わります。変更後にサブスクリプション由来のルールが残っているか確認してください。
サブスクリプション単位と全体の上書きでは適用範囲が異なります：特定のサブスクリプション専用のグループルールは、そのサブスクリプションに紐付けましょう。切り替え後に存在しないグループを参照するのを防げます。
更新のたびに設定は再生成されます：キャッシュや生成済みファイルを直接編集すると更新後に変更が消えることがあります。クライアントが対応する永続化された上書き設定に変更を加えてください。

システムプロキシとポートを再設定し、待ち受けるコアを1つにする

旧画面の表示だけを見て、新しいポートも 7890 だと決めつけないでください。以下では 127.0.0.1:7890 を混合プロキシポートの例として使います。実際には新クライアントに表示される値を確認してください。mihomoの mixed-port は、同じポートでHTTPとSOCKSのプロキシ要求を受け付けます。HTTPとSOCKSの待ち受けを分ける場合は、異なるポートを使うこともあります。

待ち受けを確認してからシステムプロキシを有効にする

PowerShellで次のコマンドを実行し、例に示したポートを待ち受けているプロセスを確認します。新クライアントにポートの競合が表示された場合は、プロセスIDから該当するアプリを特定してください。正体がわからないシステムプロセスをそのまま終了しないでください。

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

Get-Process -Name "*clash*", "*mihomo*" -ErrorAction SilentlyContinue |
  Select-Object Id, ProcessName, Path

待ち受けが正常なことを確認してから、新クライアントで「システムプロキシ」を有効にします。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」から手動プロキシのアドレスを確認できます。Windows 10でも「設定」→「ネットワークとインターネット」→「プロキシ」を開きます。ポートは新クライアントのHTTPポートまたは混合ポートに合わせてください。

このPCだけで使う場合、通常はLAN接続を許可する必要はありません。接続エラーを解消するためだけに待ち受けアドレスをすべてのネットワークインターフェイスに変更したり、コントローラーAPIをLANに公開したりしないでください。コントローラーのアドレスとキーは別の設定であり、システムプロキシのポートとは異なります。

プロキシを明示したリクエストで原因を切り分ける

curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com/
curl.exe --proxy socks5h://127.0.0.1:7890 --head --max-time 15 https://example.com/

例ではタイムアウトを15秒に設定し、プロキシを明示的に指定しているため、ブラウザーがシステム設定を参照するかどうかに左右されません。2つ目のコマンドで使う socks5h は、接続先ドメインの名前解決をプロキシ側で行います。HTTPレスポンスが返ればテスト経路は確立していますが、接続パネルで適用されたルール、グループ、出力ノードも確認してください。

ブラウザーでは使えるのにターミナルでは使えない場合は、ターミナルの環境変数とアプリ独自の設定を確認します。HTTP_PROXY、HTTPS_PROXY、ALL_PROXY が旧ポートを指している可能性があります。WinHTTPのプロキシ設定も、Windowsユーザー単位のシステムプロキシとは別に管理されます。システムプロキシを一度切り替えただけで、すべてのアプリの移行が完了したと考えないでください。

基本的な接続を確認してからTUNとDNSを設定する

システムプロキシでのテストが成功してから、TUNが必要か判断します。TUNは仮想ネットワークアダプターとルーティングを使って通信を処理するため、システムプロキシに従わない一部のアプリも対象にできます。ただし、すべての通信が必ずリモートプロキシを通るわけではありません。最終的な通信先はルール、ルートの除外設定、DIRECTポリシーによって決まります。

まず旧クライアントのTUNを無効にし、旧コアや旧サービスが自動で再起動しないことを確認します。
新クライアントの現在のバージョンに対応した手順に従って、サービスモードをインストールまたは有効化します。旧CFWのサービスを新クライアントのサービスとしてそのまま使うことはできません。
新クライアントが生成するTUNの基本設定はそのまま使い、旧仮想ネットワークアダプターの設定、DNSハイジャックルール、カスタムルートを一度に持ち込まないでください。
TUNを有効にしたら、一般的なWebサイト、LAN内のデバイス、スリープからの復帰をテストします。企業VPNや他の仮想ネットワークアダプターも個別に確認し、同時に有効化して競合の原因がわからなくならないようにします。

DNSでは enhanced-mode、fake-ip-filter、上流リゾルバー、クライアントが生成する上書き設定を個別に確認します。旧設定で fake-ip を使っていても、古いDNS項目をすべてそのままコピーするべきとは限りません。対応フィールドは、現在使用しているmihomoのバージョンで確認してください。ルールに基づく名前解決を使う場合は、ドメインルールとDNSリクエストの経路との関係も確認します。

TUNを有効にして社内ドメインだけ解決できない場合は、まず企業DNSと通信の振り分け要件を確認します。LAN内のアドレスだけ使えない場合は、ルーティングとDIRECTルールを確認してください。社内ネットワーク全体をすぐにリモートノードへ送らないでください。TUNを無効にしてシステムプロキシに戻してテストすれば、サブスクリプションと仮想ネットワークアダプターの問題を切り分けられます。

更新確認、トラブル対処、旧クライアントの整理

移行完了の判断を「Webページを開けた」だけで済ませないでください。少なくともサブスクリプションを手動で一度更新し、クライアントを再起動し、Windowsへのログイン後に自動起動することを確認します。更新後もカスタムルールが残って初めて、上書き設定が永続化されていると判断できます。

症状	まず確認する項目	次に行うこと
インポート後にノードが表示されない	サブスクリプションのレスポンス、有効期限、形式	上書き設定を無効にし、元のサブスクリプションだけを確認する
設定の適用に失敗する	スクリプトのエラー、ルールの適用先、フィールドの型	直近で追加した変更を無効にする
更新後にルールが消える	生成済みファイルを直接編集していないか	永続化されるスクリプトまたは設定マージに移行する
ローカルポートへの接続が拒否される	コアの状態、実際のポート、ポートを使用中のプロセス	まず待ち受けを復旧し、その後ネットワークを確認する
再起動後にプロキシアドレスが旧設定へ戻る	旧クライアントの自動起動、旧サービス、他のプロキシアプリ	プロキシを管理するアプリを1つに絞る
TUNを有効にすると社内ネットワークに接続できない	ルーティング、DNS、企業VPN	システムプロキシに戻し、項目ごとに再テストする

移行完了前のチェックリスト

サブスクリプションを手動で更新でき、ノードとグループが想定どおりに表示される。
カスタムルールが正しく適用され、ルールで指定したグループが実際に存在する。
通常の終了と再起動の後も、システムプロキシのポートが旧アプリによって書き戻されない。
プロキシが必要なブラウザー、ターミナル、その他のアプリをそれぞれテストする。
TUNを有効にした場合は、LAN、DNS、スリープからの復帰、他のVPNを個別に確認する。
元のサブスクリプションURL、上書きスクリプト、設定の記録を別の場所にバックアップしてある。

これらの確認が済んだら旧クライアントをアンインストールし、不要になったサービスを旧クライアントの管理方法に従って削除します。一時的に旧環境へ戻す場合は、新クライアントのシステムプロキシとTUNを無効にしてコアを終了してから、旧クライアントを起動してください。2つのアプリに同時に通信を制御させないでください。移行後の日常的な設定は接続確認ガイド、サブスクリプションの管理はサブスクリプションの登録手順をご覧ください。