Clash Meta から Mihomo へ：旧版 Core からの完全移行チュートリアル

なぜレガシー Clash Core から Mihomo へ移行すべきか

2022 年以前にリリースされたオリジナルの Clash Core（Dreamacro 氏がメンテナンスしていた版）をいまだにお使いの方は、本稿を手元に置いておく価値があります。上流の Clash プロジェクトは 2023 年 11 月に公式にアーカイブされ、GitHub 上のリポジトリは読み取り専用となりました。つまり、セキュリティパッチやバグ修正、新機能の提供は今後期待できません。

一方で、プロキシまわりのプロトコルは急速に進化しています。VLESS + REALITY、Hysteria2、TUIC v5 など、次世代の方式を採用するプロバイダーが増えており、これらはレガシー Clash Core ではそもそも扱えません。ノード一覧に「接続失敗」「未対応のプロトコル」と並ぶ場合、カーネルが古いことが原因である可能性が高いです。

Mihomo（旧称 Clash Meta）は、いま最も活発に開発されている Clash 系カーネルのフォークで、MetaCubeX チームが継続的にメンテナンスしています。既存の Clash 設定構文との後方互換性を保ちつつ、REALITY、Hysteria2、TUIC v5、Shadowsocks 2022 などへのネイティブ対応を追加し、旧ビルドに見られたメモリリークや接続の不安定さの多くも解消されています。Clash ライクな体験を最新のまま維持するうえで、Mihomo への移行は最も現実的な選択肢です。

アップグレード前の準備

作業に入る前に、次の項目を 5 分ほどで済ませておくと、データ消失や設定破損のリスクを大きく下げられます。

ステップ 1：既存の設定ファイルをバックアップする

Clash の設定は通常 config.yaml という名前で、次のような既定パスに置かれます。

• Windows：%USERPROFILE%\.config\clash\、またはクライアントのデータディレクトリ内の profiles\ フォルダー
• macOS：~/.config/clash/
• Linux：~/.config/clash/

フォルダーごとデスクトップなど安全な場所にコピーしておきましょう。万が一の際に旧設定へ戻せる、いちばん重要な保険になります。

ステップ 2：利用中のクライアント種別を把握する

Mihomo 本体はコマンドラインプログラムです。多くのユーザーは、GUI クライアント経由で間接的に利用しています。

すでに Clash Verge Rev や FlClash をお使いなら、クライアントを最新版に保つだけで十分です。手動でカーネルファイルを入れ替える必要は通常ありません。

古い Clash for Windows や ClashX を使っている場合は、以下の手順でカーネルまたはクライアントごと移行します。

Windows：Mihomo カーネルの差し替え

Windows での作業は「ダウンロード → ファイル置換 → クライアント再起動」の 3 段階に分けられます。

ステップ 1：Mihomo カーネルを入手する

Mihomo の GitHub Releases を開き、最新リリースの Assets から環境に合うファイルを選びます。

• 64 ビットの Intel / AMD（ほとんどの PC）：mihomo-windows-amd64.zip
• ARM 系 CPU（Surface Pro X など）：mihomo-windows-arm64.zip

展開すると mihomo-windows-amd64.exe が得られます。

ステップ 2：カーネル実行ファイルを置き換える

クライアントごとに配置場所が異なります。

• Clash for Windows：インストール先の resources\static\files\win\x64\ にある clash-win64.exe を、入手した mihomo-windows-amd64.exe で上書きし、ファイル名を clash-win64.exe に揃えます。

ステップ 3：再起動して確認する

再度クライアントを起動し、設定やバージョン情報にカーネル名として Mihomo や Meta が含まれるか確認します。ログパネルに Mihomo 由来の起動ログが出ていれば、差し替えは成功しています。

macOS：新しいクライアントへの移行を推奨

macOS では、旧 ClashX の中身だけカーネル交換するより、Mihomo を最初から同梱した現行クライアント（例：Clash Verge Rev）へ乗り換える方がトラブルが少ないです。ClashX 自体も更新が止まっており、カーネルだけ新しくしても GUI 層で不整合が出やすくなります。

ステップ 1：サブスクリプション URL を控える

ClashX の設定画面から、プロバイダーから渡された https:// で始まるサブスクリプション URL をコピーして保存します。ローカルの YAML のみを使っている場合は、そのファイルをバックアップします。

ステップ 2：新しいクライアントをインストールする

当サイトのダウンロードページから、お使いの Mac に合うビルドを選びます。

• Apple Silicon（M1 / M2 / M3 / M4）：ARM64（Apple Silicon）向け
• Intel Mac：x64 向け

初回起動時にゲートキーパーが表示されたら、システム設定 → プライバシーとセキュリティから「このまま開く」などで許可します。

ステップ 3：サブスクリプションを取り込む

新クライアントの「サブスクリプション」または「プロファイル」画面で URL を貼り付け、インポートまたは更新を実行します。ノード一覧が表示されたら、任意のノードを選んで利用を開始できます。

設定ファイル移行時の注意点

Mihomo はレガシー Clash Core の構文と高い互換性があります。そのため多くの既存 config.yaml は無改変のまま読み込めます。ただし、項目ごとの挙動差がそのまま「移行後の不具合」につながることがあります。

主な設定の違い

Mihomo 向け最小構成の例

以下は Mihomo で問題なく読み込める最小限の config.yaml の例です。既存設定を整理する際の参考にしてください。

YAMLmixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: true

external-controller: '127.0.0.1:9090'
secret: ''

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: '198.18.0.1/16'
  nameserver:
    - 'https://doh.pub/dns-query'
    - 'https://dns.alidns.com/dns-query'
  fallback:
    - 'https://cloudflare-dns.com/dns-query'
    - 'tls://dns.google'
  fallback-filter:
    geoip: true
    geoip-code: CN

tun:
  enable: false
  stack: system
  dns-hijack:
    - 'any:53'
  auto-route: true
  auto-detect-interface: true

proxies: []

proxy-groups:
  - name: "プロキシ選択"
    type: select
    proxies:
      - "自動選択"
      - DIRECT

  - name: "自動選択"
    type: url-test
    proxies: []
    url: 'http://www.gstatic.com/generate_204'
    interval: 300

rules:
  - GEOIP,CN,DIRECT
  - MATCH,プロキシ選択

移行直後に起きやすい問題と対処

手順どおり進めても、環境差でつまずくことはあります。ここでは報告の多いパターンと対処の方向性を整理します。

事象 1：Dashboard が開かない（ERR_CONNECTION_REFUSED）

多くの場合、external-controller の待ち受けが 0.0.0.0:9090 から 127.0.0.1:9090 に変わっている、またはファイアウォールがポートを塞いでいることが原因です。

対処：設定ファイルで external-controller の値を確認し、ブラウザで http://127.0.0.1:9090/ui など実際の値に合わせてアクセスします。GUI クライアントなら設定内の「Dashboard を開く」に相当するボタンが早道です。

事象 2：ノードがすべてタイムアウト／接続失敗

想定される要因は次のとおりです。

• サブスクリプションが古い：サーバー側のプロトコル更新後、古いリンクのノード定義が無効になっていることがあります。クライアントで「サブスクリプションを更新」を実行し、最新の一覧を取り直してください。
• DNS が解決できない：Mihomo は fake-ip を既定で使うため、dns.nameserver の指定が不適切だとホスト名解決に失敗します。信頼できる上流 DNS を少なくとも 1 つは明示しましょう。
• システムプロキシが未設定：カーネル単体では OS のプロキシは切り替わりません。クライアントの「システムプロキシを有効化」を使うか、手動で 127.0.0.1:7890 を指定します。

事象 3：TUN モードが起動しない

TUN は仮想 NIC を作るため管理者権限が必要です。Windows では管理者として起動するかサービスモードを有効化し、macOS ではシステム拡張の許可を行います。

事象 4：ルール読み込みエラー

Mihomo はルール構文の検証が厳しめです。典型例は次のとおりです。

• RULE-SET は対応する rule-providers の定義が必須。定義なしで RULE-SET,xxx,DIRECT と書くとパースエラーになります。
• ルールセットは有効な YAML または MRS 形式である必要があります。旧コアが黙認していた非標準形式は拒否されることがあります。
• プロキシグループ名に記号を多用しない方が安全です。日本語・英字・数字の組み合わせが無難です。

動作確認とパフォーマンス調整

移行が完了したら、次のチェックで正常性を確認し、必要に応じて軽いチューニングを加えると快適さが増します。

確認の手順

1. Dashboard のプロキシ一覧でノードが表示され、常用ノードに対する遅延テスト（Ping）が数値を返すこと。
2. ブラウザでプロキシ経由でのみ見られるサイト（例：Google）を開き、表示できること。
3. ログに ERROR や FATAL が連続して出ていないこと。
4. REALITY や Hysteria2 ノードを使う場合、旧カーネルでは常にタイムアウトだったものが、遅延値を返すこと。

パフォーマンスのヒント

次の設定は実運用で効きやすいです。

• TCP 同時接続（tcp-concurrent）：tcp-concurrent: true を有効にすると、複数経路への接続を同時に試し、速い方を採用します。
• geodata の自動更新：GeoIP / GeoSite を自動で取り直すと、ルール分岐の精度が保たれやすくなります。
• 選択ノードの記憶：profile.store-selected: true にすると、再起動後も前回選んだノードを覚えてくれます。

まとめ：長期的には Mihomo 一択に近い

レガシー Clash Core のアーカイブは、エコシステムの中心が Mihomo に移ったことをはっきり示しています。プロトコル対応の幅、セキュリティ更新の継続性、現代的な設定構文との相性——いずれをとっても旧カーネルを上回ります。

現行クライアントで不満が少ないなら、カーネル差し替えだけでも十分な場合があります。クライアント自体が開発停止（旧 Clash for Windows など）なら、新世代クライアントへまとめて移した方が、その後のメンテナンス負担がずっと少なくなります。

新しいクライアントを選ぶときは、Mihomo を深く統合し、GUI の完成度が高いものを優先するとよいでしょう。サブスクリプション管理、プロキシ切替、TUN のオンオフ、ルール編集といった日常操作に力を入れた製品は、コマンドラインでカーネルだけ動かすより格段に使いやすいです。

本稿で扱わなかった症状が出た場合は、より細かい手順をチュートリアルページで確認するか、推奨クライアントを試してみてください。妥当なデフォルトが最初から入っており、初めて Clash 系を触る方でも短時間で運用を始められます。