CFWサポート終了後に移行するもの

Clash for Windows（CFW）は、設定やノード、システムプロキシを管理するデスクトップクライアントであり、Clashコアそのものではありません。CFWはすでにサポートが終了しており、最終期のバージョンとして知られているのは0.20.39です。旧バージョンが起動しても、今後のOS互換性修正が提供されるわけではなく、新しいサブスクリプションのプロトコルや設定項目を旧コアが認識できるとも限りません。

設定を一度にすべて作り直す必要はありません。まずサブスクリプションとルールを移し、次にシステムプロキシを復旧し、最後にTUN、DNS、自動起動を設定すれば、問題の原因を切り分けやすくなります。クライアントを変更しても、通常は契約中のサブスクリプションを買い直す必要はありません。確認すべきなのは、サービス提供元が移行先のコアで読み込める設定を提供しているかどうかです。

設定を3種類に分けて確認する

  • サブスクリプションの内容：ノード、プロキシグループ、ルール、一部のDNS設定など。通常はリモートのサブスクリプションから生成されます。
  • ローカルでの変更：手動で追加したルール、サブスクリプションの前処理、スクリプト、オーバーライドなど。別途整理が必要です。
  • クライアントの設定：システムプロキシのオン・オフ、サービスのインストール、自動起動、画面表示の設定など。YAMLをコピーするだけではすべて復元できません。

サブスクリプションURL、カスタムルール、ローカル設定をバックアップする

現在の設定を記録する

  1. 旧CFWのProfilesページで選択中の設定を確認し、名前、サブスクリプションの提供元、最終更新が成功したかどうかを記録します。
  2. Generalページで、使用中のプロキシポート、現在のモード、System ProxyとTUN Modeのオン・オフを記録します。HTTPプロキシのポートは7890が一般的ですが、実際の値は端末の表示で確認してください。
  3. 実際の設定フォルダーを確認し、ローカルのバックアップ先にコピーします。Windowsでは%USERPROFILE%\.config\clashが一般的ですが、ポータブル版や任意のフォルダーを使っている場合もあります。既定のパスだと決めつけず、実際の場所を確認してください。
  4. 自分で編集したYAML、ルールファイル、サブスクリプションの前処理設定、スクリプトを別途保存します。手動で変更したものと、サブスクリプションの更新で生成されたものを区別して記録してください。

設定フォルダーには、クライアント設定、サブスクリプションのキャッシュ、コアの実行時ファイルなどが混在している場合があります。フォルダー全体をバックアップしておけば確認に役立ちますが、新しいクライアントにそのまま上書きするのは避けてください。プロジェクトによって設定のインデックス、データベース、ファイル名が異なります。

サブスクリプションURLと設定のスナップショットを両方保存する

サブスクリプションURLは今後の更新に使い、現在のYAMLはノードやルールの照合に使います。設定のスナップショットだけを保存し、元のサブスクリプションURLを残していないと、読み込み直後は接続できても、サービス提供元によるノードの変更を取得できないことがあります。反対にURLだけを保存した場合、ローカルのルールや使い慣れた振り分け設定が抜け落ちる可能性があります。

サブスクリプションURLのトークンは、クエリパラメーターやパスに含まれている場合があります。サポートを依頼するときは、エラー情報と必要な項目だけを共有し、URL全体は貼り付けないでください。URLを公開してしまった場合は、サービス提供元の管理画面でサブスクリプショントークンを再発行してから、新しいクライアントに設定してください。

代替クライアントの選び方：まずOS、次にコアを確認

代替クライアントを選ぶ際は、プロジェクトの最近のリリース状況、対応アーキテクチャ、コアの種類を確認しましょう。インストール版のバージョンとコアのバージョンは別物です。設定項目が使えるかどうかは、クライアント画面のバージョン表示ではなく、実際に動作しているコアのバージョンで判断してください。

利用環境候補となるクライアント移行時の確認事項
WindowsデスクトップClash Verge Rev、Clash Nyanpasuサポート状況、mihomoコアのバージョン、サービスモードの権限を確認する。
macOSデスクトップClash Verge Rev、ClashX MetaApple SiliconとIntelを区別し、ネットワーク制御機能に必要な権限を再設定する。
LinuxデスクトップClash Verge Revディストリビューションに合ったDEBまたはRPMを選び、デスクトップ環境のプロキシ設定を確認する。
バックグラウンドでコアだけを使う場合mihomo設定ファイルのパス、サービスの起動方法、コントローラーへのアクセス権を自分で管理する。

上記の名称は候補を探すためのもので、今後のサポートを保証するものではありません。インストール前にダウンロードページで現在の対応OSと配布元を確認してください。管理方法を比較する場合は、クライアント比較ガイドもご覧ください。名前が似ているだけの旧CFW再パッケージ版を、元のプロジェクトが更新を再開したものと誤認しないよう注意してください。

CFWのParsersやスクリプトでサブスクリプションを処理していた場合は、移行先のクライアントに同等のオーバーライド機能があるかも確認してください。Clash YAMLを読み込めても、CFWの画面設定やすべての前処理構文が使えるとは限りません。

サブスクリプションとルールの移行：まず最低限の接続を復旧する

最初はサブスクリプションだけを読み込み、TUNは有効にしない

  1. 旧クライアントでSystem ProxyとTUN Modeをオフにしてから、クライアントを終了します。あわせて旧クライアントの自動起動も無効にしてください。
  2. 新しいクライアントをインストールし、サブスクリプションまたは設定の管理画面から元のサブスクリプションURLを読み込みます。バージョンによってメニュー名は異なるため、画面上の「インポート」または「サブスクリプション」の項目を探してください。
  3. 更新が完了するまで待ち、ノード数とプロキシグループが想定どおりかを確認してから、その設定を現在の設定にします。
  4. ルールモードに切り替え、接続できることが分かっているノードを手動で選びます。システムプロキシだけを有効にし、ブラウザーで接続を確認してください。

読み込みに失敗した場合は、まずログを確認します。401または403が返る場合は、認証情報やサービス提供元の制限を確認してください。YAMLではなくウェブページが返る場合は、サブスクリプション用のURLをコピーしたか確認します。設定項目やプロトコルが未対応と表示される場合は、コアとサブスクリプションの形式を確認してください。ルールをすべて削除して試すのは避けましょう。

ローカルルールは更新に影響されないオーバーライド層に置く

ルールは通常、上から順に照合され、先に一致したものが優先されます。以下は順序の例です。指定したドメイン、ローカルネットワークのアドレスの順に処理し、最後にフォールバックルールを適用します。DIRECTは組み込みの直接接続ポリシーです。プロキシグループ名に置き換える場合は、その名前が設定内に存在している必要があります。

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

この例を完全なサブスクリプションとして読み込んだり、既存のrulesの下に同名のトップレベル項目をそのまま追加したりしないでください。実際の移行では、移行先のクライアントに用意されたルールのマージ機能またはオーバーライド機能を使って、自分のルールを適切な位置に追加し、サブスクリプションに含まれるフォールバックポリシーを維持します。

旧設定をmihomoへ移行する際の互換性チェック

Clash.Metaは後継プロジェクトのmihomoとして開発が続いており、基本的なClash YAMLの項目は引き続き使えるものが多くあります。ただし、旧クライアント独自の機能を、名前が同じというだけでそのまま移せるとは限りません。移行時はまずproxies、proxy-groups、rulesなどの基本構造を維持し、拡張機能を一つずつ確認してください。

  • 旧スクリプトと前処理：CFW Parsers、JavaScriptによる処理、旧コアのスクリプトモードが移行先でもそのまま動くとは限りません。機能がどこに属するかを確認し、移行先の実装に合わせて書き直してください。
  • ルールファイルのパス：rule-providersの相対パスは、新しい設定フォルダーの影響を受けます。ローカルのルールファイルをコピーしたら、パスと読み取り権限を確認してください。
  • プロキシグループの参照：ルールから参照するグループ名が正確か確認します。スペースや大文字・小文字も要チェックです。グループ名が見つからないと、設定の読み込みに失敗したり、ルールが意図どおりに動作しなかったりすることがあります。
  • コントローラーのアクセス権：リモート管理が不要な場合、external-controllerはループバックアドレスに限定してください。すべてのネットワークインターフェースで待ち受け、アクセスキーも設定されていない旧設定をそのまま使わないでください。
  • DNS設定：まず現在の動作を基準として保存し、その後でfake-ip、上流DNSリゾルバー、ドメインごとのポリシーを調整します。コアの変更とDNS方式の変更を同時に行うと、問題の切り分けが難しくなります。

mihomoコアを単独で使っている場合は、mihomo -t -f config.yamlで指定した設定が検証に通るか確認できます。実行時には実際のファイルパスを指定してください。GUIクライアントでは、設定の検証結果とコアのログを確認するのがおすすめです。検証に通っても、サブスクリプションURL、ルールの配布元、すべてのノードへの接続が正常だとは限りません。

システムプロキシ、TUN、ポート競合のトラブル対処

ブラウザーは使えるのに、ほかのアプリは使えない

システムプロキシが適用されるのは、システムのプロキシ設定に従うアプリが中心です。すべてのアプリが利用するとは限りません。まず対象のアプリに個別のプロキシ設定がないか確認してください。システムプロキシに従わない通信も制御する必要がある場合は、新しいクライアントの説明に従ってTUNを有効にし、サービスや管理者権限を設定します。

旧CFWでサービスをインストールしていても、その状態は新しいクライアントに自動で引き継がれません。新しいクライアントで権限不足が表示された場合は、クライアント内のサービスインストール機能を使ってください。旧サービスのファイルを直接移したり、複数のプロキシクライアントで仮想ネットワークアダプターやルートを同時に作成したりしないでください。

ポート競合、または終了後にネットワークへ接続できない

新しいクライアントのログにaddress already in useと表示された場合は、まず旧プロセスがバックグラウンドで動作していないか確認してください。Windowsではターミナルで以下のコマンドを実行し、7890をリッスンしているプロセス番号を確認してから、タスクマネージャーでプログラム名を照合します。

netstat -ano | findstr :7890

プロセスの用途が分からない場合は、すぐに終了しないでください。新しいクライアントに未使用のポートを割り当てる方法もありますが、ブラウザー拡張機能、ターミナルの環境変数、ほかの手動プロキシ設定もあわせて変更する必要があります。特にHTTP_PROXY、HTTPS_PROXY、ALL_PROXYが旧ポートを参照したままになっていないか確認してください。

クライアントを終了した後もブラウザーがローカルプロキシに接続しようとする場合は、Windows 11の「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「プロキシサーバーを使う」の設定を確認してください。組織のポリシーやほかのソフトが必要としていないと確認できた場合に限り、オフにします。TUNを無効にしても接続に問題が残る場合は、ほかのVPN、仮想ネットワークアダプター、DNS設定も確認してください。

移行後の動作確認と旧クライアントへの切り戻し

移行完了の判断を、遅延の数値が表示されるかどうかだけに頼らないでください。遅延テストで確認できるのは一部の通信に限られ、すべての通信が正しいルールで適切な経路に送られているとは限りません。旧クライアントをアンインストールする前に、次の項目を実際に確認しましょう。

  1. サブスクリプションの更新：手動更新が成功し、ノードとカスタムルールが意図せず消えていない。
  2. ルールの適用：直接接続されるはずの宛先と、プロキシ経由になるはずの宛先にそれぞれアクセスし、接続ログで一致したルールと実際のポリシーを確認する。
  3. 普段使うアプリ：ブラウザー、ターミナル、よく使うデスクトップアプリを試し、ブラウザーだけの確認で終わらせない。
  4. ローカルネットワークへのアクセス：ルーターの管理画面、プリンター、NASに、これまでどおりアクセスできることを確認する。
  5. 再起動と復帰：PCを再起動し、スリープからの復帰も試して、自動起動、サービスの権限、プロキシの状態が正しいことを確認する。

サブスクリプションの更新やノードへの接続に問題がある場合は、サブスクリプション更新のトラブル対処と遅延テストの解説もご覧ください。移行では、サブスクリプション、ルール、ネットワーク制御を分けて扱い、それぞれの段階で確認することが重要です。旧フォルダーを丸ごと上書きする方法は避けてください。