Clash for Androidの更新終了後の移行ガイド｜設定のバックアップと代替アプリ

まずバックアップ、次に移行：旧アプリはすぐに削除しない

Clash for Android（以下、CFA）のサポート終了後も、保存済みの設定がすぐに使えなくなるわけではありません。対処が必要なのは、今後のAndroidとの互換性、コアの不具合修正、サブスクリプション形式の変更です。移行時は旧アプリとそのデータを残し、新しいアプリで通信、画面ロック中の動作、サブスクリプションの更新を確認してからアンインストールを判断してください。

クライアントは設定管理や画面表示を担うアプリで、コアはプロキシ接続、DNS、ルールを実際に処理するコンポーネントです。旧アプリで読み込めた設定が、新しいアプリでも同じように動くとは限りません。逆に、新しいサブスクリプションの項目が旧コアの対応範囲を超える場合もあります。そのため、移行ではリンクを貼り付けるだけでなく、アプリ内の設定も再現する必要があります。

1. 旧クライアントで現在有効な設定、動作モード、選択中のプロキシグループを記録します。
2. サブスクリプションURL、ローカルのYAML設定、アプリ内のオーバーライド設定をそれぞれ保存します。
3. 移行先の候補アプリをインストールし、まず設定を1つだけインポートします。サブスクリプションサービスは同時に変更しないでください。
4. 旧クライアントを停止してから新しいクライアントを起動し、ネットワークの動作を項目ごとに確認します。

設定のバックアップ項目：サブスクリプション、YAML、オーバーライドを分けて保存

サブスクリプションURLだけでは完全なバックアップにならない

サブスクリプションは、クライアントがリモート設定を取得するための入口です。URLにはアカウントトークンが含まれていることもよくあります。サーバー側で提供されるノードやルールは復元できますが、後から追加した直接接続用ドメイン、ノードの選択、バッテリー設定、除外アプリのリストまで戻るとは限りません。サブスクリプションが無効になると、URLだけでは以前の内容を再取得できません。

一般的なCFA 2.5.xの画面を例にすると、まず「設定」を開いて使用中の設定を選び、その項目の編集または管理画面で参照元URLを確認します。エクスポートやファイル共有機能があれば、YAMLを端末内に保存してください。ビルドによってボタン名は異なる場合があります。エクスポート機能が見つからない場合も、元のサブスクリプションURLと手動変更の内容は必ず記録しましょう。共有リンクをファイルのエクスポートと混同しないでください。

設定画面を記録する場合は、認証情報を隠す

CFAの「設定」→「オーバーライド」で個別の上書き項目が有効になっているか確認し、「設定」→「ネットワーク」でアプリ別プロキシの項目も確認します。項目の分類はインストール済みのバージョンによって異なります。記録するのはスイッチの状態だけではありません。リストが「選択したアプリのみプロキシを使用」なのか「選択したアプリをプロキシから除外」なのかも残してください。同じアプリのリストでも、モードが逆なら移行後の通信経路は正反対になります。

バックアップファイルは端末ロックで保護された場所に保存し、自分で管理する暗号化ストレージにもコピーしておくと安心です。サブスクリプションURL、ノードのパスワード、UUID、コントローラーのAPIキーは機密情報です。ログや設定を他人に見せる前に、これらの情報を削除してください。設定全体を公開のオンライン変換ツールにアップロードするのも避けましょう。

代替クライアントの選び方：コアと端末の条件を確認

代替クライアントを選ぶときは、名前にClashが含まれるかではなく、現在配布されているインストーラーを確認しましょう。当サイトのクライアント選定ガイドで候補を確認したうえで、プロジェクトのリリースページ、更新履歴、Androidの最低要件、アプリ内に表示されるコアのバージョンを調べてください。この記事では、過去の特定バージョンを「最新の定番」として扱いません。

Clash.Metaは後継のmihomoへと発展していますが、「mihomoを使用」とあっても、すべてのクライアントで同じ設定を変更できるとは限りません。GUIで設定できるオーバーライド項目は一部に限られることがあり、サブスクリプションの更新、バックグラウンドサービス、設定のマージもクライアント側が処理します。特定のプロトコルやルール項目が必要な場合は、画面だけを比べるのではなく、候補となるコアの該当バージョンのドキュメントを確認してください。

• 主にサブスクリプションを使う場合：ダウンロードページに掲載されているAndroid向け候補のClash PlusやFlClashsなどを検討し、リモート設定の更新、設定の切り替え、ログ、バックグラウンド実行の項目を確認してください。
• 手書きの設定を管理する場合：ローカルYAMLのインポート、設定のオーバーライド、ルールセットの読み込み、エラー行の表示を重点的に確認してください。未知の項目がすべて保持されるとは限りません。
• 古いスマートフォンを使う場合：Androidの最低要件とCPUアーキテクチャを確認してください。64ビットARM端末では通常arm64パッケージを選びます。32ビットOSしか動かない端末は、プロセッサーの型番が新しくてもarm64パッケージをインストールできません。
• アプリ別プロキシを使う場合：必要な対象／除外モードに対応しているか確認し、仕事用プロファイルや複製アプリなどの特殊な環境でも実際にテストしてください。

設定のインポートとVPN接続：まず変数を減らす

同じサブスクリプションをインポートする

1. 新しいクライアントの設定管理画面でURLインポートまたはリモート設定の新規作成を選び、バックアップした完全なサブスクリプションURLを入力します。
2. ダウンロードと解析が終わるまで待ち、設定名だけでなく、想定したプロキシグループが表示されることを確認します。
3. ルールモードに切り替え、旧クライアントと同じ手動選択のプロキシグループとノードを選びます。
4. CFAのプロキシサービスを停止してから新しいクライアントを起動し、AndroidのVPN接続リクエストを許可します。

Androidのクライアントは、VpnServiceでローカルVPNインターフェースを作成し、端末の通信をコアに渡すことがあります。これはサブスクリプションサーバー自体とは別の仕組みです。同じユーザー環境で有効にできるVPNは通常1つです。企業VPN、別のプロキシ、VPNを利用するフィルタリングアプリが動作中の場合は、先に競合を解消してください。速度を比較するために2つのアプリを同時起動することはできません。

必要に応じてローカルポートを復元する

スマートフォンのアプリがシステムVPN経由で通信するだけなら、ローカルのHTTPポートやSOCKSポートは最初に確認すべき項目ではありません。ターミナルツールから以前 127.0.0.1:7890 に接続していた場合は、新しいクライアントで対応するローカルリスナーを有効にしてください。以下はリスナーとモードの一部を示す例で、ノード、プロキシグループ、ルール全体は含まれていません。このままサブスクリプションとして使用することはできません。

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

mixed-portは、同じポートでHTTPとSOCKSのプロキシ接続を受け付ける設定です。アプリ側でリスナー設定が上書きされる場合があるため、実行ログと実際の接続状況を確認してください。元の設定にexternal-controllerがある場合は、リッスンするアドレスとアクセスキーも確認します。旧管理画面を使うためだけに、コントローラーの接続口をLANに公開しないでください。

ルールとDNSを確認：接続できても移行完了とは限らない

ルール名、順序、モードをまとめて確認

ルールは上から順に評価され、通常は最初に一致した項目によって通信先のプロキシが決まります。サブスクリプションのrulesが参照するプロキシ名は、新しい設定にも存在しなければなりません。元の「自動選択」グループを改名してルールを更新しないと、解析エラーや予期しない動作の原因になります。インポート時にプロキシグループが再生成されるクライアントもあるため、実際に動作している設定を確認してください。

• 普段使うモードがルールモードであることを確認します。ルーティングの正しさを検証するためにグローバルモードを使わないでください。
• 追加したドメインルールが、広範囲に一致するルールより前にあるか確認します。
• rule-providersのダウンロード状況を確認してください。サブスクリプションの更新に成功しても、外部ルールセットのダウンロードまで成功したとは限りません。
• 接続ログを開き、対象ドメイン、適用されたルール、選択されたプロキシ、実際のノードを確認します。メイン画面のレイテンシだけで判断しないでください。

DNSのオーバーライドは元の設定に合わせてから変更する

DNSはドメイン名をIPアドレスに変換する仕組みです。移行時はdns.enable、enhanced-mode、nameserver、fake-ip-filter、IPv6関連の設定を確認し、元の設定意図を保ってください。クライアントの変更と同時にDNSサーバー、Fake-IPモード、ルールまで一度に変更すると、問題が起きたときに原因を特定しにくくなります。

Fake-IPでは、アプリに対応付け用の仮想アドレスを返し、コアが実際のドメイン名と関連付けます。一般的な設定では198.18.0.1/16のアドレス範囲が使われますが、具体的な範囲は設定によって異なります。この範囲が表示されても、すぐにDNS障害と判断しないでください。LAN内の機器を検出できない、または一部のアプリで問題が起きる場合は、アドレス範囲全体をむやみに変更せず、フィルターリスト、LANのバイパス、アプリのリストを先に確認してください。

Androidの「設定」→「ネットワークとインターネット」→「プライベートDNS」が名前解決の経路に影響することもあります。メーカーによっては「接続と共有」内にあります。まず現在の値を記録してから、1項目ずつ比較テストしてください。常に無効にする必要があると決めつけないでください。プロキシサービスが起動しているのにDNSタイムアウトが発生する場合は、ログを確認し、上流DNSに接続できないのか、DNS通信が誤った経路を通っているのか、システム設定とクライアントの制御方式が合っていないのかを切り分けます。

移行後の動作確認：通信、更新、画面ロックを個別にテスト

まず同じWi-Fi、同じノード、同じ設定を使い、モバイル回線の変動をクライアントの差と混同しないようにします。以下の時間はテストの目安であり、当サイトで測定した結果でも、すべての端末が達成すべき性能基準でもありません。

1. 基本的な通信：約5分：直接接続する想定のサービスとプロキシ経由の想定のサービスにアクセスし、接続ログでルールと接続先をそれぞれ確認します。
2. LANのテスト：自宅のルーター管理画面を開くか、把握しているLAN内の機器にアクセスします。失敗した場合は、アドレスのバイパス、ルーティング、アプリ別設定を確認してください。
3. サブスクリプションを1回更新：手動で更新し、更新後も設定を解析できること、プロキシグループが残っていること、ローカルのオーバーライドが反映されていることを確認します。
4. 画面ロック：約15分：ロックを解除したらサービスの状態を確認し、通信が必要なアプリを開きます。通知領域のアイコンだけでは、接続が正常とは判断できません。
5. ネットワークを1回切り替える：Wi-Fiからモバイルデータ通信へ切り替えて再度戻し、接続が復旧するか、ログにタイムアウトが繰り返し記録されないか確認します。

画面ロック後にサービスが終了する場合は、システムの「設定」→「アプリ」→対象クライアント→「バッテリー」を開き、バックグラウンド動作が許可されているか確認します。メーカー独自のシステムでは、自動起動の許可やバックグラウンド制限の解除も必要な場合があります。システムのVPN設定でCFAに「常時接続VPN」を指定していた場合は、新しいクライアントに変更してください。「VPN未接続時の通信をブロック」が有効だと、VPNが確立していない間は端末が通信できません。アプリを切り替える前に必ず確認してください。

すべてのテストに合格したら、旧設定のバックアップを残したまま1～2日様子を見てからCFAをアンインストールします。旧環境に戻す場合は、新しいクライアントを停止してシステムのVPN接続先を確認してから、旧アプリを起動してください。サブスクリプション自体が変更済みの場合、旧アプリで解析できないこともあるため、ローカルのバックアップは役立ちます。

移行に関するよくある質問