Clash for Windows終了後の移行先：mihomo対応クライアントと設定の移行方法

まずサブスクリプションとルールを移行し、システムプロキシとTUNは後から設定

Clash for Windowsはすでにメンテナンスが終了しています。移行で大切なのは、見た目がまったく同じアプリを探すことではありません。サブスクリプションの取得元、カスタムルール、オーバーライドの処理、システムへの適用設定を分けて移行しましょう。まず新しいクライアントのシステムプロキシで基本動作を確認し、ルールとDNSが正常に動作してからTUNモードを有効にします。2つのクライアントで同時にシステムプロキシを変更したり、ルーティングを制御したりしないでください。

Clash for WindowsはGUIクライアント、mihomoはプロキシコアであり、役割の階層が異なります。mihomoはClashの設定体系を引き継ぎつつ、対応プロトコルや設定機能を拡張しています。同じコアを採用するクライアントでも、設定のマージ順、サービスの管理方法、スクリプトのインターフェースは異なる場合があります。以前のYAMLを読み込めても、旧クライアントの設定すべてが移行済みとは限りません。

Clash for Windowsの代替クライアントの選び方

Windowsのデスクトップで使う場合は、まずClash Verge RevとClash Nyanpasuを比較してみましょう。どちらもGUIクライアントですが、mihomoに対応しているからといって、設定フォルダーやオーバーライド形式、サービスコンポーネントをそのまま共用できるとは限りません。ダウンロード前に、プロジェクト名、最新のリリースノート、OSの要件、実際に使用するコアを確認してください。

現在の設定の複雑さに合わせて選ぶ

• サブスクリプションが1つだけ：インポート、更新、プロキシグループの選択、ログの確認が使いやすいかを重視しましょう。今は使わない機能のために、移行手順を増やす必要はありません。
• ルールやオーバーライドを設定済み：ルールを先頭に追加できるか、全体設定とサブスクリプション設定がどうマージされるか、最終的な実行設定を確認できるかを重点的に確認しましょう。
• TUNを使用する：サービスのインストール、管理者権限、仮想ネットワークアダプター、VPNとの併用可否を確認しましょう。TUNを有効にできても、すべてのアプリの通信が正しく制御されるとは限りません。

ダウンロードしたファイル名が似ていることを、プロジェクトを特定する根拠にしないでください。GUIのバージョン番号だけで判断するのも避けましょう。GUIクライアントのバージョンとコアのバージョンは別々に記録し、互換性を調べる際は両方を確認します。インストール先はダウンロードにまとめています。旧クライアントのインストーラーを移行先として案内するものではありません。

移行前のバックアップ：サブスクリプションの元データと実行設定を分ける

旧バージョンのClash for Windows 0.20.39で一般的な画面名を例に説明します。まずProfilesで設定の取得元を確認し、次にProxiesでプロキシグループの選択状態を記録します。最後にGeneralでポート、System Proxy、Allow LAN、TUNの状態を確認してください。バージョンによって項目の場所が異なる場合があります。スクリーンショットだけを頼りにボタンを探さないようにしましょう。

1. サブスクリプションの取得元を保存。サブスクリプションURL、設定名、更新間隔、変換サービスの利用有無を記録します。URLに含まれるトークンはアクセス認証情報に相当するため、ログのスクリーンショットに写さないでください。
2. サブスクリプションのYAMLを保存。再インポートやオフラインでの比較に必要です。URLだけを保存しても、後からローカルに追加したルールは残りません。
3. 最終的な実行設定を保存。実際に適用されている項目の確認に使えますが、クライアントが生成したポートやコントローラーの設定、キャッシュパスが含まれている場合があります。新しいクライアントの設定をそのまま上書きする用途には適しません。
4. Parsers、Mixin、スクリプトを別途保存。特定のサブスクリプションだけに適用される変更か、すべての設定に適用される変更かを記録します。すべて入っているように見えるYAMLを1つ保存するだけでは不十分です。
5. 外部依存関係を記録。rule-providers、proxy-providers、ローカルのルールファイル、カスタムDNS、コントローラーパネルの接続パラメーターなどを記録します。

旧設定フォルダー全体を新しいフォルダーに上書きしないでください。クライアント固有のデータベース、キャッシュ、サービスの状態、コアのキャッシュは互換性がない可能性があります。移行するのは内容を確認した設定ファイルやルールファイルであり、旧プログラムの実行環境すべてではありません。

サブスクリプションのインポート：まず元の設定だけで動作確認

1. 旧クライアントでSystem ProxyとTUNをオフにして終了し、旧サービスが引き続きネットワークを制御していないことを確認します。
2. 新しいクライアントを開き、サブスクリプションまたは設定管理画面から以前のサブスクリプションURLをインポートします。ローカルのYAMLしかない場合は、ローカル設定としてインポートしてください。更新用のURLが自動的に設定されると思い込まないようにしましょう。
3. カスタムオーバーライドはまだ追加せず、まずサブスクリプションを一度更新して設定を有効にし、ノードとプロキシグループが表示されることを確認します。
4. 動作モードがRule（ルール）であることを確認し、プロキシグループでノードを選び直します。通常、旧クライアントでの選択状態はYAMLと一緒には移行されません。
5. ローカルの待ち受けポートを確認してから、新しいクライアントのシステムプロキシを有効にし、一般的なWebページと、プロキシ経由で接続する予定のサイトをテストします。

ポートは実際の動作値を確認し、記憶に頼らない

旧環境では7890を使っていても、新しいクライアントでは別のポートが使われる場合があります。ターミナル、ブラウザー拡張機能、開発ツールが旧アドレスを参照したままだと、システムプロキシが正常でも接続に失敗することがあります。以下はポートのオーバーライド例であり、完全な設定ではありません。ポートをGUIで管理するクライアントでは、画面から変更してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-portはHTTPとSOCKSで共用する待ち受けポートを設定します。Windows PowerShellでは、以下のコマンドでこのHTTPプロキシ経由の接続を明示的にテストできます。実際のポートが7890以外の場合は、実行設定に表示されている値を使ってください。

curl.exe --proxy http://127.0.0.1:7890 --head https://example.com/

このテストで確認できるのは、指定したプロキシ経由でリクエストを1回処理できるかどうかだけです。TUNやルールの適用、すべてのアプリの動作を保証するものではありません。407 Proxy Authentication Requiredが返る場合は、ローカルプロキシの認証設定を確認してください。127.0.0.1に接続できないというエラーが出る場合は、まずポートとコアの動作状態を確認します。

ルールとオーバーライドスクリプト：処理内容を移行し、インターフェースは流用しない

Clash for WindowsのParsersやMixinと、新しいクライアントの設定マージやスクリプトオーバーライドは、同じインターフェースではありません。特にJavaScriptスクリプトは、入力オブジェクト、エントリーポイント、利用可能なAPI、実行タイミングが異なる場合があります。旧スクリプトの拡張子を変えただけで有効にしないでください。また、クライアントのスクリプトからブラウザーやNode.jsの機能をすべて利用できると思い込まないようにしましょう。

以前の変更を3種類に分ける

• 項目の上書き：log-levelやallow-lanなど。これらの項目をクライアントが管理するか確認し、画面設定またはオーバーライドを選びます。
• リストの変更：ルール、DNSサーバー、プロキシグループのメンバー追加など。新しいツールがリスト全体を置き換えるのか、先頭への追加や末尾への追加に対応するのかを確認します。
• プログラムによる処理：ノード名による絞り込み、一括リネーム、プロキシグループの動的生成など。移行先クライアントの最新のスクリプトインターフェースに合わせて書き直し、出力された設定を比較します。

ルールは上から順に照合されます。直接接続する社内ドメインをMATCHの後ろに追加すると、そのルールには到達しません。以下はフォールバックルールより前に置く2つのルール例であり、単独で動作する完全な設定ではありません。

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

corp.exampleは社内ドメインの照合例です。実際に使用する際は、管理しているドメインに置き換えてください。この2行でサブスクリプションのrulesリスト全体を置き換えてはいけません。移行先クライアントが対応する先頭ルール追加機能またはスクリプトインターフェースを使ってマージし、元のルールとフォールバックポリシーを残します。

ルールセットとローカルパスも確認

rule-providersのtype、behavior、formatとファイルの内容が一致している必要があります。旧環境の絶対パスは新しいインストール先では使えない場合があります。相対パスも、新しいクライアントが実際に使うコアの作業ディレクトリを基準に確認してください。proxy group not foundなどのメッセージが出る場合は、ルール内で参照するプロキシグループが存在するか確認します。名前のスペースや大文字・小文字も一致させてください。

DNS、TUN、外部コントローラー：最後に戻す3種類の設定

DNS：用途を保ち、項目をそのままコピーしない

旧設定のdns.enable、enhanced-mode、nameserver、fake-ip-filterを確認します。Fake-IPを使う場合、198.18.0.0/16は一般的なアドレス変換用の範囲であり、リモートノードのアドレスではありません。コアやDNSモードを変更した後も、ブラウザーやOSに以前の結果がキャッシュされていることがあります。まずテスト対象のアプリを終了して開き直し、必要に応じてWindowsでipconfig /flushdnsを実行してください。

DNSエラーを1つ解消するためだけに、すべてのDNS設定をパブリックDNSに変更しないでください。社内ドメインでは内部DNSが必要な場合があります。移行後は社内ドメインと一般的なインターネット上のドメインをそれぞれ1つ確認し、ログも見てリクエストが想定どおりの経路を通っているか確認しましょう。

TUN：まず権限を確認し、その後ルーティングを調べる

システムプロキシでのテストが成功したら、ほかのVPNや仮想ネットワークアダプターを制御するアプリを終了します。その後、新しいクライアントの要件に応じてサービスコンポーネントをインストールするか、管理者権限を付与してください。tun.enable、stack、auto-route、dns-hijackの最終値も確認します。プロトコルスタックやOSの環境によって動作は異なるため、特定のstackの値をすべての端末に共通する解決策と考えないでください。

TUNをオフにした状態とオンにした状態の両方で、Webページ、社内サイト、LAN内の機器、UDPが必要なアプリをテストします。Webページが表示できても、UDP転送が正常とは限りません。UDPの動作はノードのプロトコルやサービス、ルールにも左右されます。ネットワークに接続できなくなった場合は、まずTUNをオフにして、動作確認済みのシステムプロキシの状態に戻してから、項目ごとに原因を調べてください。

外部コントローラー：旧クライアントの待ち受け先をそのまま公開しない

外部パネルを使う場合は、external-controllerとsecretを再確認してください。ローカル端末だけからアクセスする場合は、127.0.0.1:9090のようなループバックアドレスを使えます。旧パネルをすぐ接続するために、すべてのネットワークインターフェースで待ち受ける設定に変更しないでください。旧パネルに保存したポートとキーも更新が必要です。通常のデスクトップ利用で、コントローラーをLANに公開する必要はありません。

移行後に接続できない場合：症状から原因を絞り込む

問題を報告する際は、OSのバージョン、クライアントのバージョン、コアのバージョン、エラー発生時刻、最小限の再現手順を記載してください。設定やログからは、サブスクリプションURL、ノードのパスワード、コントローラーのキー、機密性の高い社内ドメインを削除します。詳しい調査にはヘルプセンターと詳細設定もご覧ください。

最終確認と切り戻し：更新を1回、再起動を1回

• サブスクリプションの更新が成功し、ノードとプロキシグループがそろっていて、カスタムルールも上書きされていない。
• 動作モードが想定どおりで、よく使うプロキシグループを選び直し、接続ログで正しいルールが適用されている。
• ブラウザー、ターミナル、社内サイトをそれぞれテストする。TUNを使う場合は、LANとUDPを使うアプリも追加で確認する。
• クライアントを再起動してもポートとオーバーライドが正しく保たれ、OSの再起動後もサービスと自動起動が想定どおりに動作する。
• 旧クライアントのシステムプロキシ、TUN、自動起動をすべて無効にし、2つのプログラムが交互にシステム設定を変更しないようにする。

切り戻す場合は、まず新しいクライアントのシステムプロキシとTUNをオフにし、クライアントとサービスを終了してから旧環境に戻します。2つの環境で通信制御を同時に有効にして比較しないでください。移行の確認が終わってから旧プログラムを削除し、機密情報を除いた移行記録を1つ残しましょう。サブスクリプションの取得元、オーバーライドファイルの場所、最終的なポートを記録しておけば、次回の端末移行にも役立ちます。