カーネルの変遷:なぜ mihomo が生まれたのか
従来版 Clash カーネルは Dreamacro 氏によって開発が主導され、長らく Clash エコシステムの事実上の標準実装として、Shadowsocks、Vmess、Trojan といった主要プロトコルをサポートしてきました。ルールエンジンや設定フォーマットも、後の多くのクライアントの基準となっています。2023 年前後、原作者のアカウントおよび関連コードリポジトリが削除され、従来版カーネルの更新は停止しました。
これを受けてコミュニティは Clash Meta フォークとして開発を継続し、後に mihomo へ改称されました。これは単なる名称変更ではなく、既存コードをベースに新規プロトコルや新機能を継続的に取り込み、機能範囲が従来版を明らかに上回る実装へと発展したものです。現在主流の Clash 系クライアント、たとえば Clash Verge、Clash for Windows の後継製品、大半のモバイル向けクライアントは、内部カーネルがすでに mihomo へ切り替わっており、従来版カーネルは一部の古いクライアントに歴史的な形で残っているだけです。
この経緯を理解しておくことには実用的な意味があります。「Clash カーネル」と表記されながら長期間更新されていないクライアントを使っている場合、それはほぼ従来版カーネルであり、対応プロトコルの範囲は現在主流のノードサービス提供者が提供するプロトコル種類に対して明らかに遅れています。
プロトコル対応範囲の比較
プロトコル対応は両者の最も直感的な違いです。従来版カーネルが対応するプロトコルの種類は、開発停止時点の状態からほぼ変わっておらず、mihomo はそれをベースに新規追加を続け、現在の対応範囲は明らかに広くなっています。
| プロトコル | 従来版 Clash カーネル | mihomo |
|---|---|---|
| Shadowsocks | 対応 | 対応(暗号方式がより豊富) |
| Vmess | 対応 | 対応 |
| Trojan | 対応 | 対応 |
| VLESS | 非対応 | 対応 |
| Hysteria / Hysteria2 | 非対応 | 対応 |
| TUIC | 非対応 | 対応 |
| WireGuard(アウトバウンドとして) | 非対応 | 対応 |
| SSH(アウトバウンドとして) | 非対応 | 対応 |
このうち VLESS と Hysteria2 は、近年ノードサービス提供者側での利用率が急速に上昇している 2 種のプロトコルです。VLESS は XTLS や Reality トランスポート層と組み合わせて特徴識別への対抗に使われることが多く、Hysteria2 は QUIC ベースで、弱いネットワーク環境や高遅延、パケットロスが発生する回線において、従来の TCP 系プロトコルよりも安定したスループットを示します。サブスクリプションにこれら 2 種のプロトコルのノードが含まれる場合、従来版カーネルではそのまま解析に失敗するかノードが利用不可となるため、mihomo カーネルを搭載したクライアントに切り替える必要があります。
使用しているクライアントがどちらのカーネルかを確認するには、クライアントの「カーネルバージョン」または「このアプリについて」ページを確認してください。mihomo または Clash.Meta と表記されているものが新カーネルで、単純な数字のバージョン番号のみで長期間更新が止まっているものは、多くが従来版カーネルです。
TUN モード:外部プラグインから内蔵機能へ
TUN モード(仮想ネットワークカードモードとも呼ばれる)とは、カーネルがシステム層に仮想ネットワークインターフェースを作成し、システム全体または指定範囲の通信を捕捉してプロキシルールで処理する仕組みで、アプリケーション層のシステムプロキシ設定に依存しません。この方式の利点は対応範囲の広さにあります。システムプロキシ設定に対応していないプログラム、一部のゲームクライアント、システムレベルのサービスによる通信も振り分けの対象にできます。
従来版 Clash カーネル自体には TUN 機能が含まれておらず、初期の実装では追加の補助プログラムやシステム層のドライバーを併用しなければ同様の効果を実現できず、設定の難易度が高く、プラットフォーム間の一貫性も低い状態でした。Windows、macOS、Linux でそれぞれ異なる対応方法が必要でした。
mihomo は TUN モードをカーネルのネイティブ機能として内蔵し、設定項目はコア設定ファイルの tun フィールドに直接記述するだけで、追加のドライバーやプラグインを必要としません(一部のプラットフォームではシステムから仮想ネットワークカード作成の権限付与が必要ですが、これはシステム層の通常の許可手続きです)。典型的な mihomo の TUN 設定例は次の通りです:
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53stack フィールドでは system、gvisor など異なるネットワークスタック実装を選択でき、それぞれ互換性と性能のトレードオフがあります。auto-route を有効にすると、カーネルがシステムのルーティングテーブルを自動的に引き継ぎ、手動でのルーティングルール設定が不要になります。この機能は従来版カーネルには一切存在せず、多くのユーザーが従来版から mihomo に切り替える直接的な理由のひとつとなっています。
ルールエンジンとルールセット機能の強化
ルールによる振り分けは Clash 系クライアントの中核機能で、ドメイン名、IP アドレス範囲、プロセス名などの条件を照合し、各接続をどのプロキシノードに振り分けるか、あるいは直接接続するかを決定します。従来版カーネルのルール種類は DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP といった基本的な種類に集中しており、ルールセット(Rule Provider)の仕組みも比較的単純でした。
mihomo はこれをベースに、いくつかの面で強化を行っています:
- ルールセット形式の拡張:従来の YAML リスト形式に加え、MRS(mihomo 専用のバイナリルールセット形式)への対応が追加され、容量が小さく読み込みも高速なため、大規模なルールライブラリに適しています。
- 論理ルール:
AND、OR、NOTといった論理結合ルールに対応し、複数の照合条件を 1 つのルールにまとめることで、ルール数を削減し保守性を高められます。 - プロセス照合ルール:
PROCESS-NAME、PROCESS-PATHなど、接続を発生させたプロセス名やパスによって振り分けるルール種類は、従来版では対応範囲が限られていましたが、mihomo ではより完全に対応しており、特にデスクトップ環境でアプリ単位の振り分けを行う場面で実用的です。 - サブネットルールとスクリプトルール:照合の次元をさらに細分化し、複雑な振り分けポリシーへの対応が容易になっています。
すでにルールセット(すべてのルールをメイン設定ファイルに直接記述するのではなく)を利用しているユーザーにとって、この変化は通常意識されません。ルールセットの URL 自体はカーネル切り替えの影響を受けませんが、ルールセットの作成者が mihomo 専用のルール種類や MRS 形式を使い始めると、従来版カーネルではそのルールセットの解析エラーやルール失効が発生します。
設定ファイルの互換性と移行時の注意点
mihomo は設計上、従来版 Clash の設定フォーマットに対して高い後方互換性を保っており、基本的なフィールド構造(proxies、proxy-groups、rules などのトップレベルフィールド)はほぼ一致しています。つまり大半の従来版設定ファイルは mihomo クライアントでそのまま正常に読み込み・動作します。ただし従来版から mihomo へ切り替える際には、いくつか留意すべき点があります:
- 新規プロトコルのノードはクライアント側の対応が必要:設定ファイルに VLESS、Hysteria2 など従来版が対応していないプロトコルのノードが記載されている場合、従来版カーネルではそのノードをスキップするかエラーになりますが、mihomo に切り替えることでノードがプロキシグループの一覧に正常に表示されるようになります。
- 一部フィールド名に差異がある:少数のフィールドは mihomo でより正確な命名に変更されているか、任意パラメータが追加されています。たとえば TUN 関連の設定はすべて mihomo で新規追加されたフィールドであり、従来版の設定ファイルには存在しないため、mihomo の公式ドキュメントを参照して追記する必要があり、旧設定から「コピー」してくることはできません。
- Provider の取得動作にわずかな違いがある:mihomo は Proxy Provider、Rule Provider のヘルスチェックと更新戦略を最適化しており、取得失敗時の再試行ロジックがより堅牢になっていますが、基本フィールド(
url、interval、path)は一致しているため変更は不要です。 - GEOIP データベース形式:mihomo はデフォルトで mihomo geoip データベースを使用しており、従来版が使用する GeoLite2 系データベースとは形式が完全には一致しません。初回切り替え時にクライアントが通常は対応するデータベースファイルを自動でダウンロードしますが、ネットワーク環境の都合でダウンロードに失敗した場合、GEOIP 系のルールは一時的に無効となり、直接接続かプロキシかの判定はその他のルールに基づいて処理されます。
移行前には既存の設定ファイルをバックアップしておくことをおすすめします。カーネル切り替え後にプロキシグループが空になったり、ルールが大量に無効化されたりした場合は、まず設定ファイル内に mihomo 専用のフィールドやルールセット形式が使われていないかを確認してください。サブスクリプション自体が失効したと決めつける前に、この点をチェックしましょう。
大多数の一般ユーザーにとって、移行の手順は非常に簡単です。mihomo カーネルに対応したクライアントのインストールパッケージに入れ替えるだけで、設定ファイルやサブスクリプションリンクはそのままインポートできます。フィールドを手動で書き換える必要はありません。自分で複雑なルールを記述している場合や、論理ルールなど mihomo 専用の記法を使っている場合に限り、フォーマットの細部に注意する必要があります。
どちらを選ぶべきか:mihomo カーネルへの切り替えは必要か
以上の比較を踏まえ、判断基準をいくつか挙げます:
- サブスクリプションのノードに VLESS、Hysteria2、TUIC などの新規プロトコルが含まれる場合は、mihomo カーネルの使用が必須です。従来版カーネルではこれらのノードを解析できません。
- TUN モードによるグローバルな透過プロキシが必要な場合、特にゲームやシステムレベルのサービスなどシステムプロキシに対応していない場面をカバーする必要がある場合、mihomo カーネルがネイティブに対応している唯一の選択肢です。
- Shadowsocks、Vmess、Trojan といった基本プロトコルのみを使用し、TUN モードが不要であれば、従来版の設定はどちらのカーネルでも正常に動作します。ただし従来版カーネルはすでに開発が停止しているため、長期的な利用では継続的にメンテナンスされている mihomo に切り替え、セキュリティ更新や安定性の改善を受けることをおすすめします。
- ルールセットの作成者が mihomo 専用の記法や MRS 形式へすでに移行している場合、従来版カーネルを使い続けるとルールセットの読み込みに失敗します。この場合はカーネルの切り替えが唯一の解決策です。
現在、主流の Clash 系クライアントはすでに mihomo カーネルをデフォルトで統合しているのが一般的で、クライアントの設定内にカーネルバージョン管理の機能を用意し、複数の mihomo バージョン間を切り替えられるようにしているものが多く、カーネルファイルを別途ダウンロードする必要はありません。新規ユーザーであれば、現在メンテナンスされているクライアントを選んでインストールするだけで、カーネル選択の問題に遭遇することはほぼありません。従来版カーネルの古いクライアントを長期間使用しているユーザーは、ノードのプロトコルや機能要件を評価したうえで、早めに mihomo ベースの代替クライアントへ移行することをおすすめします。