クライアントが開発終了したかどうかの見極め方
Clashエコシステムのクライアントは、ほとんどが同じ系統のプロキシコア(初期は Clash Premium、現在は Clash Meta とその後継である mihomo が主流)を土台にしたGUIラッパーです。コアはルールマッチング、プロトコル解析、トラフィック転送を担い、クライアントは設定管理、UI表示、プラットフォーム対応を担います。あるクライアントプロジェクトのリポジトリが数か月にわたってコミットがなく、Releaseページが古いバージョンのままで、Issue欄に未対応の互換性問題が積み重なっている場合、基本的に開発終了と判断できます。
開発終了そのものより注目すべきは終了の理由です。メンテナーの労力が後継プロジェクトに移った場合(リポジトリのREADMEに「XXXへの移行を推奨」と明記されるのが一般的)、移行パスは通常スムーズで、設定形式もほとんど変わりません。一方、上流コアのAPI変更でクライアントが完全に対応できなくなった場合や、配布上のコンプライアンス問題でプロジェクト自体が取り下げられた場合は、より慎重に対応する必要があり、旧クライアントの様子を見続けるより、アーキテクチャの異なる代替策に直接切り替えることを勧めます。
開発終了の判断には、以下のような具体的なシグナルを組み合わせて確認することもできます:クライアント起動後に新バージョンの通知が長期間表示されない、内蔵のルールセット更新元が継続的に404を返す、開発者がコミュニティ(Telegramグループ、Discord、GitHub Discussions)で明確に開発終了を告知した、などです。単一のシグナルだけでは一時的なネットワーク不調や誤判定の可能性もあるため、少なくとも2つ以上該当してから移行に着手し、プロジェクトの一時的な沈黙期間に不要な引っ越しをしてしまうことを避けましょう。
設定とサブスクリプションがそのまま使えるかの確認
移行の最初の一歩は旧クライアントを急いでアンインストールすることではなく、既存の設定ファイルとサブスクリプションリンクが新クライアントでそのまま読み込めるかを確認することです。Clash系の設定ファイルは本質的にYAMLであり、コアとなるフィールド(proxies、proxy-groups、rules)はほとんどのクライアント間で共通です。これらはクライアント独自の形式ではなく、コアの仕様に従っているためです。ただしクライアント専用の拡張フィールドは共通ではなく、よくある差異には以下のようなものがあります:
- 一部のクライアントが対応する
proxy-providers(リモートプロキシプロバイダー)の構文バージョンが異なり、フィールド名や必須項目にわずかな差異がある; - GUIクライアントは設定ファイルの先頭や末尾に独自のプライベートフィールド(UIテーマ、トレイアイコンの設定など)を追加することが多く、新クライアントへ移行するとこれらは無視されます。プロキシ機能には影響しませんが、引き継がれることもありません;
- TUNモードの実装方法はコアのバージョンによって異なり、旧バージョンのクライアントで使われている
tunフィールドの構造(stackの取り得る値など)は新しい mihomo コアでは更新されているため、そのままコピーすると手動調整が必要になる場合があります。
サブスクリプションリンクについては通常追加の処理は不要です。サブスクリプションURLが返すのは標準的な設定またはBase64エンコードされたノードリストであり、クライアントはそれをダウンロードして解析する役割を担うだけです。新しいクライアントに同じサブスクリプションURLを再登録すればよく、サブスクリプション提供元側で何かを変更する必要はありません。実際に手動で移す必要があるのは、旧クライアントで行っていたローカルオーバーライドとカスタムルールです。これらはローカルにのみ存在し、サブスクリプション元には含まれません。
移行前に、サブスクリプションリンクだけを残すのではなく、旧クライアントで現在有効になっている設定全体(サブスクリプション本文とローカルオーバーライドを統合した最終結果)を書き出しておくことを勧めます。これにより、新クライアントのオーバーライド構文が異なっていても、元のルールと照らし合わせて手動で再構築でき、以前どこを変更したかを記憶だけで探る必要がなくなります。
ローカルオーバーライドとカスタムルールの書き出し手順
ローカルオーバーライド(override)は、ほとんどのClashクライアントが備えている仕組みで、サブスクリプション本文を変更せずに配信された設定を部分的に調整できます——例えばカスタムルールの追加、DNS設定の変更、TUNモードの有効化、LANリスニングポートの調整などです。この内容はクライアントのローカルストレージにのみ存在するため、クライアントを切り替える前に必ず手動で書き出しておく必要があります。そうしないと、移行後にすべての個別設定をゼロから作り直すことになります。具体的には以下の順序での作業を勧めます:
オーバーライドファイルの実際の保存場所を特定する
多くのクライアントは、オーバーライド内容をサブスクリプション本文に直接書き込むのではなく、設定ディレクトリ内(通常はサブスクリプションのキャッシュファイルと同じ階層)に独立したYAMLファイルとして保存しています。このディレクトリを見つけてコピーしておくほうが、画面上で項目ごとにスクリーンショットを取るより確実です。
ルールオーバーライドとパラメータオーバーライドを区別する
ルールオーバーライド(カスタムのDOMAINやIP-CIDRルール)は通常、新クライアントの該当箇所にまとめてコピーできます。一方、パラメータオーバーライド(ポート、DNS、TUN仮想アダプタ名)は、クライアントごとにUIの項目名と内部フィールド名が必ずしも一致しないため、新クライアントの項目名と照らし合わせながら入力し直す必要があります。
ポリシーグループのカスタム並び順を記録する
サブスクリプションのデフォルトのグループ分けにすべて任せるのではなく、ポリシーグループ内のノード順序やグループロジックを手動で調整していた場合、この情報は通常オーバーライドファイルには反映されず、クライアントのUI状態として保存されています。個別にスクリーンショットやメモを取っておき、新クライアントで手動で並べ直す必要があります。
クライアント自体の動作パラメータをバックアップする
スタートアップ時の自動起動、システムプロキシモード、Mixedポート設定などが含まれます。これらはクライアントレベルの好み設定であり、プロキシ設定そのものとは関係がないため、移行後は新クライアントで一つずつ再設定する必要があります。
プラットフォームごとに現在も活発にメンテナンスされている代替クライアントを選ぶ
代替クライアントを選ぶ際は、次の2つの客観的な指標を優先的に確認しましょう:リポジトリのコミット活発度、そして最新の mihomo コアバージョンに追随しているかどうかです。コアは対応プロトコルの範囲とルールマッチングの精度を決定するため、クライアントの追随が遅いと新しいプロトコル(新しい Hysteria2 のパラメータなど)が使えない場合があります。デスクトップ版とモバイル版では代替のロジックがやや異なるため、分けて見ていきます:
Windows / macOS / Linux デスクトップ:現在の主流な代替パスは、Tauriまたは類似の軽量フレームワークをベースにした新世代クライアントへの移行です。この種のクライアントはリソース消費が少なく、更新頻度も安定しており、多くはデフォルトで最新の mihomo コアを統合しているため、ユーザーが手動でコアファイルを入れ替える必要がありません。移行時は、新クライアントのシステムプロキシの引き受け方式(PAC経由か、直接システムプロキシを設定するか)、およびTUNモードで仮想ネットワークアダプタドライバーの追加インストールが必要かどうかを重点的に確認してください。
Android:Android版クライアントは概ね VpnService システムインターフェースを利用して全体プロキシを実現しており、クライアントを切り替えると再度VPN権限の許可が必要になります。また、新クライアントをシステムの省電力ホワイトリストに再登録する必要があるかも確認してください。そうしないとバックグラウンドでシステムに強制終了され、接続が切れる問題が起きやすくなります。アプリ単位のプロキシ(パッケージ名でプロキシ対象を選ぶ機能)のリストも新クライアントで再設定が必要で、旧クライアントのリストは自動で引き継がれません。
iOS:iOS版クライアントは App Store の審査ポリシーの影響を強く受けるため、代替品を選ぶ前に、対象のクライアントが現在のシステムバージョンで正常にインストールでき、ネットワーク拡張の権限を許可できるかを事前に確認することを勧めます。設定ファイルの互換性の扱いはデスクトップ版と同じで、サブスクリプションリンクはそのまま使えます。
ダウンロード数やUIの見た目だけで代替クライアントを選ばないようにしましょう。まずはコードリポジトリの直近の更新日時とReleaseの頻度を確認してください。UIが簡素でも毎月更新されているクライアントは、UIが洗練されていても半年間更新のないプロジェクトより、長期的に使うリスクがはるかに低くなります。
移行完了後に再確認すべき項目リスト
設定を新クライアントに取り込んだ後、すべてがそのまま引き継がれていると思い込まないようにしましょう。以下は実際の移行作業で見落としやすく、「見た目は正常だが実際には設定がずれている」という問題を引き起こしやすいポイントです:
- DNS設定:新クライアントのデフォルトDNS戦略は旧クライアントと異なる場合があります(例えば
fake-ipモードの有効化状態など)。これはドメイン名解決の結果や振り分けの精度に直接影響するため、旧設定のdnsフィールドと1項目ずつ照合することを勧めます。 - LANおよびMixedポート:新クライアントではポート番号がデフォルト値に戻っている場合があります。ルーターなど他のデバイスが固定ポートでの接続に依存している場合は、移行前の値に再設定する必要があります。
- ルールセットの更新元:一部のクライアントはリモートルールセット(GeoIP、GeoSiteデータベース)を内蔵しています。クライアントを切り替えた後は、これらのルールセットの更新先URLを再設定する必要があります。設定しないとルールがクライアント初回インストール時のバージョンのまま固定され、次第に古くなっていきます。
- ポリシーグループの自動速度テストパラメータ:url-testやfallbackなどの自動ポリシーグループが依存する速度テストURL(
urlフィールド)と検出間隔(interval)が新クライアントでデフォルト値のままだと、以前特定のネットワーク環境向けに調整していた値と一致せず、自動切り替えの反応感度に影響することがあります。 - 自動起動とシステムプロキシの引き受け:これは最も見落とされやすい項目です——機能の移行が完了した後、多くの人が自動起動の再設定を忘れてしまい、PCを再起動してもプロキシが有効になっていないのに、その理由に気づかないというケースが起こります。
移行当日は旧クライアントをアンインストールせずに残しておき、新クライアントを1〜2日運用して安定していることを確認してから、旧バージョンとその設定ディレクトリを完全に削除することを勧めます。こうしておけば、あるオーバーライド項目の移行漏れに気づいた場合でも、いつでも旧クライアントに戻って元の設定を確認でき、記憶だけで探り直す必要がありません。