mihomoカーネルの機能解説：標準Clashとのルール・プロトコル・動作能力の違い

mihomoと標準Clashの互換性

標準Clashは、組み合わせやすい設定構造を確立しました。proxiesでノードを定義し、proxy-groupsで手動選択、自動テスト、フェイルオーバーなどの戦略を組み立て、rulesで接続を上から順にプロキシグループへ振り分けます。mihomoはこの基本構造を引き継いでいるため、一般的なClash YAML設定は移行の出発点として利用できます。DOMAIN-SUFFIX、DOMAIN、IP-CIDR、GEOIP、MATCHなどの基本ルールや、select、url-test、fallbackなどの代表的なプロキシグループは、両方の設定でおおむね近い意味を持ちます。

この互換性は、両者の設定フィールドが完全に同じという意味ではありません。mihomoで追加されたフィールド、プロキシタイプ、ルール構文を標準Clashが認識できるとは限りません。逆に、古い設定に残るフィールドが変更・廃止されていたり、特定クライアントの前処理層でしか機能しなかったりする場合もあります。特にサブスクリプション変換サービスが生成する設定には、カーネル用フィールド、クライアント専用フィールド、テンプレート変数が混在することがあります。移行時はサブスクリプションURLの名称だけでなく、最終的にカーネルへ渡されるYAMLを確認してください。

設定の互換性は3つの段階に分けられます

1. 構文を読み取れる：YAMLのインデント、リスト、フィールド名が解析を通り、カーネルを起動できる。
2. オブジェクトを認識できる：ノードプロトコル、プロキシグループの種類、ルールタイプ、DNSフィールドが現在のカーネルバージョンでサポートされている。
3. 期待どおりに動作する：ルールの適用順、DNSの応答、速度測定方式、トラフィックの取り込み範囲が元の設定意図と一致している。

「設定のインポートに成功しました」と表示されるだけでは、通常は最初の2段階の一部しか確認できません。本当の互換性を確認するには、プロキシグループが完全か、ルールプロバイダーの更新に成功しているか、DNSが待ち受けているか、ログに未知のフィールドがないか、対象サイトが最終的にどのプロキシグループへ振り分けられたかを確認する必要があります。

ルールシステムの違い：順番による照合から条件の組み合わせまで

Clashとmihomoのルール処理には、共通する重要な原則があります。ルールは上から下へ確認され、最初に一致したルールが接続先を決めます。そのため、ルールの数が多いからといって、必ずしも正確にルーティングできるわけではありません。重要なのは順序と条件の範囲です。広いドメインサフィックスルールを具体的なルールより前に置くと、後続のルールが実行されなくなることがあります。MATCHを前方に置くと、残りのトラフィックをすべて直接引き受けます。

mihomoは、基本的なルールモデルに加えて、より豊富な照合条件を提供します。ドメイン、宛先IP、送信元IP、ポート、プロセスなどの一般的な条件に加え、対応バージョンでは論理演算を使い、複数の条件をAND、OR、NOTの関係で組み合わせられます。これにより、「特定のプロセスが特定ポートへアクセスしたときに指定したプロキシグループを使う」「特定のドメイン集合に該当し、プロトコルタイプも条件を満たす場合にプロキシを使う」といった細かな要件を表現できます。具体的なルール名やネスト構文はバージョンによって変わる可能性があるため、作成前に使用中のバージョンのドキュメントと起動ログを確認してください。

基本ルールと拡張ルールの使い分け

• ドメインルール：DOMAINは完全なドメイン名に正確に一致し、DOMAIN-SUFFIXは特定ドメインとそのサブドメインに一致します。安定したサイト分類に適しています。
• IPルール：IP-CIDRとIP-CIDR6は、宛先アドレスの範囲に基づいて判定します。このルールのために追加のDNS解決を発生させたくない場合は、対応状況に応じて適切なオプションを使用できます。
• 地理情報ルール：GEOIPはIPデータベースに基づいて分類します。mihomoでは、GEOSITEやルールセットと組み合わせてドメインを分類することも一般的です。結果の精度はデータファイルの入手元と更新時期に左右されます。
• プロセスルール：プロセス名やパスに基づいてルーティングできます。デスクトップ環境に適していますが、権限、OS、トラフィックの取り込み方式によって識別結果が変わります。
• インバウンドとネットワーク条件：インバウンドの送信元、TCPまたはUDP、送信元アドレス、ポートなどの情報に基づいて戦略を細分化できます。ゲートウェイや複数の入口を持つ構成に適しています。
• ルールプロバイダー：rule-providersを使って大規模なルールセットをメイン設定から分離し、指定した間隔で更新してからRULE-SETで参照します。

ルールプロバイダーは大規模な設定で非常に便利な構造ですが、「多ければ多いほどよい」わけではありません。複数のルールセットが同じドメインを対象にしたり、更新に失敗してルーティング結果が想定と異なったりすることがあります。必ず直接接続したいLANやシステムサービスは前方に置き、用途が明確なルールセットを優先順位に従って並べ、末尾には分かりやすいフォールバック戦略を残すことをおすすめします。出所が不明、長期間更新されていない、または容量が異常に大きいルールセットは、内容の形式と動作を先に確認してください。

rule-providers:
  service-set:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/service-set.yaml
    url: https://example.com/rules/service-set.yaml
    interval: 86400

rules:
  - DOMAIN,router.local,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - RULE-SET,service-set,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

この構成はルールの整理方法を示すものであり、すべての環境にそのままコピーできるわけではありません。リモートURL、プロキシグループ名、ルールセットの形式、保存パスは、実際の設定に合わせる必要があります。特にbehaviorとダウンロードファイルの内容形式が一致していないと、ルールプロバイダーの読み込みに失敗する可能性があります。クライアントに更新成功と表示された後も、カーネルログで解析が完了しているか確認してください。

プロトコル対応の違い：ノードをインポートできても接続できるとは限らない

標準Clashは、従来型のプロキシプロトコルに対応し、統一されたプロキシグループでノードを切り替えます。mihomoはその基盤を拡張し、より多くの現代的なプロトコルやトランスポートの組み合わせに対応しています。代表例としてVLESS、Reality、Hysteria2、TUIC、WireGuardのほか、各プロトコルにおけるTLS、WebSocket、gRPCなどのパラメータ構成があります。実際に使える範囲は、mihomoのバージョン、ビルド対象、クライアントへの統合状況によって異なります。サブスクリプションに特定形式のリンクが含まれているだけで、必ず利用できると判断してはいけません。

サブスクリプションのインポートは通常、2段階で行われます。まずクライアントまたはサブスクリプションサービスがノードリンクをYAMLオブジェクトへ変換し、その後カーネルがオブジェクトを読み込んで接続を確立します。ノードがプロキシグループに表示されない場合は、変換段階で認識されなかった可能性があります。ノードは表示されるものの接続エラーになる場合は、カーネルのパラメータ、サーバー側の設定、ネットワーク環境、システム時刻に問題がある可能性が高くなります。この2段階を分けて確認するほうが、サブスクリプションを何度も再インポートするより効果的です。

プロトコル移行時に確認するパラメータ

• サーバーアドレス、ポート、ユーザー識別子、認証情報がすべて揃っているか。
• TLSが有効になっているか、サーバー名、ALPN、証明書関連のパラメータがサーバー側と一致しているか。
• トランスポート層がTCP、UDP、WebSocket、gRPCなどのどの形式か、パスとサービス名が一致しているか。
• Reality環境の公開鍵、ショートID、フィンガープリントのパラメータが正しいか。
• Hysteria2、TUICなどUDPベースのプロトコルが、現在のネットワーク、ルーター、ファイアウォールによる制限を受けていないか。
• プロキシグループが対象ノードを参照しているか、ノード名を変更した後に参照先が存在しない状態になっていないか。

速度テストの結果だけで実際の利用感を完全に判断することはできません。url-testは通常、指定URLへの応答時間を測定し、一定間隔で再テストします。到達可能で遅延の小さいノードを選ぶのに役立ちますが、動画のスループット、長時間接続の安定性、UDP品質、対象サイト側の制限までは評価できません。すべてのノードで速度テストが正常なのに特定のアプリだけ使えない場合は、ルールの適用結果、DNSの応答、IPv6経路、アプリがシステムプロキシを迂回していないかを確認してください。

標準Clashからmihomoへ切り替える主なメリットの1つは、同じプロキシ戦略体系でより多くのノードタイプを扱えることです。ただし、対応プロトコルが増えるほど設定フィールドも複雑になります。サブスクリプションを利用する場合は、まずサービス提供者にmihomo対応の設定形式を生成してもらうのがよいでしょう。設定を手動で管理する場合は、単一ノードとシンプルなプロキシグループで接続を確認してから、自動選択、負荷分散、複雑なルールを段階的に追加してください。

動作機能の違い：DNS、スニッフィング、TUNモード

カーネルの動作機能によって、トラフィックがプロキシシステムへ入る方法と、ルール照合時に取得できる情報が決まります。システムプロキシは通常、OSのプロキシ設定に従うアプリだけに影響します。一方、TUNモードは仮想ネットワークインターフェースを通じて、より広い範囲のIPトラフィックを取り込みます。OSのプロキシ設定を参照しないプログラム、一部のゲーム、通信を一元管理したい環境に適しています。mihomoはTUN、DNS、トラフィック識別に関する設定項目が多い一方、システム権限と正しいネットワークパラメータへの依存も大きくなります。

TUNモードの要点

TUNを有効にすると、クライアントは通常、仮想ネットワークアダプターを作成し、ルートを変更するか自動リダイレクト機能を有効にする必要があります。実装の詳細はOSによって異なり、クライアントによってはsystem、gVisor、mixedなどのネットワークスタックを選択できます。利用できる項目は、使用中のカーネルとクライアントに従ってください。あるプロトコルスタックが1台の端末で安定していても、すべてのOSバージョン、仮想マシン、企業のセキュリティ環境で同じ結果になるとは限りません。

TUNモードでよくある問題には、ルートが正しく追加されない、LANへのアクセスまで取り込まれる、DNSリクエストの経路が一致しない、スリープ復帰後に仮想インターフェースが使えない、ほかのVPNソフトもデフォルトルートを同時に変更している、といったものがあります。切り分ける際は、まず他のネットワーク取り込みツールを停止し、通常のシステムプロキシモードが使えることを確認してからTUNを有効にし、ログを確認してください。LAN内の機器だけにアクセスできない場合は、すべてのルールを変更するのではなく、プライベートアドレス範囲が直接接続に設定されているかを確認します。

DNSモードとドメインルール

ドメインルールを正確に機能させられるかどうかは、DNSの処理方式と密接に関係しています。mihomoでよく使われる拡張DNSモードには、redir-hostとfake-ipがあります。fake-ipはドメインに対して予約アドレス範囲のマッピングアドレスを返し、カーネルが接続時にドメイン情報を復元します。これにより、IP接続だけを開始するアプリでもドメインルールの照合に参加しやすくなります。一部のLANサービス、デバイス検出、ゲームプラットフォーム、実アドレスによる判定に依存するプログラムでは、fake-IPの除外範囲への追加が必要になる場合があります。

DNS設定では、デフォルトのリゾルバー、プロキシノードのドメイン解決用リゾルバー、ドメイン別のポリシーで選択するリゾルバー、フォールバックリゾルバーを分けることもあります。ここで起きやすいのが循環依存です。プロキシノードのサーバーアドレス自体がドメイン名なのに、そのドメインの解決にも、まだ確立していないプロキシ経由のアクセスが必要になるケースです。ノードのドメイン名には直接アクセスできる基本の解決経路を用意し、「プロキシサーバーのアドレスを解決する段階」と「プロキシ確立後に対象サイトを解決する段階」を明確に分けてください。

トラフィック嗅探の範囲

トラフィック嗅探は、HTTP HostやTLS Server Nameなどのハンドシェイク情報から対象ドメインを識別し、宛先IPしかない場合に不足するドメイン情報を補います。これはTUN環境でのルール照合に役立ちますが、嗅探はHTTPSの内容を復号するものではなく、すべての接続からドメインを取得できるわけでもありません。暗号化されたハンドシェイク方式、QUIC、アプリ独自プロトコル、IPアドレスを直接使う接続では、識別精度が制限される可能性があります。

嗅探を有効にして一部のアプリで接続異常が起きた場合は、まず識別されたドメインが正しいかを確認し、必要に応じて対象ごとにスキップ設定を追加します。嗅探、DNS、ルールの問題を一つにまとめて考えないでください。ログにドメインがあるのに戦略だけが誤っているなら、ルールの順序を確認します。ログにIPしかないなら、DNSと嗅探を確認します。接続がそもそもカーネルに入っていないなら、システムプロキシ、TUNのルート、アプリ自身の設定を確認します。

Clash設定からmihomoへ移行する際の確認手順

設定移行で最も確実なのは、拡張機能を最初からすべて有効にするのではなく、検証可能な最小構成を作り、機能を段階的に戻していく方法です。これにより、問題がYAML解析、ノード接続、プロキシグループ参照、ルール読み込み、DNS、システムによるトラフィック取り込みのどの段階で起きているかを特定できます。

1. 実際に動作しているカーネルを確認する。クライアントの概要ページ、カーネル管理画面、起動ログでカーネル名とバージョンを確認します。画面タイトルにClashと表示されていることだけでは判断できません。
2. 元の設定をバックアップする。元のYAML、サブスクリプションURL、カスタムルール、DNS設定を保存します。クライアントのデータベースと個別にエクスポートしたYAMLは同じ内容とは限らないため、重要な変更は別途保存してください。
3. まずYAMLの解析を確認する。インポート後、ログに未知のフィールド、重複キー、インデントエラー、ルールプロバイダーの読み込み失敗がないか確認します。YAMLはスペースで階層を表すため、Tabや誤ったインデントによって構造が変わることがあります。
4. シンプルなプロキシグループでノードをテストする。まず手動選択グループを作り、少数のノードだけを追加して、TCPと必要なUDP接続が機能することを確認します。この段階では複雑な速度テストや負荷分散を追加しません。
5. プロキシグループの参照を確認する。ルール末尾で指定するグループが存在している必要があります。プロキシグループ内で参照するノード名や他のグループ名も完全に一致していなければなりません。名前に含まれる空白や句読点も名称の一部です。
6. ルールセットを段階的に読み込む。LANの直接接続、主要サービスのルール、地域ルール、最終フォールバックの順に追加し、追加するたびにルールプロバイダーの更新状態と実際の適用結果を確認します。
7. DNSとTUNは最後に調整する。まずシステムプロキシモードで基本接続を確認し、その後に拡張DNS、嗅探、TUNを有効にします。取り込み機能を1つ追加するたびに、Webページ、コマンドラインプログラム、LAN、UDPアプリを再テストしてください。

異常が起きたときの切り分け方

カーネルが起動しない場合は、まず設定構文、対応フィールド、待ち受けポートの競合を確認します。ノードがすべて使えない場合は、ネットワーク接続、プロトコルパラメータ、システム時刻、ノードのドメイン解決を確認します。一部のサイトだけ接続先が誤る場合は、接続ログのドメイン、宛先IP、適用ルールを確認します。ブラウザーは正常なのにアプリが使えない場合は、そのアプリがシステムプロキシを参照するか、TUNによる取り込みが必要かを確認します。TUNを有効にして全体がインターネットへ接続できなくなった場合は、まずシステムプロキシモードへ戻し、仮想ネットワークアダプター、デフォルトルート、DNSの待ち受け状態を確認してください。

ログレベルも必要に応じて調整します。通常の利用では標準レベルで十分です。トラブルシューティング時だけ一時的に詳細ログを有効にし、アクセス先ドメイン、ノードアドレス、ローカルパスなどの情報が含まれる可能性に注意してください。切り分けが終わったら通常レベルへ戻すことで、不要な出力と長期的なログ容量を抑えられます。

標準Clashとmihomoの選び方

現在クライアントを選んでいるユーザーにとって、現実的な問題は、どのコマンドラインカーネルを単体でインストールするかではなく、どのカーネルを採用したクライアントを選ぶかです。設定が従来型プロトコルと基本的なルーティングだけで構成され、現在の環境で安定して動作し、新しい機能も必要ないなら、名称が変わったからといって急いで移行する必要はありません。安定した設定、明確なルール、復元可能なバックアップは、追加されたフィールドを追い続けることより重要です。

サブスクリプションにVLESS Reality、Hysteria2、TUICなどのノードが含まれている場合や、論理ルール、ルールプロバイダー、詳細なDNS戦略、トラフィック嗅探、TUNによる取り込みが必要な場合は、mihomoのほうがより充実した実装基盤を提供することが多いでしょう。選ぶ際は、グラフィカルクライアントが対象バージョンを速やかに統合しているか、カーネルを更新できるか、ログを分かりやすく表示するか、システムプロキシとTUNの切り替えが現在のプラットフォームに適しているかも確認してください。

違いをまとめると、標準Clashは設定とルーティングの基本モデルを築き、mihomoはそのモデルを継承しながらプロトコル、ルール、動作機能を拡張しています。移行で重要なのは、拡張スイッチをすべて有効にすることではなく、それぞれの機能がどの問題を解決するのかを確認し、ログと段階的なテストで結果を検証することです。多くの設定では、まず基本ノード、プロキシグループ、ルール順序を正しく整え、その後にDNS、嗅探、TUNへ進むことで、よくある連鎖的な障害を減らせます。