Clash for Windows終了後の移行方法：代替クライアントと設定移行ガイド

Clash for Windowsのサポート終了後も、旧バージョンを残しているからといって、現在の設定がすぐに使えなくなるわけではありません。サブスクリプションURL、プロキシノード、プロキシグループ、ルールは通常、設定ファイルから提供されます。クライアントは主に設定管理、コアの起動、システムプロキシ、TUNによるトラフィックの引き受け、画面操作を担います。そのため移行で重要なのは、見た目が同じソフトを探すことではなく、新しいクライアントが対応するコアを実行でき、既存の設定構文を読み込み、OSのネットワーク設定を正しく引き継げるかを確認することです。

安全性を重視するなら、まず旧データをバックアップし、現在も保守が続いているデスクトップクライアントを選び、サブスクリプションURLまたは元のYAMLから再インポートします。最後にルールモード、プロキシグループ、DNS、システムプロキシ、TUNを一つずつ確認してください。旧クライアントが通信を引き受けている状態で新クライアントを直接有効にすると、2つのプログラムがシステムプロキシ、仮想ネットワークアダプター、サービス状態を同時に変更し、原因の切り分けが難しくなる場合があります。

移行対象がサブスクリプション、設定、それとも実行環境なのかを確認する

Clash for Windowsで表示される「設定」は、異なる経路から取得されたデータを含む場合があります。最も一般的なのはリモートサブスクリプションです。クライアントがサブスクリプションURLを保存し、更新時にYAMLをダウンロードして、そこからノード、プロキシグループ、ルールを読み込みます。2つ目は、手動でインポートしたローカルYAMLです。自分で作成した分流設定ファイルなどが該当します。3つ目は、スタートアップ、システムプロキシのポート、画面設定、設定の上書き、スクリプト処理、TUNサービスといったクライアント固有の設定です。これら3種類のデータは、移行のしやすさがそれぞれ異なります。

サービス提供元のサブスクリプションをインポートしただけで、YAMLを手動編集していない場合、移行は通常簡単です。サブスクリプションURLとよく使うプロキシグループの選択を控え、新しいクライアントで再インポートすれば完了します。長期間にわたってカスタムルール、プロキシプロバイダー、DNSパラメーターを管理していた場合は、元のYAML、外部ルールファイル、関連パスをまとめて整理してください。旧クライアントが生成した現在の実行用設定だけをコピーするのは避けましょう。

代替クライアントの選び方：コア、対応プラットフォーム、設定機能

デスクトップの代替候補は、まず保守状況を確認し、その後にOS対応とコア機能を見ます。Clash Verge RevはWindows、macOS、Linuxに対応するデスクトップクライアントで、mihomoコアを使用します。ルール分流、設定管理、システムプロキシ、TUNを必要とするユーザーに適しています。mihomoはClashの設定体系を引き継ぎながら、ルールセット、プロトコル、DNS、トラフィック引き受けの機能を拡張しているため、多くの一般的なClash YAMLを引き続き利用できます。

現在も保守が続いているmihomo対応の他のGUIクライアントも候補になりますが、画面だけで比較しないでください。より重要なのは、リリース頻度、使用しているコアのバージョン、設定ファイルの保存方法、システムプロキシの復元機構、TUNサービスのインストール方法、接続・ログ・ルールのヒット結果を確認できるかどうかです。保守状況は時間とともに変わるため、現在のリリース履歴と公式ドキュメントを基準に判断してください。

代替クライアント選びで確認したい6項目

1. 対応プラットフォーム：現在利用しているWindows、macOS、Linuxのバージョンを明確にサポートしているか確認し、対応するCPUアーキテクチャを選びます。
2. コアの種類：mihomoを使用しているか、クライアント上でコアのバージョンを確認・更新できるかを確認します。
3. 設定の互換性：サブスクリプション、ローカルYAML、プロキシプロバイダー、ルールプロバイダー、カスタムDNSに対応しているか確認します。
4. トラフィックの引き受け方：システムプロキシとTUNを個別に制御できるか、終了時にシステム設定を復元できるか確認します。
5. 診断機能：接続一覧、リアルタイムログ、ルールマッチング、DNSログがあると、移行時の問題を特定しやすくなります。
6. 設定の維持：サブスクリプション更新、上書き、結合の仕組みを確認し、更新のたびにローカルの変更が消えないようにします。

旧版Clash for Windowsの設定には、当時のClash Premiumの動作に依存するものや、クライアント専用のparser機能でサブスクリプションを書き換えるものがあります。mihomoは一般的なノード、プロキシグループ、ルール構文との互換性が高い一方、クライアント専用スクリプト、JavaScriptによる解析ロジック、画面設定は汎用YAML標準に含まれないため、通常は再構築が必要です。選定前にクライアント比較を確認し、プラットフォームと設定の複雑さに応じて決めてください。

Clash for Windowsのデータを移行前にバックアップする方法

バックアップの目的は復元に必要な情報を残すことであり、旧ディレクトリ全体を新しいクライアントのディレクトリへそのまま上書きすることではありません。開始前にClash for Windowsを開き、現在有効な設定名、プロキシモード、よく使うプロキシグループ、システムプロキシの状態、TUNの状態を記録します。サブスクリプションURLを設定管理画面で確認できる場合は、別途保存してください。URLにアクセストークンが含まれる場合は、バックアップを管理された場所に保管し、公開スクリーンショット、ログ、フォーラムに貼り付けないでください。

続いてClash for Windowsを終了し、タスクトレイのプロセスも終了していることを確認します。Windowsの旧データはユーザーディレクトリ内の設定ディレクトリに保存されることが多いものの、具体的な場所はインストール方法やバージョンによって異なります。固定パスを推測するより、クライアントの設定画面または設定管理画面からデータディレクトリを開き、そのディレクトリ全体を読み取り専用のバックアップとしてコピーする方が確実です。

残しておきたい内容

• サブスクリプションURL、サブスクリプション名、最後に正常更新できた日時；
• 自分で作成したYAMLファイルと、そこから参照しているローカルルールファイル；
• 現在の実行設定。移行後に各セクションを比較するために使用；
• プロキシグループでよく使う選択。自動選択、フォールバック、特定ノードなど；
• カスタムポート、LANアクセス、DNSリスニング、コントローラー設定；
• 上書き、結合、parserスクリプトの元ファイルと処理ロジックの説明。

バックアップが完了したら、旧クライアントでシステムプロキシとTUNを無効にしてから通常どおり終了します。OSのプロキシ設定を開き、手動プロキシが旧クライアントのローカルポートを指し続けていないことを確認してください。旧TUNサービスが残っている場合は、旧クライアントのサービス管理画面から停止またはアンインストールしてから、新しいクライアントの対応サービスをインストールします。

サブスクリプションとYAML設定の移行手順

方法1：サブスクリプションURLを再インポートする

多くのユーザーにとって、サブスクリプションの再登録が最も簡単な方法です。新しいクライアントをインストールしたら、まずシステムプロキシとTUNを無効にしたまま、設定またはサブスクリプション画面を開きます。元のサブスクリプションURLを貼り付け、クライアントが設定をダウンロードして解析するまで待ちます。インポート後は、ノード数、プロキシグループ名、ルール数が想定どおりか確認し、よく使うプロキシを手動で選択します。

サブスクリプションのインポートに成功しても、YAMLを読み込めたことを示すだけで、通信が正常とは限りません。設定に MATCH などの最終的なフォールバックルールが含まれているか、主要なプロキシグループが有効なノードを参照しているかも確認してください。サブスクリプションによっては、クライアントのリクエストヘッダーに応じて異なる形式を返します。新しいクライアントで空の設定や形式エラーになる場合は、まずサブスクリプション提供元の管理画面からClashまたはmihomo用のURLを取得し直してください。

方法2：ローカルYAMLをインポートする

ローカル設定は、新しいクライアントのファイルインポート機能から追加します。インポート前にテキストエディターで、proxies、proxy-providers、proxy-groups、rule-providers、rules、dnsなど主要なセクションを確認できます。プロキシグループが参照するノードまたはプロバイダーが実際に存在し、ルールで参照するプロキシグループ名も定義名と完全に一致している必要があります。

mode: rule
mixed-port: 7890

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

上記の構造は、最も基本的な参照関係を示しています。ルールが通信を PROXY に渡し、PROXY プロキシグループはあらかじめ定義されていなければなりません。実際の移行では、例のポート番号やルールを機械的にコピーせず、元の設定要件を維持しながら、新しいクライアントの使用状況に合わせて調整してください。相対パスのファイルを参照している場合は、新しいクライアントの作業ディレクトリも確認します。アプリケーションを変更すると、同じ相対パスが別の場所を指す可能性があります。

方法3：上書きと結合のロジックを再構築する

Clash for Windowsでは、parserを使ってサブスクリプションにルールを追加したり、プロキシグループを削除したり、ノード名を書き換えたりするユーザーもいます。この処理は通常、通常のYAMLとしてインポートできません。移行時はまずサブスクリプションが生成する基本設定を取得し、新しいクライアントが対応する上書き、結合、スクリプト機能を使って同じ目的を再構築してください。

再構築するときは、作業を小さく分けるのがおすすめです。まずプロキシグループを1つ追加し、対応するルールを加え、設定を読み込めることを確認してから次へ進みます。大量のスクリプトを一度に移行すると、構文エラー、名前の参照ミス、ルール順序の問題が混在します。ルールは上から順に評価され、マッチした時点で停止するため、追加ルールは適切な位置に配置してください。内容が存在することを確認するだけでは不十分です。

TUN、DNS、システムプロキシはそのまま移行できない

システムプロキシは、OSのプロキシ設定に従うアプリケーションだけに影響します。一般的なブラウザーや一部のデスクトップアプリは、ローカルのHTTPまたはSOCKSポートを経由します。一方、TUNは仮想ネットワークインターフェースとルーティングによって、システムプロキシを参照しないプログラムを含む、より多くの通信を引き受けます。どちらも実行環境の設定であり、サブスクリプション内のノードデータではないため、クライアントを変更したら再設定が必要です。

まずはシステムプロキシで基本動作を確認するのがおすすめです。利用可能なノードを選び、ルールモードとシステムプロキシを有効にして、Webページへのアクセス、ルールヒット、DNS解決が正常か確認します。基本経路が安定してからTUNを有効にし、新しいクライアントの案内に従ってサービスをインストールするか、管理者権限を付与してください。問題が起きても、設定ファイルの誤りなのか、仮想ネットワークアダプター、権限、ルーティングが原因なのかを切り分けやすくなります。

DNS設定は特に慎重に扱う必要があります。mihomoでよく使われる拡張モードには fake-ip と redir-host がありますが、利用できる項目はコアのバージョンと設定によって異なります。移行後、Webページは開けるのに一部のLANドメイン、ゲーム、業務ソフトだけが不安定な場合は、すぐにノードを変更するのではなく、DNSの待受アドレス、拡張モード、除外リスト、上流DNS、ルールモードを確認してください。

元の設定でLANアクセスを有効にしていた場合は、allow-lan、待受アドレス、OSのファイアウォールも改めて確認します。ループバックアドレスで待ち受ける場合は自分のPCだけが利用でき、すべてのインターフェースで待ち受ける場合は同じネットワーク上の端末から接続できる可能性があります。移行時は実際の共有要件に合わせて設定し、旧設定が存在するからという理由だけでコピーしないでください。

移行後に通信経路を確認する方法

移行後の確認は、設定の読み込み、ノード接続、ルールマッチング、システム設定の復元という順に段階的に行います。Webページを1つ試すだけでは、ブラウザーのキャッシュ、接続の再利用、アプリ独自のDNSによって問題が隠れることがあります。次の順番で確認してください。

1. 新しいクライアントを起動し、ログにYAML解析、プロキシグループ参照、ポート競合のエラーがないことを確認します。
2. サブスクリプションを更新し、更新日時、ノード数、プロキシグループの構成が妥当か確認します。
3. ルールモードで明確なプロキシグループの出口を選び、通常のWeb接続をテストします。
4. 接続またはログ画面を開き、対象ドメインがどのルールにヒットし、最終的にどのプロキシが選ばれたか確認します。
5. 直接接続すべきドメインとプロキシ経由にすべきドメインをそれぞれテストし、DIRECT とプロキシ設定が想定どおりか確認します。
6. TUNを有効にした後、システムプロキシを参照しないアプリをテストし、該当する接続がコアに取り込まれているか確認します。
7. クライアントを終了し、システムプロキシが復元され、停止したローカルポートへ通信が向かい続けていないことを確認します。

ルールのヒット結果が旧クライアントと異なる場合は、サブスクリプション名だけでなく、両方で実際に読み込まれた最終設定を比較してください。サブスクリプション更新、クライアントの上書き、ルールセットのダウンロード失敗、コア機能の違いによって、最終的な内容が変わることがあります。mihomoの接続詳細には通常、ルールの種類、プロキシチェーン、出口ノードが表示されます。これらは通信速度だけを観察するより、分流が正しく行われているかを判断するのに適しています。

移行後によくある問題と対処の順番

サブスクリプションはインポートできるが、ノードが表示されない

まずサブスクリプションURLの有効期限と、返される内容がClashまたはmihomoの設定かどうかを確認します。サービス管理画面で形式変換が必要なURLもあります。ブラウザーで開いた結果がログインページ、エラーテキスト、別クライアント用の形式だった場合、新しいクライアントでノード一覧を生成できないのは当然です。

設定でプロキシグループが存在しないと表示される

rulesで使用しているプロキシ名が、proxy-groupsの定義と完全に一致しているか確認します。大文字・小文字、スペース、記号も一致していなければなりません。プロキシグループが use を参照している場合は、対応する proxy-providers が定義され、ダウンロードにも成功していることを確認します。プロキシグループを手動で削除した場合は、それを参照するルールも同時に修正してください。

起動時にポートが使用中と表示される

旧クライアントまたは旧コアのプロセスがバックグラウンドでポートを待ち受けている可能性があります。まず2つのクライアントを完全に終了し、タスクマネージャーやシステム監視ツールで関連プロセスが終了したことを確認してから、新しいクライアントを起動します。一時的に新しいクライアントの混合ポートを変更する方法もありますが、その場合はシステムプロキシも新しいポートに合わせて変更する必要があります。

TUNを有効にするとインターネットに接続できない

まずTUNを無効にし、システムプロキシモードが正常に動作するか確認します。システムプロキシが使える場合は、TUNサービス、権限、仮想ネットワークアダプター、ルーティング、DNSを重点的に確認してください。複数のクライアントをインストールしたことがある場合は、旧サービスが動作し続けていないかも確認します。サービスの競合を解消してからシステムを再起動し、残ったルートが判断に影響しないようにします。

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

これは通常、変更内容をサブスクリプションのキャッシュへ直接書き込んでいたことを意味します。リモート更新では設定が再ダウンロードされ、キャッシュの内容が上書きされます。新しいクライアントの上書きまたは結合機能でローカルルールを管理するか、独立したYAMLを作成し、リモートノードをプロキシプロバイダーとして更新してください。具体的な項目と操作方法は技術リファレンスを参照してください。

旧クライアントはすぐ削除すべきか

バックアップ後は、インストーラーとデータディレクトリをしばらく残しておいて構いません。ただし旧クライアントをスタートアップで起動したり、新しいクライアントと同時にシステムプロキシやTUNを引き受けさせたりしないでください。数日使ってサブスクリプション更新、ルール分流、スリープ復帰、終了時の復元が正常だと確認してから、旧プログラムとサービスを削除する方が安全です。

移行の結論：設定の出所を残し、実行環境を再構築する

Clash for Windows終了後の移行で重要なのは、再利用できるものと再構築が必要なものを分けることです。再利用できるのはサブスクリプション、ノード、プロキシグループ、汎用ルールです。一方、再構築が必要なのはクライアント設定、上書きロジック、システムプロキシ、TUNサービス、一部のDNS動作です。通常のサブスクリプションユーザーなら、サブスクリプションを再インポートしてプロキシグループを確認すれば十分でしょう。カスタムYAMLを管理しているユーザーは、名前の参照、ルール順序、外部ファイルのパス、コアの構文を重点的に確認してください。

代替クライアントを選ぶ際は、画面の類似性よりも、継続的な保守、mihomoコアへの対応、診断機能、システム引き受けの安定性が重要です。移行後は元の設定バックアップを保管し、新しいクライアントの主要設定も記録しておきましょう。次に端末やクライアントを変更するときも、特定のプログラムが生成した一時キャッシュに頼らず、明確なデータソースから復元できます。