Mihomo（Clash Meta）とは何か
Mihomoは、かつてClash Metaと呼ばれていたコアの後継ブランチであり、オリジナルの Clash Premium 系実装をベースに、コミュニティ主導で高速に機能追加と保守が進められています。名称は変わりましたが、多くの GUI クライアントやルーター向けパッジでは、依然として「Meta コア」「Mihomo コア」として同一の実行ファイル群を指します。ユーザーが日々触れるのはコマンドライン単体より、Clash Verge RevやFlClashなど、内蔵コアとして Mihomo を同梱したクライアントであるケースがほとんどです。
オリジナル Clash と比較した際の位置づけは、「プロトコル面と DNS・ルール処理の拡張性が広い、現行の事実上の標準コア」に近いと考えると理解しやすいです。サブスクリプションの形式やポリシーグループの概念は共通しているため、既存ユーザーにとって学習コストは比較的低く抑えられます。一方で、細かなキーや挙動差が蓄積しているため、長期間バージョンを固定していた環境では、一度だけではなく段階的な確認を挟むのが安全です。
アップグレードで押さえたい主な新機能と改善点
リリースノートは常に更新されるため、ここでは「移行の判断や設定見直しに直結しやすい柱」に絞って整理します。実際のバージョンでは項目名やデフォルト値が微妙に異なる場合があるため、更新後はクライアント付属のログと公式ドキュメントを併せて確認してください。
- 新世代トランスポートのサポート拡大：Hysteria2 や TUIC v5 など、従来 Clash 単体では扱いづらかったプロトコル群を、同一のルールエンジン上で扱いやすくまとめています。サブスクリプション側が対応していれば、ノード一覧にそのまま現れ、ポリシーグループでの選択が可能になります。
- DNS の柔軟性とリーク対策：
fake-ipとredir-hostの使い分け、ドメイン単位の DNS サーバ指定、フォールバックチェーンなど、実運用での「名前解決がボトルネックになる」状況への対処がしやすくなっています。TUN モードと併用する場合は、DNS ハイジャックやスニッフィング回避の設定もセットで見直す価値があります。 - ルールと Geo / ルールプロバイダ：
rule-providersによるリモートルールの定期取得や、地理情報データの更新フローが洗練され、肥大化した設定ファイルをローカルで全部手書きしなくても運用しやすくなっています。大規模なリストを使うほど、キャッシュディレクトリの容量と更新間隔のバランスが効いてきます。 - メモリと並行処理まわりの最適化：ノード数や接続数が多い環境では、旧世代コアと比べて GC やコネクションプール周りの挙動差を体感することがあります。極端に古いマシンでは、同時接続上限や keep-alive 系のチューニングを見直すと安定しやすいです。
移行前に必ず行う準備
本番プロファイルをいきなり差し替えるのではなく、次の順で進めるとロールバックが容易です。
-
設定ディレクトリの丸ごとバックアップ
有効化しているconfig.yamlに加え、profilesやrulesetのキャッシュ、カスタムスクリプトがあれば同梱フォルダごとコピーします。Windows ならユーザーディレクトリ配下、macOS ならアプリサポート配下など、クライアントごとの実パスは公式 FAQ を参照してください。 -
サブスクリプションとルールセットの取得元を記録
どの URL から取得しているか、更新間隔、認証ヘッダの要否をメモしておくと、再構築時に迷いません。チーム利用なら、共有ドキュメントに URL ではなく「取得手順」まで書いておくと安全です。 -
動作確認用の最小構成を用意
本番と同じ巨大ルールをいきなり当てず、単一のプロキシと数行のRULEだけの最小 YAML で起動確認すると、不具合の切り分けが速くなります。
GUI クライアント経由でコアを新しくする考え方
多くのユーザーは、クライアントのダウンロードページから入手したインストーラーやポータブル版を通じて間接的にコアを更新します。典型手順は次のとおりです。
- まずクライアント本体を最新安定版へ上げ、リリースノートに「コア更新」「破壊的変更」の記載がないか読む。
- 設定画面の「コア」または「Kernel」セクションで、内蔵バンドル版とカスタムパスのどちらを使っているか確認する。手動でバイナリを差し替えている場合は、実行権限とコード署名（特に macOS）に注意する。
- アップデート直後に一度アプリを完全終了し、プロセスが残っていないかタスクマネージャや
psで確認してから再起動する。
プラットフォーム横断で手順を追いたい場合は、当サイトのドキュメント／チュートリアルもあわせて参照すると、TUN や Linux CLI など文脈がつながりやすくなります。
設定ファイルの互換性とよくある差分
多くのサブスクリプションはそのまま動きますが、次のような項目はバージョンをまたぐと揉めやすいので、更新後にログを一度通読することをおすすめします。
| 領域 | 確認ポイント | メモ |
|---|---|---|
| ポートとミキシング | mixed-port、allow-lan |
LAN 共有や他デバイスからの接続を許可している場合、ファイアウォール規則の再確認が必要になることがあります。 |
| TUN / スタック | サービスモード、権限、ルートテーブル | OS アップデート後に TUN が無効化される例があります。管理者権限でサービスを再インストールすると直ることが多いです。 |
| DNS | enhanced-mode、名前サーバの並び |
ドメインが意図せず DIRECT 側の DNS に流れると、遅延やフィルタ抜けの原因になります。 |
| ルールプロバイダ | 更新間隔、behavior、パス |
リモート側のフォーマット変更でパースエラーが出ることがあります。キャッシュ削除で復旧する場合と、URL の切り替えが必要な場合があります。 |
更新後の検証チェックリスト
次を順に試すと、表面だけ通るのに裏で DNS や UDP が漏れている、といったケースを減らせます。
- ルールモードで国内サイトが DIRECT、対象ドメインが意図したポリシーに乗るかをブラウザと CLI の両方で確認する。
- UDP を要するアプリ（特定のゲームや VoIP）を使う場合は、該当トラフィックが接続ビューに現れるかを見る。
- 出口 IP と DNS リーク検査サイトを用い、期待する経路と一致するかを確認する（検査サイトの信頼性にも留意する）。
トラブルシューティングのすすめ方
起動直後に設定エラーで止まる
ログに YAML の行番号が出ていれば、そのブロックを一時的にコメントアウトして二分探索します。ルールプロバイダ由来のエラーなら、該当 URL をブラウザで開き生データが期待フォーマットかを確認します。
名前解決だけが異常に遅い
上流 DNS の応答、IPv6 の有無、システムプロキシと TUN の併用状態を切り分けます。dig や nslookup でクライアント外からの解決時間と比較すると原因が絞れます。
どうしても安定しない
バックアップから設定ディレクトリを丸ごと戻し、クライアントだけを一つ前の安定版に固定するのが最も確実です。そのうえで、コアのみを一段ずつ上げる「段階更新」に切り替えてください。
上流プロジェクトと情報の見方
ライセンス、ソースコード、既知の不具合やリグレッションの議論は、MetaCubeX の Mihomo リポジトリで公開されています。インストールパッケージの入手は GUI クライアントの更新機能や、当サイトのダウンロード導線を優先し、GitHub は仕様確認やコミュニティの議論の参照先として使い分けると混乱が少ないです。
まとめ：無理のない移行が長く使えるコツ
Mihomo への移行は、目新しいプロトコル表記が増える一方で、ルールとポリシーという骨格はこれまでの Clash 体験と大きく矛盾しません。差分は「DNS と TUN の境界」「ルールプロバイダのライフサイクル」「クライアントとコアの更新タイミングのズレ」に現れやすい、と覚えておくと現場対応が速くなります。変更のたびにバックアップと最小構成検証を挟むだけで、夜中に全クライアントが同時に沈むリスクを大きく下げられます。
同種のツールのなかでも、Clash 系はルール表現とクライアントエコシステムの両面で情報が蓄積されており、長期運用しやすいバランスにあります。まずは手元の環境でコアだけを一段上げ、ログに違和感がなければ本番プロファイルへ広げる、という段階的な進め方がもっとも事故りにくいでしょう。