Clash for Windows終了後の対処法：mihomoコア対応クライアントへの移行ガイド

移行が必要なのはクライアント、サブスクリプション、それともローカル設定かを確認する

Clash for Windowsのメンテナンス終了後も、すでにインストール済みの環境がすぐ使えなくなるわけではありません。サブスクリプションURLにアクセスでき、ノードのプロトコルが現在のコアでサポートされていれば、旧クライアントで設定を読み込み、通信を中継できる場合があります。本当の問題は、コアの更新が長期間止まることで、新しいプロトコルの項目、ルール構文、DNSの挙動、OSとの互換性が追従されなくなることです。旧バージョンを残すのは短期的な移行期間には向いていますが、長期的な設定環境として使い続けるのはおすすめできません。

移行前に、データを3種類に分けて考えましょう。クライアントはGUIとOS連携を担う層、サブスクリプションはサーバー側で設定を生成する入口、ローカルのYAMLは手動登録したノード、ルールセット、DNS、TUNの項目などを含むファイルです。これらを1つのファイルとして扱ってはいけません。サブスクリプションだけを使っている場合、通常はサブスクリプションURLを保存するだけで移行できます。手動ルールや上書き設定がある場合は、設定ファイルを書き出し、端末固有の項目も別途記録してください。

移行先の条件

現在もメンテナンスが続き、mihomoをコアに採用し、コアのバージョン表示と設定検証に対応したクライアントを優先しましょう。mihomoはClashの設定体系を引き継ぎながら、プロトコル、ルールセット、DNS、TUN、トラフィック解析の機能を拡張しています。旧設定はそのまま読み込めることが多く、端末に合わせて調整できます。

移行前に保存しておくもの

サブスクリプションの元URL、サブスクリプション名、更新日時、残りの通信量。
現在使用中のYAMLファイル。クライアントのスクリーンショットだけで済ませないでください。
プロキシグループで手動選択しているノード。たとえば「ノード選択」「ストリーミング」「ダウンロード」で何を選んでいるか。
ローカルの上書き設定。DNS、TUN、ルールの追加、プロキシを経由しないアドレス、アプリの振り分けリストなど。
システムプロキシのポート。一般的なMixedポートは7890、コントロールポートは9090ですが、実際の値は旧設定を確認してください。

Clash for Windowsから設定を取り出す

Clash for Windowsでまず「Profiles」を開き、現在の設定名を確認します。サブスクリプション設定は画面に表示されるサブスクリプションURLを記録し、ローカル設定は設定メニューからファイルの保存場所を開きます。一般的なデータディレクトリは%USERPROFILE%\.config\clashですが、ポータブル版やカスタムHome Directory、配布パッケージによって異なる場合があります。クライアントに表示されるディレクトリを優先してください。

ディレクトリをコピーする際は、config.yaml、サブスクリプションから生成されたYAML、Providerのキャッシュ、カスタムスクリプトを確認します。キャッシュファイルは移行の中心ではありません。新しいmihomoクライアントがプロキシProviderとルールセットを再ダウンロードします。保存すべきなのは元の設定と、設定を再取得できるURLです。

mihomoクライアントはコアとOS連携機能で選ぶ

移行とは、見た目がClash for Windowsと完全に同じクライアントを探すことではありません。より確実な選び方は、まずコアを確認し、次にOSの通信をどのように制御するかと設定管理を確認することです。デスクトップではシステムプロキシ、TUN、自動起動、設定更新が必要です。AndroidではAndroid VPN権限、アプリごとの振り分け、バックグラウンド動作、バッテリー設定への対応が重要になります。

デスクトップで確認する項目

コア情報を確認できる：「設定」または「バージョン情報」画面でmihomoの使用を確認でき、具体的なバージョン番号が表示される。
設定検証が明確：読み込みに失敗したとき、単に起動失敗と表示するのではなく、YAMLの行番号や項目を示す。
システムプロキシを制御できる：HTTP、SOCKS、Mixedのポートを設定でき、一般的な初期値は7890。
TUNの状態を確認できる：仮想ネットワークアダプターの作成状況を表示し、管理者権限やサービスのインストール状態を知らせる。
上書き設定とサブスクリプションを分離できる：サブスクリプション更新後も、端末側のポート、DNS、TUNの変更が設定全体で上書きされない。

Androidで確認する項目

mihomoの設定に対応し、リモートサブスクリプションまたはローカルYAMLを読み込める。
AndroidのVPNインターフェースで通信を制御し、起動時にシステムのVPN許可ダイアログが表示される。
「設定」→「ネットワーク」または「設定」→「上書き設定」のような入口があり、DNS、IPv6、TUNスタック、MTUを調整できる。
アプリごとのプロキシに対応し、選択したアプリだけをプロキシ経由にするか、指定アプリを除外できる。
ログ画面で接続先、適用ルール、プロキシグループ、送信先ノードを確認できる。

クライアントによって画面上の名称は異なりますが、コアの機能は実際のバージョンと設定テストで判断してください。読み込み後、ログでmihomoの起動メッセージを探し、ウェブページにアクセスして、接続記録に対象ドメイン、適用ルール、送信先ポリシーが表示されることを確認します。画面に「接続済み」と表示されるだけでは、DNSとルールチェーンが正常だとは限りません。

サブスクリプション移行：元のURLを再登録する

空港サービスやプロバイダーのサブスクリプションだけを使っている場合、Clash for Windowsが生成したconfig.yamlをコピーするより、新しいクライアントで元のサブスクリプションURLを登録し直すのが安全です。デスクトップでは通常「設定」→「新規作成」→「URL」から追加します。Androidのmihomoクライアントでは通常「設定」→右上の「+」→「URLからインポート」から追加します。名前を入力したら一度更新し、プロキシグループとノード数を確認してください。

旧クライアントでサブスクリプションの更新日時、ノード数、主なプロキシグループ名を記録します。
新しいクライアントに同じサブスクリプションURLを追加し、更新間隔を設定します。たとえば1440分です。
更新が完了したら、その設定を選択し、コアが再読み込みするまで待ちます。
「プロキシ」画面を開き、GLOBAL、DIRECT、REJECTとカスタムプロキシグループが正常に表示されることを確認します。
少なくとも2つのノードを順番にテストし、遅延と実際の接続状態を記録します。

遅延値はあくまで初期選別の目安です。あるノードが42 msと表示されても、95 msのノードより必ず高速とは限りません。移行後の確認では、ウェブページが2秒以内に初回表示されるか、1080p動画を連続再生して頻繁にバッファリングしないか、同じテストファイルの安定した速度が移行前より明らかに低下していないかを確認します。すべてのノードで問題が起きる場合は、サブスクリプションを何度も変えるのではなく、まずDNS、システムプロキシ、TUNを確認してください。

サブスクリプションURLは機密情報

サブスクリプションURLには、アカウントを識別するトークンが含まれていることがあります。完全なURLを公開ログ、スクリーンショット、コードリポジトリ、共有YAMLに記載しないでください。複数の端末で使う場合は、各端末のクライアントにURLを直接保存します。

生成済み設定の長期コピーをおすすめしない理由

生成済み設定は、ある時点のサブスクリプション更新結果です。ノードアドレス、証明書パラメーター、プロキシグループ、ルールはその後も変わる可能性があります。直接コピーすれば一時的な復旧には使えますが、以降の更新は自動で反映されません。設定にproxy-providersやrule-providersが含まれている場合は、コピー後もProvider URLが有効であることを確認し、新しいクライアントがローカルキャッシュの保存先を再作成できるようにしてください。

ローカルYAMLの移行：まず検証し、端末依存の項目を修正する

mihomoは従来のClash設定との互換性が高く、一般的なproxies、proxy-groups、rules、proxy-providers、rule-providersは引き続き使えることが多いです。移行時はいきなり構文を大幅に書き換えず、元ファイルのコピーを保存してから読み込み、最初に表示される明確なエラーを確認します。一度に変更する項目の種類を1つに絞ると、原因を特定しやすくなります。

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

external-controller: 127.0.0.1:9090

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - 自動選択
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

上の例では、Mixedの受信ポートに7890、外部コントロールポートに9090、DNSのリスニングポートに1053を使用しています。これらの値はデスクトップでは使えますが、すべての端末にそのままコピーしてはいけません。Androidクライアントは通常、VPNの受信処理とコントロールインターフェースを自身で管理するため、手動で指定したリスニングアドレスが内蔵サービスと競合する可能性があります。

通常そのまま保持できる項目

proxiesにある、使用中のmihomoバージョンがサポートするノードプロトコルのパラメーター。
proxy-groupsのselect、url-test、fallback、load-balanceの構造。
rules内のドメイン、IP、プロセス、ルールセットへの参照。ただしプロセスルールはOSの権限に左右されます。
proxy-providersとrule-providersのリモートURL、更新間隔、ヘルスチェックの仕組み。
DNSのnameserver、fallback、nameserver-policy、fake-ip-filterのルール。

端末ごとに確認または書き換えが必要な項目

external-controller：127.0.0.1に制限することをおすすめします。旧設定が0.0.0.0:9090で待ち受けている場合、コントロールインターフェースがLANに公開されます。
secret：リモート制御を有効にする場合は専用の値を設定し、対応するパネルの接続設定にも同じ値を入力します。
interface-name：Windows、Linux、Androidではネットワークインターフェース名が異なるため、移行後は旧値を削除するか、再選択する必要があります。
routing-mark：主にLinuxのポリシールーティングで使われます。WindowsやAndroidにコピーしても同じ効果はありません。
tun：サポートされるstack、自動ルート、DNSハイジャックの方式はプラットフォームによって異なります。
Providerのローカルpath：C:\Users\...のようなWindowsパスはAndroidでは使えません。相対パスに変更するか、クライアントに管理させてください。

TUN設定をプラットフォーム間で丸ごとコピーしない

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true
  dns-hijack:
    - any:53

デスクトップのTUNは通常、管理者権限またはシステムサービスを必要とします。AndroidではシステムのVPNインターフェースに依存します。同じAndroid端末で同時に維持できる主要なVPN制御ツールは1つだけです。スマートフォンで別のVPN、企業向け仕事用プロファイルのVPN、ローカルファイアウォールを同時に動かしていると、mihomoクライアントがインターフェースを作成できない場合があります。

移行後、ウェブページは開けるのにアプリだけ通信できない場合は、「設定」→「ネットワーク」でTUN stackをsystemからmixedまたはgvisorに切り替えて比較します。その後、アプリごとのプロキシリストも確認してください。切り替え後はサービスを完全に停止して再起動し、古い仮想インターフェースの状態が結果に影響しないようにします。

デスクトップとAndroidで設定をそろえる正しい分離方法

複数端末で設定をそろえることは、すべての端末で完全に同じYAMLを使うことではありません。ノード、リモートルール、プロキシグループを共通層とし、ポート、TUN、LANアクセス、アプリの振り分け、OS権限を端末層に分けるのが合理的です。共通層はサブスクリプションまたはProviderで更新し、端末層は各クライアントの上書き機能に置きます。

端末間で共有しやすい内容

ノードのサブスクリプションとproxy-providers。
プロキシグループ名と基本的な選択ロジック。
ドメインルール、IPルール、リモートのrule-providers。
DNSの上流サーバーとドメイン別の振り分け方針。
よく使う直接接続、拒否、プロキシのルール。

各端末で個別に管理すべき内容

デスクトップのMixed、HTTP、SOCKS、コントロールポート。
LAN上の端末からの接続を許可するかどうかと、待ち受けアドレス。
Windowsのサービスモード、自動起動、TUNドライバーの状態。
Androidのアプリごとのプロキシ、VPNの常時接続、バッテリー最適化、モバイルネットワーク時の挙動。
IPv6の有効化、MTU値、使用するTUN stack。

たとえばデスクトップではmixed-port: 7890を残し、ブラウザーや開発ツールから127.0.0.1:7890へ手動接続できます。Androidでは他のアプリにこのポートを入力する必要はなく、VPNインターフェースが一括して通信を制御します。デスクトップのポート設定を「全端末で必須」と考えると、Androidで起動競合や不要な設定が発生しやすくなります。

プロキシグループの選択は自動的に同期されない

デスクトップとAndroidが同じサブスクリプションを使っていても、クライアント上で選択したノードは通常自動同期されません。デスクトップの「ノード選択」で香港のノードを選んでも、スマートフォンがすぐ同じノードを選ぶわけではありません。複数端末で挙動を安定させたい場合は、メインのプロキシグループからurl-testの自動測定グループを参照し、テストURL、間隔、許容差を適切に設定します。

proxy-groups:
  - name: 自動選択
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: ノード選択
    type: select
    proxies:
      - 自動選択
      - DIRECT

ここでのinterval: 300は300秒ごとにテストすることを示し、tolerance: 50は遅延差が50 ms以内の場合に頻繁な切り替えを抑える設定です。テストURLは安定していて、小容量のレスポンスを返すものを使います。ネットワークによって結果は変わるため、スマートフォンがモバイル回線を使っている場合、選ばれるノードが自宅のブロードバンド回線と同じとは限りません。

移行後の確認手順とよくあるトラブル

移行後は1つのウェブページだけで確認を終えないでください。設定の読み込み、DNS、ルールの適用、ノード接続、システムによる通信制御の5つの層を順番に検証します。これにより、問題が設定解析、名前解決、ポリシー選択、仮想ネットワークアダプターのどこで起きているかを切り分けられます。

設定の読み込み：ログにYAML解析エラー、ポートの重複、Providerのダウンロード失敗がない。
DNS解決：ドメインへの問い合わせが結果を返し、ログにtimeout、SERVFAIL、問い合わせループが連続していない。
ルールの適用：よく使うサイトへアクセスした際、接続記録に想定したルールとプロキシグループが表示される。
ノード接続：異なる地域のノードを少なくとも2つテストし、単一ノードの障害を切り分ける。
システムによる通信制御：システムプロキシを無効にするかVPNを停止すると通信経路が想定どおり変化し、再起動すると復旧する。

読み込みは成功したのに、すべてのノードがタイムアウトする

まずスマートフォンまたはPCのシステム時刻を確認します。証明書のハンドシェイクは時刻のずれに影響されやすいためです。次にサブスクリプションを更新し、ノードのパラメーターが古いキャッシュではないことを確認します。ドメイン名のノードだけタイムアウトし、IPアドレスのノードが使える場合は、DNSを重点的に確認してください。ログにconnection refusedと表示される場合は、ノード側のポートに到達できない可能性があります。i/o timeoutの場合は、ローカルネットワーク、ルーティング、ファイアウォールも調べます。

ルールモードで一部のアプリだけ通信できない

原因の切り分けを目的に、一時的にモードをGlobalへ切り替えます。Globalでは使えるのにRuleでは使えない場合、原因は通常、ルール、プロキシグループ、ルールセットの更新にあります。最終的なMATCHが指すプロキシグループが存在するか確認し、そのグループで利用可能なノードが選択されていることを確認します。診断が終わったらRuleに戻し、Globalでルールの問題を隠したままにしないでください。

Androidで起動後すぐにシステムが停止する

Androidの「設定」→「アプリ」→対象クライアント→「バッテリー」を開き、バックグラウンド動作を許可するか「制限なし」を選択します。続いて「設定」→「ネットワークとインターネット」→「VPN」で接続状態を確認してください。メニュー名はメーカーによって異なります。常時接続VPNを有効にしている場合は、別のVPNアプリが同じ役割に設定されていないことも確認します。

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

サブスクリプションの生成ファイルに直接変更を加えており、更新時に設定全体が上書きされた状態です。元のサブスクリプションを復元し、端末用ルールをクライアントの上書き設定、マージ設定、または独立したProviderへ移してください。共通サブスクリプションはノード更新、ローカルの上書き設定は固定項目を担当させ、2つの層を分けることで継続的に管理できます。

切り戻し期間を確保する

新しいクライアントが数日間安定して動作してから、旧ディレクトリを削除します。その間、2つのクライアントでシステムプロキシやTUNを同時に有効にしないでください。比較が必要な場合は、まず一方のクライアントを完全に停止してからもう一方を起動し、システムプロキシのアドレスとVPNアイコンが切り替わったことを確認します。

移行後のメンテナンス方法

移行後は、クライアントのバージョン、mihomoコアのバージョン、サブスクリプションの更新間隔、主要な上書き設定を記録することをおすすめします。問題が起きたら、直近のクライアント更新、コア更新、サブスクリプション更新の日時を比較すると、変更範囲をすばやく絞り込めます。クライアントの画面バージョンとコアのバージョンは別物です。プロトコルやルールの挙動を調べるときは、まずコアのバージョンを記録してください。

設定ファイルも読みやすい状態に保ちましょう。プロキシグループには安定した名前を付け、ルールは用途ごとに分け、Providerには明確な更新間隔を設定します。変更前に正常起動できるバージョンをコピーし、DNS、TUN、ルールセットを調整するときは一度に1モジュールだけ変更して、ログで結果を確認します。こうすれば、後から別のmihomoクライアントへ乗り換えても、共通設定を引き続き利用できます。

多くのユーザーにとって、移行手順は3段階に整理できます。サブスクリプションと旧YAMLを保存し、メンテナンスが続くmihomoクライアントを選び、最後にデスクトップとAndroidの端末固有パラメーターを個別に設定します。サブスクリプションはノード更新、共通ルールは通信の振り分け、ローカルの上書き設定はOSの違いを担当します。この境界で管理するほうが、旧ディレクトリ全体をコピーするより安定し、後のトラブルシューティングも容易です。