目次
クライアントの移行は、フォルダーを別の場所にコピーするだけでは終わりません。以前のサブスクリプションや独自ルールは残す価値がありますが、キャッシュ、サービスの状態、画面の使い方までそのまま引き継げるとは限りません。機能を少しずつ戻し、終了後も直接接続できることを確かめると、異常が出たときに戻し方が明確になります。
移行時に残すべき構成
Clash for Windows のメンテナンス終了後、Clash Verge Rev に移行する前に、必要なサブスクリプションの取得元、ローカル設定、独自ルールや Mixin、普段選ぶポリシー、ポート設定を整理します。ウィンドウの状態、キャッシュ、古いコア、サービスのファイル、過去のログをまとめてコピーすると、以前の問題を持ち込む可能性があるため避けてください。
以前のクライアントを開き、各項目をスクリーンショットまたはローカル文書へ記録します。現在有効な Profile の名称と更新時刻、General で使用中のポート、System Proxy、TUN、Allow LAN が有効かどうか、Profiles 画面にローカルの Mixin があるかを確認してください。サブスクリプションリンクには個人の token が含まれるため、パスワードマネージャーまたは暗号化バックアップだけに保存し、スクリーンショットには入れません。
移行チェックリスト
- 現在も更新できるサブスクリプションのアドレス
- 再ダウンロードできないローカル YAML
- 自分で管理しているルールとオーバーライドのロジック
- mixed-port またはローカルネットワーク共有用のポート
- 本当に残す必要があるポリシーグループの選択
- トラブルシューティングで比較するための、以前のクライアントとコアのバージョン
旧クライアントを終了し Windows の直接接続を確認する
移行で最も避けるべきなのは、二つのクライアントが同時にシステムプロキシまたは TUN を制御することです。まず Clash for Windows で System Proxy、TUN、自動起動を無効にし、次にシステムトレイから完全に終了します。その後「設定 → ネットワークと Internet → プロキシ」を開き、「プロキシ サーバーを使う」が以前の 127.0.0.1 ポートを参照し続けていないことを確認してください。
両方のクライアントを終了したままブラウザーで通常の Web サイトへアクセスし、社内ネットワークまたはルーターの管理画面も開けることを確認します。この状態が正常であれば、その後の問題が新しいクライアントに起因するかを判断できます。
この時点ですでにネットワークへ接続できない場合は、以前のプロキシまたは TUN の残存設定を消去してください。Clash Verge Rev を起動して一時的に隠さないでください。
インストール、サブスクリプションの取り込み、ポリシーグループの再選択
一般的な Windows 11 コンピューターでは x64 インストーラーを使用し、Windows on ARM デバイスの場合にだけ arm64 を選択します。インストール前に、リリース元のリポジトリ、ファイル名、バージョン情報を確認し、クライアント、サブスクリプション、ノードをまとめた第三者の「ポータブル強化版」は使用しないでください。
初回起動時は、サービスモードと TUN をすぐ有効にしないでください。まずサブスクリプションまたは設定画面で元のサブスクリプションを追加し直し、一度手動更新して、更新時刻、プロキシグループ、ノードが表示されることを確認します。その後、固定ノードを一つ選び、システムプロキシを有効にしてください。これにより、ダウンロード、解析、基本的な転送の三段階が正常だと先に確認できます。
プロキシグループの定義は通常サブスクリプションの YAML に含まれるため、再インポートすると一緒に表示されます。一方、Clash for Windows で各 Selector が現在どのノードを選んでいるかは実行時の状態であり、キャッシュをコピーして移行するのには適しません。
Clash Verge Rev のプロキシ画面を開き、「ノード選択」「自動選択」「ストリーミング」など普段使うグループを一つずつ確認し、必要な出口を手動で選び直します。
同じサブスクリプションでも新しいクライアントでポリシーグループが少ない場合は、まずサブスクリプションの更新時刻と最終設定を比較します。サービス側の更新、以前の Parsers、新しい Merge のいずれでもグループ名が変わる可能性があります。以前の選択を一つ復元するために、古いキャッシュ全体をコピーしないでください。
新しいクライアントでの最初のテスト
使用中のサブスクリプションを確認する
現在選択しているのが、取り込んだばかりの Profile であることを確認し、固定したノードとシステムプロキシのリクエストを調べます。今回のテストはこの設定だけで行い、ほかの過去の設定を同時にインポートしないでください。
通常の手順で終了する
終了後は Windows が直接接続へ戻り、以前のポートを残さない。
Clash Verge Rev を開き直し、各グループの選択が想定どおり残っているか確認します。残っていなければ、実行中の設定とグループ名の変化を記録し、古いキャッシュをコピーして直そうとしないでください。
元の目的に合わせて Mixin と上書き設定を再構築する
Clash for Windows の Mixin、Parsers、スクリプトは固有のマージ方式に依存することがあります。Clash Verge Rev には現在の Merge、Script、オーバーライドの操作箇所があります。名称は似ていますが、生成順序とフィールドが同じとは限りません。
移行前に、各カスタム設定の目的を一文で記録してください。たとえば「社内ドメインへ直接接続する」「GitHub を開発用グループへ入れる」などです。その後、現在のクライアントが対応する方法で作り直します。
設定を一つ追加するたびに、最終的なマージ設定または実行ログを確認します。group not found、duplicated key、unknown field が出た場合は、追加したばかりのオーバーライドを元に戻してください。最後にまとめて直そうとして、次の設定を重ねないでください。
以前の設定の扱い方
| 以前の内容 | 移行方法 | 検証結果 |
|---|---|---|
| カスタム DOMAIN-SUFFIX ルール | 現在のルールオーバーライドへ入れ、対象のポリシーグループが存在することを確認する | 対象ドメインへアクセスした際、接続画面でそのルールに一致する |
| カスタム DNS | まずサブスクリプションの既定値を使い、その後で個別に移行する | 内部ドメインと公開ドメインの両方で想定した結果が得られる |
| ポート設定 | Clash Verge Rev の一般設定で改めて指定する | 実際にポートが待ち受け、システムプロキシが同じ値を参照する |
| UI、キャッシュ、過去のログ | 移行対象にしない | 新しいクライアントをクリーンな状態から起動する |
まずシステムプロキシを復旧し、本当に必要な場合に限り TUN を移行する
サブスクリプション、ポリシーグループ、カスタムルールが安定したら、Clash Verge Rev で System Proxy を有効にします。Windows の「プロキシ」画面が現在の mixed-port を参照し、ブラウザーと普段使うアプリで接続記録が生成されることを確認してください。クライアントを通常の手順で終了した後は、システムプロキシも自動的に元へ戻る必要があります。
ゲームやターミナルなどがシステムプロキシを使わない場合に TUN を検討します。Windows サービスを有効にする前に、実際のサービスが修正済みか公式セキュリティ勧告で確認してください。GUI のバージョンだけでは判断できません。その後 TUN、スリープ復帰、ほかの VPN を個別に試し、TUN 停止後のルート復帰を確認します。自動起動と上書き設定は別に移行します。
普段使うアプリや作業で動作を確認してから、以前のクライアントをアンインストールする
少なくとも一つの業務サイクルを通して継続的に検証する
- サブスクリプションを手動で更新でき、次回起動時にも自動的に使用できる
- ブラウザー、Git、普段使う業務アプリが想定したルールに一致する
- 内部サイト、NAS、プリンターへ引き続き直接接続できる
- TUN が必要なプログラムが実際に接続記録へ表示される
- 終了と再起動の後も Windows にプロキシ設定が残らない
- 以前の設定をオフラインでバックアップし、token を公開していない
以前のインストールは数日間残しても構いませんが、自動起動はさせないでください。新しいクライアントに異常が出た場合は、まずそれを終了して Windows の直接接続を復旧し、バックアップを使って以前の環境へ戻します。比較のために二つのクライアントを互いに制御させないでください。更新、利用、終了、再起動が安定したら Clash for Windows をアンインストールし、以前のサービスと起動ショートカットも消去されたか確認します。