まず、更新停止がどの層に及んでいるのかを見極める
Clash 関連のプロジェクトは大きく三つの層に分かれます。コア、GUI クライアント、そして設定とルールセットです。コアはプロトコル解析、DNS、TUN ルーティングを担当し、クライアントは UI、サブスクリプション管理、システムプロキシの切り替えを担当します。設定層は profile ファイルとルールセットファイルです。三つの層は YAML 設定とローカルポートを介してやり取りするため、インターフェースが変わらなければ、どの層でも個別に差し替えられます。
まず更新が止まったのがどの層なのかを特定し、そのうえで設定に手を入れる必要があるかを判断します。判断材料は release タグの公開日時とデフォルトブランチの最終コミット日時であり、star 数やダウンロード数は関係ありません。
| 層 | 典型的な兆候 | 実際の影響 | 対処方法 |
|---|---|---|---|
| コア | リポジトリがアーカイブ済みで、最後の release から 12 か月以上が経過。オリジナルの Clash は v1.18.0（2023 年 8 月）で停止 | 新しいプロトコルや DNS 機能は取り込まれず、ルールセットの新形式も解析できない | コアを差し替え。profile の大半は再利用できる |
| クライアント | 9 か月以上新しい release が出ておらず、issue も長期間放置されている | UI とサブスクリプション管理が旧バージョンのまま。TUN が新しい OS バージョンと互換性を持たない可能性がある | クライアントを差し替え。サブスクリプションと profile はそのままインポートできる |
| ルールセット | ルールリポジトリに 6 か月間コミットがない | ドメインリストと IP リストが徐々に古くなり、振り分けの精度が低下する | ルール配布元を変更し、rule-providers の url を書き換える |
- クライアントの「設定」→「バージョン情報」または「このアプリについて」で、UI バージョンとコアバージョンの 2 つを控えておきます（例：v1.18.0、v1.19.5）。
- 該当するリポジトリの releases ページを開き、最新タグの日付を確認して、本当に更新が止まっているのかを確かめます。
- profile ディレクトリを開き、設定がサブスクリプション URL 由来なのかローカルファイル由来なのかを確認します。前者は再生成できますが、後者は必ずバックアップが必要です。
クライアント層だけが更新停止した場合は、変更が最小で済む
既存の profile とルールセットはそのままに、メンテナンスが続いている UI に乗り換えるだけです。コア、サブスクリプション、ルールセットに手を入れる必要はなく、移行は通常 10 分以内で完了します。
移行前に設定資産をエクスポートする
設定資産は 3 種類に分かれます。サブスクリプション URL、ローカルの profile ファイル、そしてクライアント上で手動変更した項目（ポート、TUN のオン／オフ、自動起動、ルールの上書き）です。前の 2 つは完全にエクスポートできますが、3 つ目は項目ごとに記録するしかありません。エクスポート作業はプロキシをオフにした状態で行い、途中で通信が切れてサブスクリプションの更新に失敗するのを避けます。
プラットフォーム別 profile の既定ディレクトリ
| プラットフォーム | クライアントの設定ディレクトリ | コアの既定ディレクトリ |
|---|---|---|
| Windows | %APPDATA%\io.github.clash-verge-rev.clash-verge-rev\profiles\、旧版 Verge は %APPDATA%\clash-verge\ | %USERPROFILE%\.config\clash\ |
| macOS | ~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/profiles/ | ~/.config/mihomo/ |
| Linux | ~/.config/io.github.clash-verge-rev.clash-verge-rev/profiles/ | ~/.config/mihomo/ または /etc/mihomo/ |
| Android | アプリ内の「プロファイル」メニューにあるエクスポート項目。書き出したファイルは通常 /sdcard/Download/ に保存される | アプリ専用ディレクトリ。root 化しないと直接読み取れない |
エクスポート手順
- システムプロキシと TUN をオフにする：「設定」→「システムプロキシ」をオフ、「設定」→「TUN モード」をオフ。
- 「サブスクリプション」ページで対象の profile を右クリック →「サブスクリプション URL をコピー」し、ローカルのテキストファイルに貼り付けて保存します。
- ローカルファイル型の profile：profiles ディレクトリ全体をバックアップ先にコピーします。providers サブディレクトリも含めます。
- ポートを記録：混合ポート 7890、コントロールポート 127.0.0.1:9090、DNS リスニング 1053。
- ルールセットの配布元を記録：rule-providers の各項目の url、interval、path。
最小構成の移行用設定
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
unified-delay: true
tcp-concurrent: true
dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- https://223.5.5.5/dns-query
- https://1.1.1.1/dns-query
proxy-providers:
main:
type: http
url: "https://sub.example.com/link/8f3c1a2b?flag=meta"
interval: 3600
path: ./providers/main.yaml
health-check:
enable: true
url: https://www.gstatic.com/generate_204
interval: 300このうち unified-delay と tcp-concurrent は mihomo のフィールドで、オリジナルの Clash が読むと解析エラーになります。移行時は移行先コアのバージョンに応じて残すか削除するかを決めてください。その他のフィールドは両方で共通です。
コアの差し替え：オリジナル Clash から mihomo へ
オリジナルの Clash コアは v1.18.0 で停止しています。Clash.Meta ブランチは 2024 年に mihomo へ改名され、メインラインは v1.19 系へ進み、TUN スタック、DNS、ルールセット形式は今も更新が続いています。両者は設定フィールドの大半が同名で、違いはここ 2 年で追加された機能に集中しています。
| 設定フィールド | オリジナル Clash v1.18.0 | mihomo v1.19.x | 移行時の対応 |
|---|---|---|---|
mixed-port | 対応 | 対応 | 変更不要 |
tun.stack | system / gvisor に対応 | mixed の値を追加 | そのままの値で可 |
sniffer | 非対応 | 対応 | 追加可能。fake-ip で上書きされたドメインを復元する用途に使う |
rule-providers の format: mrs | 非対応 | 対応 | メモリ使用量を抑えたい場合は mrs に変更可 |
geodata-mode、geox-url | 非対応 | 対応 | geo ファイルが必要な場合は追加する |
proxy-groups の lazy | 非対応 | 対応 | 任意。アイドル時のヘルスチェックを減らせる |
sub-rule（1.19 で追加） | 非対応 | 対応 | 旧コアでは解析エラーになる |
逆方向の互換性はほぼ成立します。mihomo はオリジナル Clash の profile をそのまま読めますが、逆は余分なフィールドのせいで解析に失敗します。したがって移行の方向は旧コアから mihomo への一方向だけで、逆向きにはできません。
Linux でコアを差し替えるコマンドライン
# 旧コアのサービスを停止
sudo systemctl stop clash
# mihomo コアをダウンロードしてインストール（amd64 の例）
curl -LO https://github.com/MetaCubeX/mihomo/releases/download/v1.19.5/mihomo-linux-amd64-v1.19.5.gz
gunzip mihomo-linux-amd64-v1.19.5.gz
sudo install -m 0755 mihomo-linux-amd64-v1.19.5 /usr/local/bin/mihomo
# 差し替えが反映されたか確認
mihomo -v
# 旧設定でフォアグラウンド試運転し、フィールド解析エラーが出ないか確認
mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml試運転中はフォアグラウンド出力を保ち、ログに parse error のようなフィールドエラーが出ていないことを確認してから終了し、systemd に任せます。非 root ユーザーで実行する場合は、ネットワーク権限を別途付与する必要があります：
[Unit]
Description=mihomo
After=network-online.target
[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
LimitNOFILE=1048576
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
[Install]
WantedBy=multi-user.target同じパスに別々のコアのバイナリを上書きし続けない
旧コアのプロセスがバックグラウンドで動いたまま 9090 ポートを占有していると、差し替え後に「設定が反映されない」ように見えます。まずプロセスが終了していることを確認してから、バイナリを上書きしてください。
プラットフォーム別に代替クライアントを選ぶ
代替クライアントを選ぶ際は 3 つの必須条件で判断します。コアのダウンロードと更新の経路を内蔵しているか、profile ディレクトリを直接インポートできるか、システムプロキシと TUN の両モードを備えているかです。3 つすべてを満たす UI なら、サブスクリプションもポートの運用もそのまま持ち込めるため、移行コストが最も低くなります。
| プラットフォーム | 選択できるクライアント | コア | 設定のインポート方法 |
|---|---|---|---|
| Windows | Clash Verge Rev、FlClash、Clash Nyanpasu | mihomo | サブスクリプション URL を貼り付けるか、yaml をウィンドウにドラッグ |
| macOS | Clash Verge Rev、FlClash、Mihomo Party | mihomo | 同上。TUN の初回有効化時はシステム設定での承認が必要 |
| Android | FlClash、Clash Meta for Android | mihomo | アプリ内でサブスクリプションを貼り付けるか、ローカルファイルからインポート |
| iOS | App Store で Network Extension を提供するクライアント（Shadowrocket、Stash、Loon など） | 独自のコア | 多くはサブスクリプション URL のみを受け付け、完全な yaml は解析しない |
| Linux | Clash Verge Rev（AppImage / deb / rpm）、mihomo + systemd | mihomo | 設定ファイルは直接 /etc/mihomo に配置される |
iOS では地域差に注意が必要です。こうしたクライアントは中国本土の App Store では配信されておらず、別の地域のアカウントに切り替えてダウンロードする必要があります。また、多くは完全な yaml を解析せずサブスクリプション URL しか受け付けないため、ローカルで手書きしたルールは事前にサブスクリプション側へ整理しておかないと、移行後にルールが欠けてしまいます。
旧クライアントから設定を移す手順
- まず新しいクライアントをインストールし、いつでも見比べられるよう、しばらくは旧クライアントをアンインストールしないでおきます。
- サブスクリプション URL をインポートし、profile の生成が完了してノード一覧が表示されるまで待ちます。
- バックアップの記録と照らし合わせながら、混合ポート、コントロールポート、TUN スタックの種類、自動起動、システムプロキシモードを 1 項目ずつ戻していきます。
- 新しいクライアントで通信できることを確認してから、旧クライアントを停止し、そのバックグラウンドサービスをアンインストールします。Windows のサービスモードや macOS の特権ヘルパーは個別に削除しないと、待ち受けポートが残ったままになります。
移行後の確認チェックリスト
以下の 10 項目を順に確認すれば、移行後に残る問題のほとんどをカバーできます。コマンド内のポートは既定値で示しているので、変更している場合は実際の値に置き換えてください。
- コアのバージョン：
curl -s http://127.0.0.1:9090/versionを実行し、返ってくる version フィールドがインストールしたタグと一致していることを確認します。 - プロキシ経路：
curl -I -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204を実行し、HTTP/2 204が返れば経路が通っていると判断できます。 - DNS 解決：Windows では
nslookup www.google.com 127.0.0.1、macOS と Linux ではdig @127.0.0.1 -p 1053 www.google.comを使います。198.18.0.0/16 のアドレスが返れば fake-ip が有効です。 - ルールの適用確認：UI の「接続」ページを開き、まず日本国内のサイトにアクセスして DIRECT になるか、続いて海外のサイトにアクセスしてプロキシグループに入るかを確認します。
- TUN ルーティング：Windows では
route print -4を実行して TUN アダプターと 198.18.0.0 セグメントを確認します。Linux ではip route show table all | grep 198.18を実行します。 - ポートの占有状況：Windows では
netstat -ano | findstr :9090、macOS と Linux ではlsof -i :9090を使い、待ち受けているプロセスが 1 つだけであることを確認します。 - サブスクリプションの更新：手動で 1 回更新を実行し、ログに 403、404、TLS ハンドシェイク失敗が出ていないことを確認します。
- ルールセットの保存：ルールセットディレクトリ内のファイルサイズが 0 でなく、更新日時がたった今になっていることを確認します。
- 自動起動：システムを 1 回再起動し、クライアントが自動で立ち上がり、システムプロキシの状態が再起動前と同じであることを確認します。
- フォールバック経路：プロキシノードを切断し、DIRECT ルールのサイトに引き続きアクセスできることを確認します。これで振り分けがすべてプロキシグループに寄っていないことが分かります。
よくある移行トラブルと対処
サブスクリプションの更新が 403 または 404 を返す
多くは User-Agent の不一致が原因です。サーバー側が UA によって返す形式を変えている場合、新しいコアの既定 UA が旧クライアントと一致しないと、管理画面側でそのまま拒否されます。まずクライアントのサブスクリプション設定で UA のドロップダウン項目を探し、clash に切り替えて再試行してください。次に疑わしいのは URL 自体の期限切れで、その場合は管理画面に戻ってコピーし直します。
ルールセットのダウンロードに失敗する
geodata-mode: true の場合は geoip.dat、geosite.dat、または対応する mmdb ファイルが必要です。mihomo は作業ディレクトリへの自動ダウンロードを試みますが、ネットワークが制限されていると失敗します。手動でファイルを作業ディレクトリに置くか、geox-url をアクセス可能なアドレスに変更してください。
TUN モードが起動しない
- Windows：まずサービスモードをインストールする必要があります。初回インストール時に wintun.dll も展開されます。旧版のサービスを入れたことがある場合は、設定から一度アンインストールしてから入れ直してください。
- macOS：初回有効化時はシステム設定でネットワーク拡張または特権ヘルパーを承認する必要があります。一度拒否してしまうと、設定で認可をリセットしてやり直すしかありません。
- Linux：非 root で実行する場合はバイナリにネットワーク権限を付与します。
sudo setcap cap_net_admin,cap_net_bind_service+ep /usr/local/bin/mihomo
起動直後に終了する、または設定が反映されない
まず 9090 が旧プロセスに占有されていないかを確認し、次に設定ファイルのインデントと文字コードを確認します。YAML を Tab でインデントすると解析に失敗します。ファイルは UTF-8（BOM なし）で保存してください。ログレベルを log-level: debug にするとログに具体的な行番号が出るので、設定ファイルを 1 行ずつ見比べるよりはるかに速く特定できます。
移行の本質は、3 つのものを新しい器に移すことに尽きます。サブスクリプション URL、profile ファイル、そしてポートとモードの運用習慣です。この 3 つが手元にあれば、クライアントを何度乗り換えても日常の使用には影響しません。逆に、UI 上のスイッチの位置だけを覚えていると、次に更新停止に直面したときにまた一から調べ直すことになります。