2026-05-06 クライアント選び読了目安 9 分

Clash クライアントの開発終了後どう移行するか:設定ファイルの書き出しと代替候補一覧

Clash for Windows や ClashX は開発終了後も使えるが、内核の古さやルール失効のリスクがある。設定ファイル・サブスクリプションの書き出し方法、各OSで乗り換え可能な現行クライアント、移行後に見直すべき設定項目を整理。

開発終了クライアントに潜む3つのリスク

Clash for Windows は2024年に更新が止まり、ClashX と ClashX Pro もすでにメンテナンスされていない状態が続いている。これらのクライアントは今も起動・接続できるが、長く使い続けると抽象的な「安全性」の話ではなく、具体的に3種類の問題に直面する。

内核が旧バージョンで固定される。Clash for Windows に内蔵された内核はオリジナル版 Clash 系統のまま止まっており、プロトコル解析や接続安定性に関するその後の修正は一切取り込まれない。オリジナル版 Clash プロジェクト自体もすでに更新が止まっているため、新しいプロトコル仕様(一部の VLESS 拡張フィールドや新しい Hysteria2 パラメータなど)は旧内核で解析に失敗することがある。
ルール構文が新仕様に追いつかない。Clash Meta(mihomo)内核はルール種別やポリシーグループの機能を継続的に追加している。例えば rule-providers のビヘイビア型ルールや、dns.nameserver-policy によるきめ細かい DNS ポリシーなどだ。開発終了クライアントの内核はこれらの新構文を認識できず、設定ファイルに使われているとエラーになるか、静かに無視される。
システム互換性が下がる。macOS や Windows の OS 更新はネットワーク拡張やプロキシ API の挙動を変更する。開発終了クライアントはこれに追随しないため、システムプロキシを設定しても反映されない、OS を更新するとクライアントがそもそも起動しないといった症状がよく見られる。

判断基準

「クライアントが古い」というだけで慌てて移行する必要はない。本当に対処すべきサインは、設定ファイルで新内核のルール構文エラーが出る、新しい OS バージョンで TUN モードが有効化できない、サブスクリプションのノードが旧内核未対応のプロトコルを使っている、のいずれかに当てはまる場合だ。一つでも該当したら移行を計画すべきタイミングといえる。

移行前にまず設定ファイルとサブスクリプションを書き出す

移行の核心は設定をゼロから作り直すことではなく、既存の設定資産をそのまま新しいクライアントに移すことにある。移行対象は主にローカル設定ファイルとサブスクリプションリンクの2種類だ。

設定ファイルの実際の保存場所を探す

Clash for Windows の設定ファイルは既定でユーザーディレクトリ配下の .config\clash フォルダに保存されており、ファイル名は通常サブスクリプションから生成された .yaml だ。ClashX 系は ~/.config/clash ディレクトリに保存される。テキストエディタで直接開いて内容が完全かどうかを確認し、次のフィールドが存在するかを重点的にチェックする。

proxies:
  - name: "ノード例"
    type: vless
    server: example.com
    port: 443
rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/reject.yaml"
rules:
  - DOMAIN-SUFFIX,github.com,ノード選択
  - MATCH,直接接続

設定ファイルがサブスクリプションリンクから自動生成されたもの(手書きではない)であれば、ローカル生成ファイルを移すよりも、サブスクリプションリンク自体を探し出すほうが確実だ。ローカルファイルはある更新以前の古いバージョンかもしれないが、サブスクリプションリンクなら業者側の最新のノードリストを取得できる。

サブスクリプションリンクはどこで見つかるか

多くのサブスクリプション業者のリンクは、購入時のメール、ユーザーパネル、あるいは業者公式サイトの「マイサブスクリプション」ページに残っている。ローカルクライアント上のサブスクリプション名が業者パネル上のプラン名と一致していれば、サブスクリプションアドレスをそのままコピーすればよく、サポートに問い合わせる必要はない。サブスクリプションリンクが見つからない場合は、クライアントの設定に「プロファイル管理」や「Profile」といった画面があるかを確認すると、元のサブスクリプション URL が表示されていることが多いので、それをそのままコピーすればよい。

各プラットフォームで直接乗り換え可能な現行クライアント

移行に「機能が最も充実した」クライアントを選ぶ必要はなく、元のクライアントと操作感が近く、内核が継続的に更新されているものを選ぶのがポイントだ。以下、プラットフォーム別に直接乗り換え可能な選択肢を示す。

Windows:Clash Verge Rev または Clash Plus

Clash Verge Rev はコミュニティの活発度が高い代替候補で、画面レイアウトは Clash for Windows とよく似ており、ルール編集やポリシーグループの切り替え操作もほぼ同じ手順で行える。習熟コストが低い。mihomo 内核をベースにしているため、ルール構文や新機能にも継続的に追随できる。Clash Plus はより充実したグラフィカルな設定ガイドを提供しており、YAML を手書きしたくない人に向いている。両者とも TUN モードとサブスクリプションの自動更新に対応しており、移行後はサブスクリプションリンクを再度インポートするだけでよい。

macOS:ClashX Meta または Clash Verge Rev

ClashX Pro の開発終了後、操作感が最も近いのは ClashX Meta で、同じくメニューバーアイコンでの操作方式を採用しつつ、内核は継続更新されている mihomo に置き換わっている。メニューバーアイコンよりウィンドウ表示のインターフェースに慣れている場合は、Clash Verge Rev の macOS 版も利用可能で、Apple シリコン版と Intel 版の2種類のインストーラーに分かれているため、ダウンロード時に区別すること。

Android:FlClash または Clash for Android

Android 向けのオリジナル版 Clash for Android プロジェクトは更新頻度が低いものの、今もメンテナンスは続いており、設定のインポート方法は旧クライアントと変わらない。FlClash はより活発に更新されている選択肢で、画面デザインが現代的に調整されており、Android と PC の両プラットフォームに対応する。複数プラットフォームを日常的に切り替えて使うなら、FlClash に統一すると学習コストを抑えられる。

Linux:Clash Verge Rev

Linux デスクトップ環境では、Clash Verge Rev が deb と rpm の2種類のインストーラーを提供しており、主要ディストリビューションのパッケージ管理方式をカバーする。設定のインポートロジックは Windows 版と同じで、最も移行しやすい。

元のクライアント	推奨する乗り換え先	移行のポイント
Clash for Windows	Clash Verge Rev / Clash Plus	元のサブスクリプションリンクを直接インポート、ルール構文はほぼ互換
ClashX / ClashX Pro	ClashX Meta	メニューバー操作の感覚は同じ、内核のみ更新
旧版 Clash for Android	FlClash	画面の変更が大きいので設定項目を一つずつ見直すことを推奨

移行手順:インポートから動作確認まで

新しいクライアントをインストールする。ダウンロードページで対応するOSのインストーラーを選び、インストール完了後は旧クライアントをすぐに削除せず、比較用に残しておく。
サブスクリプションまたはローカル設定をインポートする。新しいクライアントで「サブスクリプション管理」または「Profile」の入り口を探し、サブスクリプションリンクを貼り付けて更新する。サブスクリプションリンクがない場合はローカルの YAML ファイルをインポートする。
プロキシグループとルール数を確認する。インポート完了後、新旧クライアントのポリシーグループ数とルール件数が一致しているか比較する。差異が大きい場合は一部のルールが解析時にスキップされている可能性があるので、ログパネルを開いて具体的なエラーを確認する。
主要なサイトを一つずつテストする。すべてのルールをテストする必要はなく、よく使うドメインルールをいくつか選び、ノード経由か直接接続かをそれぞれ確認し、振り分け結果が旧クライアントと一致しているかをチェックする。
問題がないことを確認してから旧クライアントをアンインストールする。数日安定して動作することを確認してからアンインストールし、新クライアントで未発見の問題が出た際に予備手段がない状態を避ける。

移行後に見直すべき設定項目

設定ファイルはそのままインポートできるが、クライアント側のシステム設定は通常自動的には引き継がれない。以下の項目は見落としやすいので、一つずつ確認することを勧める。

システムプロキシと TUN モードのオン・オフ。新しいクライアントでは既定でオフになっている場合があるため、手動で再度オンにしないと通信がプロキシを経由しない。
LAN 接続とポート設定。元の環境で LAN 内の他デバイスとプロキシを共有する設定をしていた場合、新クライアントでもポート番号とリスニングアドレスを同じ内容で再設定する必要がある。そうしないと他デバイスからの接続が失敗する。
ログイン時の自動起動。旧クライアントの自動起動設定は新クライアントに引き継がれないため、システム設定またはクライアント設定側で個別にチェックを入れる必要がある。
DNS 設定。元の設定でカスタム DNS サーバーや fake-ip モードを使用していた場合、移行後に新クライアントの DNS モジュールのオン・オフ状態が元と一致しているか確認すること。DNS 設定の不一致は、移行後に「ノードには接続できるがサイトが開かない」という現象の最もよくある原因だ。
サブスクリプションの自動更新周期。クライアントごとに既定のサブスクリプション更新間隔が異なるため、以前使っていた更新頻度に手動で合わせておくことを勧める。ノードリストが長期間更新されないと、無効なノードが溜まってしまう。