カーネル解説 読了目安 13分

mihomoカーネルの新機能とは？オリジナルClashカーネルとの機能差を徹底比較

対応プロトコル、ルールタイプ、TUN実装、GEOデータ管理まで、mihomo（Clash Meta）がオリジナルカーネルに追加した機能と、mihomo専用の設定項目を解説します。

まず整理したいオリジナルClash、Clash Meta、mihomoの違い

ここでいう「オリジナルClash」とは、通常Dreamacroが開発していたClashオープンソースカーネルを指します。YAML設定の読み込み、プロキシ接続の確立、ルールマッチングの実行に加え、HTTP、SOCKS5、mixed-portを通じてローカルアプリにプロキシ機能を提供します。オリジナルプロジェクトの更新停止後は、コミュニティ版のClash Metaがプロトコル、ルール、DNS、透過プロキシ機能を拡張し、その後プロジェクト名がmihomoに変更されました。

つまり、Clash Metaとmihomoは二者択一の別カーネルではありません。前者は旧称、後者が現在の名称です。一部のクライアント画面、サブスクリプション変換ツール、古い設定では今も「Meta」と表示されるため、判断する際はクライアント名だけでなく実際のカーネルバージョンを確認してください。

カーネルとGUIクライアントは分けて考える必要があります。クライアントはトレイメニュー、設定のダウンロード、システムプロキシの切り替え、ログ表示を担当します。一方、proxies、rules、dns、tun などの項目を実際に認識するのはカーネルです。同じ設定でもクライアントによって動作が異なる場合、画面ではなく、組み込まれているカーネルの種類やバージョンが原因であることがよくあります。

機能比較の基本範囲

機能 オリジナルClash mihomo
基本的なルールベースのプロキシ 対応 互換性を保ちながら拡張
現代的なプロキシプロトコル 初期世代のプロトコルが中心 VLESS、Reality、TUIC、Hysteria2などを追加対応
TUN透過プロキシ オープンソース版の機能は限定的で、かつてはPremium版の実装と併存 複数のプロトコルスタックと自動ルーティングを統合
論理結合ルール 基本は直線的なルール AND、OR、NOT、サブルールに対応
GEOデータ GEOIP、GEOSITEの基本的な利用 読み込み方法、ダウンロード先、自動更新を制御可能
トラフィックのスニッフィング 機能は限定的 独立したsniffer設定セクションを提供

プロトコル対応：増えたのはノードタイプだけではない

オリジナルClashは、Shadowsocks、VMess、Trojan、Snell、SOCKS5、HTTPなど一般的なノードに対応していました。mihomoはその上でプロトコルやトランスポート層の実装を継続的に拡張しており、VLESS、XHTTP、Reality、TUIC、Hysteria、Hysteria2、WireGuardのほか、Shadowsocksのプラグインや多様なトランスポート構成にも対応しています。利用できる項目はカーネルのバージョンに左右されるため、サブスクリプションに新しい項目が含まれていたら、まずクライアントに組み込まれたmihomoが十分新しいか確認してください。

VLESSとReality

オリジナルClashは、mihomo設定のVLESSノードを認識できません。mihomoは type: vless を読み込み、uuid、flow、network、tls などの項目を処理できます。Realityを使う場合は、reality-opts、public-key、short-id が含まれることもあります。これらの項目をオリジナルカーネルにそのまま渡すと、通常は設定検証の段階で、プロキシタイプまたは項目がサポートされていないというエラーが表示されます。

proxies:
  - name: vless-reality-example
    type: vless
    server: example.net
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    network: tcp
    tls: true
    udp: true
    servername: www.example.com
    reality-opts:
      public-key: example-public-key
      short-id: "01234567"
    client-fingerprint: chrome

この例は項目の階層を示すためだけのものです。アドレス、UUID、公開鍵、短いIDは実際のサービス設定に置き換えてください。Reality関連のパラメータは一式で対応している必要があり、通常のVLESSノードの tls だけを true に変更しても動作しません。

TUICとHysteria2

TUICとHysteria2はいずれもQUICとUDPを基盤としますが、設定項目は共通ではありません。TUICでは uuid、password、congestion-controller、udp-relay-mode などがよく使われます。Hysteria2では password、obfs、obfs-password、帯域幅パラメータなどが一般的です。プロバイダーが指定するプロトコルタイプは、カーネル設定の type と一致していなければなりません。

グローバルTLSフィンガープリント

mihomoでは global-client-fingerprint にグローバルなクライアントフィンガープリントを設定でき、一部のプロキシノードには client-fingerprint を個別に指定できます。よく使われる値は chrome、firefox、safari、ios、random です。ノード単位の設定は通常、グローバル設定より優先されるため、設定を移行する際は競合する値を同時に記述しないようにしてください。

global-client-fingerprint: chrome
unified-delay: true
tcp-concurrent: true

unified-delay は遅延の計算方法を統一し、完全な接続プロセスに近いテスト結果を得るための項目です。tcp-concurrent は名前解決結果に含まれる複数のIPへの接続を並行して試行し、先に成功した接続を使います。いずれもmihomoでよく使われるトップレベルの拡張項目であり、オリジナルClashの設定では依存しないでください。

ルールシステム：逐次マッチングから論理結合へ

どちらのカーネルも「上から順に評価し、最初に一致した時点で停止する」という基本的なルール順序に従います。オリジナルClashでよく使うルールは DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、PROCESS-NAME、RULE-SET、最後の MATCH です。mihomoはこれらを維持しつつ、ネットワーク属性と論理結合機能をさらに追加しています。

AND、OR、NOT

論理ルールは「複数の条件を同時に満たす通信」や「特定の条件を除外する通信」を表すのに適しています。たとえば、UDPかつ宛先ポートが443の通信だけを指定したプロキシグループへ振り分ける場合、ネットワーク種別とポート条件を組み合わせられます。論理ルールは括弧やカンマの階層が厳密なので、使用中の設定を直接上書きせず、先にカーネルの検証コマンドで確認してください。

rules:
  - AND,((NETWORK,UDP),(DST-PORT,443)),QUICポリシー
  - OR,((DOMAIN-SUFFIX,example.com),(DOMAIN-SUFFIX,example.net)),プロキシ
  - NOT,((GEOIP,CN)),中国本土以外の通信
  - MATCH,最終選択

論理結合の目的はルール数を減らすことではなく、1つの条件を重複した複数のリストに分解せずに済むようにすることです。ルールが複雑になるほど、頻繁に使う明確なドメインルールを前方に置き、広範囲を対象とするGEOIP、ルールセット、MATCH は後方に配置することが重要です。

ポート、ネットワーク、プロセスのルール

mihomoでは、送信元ポート、宛先ポート、インバウンドタイプ、ネットワークプロトコル、プロセスパスに基づいてさらに振り分けられます。よく使われる項目は SRC-PORT、DST-PORT、IN-TYPE、NETWORK、PROCESS-NAME、PROCESS-PATH です。たとえばDNSは通常53番ポート、HTTPSは通常443番ポートを使い、ローカルのmixed-portには7890を設定することがよくあります。

ルールセットとサブルール

rule-providers は、大量のドメインやIPルールを管理する主要な方法です。mihomoは domain、ipcidr、classical などの動作タイプに対応し、YAMLテキストやMRSなどのデータ形式を利用できます。ルールプロバイダーの behavior はファイルの内容と一致させる必要があります。ドメインだけの集合を ipcidr として指定してはいけません。完全なルール構文を含むリストには classical を使用します。

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

rules:
  - RULE-SET,private-domains,DIRECT
  - MATCH,プロキシ

interval: 86400 は86400秒、つまり24時間ごとに更新を確認する設定です。リモートルールの初回ダウンロードに失敗しても、カーネルが内容を自動生成することはできません。URLへのアクセス、ファイル形式、保存先ディレクトリの権限、ログに記録されたHTTPステータスコードを確認してください。

TUNモード：より広い接続範囲と完全なプロトコルスタック

システムプロキシの影響を受けるのは、プロキシ設定を自分で読み取るアプリだけです。ブラウザは通常システムプロキシを利用できますが、ゲーム、コマンドラインツール、一部のストアアプリ、UDPソケットを直接作成するソフトウェアは迂回することがあります。TUNモードでは仮想ネットワークアダプターを作成し、ルーティング条件に合うIP通信をカーネルへ渡すため、より広い範囲を引き受けられます。

オリジナルのオープンソースClashと旧Premiumカーネルでは、TUN機能の範囲に違いがありました。mihomoはTUN、DNSハイジャック、自動ルーティング、トラフィックのスニッフィングを、継続的に保守される1つの設定体系に統合し、system、gvisor、mixed などのプロトコルスタックを提供します。利用できる機能はOSとクライアントの権限にも左右されます。

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

3種類のstackの選び方

auto-route はルートを自動設定し、通信をTUNへ流します。auto-detect-interface は現在の出口ネットワークアダプターを識別します。strict-route は迂回経路をより厳格に制限します。Windows、macOS、Linuxではルーティングの実装が異なるため、有効化後にLANプリンターやNASへアクセスできなくなった場合は、すぐにプロキシノードを変更せず、プライベートネットワークが正しく直接接続されているか確認してください。

トラフィックのスニッフィングでドメイン情報を補完

TUNで引き受けた接続には、宛先IPだけが含まれ、元のドメイン名がない場合があります。mihomoの sniffer はTLS ClientHello、HTTP Host、QUICハンドシェイクからドメイン名を抽出し、ドメインルールのマッチングに利用できます。これにより、「ドメインルールを設定したのに接続がIPにしか一致しない」という状況を減らせます。

sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  skip-domain:
    - Mijia Cloud

スニッフィングはDNS名前解決の代わりにはならず、すべての暗号化接続から完全なドメイン名を復元できるわけでもありません。設定時は対象ポートの範囲を制限し、宛先情報を書き換えるのに適さないことが分かっているサービスを skip-domain で除外してください。トラブルシューティングでは、まずスニッフィングを無効にして結果を比較し、原因がノード、DNS、ルール、ドメイン上書きのどれかを切り分けます。

DNSとGEOデータ：増えた制御項目を整理

オリジナルClashには nameserver、fallback、fallback-filter、enhanced-mode、fake-ip-filter がありました。mihomoはこれらを引き継ぎ、default-nameserver、proxy-server-nameserver、direct-nameserver、nameserver-policy、respect-rules など、より細かな制御項目を追加しています。

nameserverごとの役割

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query

この例では、カーネルのDNSリスナーを1053番ポートで待ち受けさせ、一般的なシステムの53番ポートを直接使用しません。TUNの dns-hijack が、条件に合う53番ポート宛ての問い合わせをカーネルへ送ります。システム上ですでにローカルDNSサービスが動作している場合は、同じアドレスを2つのプロセスが待ち受けないよう、まずポートの使用状況を確認してください。

GEOIP、GEOSITE、GeoSite.dat

GEOIP は宛先IPが属する地域に基づいてマッチし、GEOSITE は整備済みのドメイン分類に基づいてマッチします。両者は異なる種類のデータです。ドメインルールはDNS解決前に一致することがありますが、GEOIPでは通常、宛先IPの取得が必要です。すべての通信をGEOIPだけで判定してもドメイン分類の代わりにはならず、解決後のマッチング処理が増える可能性もあります。

mihomoには、データ形式、読み込み方法、ダウンロード先、更新間隔を制御する geodata-mode、geodata-loader、geox-url、geo-auto-update、geo-update-interval などのトップレベル設定があります。バージョンによっては、GeoIP、GeoSite、MMDB、ASNデータに個別のURLを指定することもできます。

geodata-mode: true
geo-auto-update: true
geo-update-interval: 24
geox-url:
  geoip: https://example.net/data/geoip.dat
  geosite: https://example.net/data/geosite.dat
  mmdb: https://example.net/data/country.mmdb
  asn: https://example.net/data/ASN.mmdb

geo-update-interval: 24 は通常、時間単位として解釈され、24時間ごとに更新を確認します。実際に利用できる項目やデータ形式はmihomoのバージョンによって変わるため、導入前に使用中のカーネルのドキュメントと起動ログを確認してください。ダウンロード先がHTMLのエラーページを返す場合、HTTPステータスが正常に見えてもデータの読み込みは失敗します。

オリジナルClashへ戻すと問題になりやすい設定項目

基本的な port、socks-port、mixed-port、allow-lan、mode、log-level、proxies、proxy-groups、通常の rules は、比較的互換性があります。移行に失敗する主な原因は、mihomo独自のノードタイプ、論理ルール、トップレベルの拡張設定です。

項目または記述方法 mihomoでの用途 移行時の注意点
global-client-fingerprint グローバルTLSクライアントフィンガープリントを設定 オリジナルカーネルではこの項目に依存しない
sniffer HTTP、TLS、QUIC通信からドメインを識別 関連するドメイン上書き処理を削除する必要がある
geox-url GEOデータのダウンロード先を指定 オリジナルとはデータ管理方法が異なる
tcp-concurrent 複数の名前解決先を並行して試行 旧カーネルでは無視または拒否される可能性がある
VLESS、TUIC、Hysteria2 現代的なプロキシプロトコル ノードを変更するか、mihomoを使い続ける必要がある
AND、OR、NOT 論理結合ルール オリジナルが認識できる直線的なルールへ分解する必要がある
listeners 複数の独自インバウンドリスナーを定義 オリジナルでは通常、固定ポートの項目を使用する

検証してから実行中の設定を置き換える

YAMLを変更したら、まず独立したディレクトリで検証を実行できます。mihomoでは次のようなコマンド形式をよく使います。-d は設定ファイルとデータファイルを含む作業ディレクトリ、-f は設定ファイルを指定します。

mihomo -t -d ./mihomo-work -f ./config.yaml

検証に合格しても、構文、項目、ローカルファイルを基本的に読み取れることしか確認できません。その後、実行ログでノードのハンドシェイク、ルールプロバイダーのダウンロード、DNSリスナー、TUNルートも確認してください。少なくとも4つのテストを推奨します。直接接続すべきサイトへのアクセス、プロキシ経由にすべきサイトへのアクセス、UDPリクエストの実行、システムプロキシを無効にした状態でTUNが対象アプリを引き続き引き受けるかの確認です。

mihomoが必要かどうかを判断する方法

設定がShadowsocks、VMess、Trojanと単純なドメインルールだけで、システムプロキシですべてのアプリをカバーできるなら、カーネルを変更しても目に見える違いは小さいでしょう。設定の安定性を左右するのは、カーネル名そのものよりも、ノードパラメータ、ルールの順序、DNS経路です。

次のような環境ではmihomoが適しています。サブスクリプションにVLESS Reality、TUIC、Hysteria2が含まれる場合、TUNでゲームやコマンドラインプログラムを引き受けたい場合、プロセス・インバウンド・論理条件で通信を振り分けたい場合、ノードドメインのDNSを個別に管理したい場合、GEOSITE、ASN、MRSルールセットやGEOデータの自動更新を利用する場合、透過プロキシ環境でスニッフィングによりドメインを復元したい場合です。

  1. まずクライアントの「設定」→「カーネル」で、実際のカーネル名とバージョンを確認してください。
  2. 現在の設定をエクスポートし、type: vless、type: tuic、type: hysteria2、sniffer:、geox-url: を検索します。
  3. 設定を検証し、不明な項目、インデントの誤り、データファイルの不足などを解消します。
  4. ログを開き、レベルを一時的に info に設定します。debug は複雑な接続を調査するときだけ短時間使用してください。
  5. TUN、DNSハイジャック、スニッフィングは1つずつ有効にし、ネットワーク経路を一度にすべて変更しないでください。
Clashクライアントをダウンロード 各プラットフォーム対応版を確認