クライアント・コア・サブスクリプションの違いを確認
Clash for Windowsは、一般にCFWと略されます。名前にWindowsとありますが、Linux版とmacOS版も提供されていました。サブスクリプションの管理、プロキシグループの選択、デスクトップ上の各種切り替えを担うのがクライアントです。実際の通信処理は、クライアントとともに動作するプロキシコアが行います。CFWのサポート終了後も古いインストール版が起動する場合はありますが、新しいシステムやプロトコルへの対応、セキュリティ修正が続くことを意味するわけではありません。
移行しても、サブスクリプションを買い直す必要はありません。また、古いディレクトリ全体を新しいディレクトリに上書きする方法も適切ではありません。クライアントの操作設定、コアが読み込むYAML設定、サービス提供元のサブスクリプションURLという3つに分けて扱いましょう。それぞれ関連はありますが、互いに置き換えられるものではありません。
- クライアントの設定：自動起動、システムプロキシ、ショートカットキー、画面表示の設定、バックグラウンドサービスなどは、通常、新しいアプリで設定し直す必要があります。
- コアの設定：ノード、プロキシグループ、ルール、DNS、TUN関連の項目が新しいコアで受け付けられるか確認します。
- サブスクリプションURL：リモートの設定を再取得するために使います。ダウンロード済みのYAMLだけを保存しても、自動更新できる状態が保たれるわけではありません。
OSに合わせて代替クライアントを選ぶ
これまで主にClash YAMLを使っていた場合は、同種の設定を読み込めるクライアントを選ぶと、移行の手間を抑えやすくなります。mihomoは、旧Clash Metaプロジェクトの後継として使われている名称で、より多くのプロトコルやルール機能に対応しています。ただし、対応機能の設定項目がクライアントに用意されているか、どのバージョンのコアが同梱されているかは、実際のインストール内容によります。選定前にクライアント比較を確認し、プロジェクトの最近のリリース履歴と、使用するOS向けのインストーラーも調べましょう。
| デバイスのOS | 検討できる選択肢 | 移行前に確認すること |
|---|---|---|
| Linuxデスクトップ | Clash Verge Rev、FlClashs | CPUアーキテクチャ、DEB／RPM形式、トレイ対応、サービスの権限 |
| Windows | Clash Verge Rev、Clash Nyanpasu | OSのバージョン要件、コアの種類、古いシステムプロキシが解除されているか |
| macOS | Clash Verge Rev、ClashX Meta | Apple Silicon／Intelのアーキテクチャ、OSのバージョン、ネットワーク権限 |
| Android | FlClashなど、現在も対応・更新が続いているクライアント | Clash設定への対応、VpnServiceの権限、バックグラウンド実行時の省電力制限 |
| iOS | 必要なプロトコルと設定のインポートに対応するiOSクライアント | 利用地域のストアで入手できるか、サブスクリプション形式とルール構文が一致するか |
Linuxではインストール形式を確認
UbuntuやDebian系ディストリビューションではDEB、FedoraなどではRPMを選ぶのが一般的です。ただし、パッケージ形式が合っていても、依存関係が満たされるとは限りません。ターミナルで uname -m を実行すると、出力が x86_64 なら通常はx64、aarch64 なら通常はARM64に該当します。「ダウンロードできる」ことと「使用中のデバイスに適している」ことは分けて判断してください。
モバイルではデスクトップと同じ通信制御を前提にしない
AndroidのVpnServiceは、システムが提供する通信制御用のインターフェースであり、Linuxのサービス方式をそのまま使うものではありません。iOSクライアントでは設定形式が異なる場合もあります。同じノードプロトコルに対応していても、Clashのプロキシグループやルールをすべて読み込めるとは限りません。まず設定を1つインポートして動作を確認し、その後で全設定を移行するか判断しましょう。
旧版のClash for Androidも、メンテナンス状況に注意が必要なアーカイブ済みの選択肢です。名前に馴染みがあるという理由だけで、長期的な代替先に選ぶのは避けましょう。上の表は選定の参考であり、今後もメンテナンスが続くことを保証するものではありません。
サブスクリプションとローカル変更をバックアップ
いつでも戻せるよう、旧クライアントはすぐにアンインストールせず、そのままにしておきます。CFWの Profiles ページで各設定を確認し、名前、取得元、現在選択されている項目、更新間隔を記録してください。サブスクリプションURLは、サービス提供元の管理画面かクライアントのコピー機能から保存します。ローカルファイルしかない場合は「ローカルからインポート」と記録し、自動更新できると誤解しないようにしましょう。
- 元の設定をエクスポート：使用中のYAMLを保存し、クライアントで処理される前のサブスクリプション内容も別途保管します。ファイル名にはバックアップ日を含めましょう。
- 加工処理を別に保存：CFWのParsersやMixin、手動で追加したルールを確認します。クライアント側の設定は、サブスクリプションファイルに含まれていない場合があります。
- 動作時の設定を記録：HTTP、SOCKS、または混合ポート、LANからの接続許可、使用中のモードとDNS設定を控えます。
- 外部ファイルも保存：ローカルのルールセット、証明書、設定から参照されるその他のファイルも保管します。メインのYAMLだけをコピーして、これらを漏らさないようにしてください。
- プロキシグループの選択を記録：よく使うグループ名とノード名を控えます。古いキャッシュを新しいクライアントで読み込めない場合があるため、テキストの一覧も用意しておきましょう。
Linuxでは、まず自分だけがアクセスできるバックアップ用ディレクトリを作成し、エクスポートしたファイルを保存します。以下のコマンドはディレクトリを作成して権限を制限するだけで、古い設定の検索やエクスポートは行いません。
mkdir -p "$HOME/cfw-migration"
chmod 700 "$HOME/cfw-migration"
# エクスポートした設定と移行記録をこのディレクトリに入れてから、ファイルの権限をさらに制限します。
find "$HOME/cfw-migration" -type f -exec chmod 600 {} \;設定をインポートし、古いディレクトリ全体は上書きしない
新しいクライアントを初めて起動したら、まずTUNとシステムプロキシを無効にしたまま設定を1つインポートし、読み込み結果を確認します。サブスクリプションURLがある場合は、URLから再インポートしてください。ローカルのYAMLしかない場合は、ローカル設定としてインポートします。インポート方法が複数ある場合は「リモート設定」と「ローカルファイル」を区別しましょう。更新ボタンが表示されていても、更新元が設定されていないケースがあります。
まず設定項目の互換性を確認し、その後でルールを調整
一般的な proxies、proxy-groups、rules の構造は引き続き使える場合が多いものの、解析ログの確認は必要です。オリジナルのコア固有のスクリプト機能、CFW専用の加工構文、古い実験的な項目がmihomoでもそのまま動作するとは限りません。エラーが出たら該当する項目を特定してください。ファイルを読み込ませるために、不明な項目をまとめて削除するのは避けましょう。
- ノードのプロトコル：VLESSやHysteria2などへの対応状況は、移行先のコアによって異なります。設定を読み込めても、すべてのノードで接続できるとは限りません。
- ルールプロバイダー：
rule-providersのURL、動作タイプ、形式が一致しているか確認し、ダウンロードや解析の失敗がログに出ていないか確認します。 - ローカルパス：Windowsのドライブ文字を使ったパスは、Linuxではそのまま使えません。相対パスの基準位置は、新しいクライアントの設定ディレクトリとコアの動作に応じて確認してください。
- ルールの順序：通常、ルールは上から順に照合されます。カスタムルールを最後の
MATCHより後に置いても、期待どおりに適用されないのが一般的です。
カスタム変更は永続化できる上書き機能に設定
ダウンロード後に生成されたサブスクリプションファイルを直接編集するだけでは、次回の更新で変更が上書きされる可能性があります。移行先クライアントが対応するオーバーライド、マージ、スクリプト機能を優先して使い、実際の統合結果を確認しましょう。ルール配列全体を置き換える機能もあれば、ルールを先頭に追加できる機能もあります。機能名だけで判断せず、確認しやすいルールを1つ追加してからサブスクリプションを更新し、設定が残っているか確かめてください。
CFWのParsersやMixinは、元の構造をそのままコピーせず、移行先クライアントが対応する方法に項目ごとに書き換えます。各項目の役割はコアと設定のリファレンスで確認できます。
システムプロキシとTUNは別々に確認
移行時によくあるトラブルはノードの故障ではなく、2つのクライアントが同じポートを使おうとすることや、古いシステムプロキシが終了済みのプログラムを参照し続けることです。切り替える前に、CFWの General ページで System Proxy をオフにしてください。TUNを有効にしていた場合は、それもオフにして旧クライアントを正常終了してから、新しいクライアントを起動します。
最初はローカルのプロキシポートだけをテスト
ここでは、新しいクライアントで mixed-port: 7890 を明示的に設定し、ローカルのループバックアドレスで待ち受けていることを前提とします。7890は今回の確認に使うポートの例であり、すべてのクライアントの初期値ではありません。画面表示または有効な設定を確認し、アクセス権のあるテスト用URLを使ってください。
# Linuxで7890ポートの待ち受け状態を確認
ss -lntp 'sport = :7890'
# HTTPプロキシを明示してリクエストを送信し、デスクトップのシステムプロキシ設定には依存しない
curl --proxy http://127.0.0.1:7890 \
--connect-timeout 10 --max-time 20 \
--output /dev/null --write-out 'HTTP %{http_code}\n' \
https://clash86.com/接続が拒否された場合は、待ち受けがない、ポート番号が違う、またはプロセスの起動に失敗している可能性があります。タイムアウトする場合は、コアのログ、ノードへの接続、DNSをさらに確認してください。HTTPレスポンスが返っても、それだけで確認できるのは今回のリクエストに応答があったことです。想定したルールとプロキシグループが使われたか、クライアントの接続ログでも確認しましょう。
次にシステムプロキシを有効化
ローカルポートが使えることを確認してから、新しいクライアントでシステムプロキシを設定し、ブラウザーでテストします。システムプロキシが適用されるのは、基本的に該当設定に従うアプリです。ターミナルのプログラムがプロキシを使うかどうかは、環境変数やプログラム独自の引数にも左右されます。GNOMEデスクトップでは gsettings get org.gnome.system.proxy mode を実行すると、デスクトップのプロキシモードを確認できます。ただし、この結果だけで、すべてのアプリがプロキシ経由になっているとは判断できません。
必要に応じて最後にTUNを有効化
TUNを使うと、システムプロキシに従わない接続も含め、より多くの通信を制御できます。必要な権限やクライアント側のサービスを確認してください。まず新しいクライアントのサービス権限を確認してからTUNを有効にし、新旧の仮想インターフェースが同時にデフォルトルートを制御しないようにします。Linuxでは ip rule と ip route show table all を確認に使えますが、ネット上で見つけたルート一括削除コマンドをそのまま実行しないでください。詳しくはTUNモードの設定ガイドをご覧ください。
チェックリストで移行完了を確認
遅延テストに成功しても、移行が完了したとは限りません。通常、確認できるのはテスト先に到達できることだけで、実際のアプリやルールの照合、DNSの動作は検証できません。同じネットワークに接続した状態で、以下の順に確認しましょう。問題の切り分けがしやすいよう、設定は一度に1つだけ変更してください。
| 確認項目 | 確認方法 | 合格条件 |
|---|---|---|
| サブスクリプションの更新 | 手動で1回更新し、更新時刻とログを確認する | ノードが残っており、カスタムルールが上書きされていない |
| ルールによる通信の振り分け | 直結するはずのURLとプロキシ経由にするURLへそれぞれアクセスする | 接続ログに想定したルールとプロキシチェーンが表示される |
| DNSとLAN | よく使うドメイン、ルーター、LAN内のサービスにアクセスする | 名前解決が正常で、LAN内の通信が誤ってプロキシ経由にならない |
| バックグラウンドからの復帰 | ウィンドウを閉じる、スリープから復帰する、ネットワークを切り替える | バックグラウンドプロセスと必要な通信制御が復帰する |
| 終了後の復旧 | プロキシをオフにして、新しいクライアントを正常終了する | システムが無効なローカルプロキシポートを参照していない |
fake-ipを有効にしていて、イントラネット上のサイトで名前解決に問題が出る場合は、DNS設定と fake-ip-filter を確認してください。DNSの問題を安易に「ノードの品質」のせいにしないようにしましょう。IPv6も別途確認が必要です。IPv4サイトにアクセスできても、IPv6通信が想定した経路を通っているとは限りません。
スマートフォンでは画面ロック中の動作も確認してください。Android端末がロック中に切断される場合は、バッテリー最適化、自動起動、バックグラウンド実行の制限を確認します。これは、デスクトップでYAMLを正常にインポートできるかどうかとは別の問題です。
旧環境に戻せる期間を設けてから整理
初回の動作確認後、少なくとも再起動、ネットワークの切り替え、サブスクリプションの更新をそれぞれ1回試してから、CFWのアンインストールを検討してください。バックアップを保管することと、古いクライアントを起動し続けることは別です。古いクライアントの自動起動を無効にし、バックグラウンドサービスがポートを占有しないことも確認します。プログラムのファイルを削除しても、システムサービスやネットワーク設定が自動で解除されるとは限りません。削除方法は、元のインストール方法に合わせてください。
- 新しいクライアントを正常終了し、通常のネットワーク接続に戻ることを確認する。
- サブスクリプションの取得元、ローカルのオーバーライド、移行記録を保管し、バックアップを実際に読み込めることを確認する。
- 古いプログラムの自動起動を無効にし、元のサービス管理方法またはアンインストール方法に従ってバックグラウンドのコンポーネントを整理する。
- 旧環境に戻す場合は、新しいクライアントのシステムプロキシとTUNを先に無効にしてから旧環境を起動し、二重に通信を制御しないようにする。
移行の完了は、画面が以前と似ていることではなく、サブスクリプションを更新でき、ルールの動作を把握でき、終了後に通常の通信へ戻れることで判断します。「バックアップ → インポート → ローカルポート → システムプロキシ → TUN → 再起動後の確認」の順に進めれば、問題が起きた場合もどの段階で止まったのか特定しやすくなり、すべてのコンポーネントを一度に再インストールせずに済みます。