mihomo カーネルの機能解説：Clash 公式版との設定差分と移行の要点

Clash クライアントでは、グラフィカルな画面が設定のインポート、プロキシ選択、稼働状況の表示を担います。一方、接続、DNS、ルール照合、プロキシプロトコルを実際に処理するのがカーネルです。mihomo は Clash.Meta から発展した互換カーネルで、多くのクライアントで標準コアとして採用されています。ただし、画面上では Clash、Meta、Premium などの名称が引き続き使われる場合があります。現在の機能を判断する際は、クライアント名だけでなく、実際に読み込まれているカーネルの種類、バージョン、起動ログも確認してください。

旧 Clash の設定は通常、移行の出発点として利用できます。ただし、「読み込める」ことが、そのまま動作結果の完全な一致を意味するわけではありません。mihomo はプロキシプロトコル、ルール種別、DNS 制御、トラフィックのスニッフィング、TUN ルーティング、ルールセット形式を拡張し、一部のフィールドもより明確に処理します。移行では新機能を一度にすべて有効にするのではなく、まず従来の振り分け結果を維持し、その後で機能を一つずつ追加するのが基本です。

カーネルの位置づけと互換性の範囲

Clash 公式版、Clash.Meta、mihomo の関係

Clash 公式版は、YAML 設定、プロキシグループ、ルール振り分け、外部制御インターフェースなどの基本構造を築きました。Clash.Meta はこの構造を基盤に、プロトコル、DNS、TUN、ルール表現、トラフィック識別の機能を拡張しました。その後、プロジェクトは mihomo の名称で継続的に開発されているため、設定ドキュメント、ログ、クライアント設定には今も Meta の表記が残っている場合があります。移行の観点では、mihomo は Clash の設定モデルを引き継ぎながら、より多くのネットワーク処理機能を加えたカーネルと考えるとよいでしょう。完全に独立した設定体系ではありません。

互換性の範囲は、主に3つの層に左右されます。第1層はカーネル本体で、使用中の mihomo のバージョンが対象フィールドに対応しているかどうかです。第2層はクライアントで、画面から実際の設定へフィールドを書き込めるか、起動前に設定を結合・上書きしないかを確認します。第3層はサブスクリプションの提供元で、対象カーネルが認識できないプロトコルやルールが含まれていないかを見ます。トラブル対処ではこの3層を分けて確認し、画面上のスイッチだけで最終設定を判断しないでください。

同じ YAML なのに結果が変わる理由

旧カーネルで正常に起動した設定でも、mihomo に切り替えると DNS の結果、ルールのヒット先、ルーティング範囲が変わる場合があります。よくある原因は、クライアントによる DNS 設定の自動注入、カーネルごとのネットワークインターフェース選択の違い、GeoData データベースのバージョン差、TUN スタックやシステムルート実装の違いです。反対に、mihomo 専用フィールドを旧 Clash に戻すと、拒否・無視されたり、設定の読み込みに失敗したりする可能性があります。

移行前に、クライアントに「実行時設定の表示」または「最終設定のエクスポート」機能があるか確認してください。サブスクリプションの原文、クライアントの上書き後の設定、カーネルが実際に読み込む設定は、同じファイルとは限りません。ポート、DNS、ルーティングが現在の動作になる理由を説明できるのは、最終設定だけです。

確認レイヤー	確認する項目	よくある現象
クライアント	コア選択、上書きスクリプト、実行権限	画面上では保存済みだが、カーネルのパラメータが変わらない
カーネル	バージョン、対応フィールド、起動ログ	未知のフィールド、ルールセットの解析失敗
設定	YAML のインデント、プロキシグループ参照、ポート	設定を読み込めない、またはプロキシグループが空になる
システムネットワーク	ルート、DNS、ネットワークインターフェース、ファイアウォール	TUN は起動したが、一部のアプリだけネットワークに接続できない

mihomo の主な機能差

プロキシプロトコルとアウトバウンド機能

Clash 公式版の設定では、複数のプロキシノードをプロキシグループにまとめ、ルールで利用先を選ぶ構成が基本です。mihomo はこの仕組みを維持しつつ、利用できるプロトコルやトランスポートの選択肢を拡張しています。実際に使える範囲は、具体的なバージョンやクライアントのパッケージ構成にも左右されます。サブスクリプションを移行する際は、新しいプロトコルを使うノードがある場合、まず現在のクライアントに含まれる mihomo が対応フィールドを解析できるか確認し、そのうえでサーバー側のパラメータが揃っているかを確認してください。

プロトコルに対応していても、ノードへの接続が必ず成功するとは限りません。証明書名、トランスポート層のパラメータ、ユーザー識別子、暗号化方式、UDP 対応、システム時刻がハンドシェイクに影響します。単一ノードの接続に失敗した場合は、全体モードを何度も切り替えるのではなく、まずカーネルログで接続のどの段階に失敗したかを確認します。すべてのノードが失敗する場合は、サブスクリプションがクライアントで変換されていないか、対象ポートがネットワークで制限されていないか、DNS でサーバーアドレスを解決できるかを調べます。

ルールシステムとルールセット

mihomo は、上から下へルールを照合する方式を引き継いでいます。接続が条件に合う最初のルールに一致すると、指定されたプロキシグループへ渡されます。よく使われるルールには、ドメイン、ドメインサフィックス、IP サブネット、プロセス、GeoIP、GeoSite、リモートルールセットなどがあります。最後に通常、未照合のトラフィックを MATCH で受けます。

rules:
  - DOMAIN-SUFFIX,example.net,Proxy
  - GEOSITE,cn,DIRECT
  - GEOIP,cn,DIRECT,no-resolve
  - MATCH,Proxy

移行時は、ルールが参照するプロキシグループ名が実際に存在するか確認してください。グループ名は文字単位で区別されるため、サブスクリプション更新後に Proxy が別名へ変更されると、ルール構文が正しくても想定どおり動作しません。GeoSite と GeoIP はローカルデータファイルにも依存します。データベースの欠落、ダウンロード失敗、バージョンの不一致があると、同じドメインでも判定が変わる場合があります。

ルールセットを使うと、大量のドメインやサブネットをメイン設定から分離できます。mihomo は複数のルールセット動作と形式に対応していますが、旧クライアントでは新しい形式を認識できないことがあります。移行初期は、動作確認済みの YAML またはテキスト形式のルールセットを維持し、安定してからよりコンパクトな形式を検討してください。同じ移行でカーネル、ルールデータの提供元、すべてのプロキシグループ名を同時に変更すると、差異が出た際に原因を特定しにくくなります。

DNS、Fake IP、ドメインマッピング

mihomo の DNS モジュールでは、上流サーバー、プロキシノードのドメイン解決用サーバー、フォールバック方針、ドメイン別のリゾルバーを個別に指定できます。fake-ip モードでは、カーネルがアプリに予約アドレスを返し、そのアドレスと元のドメインの対応を保存します。その後の接続がカーネルに入ると、引き続きドメインルールで振り分けられます。宛先 IP しか提供しないアプリでは特に有効ですが、DNS リクエストが確実にカーネルへ入ることが前提です。

システムが DNS リクエストを別のローカルサービスへ送っている場合や、ブラウザで独自の暗号化 DNS が有効になっている場合、カーネルが元のドメインを取得できないことがあります。その結果、ドメインルールに一致しない、判定結果が混在する、一部のアプリが振り分けを迂回するといった現象が起こります。TUN 環境では DNS のリダイレクトを併用できますが、ポート競合、LAN の DNS、企業ネットワークのポリシーは別途確認が必要です。

TUN、スニッフィング、アプリのトラフィック取り込み

システムプロキシは通常、OS のプロキシ設定に従うアプリにだけ作用します。コマンドラインツール、ゲーム、一部のストアアプリ、直接 UDP 接続を確立するアプリは迂回することがあります。TUN モードでは、仮想ネットワークインターフェースとシステムルートを通じて、より広範囲のトラフィックを受け取り、カーネルで判定します。mihomo は複数の TUN スタックや自動ルーティング関連のオプションを備えていますが、必要な権限やルーティング実装は OS ごとに異なります。

トラフィックのスニッフィングは、確立済みの接続からドメイン情報を識別し、宛先 IP しか分からない場合のルール照合を改善します。すべてのプロトコルで有効とは限らず、正しい DNS 設定の代わりにもなりません。移行時は、まず通常の DNS とルールを検証し、その後アプリの範囲を限定してスニッフィングを有効にしてください。ルールの差異とスニッフィングによる宛先の書き換えを同時に扱わずに済みます。

設定フィールドと構文移行の要点

基本ポートと制御インターフェースを先に維持する

基本フィールドは、2種類のカーネル間で比較的よく似ています。移行時は、混合ポート、LAN アクセス、動作モード、ログレベル、外部制御インターフェースをいったん維持できます。ポート番号はクライアント画面やシステムプロキシの設定と一致させ、制御インターフェースにはアクセスキーと適切な待受範囲を設定してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: "local-control-key"

mixed-port は HTTP と SOCKS のプロキシリクエストを同時に受け付けるため、一般的なデスクトップクライアントに適しています。旧設定で port と socks-port を分けている場合は、その構成を一時的に維持し、これらのポートを使うアプリの移行を確認してから統合できます。複数のクライアントに同じポートを待ち受けさせないでください。後から起動したカーネルがアドレス使用中のエラーを出します。

ルールプロバイダーの動作タイプ

rule-providers で重要なのは、ダウンロード先だけではありません。behavior、format、ローカルパス、更新間隔も確認が必要です。domain はドメイン集合に、ipcidr は IP サブネットに、classical はタイプとプロキシグループ条件を含む従来型ルールに適しています。動作タイプとファイル内容が一致しないと、ルールセットのダウンロードに成功しても解析できないことがあります。

rule-providers:
  private-domains:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/private-domains.yaml
    url: https://example.invalid/rules/private-domains.yaml
    interval: 86400

rules:
  - RULE-SET,private-domains,DIRECT
  - MATCH,Proxy

ルールプロバイダーの URL はデータの取得元にすぎず、最終的には RULE-SET を使って順序付きのルール一覧に組み込む必要があります。プロバイダーを定義しただけで参照しなければ、振り分けには使われません。移行後は接続ログやクライアントの接続画面で一致したルールを確認し、トラフィックが想定したルールセットに入っていることを確かめてください。

検証しやすい DNS 設定の最小構成

DNS 設定は段階的に追加するのが適しています。第1段階ではカーネルの DNS、待受アドレス、安定した上流サーバーだけを有効にします。第2段階で拡張モードを有効にし、第3段階でドメイン別のポリシー、プロキシノード専用リゾルバー、フィルターリストを追加します。以下の構成はフィールドの関係を示すもので、具体的な上流サーバーはネットワーク環境と用途に応じて選択してください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

proxy-server-nameserver は主にプロキシサーバー自身のドメインを解決するために使い、プロキシ接続を確立する前の名前解決依存を避けます。ノードのサーバーに IP アドレスを直接指定している場合、この項目の影響は小さくなります。IPv6 を有効にする前に、ローカルネットワーク、プロキシノード、ルールが IPv6 を正しく処理できるか確認してください。DNS で IPv6 アドレスを返すだけでは、後続の接続経路が利用可能になるとは限りません。

TUN フィールドはシステム環境から切り離してコピーしない

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53

このフィールド群は一般的な方向性を示すものであり、すべてのシステムで同じ値を使うべきだという意味ではありません。仮想マシン、コンテナ、VPN、企業向けセキュリティソフト、複数のネットワークアダプターがデフォルトルートを変えることがあります。Windows では通常、仮想インターフェースの作成とルート変更の権限がクライアントに必要です。macOS ではネットワーク拡張やシステム認証が求められることがあります。Linux では適切なネットワーク管理権限が必要です。有効化後に LAN 上の機器へ接続できなくなった場合は、プロキシルールを直接変更するのではなく、ルートテーブルと除外サブネットを確認してください。

旧 Clash から mihomo へ移行する手順

現在の基準状態を記録する。
元の YAML、クライアントの上書きルール、サブスクリプション URL を保存し、現在のシステムプロキシポート、制御ポート、DNS モード、TUN の状態、正常に動作しているプロキシグループを記録します。スクリーンショットは比較の補助にとどめ、復元可能な設定ファイルも必ず保管してください。
クライアントが実際に使うカーネルを確認する。
クライアントのカーネル設定、バージョン情報画面、起動ログでカーネル名とバージョンを確認します。クライアントによってはカーネル切り替え後に完全な再起動が必要です。設定の再読み込みだけでは、旧プロセスが引き続きトラフィックを処理する場合があります。
構文チェックを行う。
まず YAML のインデント、重複キー、空のプロキシグループ、存在しないプロキシグループ参照を確認します。文字列にコロン、シャープ記号、特殊文字が含まれる場合は引用符で囲んでください。設定の解析エラーはログで示された行の周辺から確認しますが、実際の原因が直前のインデントにあることもあります。
システムプロキシで基本経路を検証する。
いったん TUN、スニッフィング、複雑な DNS 上書きを無効にし、動作確認済みのプロキシノード1つと単純なルールだけを有効にします。直接接続、プロキシ接続、拒否の3種類のポリシーがそれぞれ想定どおり一致するか確認してください。基本経路が失敗している場合は、ノードとポートを優先して対処し、高度な機能を追加し続けないでください。
プロキシグループとルールセットを復元する。
select、url-test、fallback などのグループ内メンバーが有効で、ルールの対象とプロキシグループ名が一致していることを一つずつ確認します。自動テストグループでは、テスト URL、間隔、許容値が選択結果に影響します。一度の遅延が最小だったからといって、長期的に最適とは限りません。
DNS を移行する。
まずカーネルの待受ポートが使用されていないことを確認し、次にシステムまたは TUN が DNS クエリをその待受アドレスへ渡しているか確認します。通常のドメイン、ルールセットのドメイン、プロキシサーバーのドメインを個別にテストし、ログに表示されるリゾルバーと最終ルールを確認してください。
最後に TUN とスニッフィングを有効にする。
有効化後は、デフォルトルート、LAN アクセス、スリープ復帰、ネットワーク切り替えを確認します。異常が出たアプリについては、宛先アドレス、プロトコル、一致したルールを記録し、そのうえで除外項目を追加するかスニッフィング範囲を調整します。

サブスクリプションの移行では、「リモート設定」と「ローカル上書き」も区別する必要があります。リモート更新ではノードやプロキシグループが上書きされる可能性があり、ローカル上書きはポート、DNS、カスタムルールの維持に使います。クライアントが設定のマージに対応している場合は、マージ順序を明確にしてください。対応していない場合は、サブスクリプション更新のたびにカスタムフィールドが残っているか確認します。クライアントが管理するキャッシュファイルを直接編集しないでください。次回更新時に再生成される可能性があります。

移行後によくある問題と確認方法

設定は読み込めるが、カーネルにトラフィックが流れない

まずシステムプロキシが現在の mixed-port を向いているか確認し、次にクライアントのプロセスが実際にそのポートを待ち受けているか調べます。ブラウザに古いプロキシ設定が残っている場合や、コマンドラインプログラムが環境変数の古いポートを参照している場合もあります。TUN を使う場合は、仮想インターフェースが作成されているか、デフォルトルートが変わっているか、現在接続中のネットワークインターフェースが正しく認識されているかを確認してください。

ドメインルールに一致せず、IP ルールだけが表示される

これは通常、カーネルが対象ドメインを取得できていないことを示します。アプリが独自 DNS を使っていないか、システムの名前解決がカーネルに入っているか、Fake IP のマッピングが有効かを確認してください。一部のプロトコルだけドメインを取得できない場合は、スニッフィングを検討します。すべてのアプリで IP しか残らない場合は、まず DNS 経路を修正してください。ルールの順序も確認が必要です。前方にある IP ルールやルールセットが、すでにトラフィックを先に受け取っている可能性があります。

ルールプロバイダーの更新に失敗する

ダウンロード URL、ネットワーク経路、ファイル形式、ローカルディレクトリの権限を確認します。初回起動時は、リモートルールがまだキャッシュされていないことがあります。ダウンロード自体が、まだ確立していないプロキシポリシーに依存している場合は、起動時の依存関係が問題になります。まずルールの取得元に明確なアクセス経路を用意し、ファイルが正常に保存されてから完全な振り分けを戻してください。ログの HTTP ステータス、解析エラー、ファイルパスは、画面に出る一律の「更新失敗」表示よりも原因特定に役立ちます。

TUN 有効化後に LAN または一部アプリが切断される

まず TUN を無効にして、問題が仮想ルーティングに関係するか確認します。その後、プライベートサブネット、ゲートウェイ、LAN の DNS、他の VPN を確認してください。複数のネットワークアダプターがある端末では、自動検出が現在接続中のインターフェースを選択しているかも確認します。特定の UDP アプリだけに異常がある場合は、ノードが UDP に対応しているか、プロキシグループが適切なアウトバウンドを選択しているか、システムファイアウォールが仮想インターフェースのトラフィックを許可しているかを調べます。

サブスクリプション更新後にプロキシグループ名が変わる

ルール、ルールセット、クライアントのショートカット選択はいずれもプロキシグループ名を参照する可能性があります。更新後にグループ名が変更されると、旧ルールは存在しない対象を指すことになります。対処は、画面で一度選び直すだけではなく、名前を統一してすべての参照先を確認することです。長期的に使うカスタムルールには、安定したローカルプロキシグループを中間層として用意し、サブスクリプションのノードをそのグループへ入れる方法もあります。

mihomo 移行チェックリスト

クライアントに表示される実行中のカーネルが、想定した mihomo のバージョンになっている。
元の設定、サブスクリプション情報、クライアントの上書き設定を個別にバックアップしている。
HTTP、SOCKS、混合ポートが他のプロセスと競合していない。
すべてのルールが参照するプロキシグループが存在し、各グループに少なくとも1つの利用可能なメンバーがある。
ルールが具体的な条件からフォールバック条件の順に並び、最後の MATCH が明確なプロキシグループを指している。
GeoIP、GeoSite、リモートルールセットを正常に読み込み、更新できる。
DNS クエリが想定した待受アドレスに入り、プロキシサーバーのドメインを解決できる。
システムプロキシモードで、直接接続とプロキシ接続のトラフィックがいずれもルールどおり一致する。
TUN 有効化後も、デフォルトルート、LAN アクセス、ネットワーク切り替えが正常に機能する。
サブスクリプション更新後も、ローカル上書き、プロキシグループ名、カスタムルールが有効になっている。

mihomo の価値は、継続的に保守されるカーネル機能、より充実したルールと DNS の制御、現代的なネットワーク取り込み環境への対応にあります。移行の成否は、接続ログ、ルールの一致、DNS 経路、システムルートの実際の結果で判断してください。基本プロキシ、ルール、DNS、TUN の順に段階的に検証すれば、旧 Clash 設定からも比較的スムーズに移行でき、問題発生時の切り戻しポイントも明確に保てます。