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

継続的に保守されているクライアントを選び、サブスクリプションとルールを移行する

Clash for Windowsの保守終了後は、長期的なメインクライアントとして使い続けることはおすすめできません。移行で重要なのは、画面が完全に同じソフトを探すことではなく、新しいクライアントのコア、対応する設定項目、システムプロキシの実装、TUN機能が現在の用途に合っているかを確認することです。Windows、macOS、Linuxのデスクトップ環境では、mihomoコアを採用し、現在も保守されているGUIクライアントを優先して検討しましょう。軽量な導入やリモート管理が必要なら、mihomoのコマンドラインコアに管理パネルを組み合わせる方法もあります。AndroidとiOSでは、それぞれのプラットフォームに対応したクライアントへサブスクリプションを再インポートしてください。デスクトップアプリのフォルダーをそのままコピーすることはできません。

一般的なサブスクリプションの多くは、新しいクライアントに再追加するだけで利用でき、旧クライアントの実行フォルダー全体を移行する必要はありません。個別に対応が必要なのは、ローカルのYAML設定、ルールセット、プロキシグループの選択、オーバーライド、スクリプト、サブスクリプション更新URL、LAN共有設定です。Clash for Windowsの画面設定、JavaScript Parser、特定バージョンのProfilesデータ構造、システムプロキシの状態は、汎用的なClash設定と同じではありません。単純にコピーすると、設定を読み込めない、ルールの順序が変わる、DNSの動作が異なるといった問題が起こる可能性があります。

OS、コア、保守状況で代替クライアントを選ぶ

代替クライアントは名前が似ていても、同じプロジェクトの継続版とは限りません。選定時は「GUI」と「プロキシコア」を分けて考えましょう。GUIは設定管理、サブスクリプション更新、システムプロキシの切り替え、ログ表示を担当し、コアはプロトコル接続、ルール判定、DNS、TUN、トラフィック転送を担当します。mihomoコアを採用したクライアントは、より多くの最新設定項目を認識できる傾向がありますが、対応範囲はクライアントのバージョン、コアのバージョン、OSの権限にも左右されます。

もともと「ルールモード、サブスクリプション更新、システムプロキシ」だけを使っていたなら、主流のmihomoデスクトップクライアントへの移行は比較的簡単です。旧環境でTUN、スクリプトによるオーバーライド、複雑なDNS、LAN共有、複数のプロキシプロバイダーを使っていた場合は、対象クライアントの設定ドキュメントを先に確認してから、小規模なテストを行ってください。画面のスクリーンショットだけで互換性を判断してはいけません。同じクライアントでも、バージョンによってコアや設定の保存方式が変わることがあります。

Windowsユーザーはサービスモードを優先的に確認

Windowsの通常のシステムプロキシは、システムプロキシ設定に従うアプリに主に影響します。一方、ゲーム、コマンドラインプログラム、一部のストアアプリ、独自のネットワークスタックを使うソフトは、この経路を通らない場合があります。より多くの通信を制御するには、通常TUNを使用します。TUNには仮想ネットワークアダプター、管理者権限、ルーティングテーブル、DNSの制御が関係するため、移行後はまず通常のシステムプロキシを確認し、その後にTUNを個別に有効化してください。複数の要因を同時に調べる事態を避けられます。

macOSとLinuxでは権限とデスクトップ環境を確認

macOSでは、システム拡張、ネットワーク権限、バックグラウンド項目の設定がTUNや自動起動に影響します。Linuxでは、デスクトップ環境のプロキシ設定、NetworkManager、systemdサービス、カーネルのネットワーク権限を確認する必要があります。クライアントが特定のプラットフォームに対応していることは、実行できることを意味するだけで、すべてのデスクトップ環境でシステムプロキシを自動設定できるとは限りません。サーバーやGUIのない環境では、mihomoコアと設定ファイルを組み合わせる方がデスクトップクライアントより適しています。

サブスクリプションをインポートできても、旧設定をそのままコピーできるとは限らない

Clashの設定は通常YAMLを使用しますが、「すべてYAML」であることは、項目が完全に互換であることを意味しません。標準的なプロキシノード、プロキシグループ、ルールは移行しやすい一方、特定のコア、GUIクライアント、OSに依存する部分は再確認が必要です。移行時は、内容をサブスクリプションデータ、コア設定、クライアントオーバーライド、システム状態の4層に分けて考えると整理しやすくなります。

1. サブスクリプションデータ：サブスクリプションURL、ノード、プロキシグループ、リモートルールプロバイダーが含まれます。最も確実なのは、新しいクライアントでサブスクリプションURLを再追加し、対象クライアント自身にダウンロードと解析を行わせる方法です。
2. コア設定：ポート、動作モード、DNS、TUN、ルール、プロキシグループ、外部コントローラー、LANリスニングが含まれます。対象コアのドキュメントに沿って項目を確認してください。
3. クライアントオーバーライド：サブスクリプション統合、グローバル拡張、設定の前処理、スクリプト、画面上で保存された追加項目が含まれます。この層はクライアント間でそのまま再利用できないことが多くあります。
4. システム状態：システムプロキシ、仮想ネットワークアダプター、サービス、自動起動項目、ファイアウォールの許可、ローカルポートの使用状況が含まれます。設定ファイルをコピーしても、これらの状態は自動的に移行されません。

通常そのまま利用できる設定項目

一般的な proxies、proxy-groups、rules、proxy-providers、rule-providers は移行の土台として利用できます。DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、MATCH などのルールタイプを使う場合は、上から下へ判定する順序を維持してください。最初に一致したルールが通信先を決めます。移行時にクライアントがルールやオーバーライドを自動挿入すると、旧環境とは結果が異なる場合があります。

再確認が必要な設定項目

• tun 配下のネットワークスタック、自動ルート、インターフェース検出、DNSハイジャックの設定。
• dns 配下の enhanced-mode、Fake IPの範囲、フォールバックリゾルバー、ドメインフィルター。
• external-controller、コントローラーの待ち受けアドレス、アクセスキー。
• allow-lan、bind-address、ローカルファイアウォールのルール。
• 旧クライアントだけが解釈するParser、JavaScriptスクリプト、ショートカットコマンド、画面上のオーバーライド。
• 特定のコアにのみ存在するプロトコルパラメーター、ルールタイプ、スニッフィング設定。

以下は、移行後の確認に使える簡略化した構成例です。ポート、モード、DNS、ルールを新しいコアが読み込めるかを確認することに重点を置いています。実際のノードは含まれていません。実際に使用する場合は、サブスクリプションからノードとプロキシグループをインポートし、機密性の高い接続情報を公開ドキュメントに記載しないでください。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

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

この設定の PROXY は、実際に存在するプロキシグループに対応していなければなりません。対応するグループがない場合、コアはプロキシ先が存在しないと報告します。DNSアドレスも構造を示す例にすぎないため、ネットワーク環境、プライバシー要件、サブスクリプションの説明に応じて選択してください。移行前にredir-hostを使用していてfake-ipへ切り替えると、LAN内ドメイン、特殊なアプリ、接続テストツールの動作が変わる可能性があります。初回インポート時にDNSモードまで変更しないようにしましょう。

実行状態全体ではなく、設定の出所をバックアップする

移行を始める前に、旧クライアントで現在正常に動作している状態を基準として記録します。バックアップの目的は「以前どのように接続していたか」を再現できるようにすることであり、2つのクライアントで同じデータディレクトリを共有することではありません。クライアントが異なると、設定インデックス、キャッシュ、プロキシグループの選択履歴を同時に書き込む場合があり、共有ディレクトリではファイル形式の衝突が起こりやすくなります。

保存しておくとよい内容

• 有効なサブスクリプションURLと用途。メイン、テスト、ローカル設定を区別して記録します。
• 手動で管理しているYAMLファイル、ルールファイル、プロキシプロバイダー、ルールプロバイダーのURL。
• 現在使用しているプロキシモード。ルール、グローバル、ダイレクトなど。
• よく使うプロキシグループの選択結果。自動選択、フォールバック、指定ノードなど。
• 混合ポート、HTTPポート、SOCKSポート、外部コントロールポート。
• DNS拡張モード、TUNの状態、LANアクセスの状態、待ち受けアドレス。
• 保存が必要なParserまたはオーバーライドのロジックと、どの項目を変更しているかの説明。

サブスクリプションURLやローカル設定にはアクセス認証情報が含まれる場合があります。公開ログ、スクリーンショット、オンラインの整形ツールに貼り付けないでください。バックアップファイルは、現在のアカウントで管理できる場所に保存します。OSを再インストールする場合は、クライアントのバージョン、コアのバージョン、システムアーキテクチャも記録してください。同じ設定でも、コアのバージョンによって動作が異なる場合があります。

旧クライアントを終了する前にポートの使用状況を記録

Clash系クライアントでは7890のようなローカルポートがよく使われますが、実際のポートは変更されている可能性があります。移行後に新しいクライアントが待ち受けに失敗する場合、旧プロセスが終了していない、別のプロキシソフトがポートを使用している、システムサービスがバックグラウンドで動作しているといった原因が考えられます。ウィンドウを閉じただけではプロセスが終了したとは限りません。クライアントのメニューから正常に終了し、タスクマネージャーやシステムのプロセス一覧で確認してください。

最小構成で接続を確立し、高度な機能は一つずつ戻す

古い設定を一度にすべてインポートすると、障害の原因を特定しにくくなります。より確実なのは、まずクライアントとコアが起動することを確認し、次にサブスクリプションの解析、ノード接続、ルール判定を確認し、最後にTUN、DNSオーバーライド、LAN共有を設定する順序です。

1. システムとプロセッサーアーキテクチャを確認する。

   Windowsではx64、ARM64などのアーキテクチャを区別します。macOSではAppleシリコンとIntel搭載機を確認し、Linuxではディストリビューション、パッケージ形式、デスクトップ環境も確認します。インストーラーのアーキテクチャが合わないと、プログラムが起動しない、またはシステムサービスをインストールできない場合があります。

2. 対象クライアントをインストールし、コアを確認する。

   初回起動後、クライアントに表示されるコアの名称とバージョンを確認します。mihomoの設定拡張を使う予定なら、クライアント名だけで判断せず、実際にmihomoが動作していることを確認してください。

3. 旧クライアントを完全に終了する。

   旧クライアントのシステムプロキシとTUNを無効にしてから、バックグラウンドプロセスを終了します。新旧2つのクライアントが同時にシステムプロキシ、ルート、DNSを変更しないようにしてください。

4. サブスクリプションを再追加する。

   元のサブスクリプションURLを使って、新しいクライアントに設定を作成するのが基本です。更新後、ノードとプロキシグループが生成されているか、設定画面に解析エラーがないかを確認します。サブスクリプションサービスの形式が特定のクライアント専用の場合は、Clash形式またはmihomo形式を提供しているか先に確認してください。

5. まずルールモードとシステムプロキシを有効にする。

   利用可能なノードまたはプロキシグループを選択し、TUNを無効にしたままブラウザーで基本接続をテストします。この段階でコアのログを確認し、ドメイン解決、ルールの一致、プロキシのハンドシェイクが正常であることを確認してください。

6. カスタムルールとオーバーライドを戻す。

   一度に1種類の変更だけを追加します。たとえば、まずルールプロバイダー、次にプロキシグループの調整、最後にDNSを戻します。追加するたびに設定を再読み込みし、エラー箇所を確認してください。

7. 必要に応じてTUNを有効にする。

   通常のシステムプロキシが使えることを確認してから、必要な権限を付与してTUNを有効にします。テスト後は、クライアント終了時にルート、DNS、仮想ネットワークアダプターが正しく元に戻るか確認してください。

8. 最後に自動起動とLAN共有を設定する。

   自動起動は、日常の接続が安定してから設定します。LAN共有には適切なアドレスへのバインドとファイアウォールルールの設定も必要です。信頼できるネットワーク内に限定して使用してください。

コアの起動、ルールの一致、システムの復元まで段階的に確認する

「ブラウザーでウェブページを開ける」ことは、一部の経路が機能していることしか示しません。完全な移行では、サブスクリプションが更新できること、ルールの結果が想定どおりであること、必要なアプリがプロキシを利用できること、クライアント終了後にシステムのネットワークが復元されることまで確認する必要があります。

第1層：設定がコアに受け入れられるか

まず起動ログを確認します。YAMLのインデントエラー、重複項目、存在しないプロキシグループの参照、ルールプロバイダーのダウンロード失敗、ポート競合は、通常この段階で発生します。設定の解析に失敗した場合、ノードを何度も切り替えるのではなく、ログにある項目名と行番号から原因を特定してください。ローカル設定は読み込めるのにサブスクリプション設定だけ読み込めない場合、問題はサブスクリプションの形式またはオーバーライド処理にある可能性が高いです。

第2層：ノードとDNSが機能するか

接続テストでは、遅延テストと実際のリクエストを同時に確認します。遅延テストが成功しても、すべての対象サイトにアクセスできるとは限りません。テスト先、DNSの結果、ルール経路、プロトコルのハンドシェイクが異なるためです。ドメインにはアクセスできないのにIP接続は正常な場合は、まずDNSを確認します。すべてのノードが同時にタイムアウトする場合は、ローカルネットワーク、ファイアウォール、サブスクリプションの有効性、システム時刻を確認してください。

第3層：ルールが想定どおり一致するか

クライアントの接続ログを開き、対象ドメインがどのルールに一致し、最終的にどのプロキシグループを使ったかを確認します。通信が意図せずダイレクト接続になる場合は、優先度の高いダイレクトルールが後続のプロキシルールを上書きしていないか確認します。すべての通信がプロキシ経由になる場合は、グローバルモードを誤って選択していないか、または MATCH より前に必要なダイレクトルールがないかを確認してください。ルールプロバイダーを使う場合は、リモートファイルのダウンロードと設定からの参照も確認します。

第4層：システムプロキシとTUNが競合していないか

TUNを有効にした後も、一部のクライアントではシステムプロキシが同時に有効なままになることがあります。環境によっては二重に制御されたり、原因の切り分けが難しくなったりするため、対象クライアントが推奨する組み合わせを選んでください。ブラウザーだけ使えて他のアプリが使えない場合は、通常のシステムプロキシは機能しているものの、対象アプリがその設定を読み取っていない可能性があります。TUNを有効にすると全体がオフラインになる場合は、仮想ネットワークアダプターの権限、自動ルート、DNSハイジャック、他のVPNソフトを確認します。

第5層：終了後にネットワークが復元されるか

新しいクライアントを終了した後、システムプロキシが無効になっているか、ブラウザーで直接接続が許可されたサイトを開けるか、DNSが無効なローカル待ち受けポートを参照し続けていないかを確認します。Windowsではシステムプロキシの画面、macOSでは現在のネットワークサービスのプロキシ項目を確認できます。Linuxではデスクトップ環境と起動方式に応じて、環境変数、デスクトッププロキシ、systemdサービスを確認してください。終了後もインターネットに接続できない場合は、まず残ったプロキシ状態を解除し、その後に仮想ネットワークアダプターとルートを確認します。

移行完了後に長期運用で確認したいポイント

新しいクライアントが安定して動作した後は、保守元を整理して固定する必要があります。クライアント、プロキシコア、サブスクリプション、ルールデータベースは、それぞれ独立した更新要素です。すべての異常をクライアントだけの問題と考えてはいけません。GUIの更新で設定管理の方法が変わることがあり、コアの更新で項目が追加・変更されることがあります。サブスクリプションの更新はノードとプロキシグループを変え、ルールデータベースの更新はドメインやアドレスの分類に影響します。

日常利用では、構成が簡単な緊急用設定を1つ残し、現在安定しているバージョンを記録しておくと安心です。更新前に変更内容を確認し、更新後はコアの起動、サブスクリプションの更新、よく使うルール、TUNを順番に確認します。業務環境で継続性が重視される場合は、大きなバージョン変更を急がず、独立した設定で先にテストしてください。クライアント代替の最終的な目的は、画面や機能数を追い続けることではなく、検証とロールバックが可能な設定経路を構築することです。

対象クライアントがまだ決まっていない場合は、まず当サイトのクライアント比較と用語クイックリファレンスを確認し、OS、TUNの必要性、ローカルルールの管理、LAN共有の要否に応じて選択してください。インストール後は、使い方ガイドに沿って最小構成を作成すると、旧データをすべて直接インポートするより問題を特定しやすくなります。