mihomoと従来版Clashのカーネルの違い：新規プロトコル・ルールセット構文・TUN実装を比較

カーネル・クライアント・Clash Premiumを区別する

カーネルを比較する前に、3つの役割を整理しましょう。カーネルは設定の読み込み、プロキシ接続の確立、DNS処理、ルール判定を担います。デスクトップやモバイルのクライアントは、設定管理、トレイメニュー、サブスクリプション更新、権限の要求を担当します。サブスクリプションにはノード、プロキシグループ、ルールが含まれます。クライアント名にClashが付いていても、従来版Clashを実行しているとは限らず、mihomoの設定すべてに対応するわけでもありません。

従来版ClashのオープンソースカーネルとClash Premiumも、同じ機能セットではありません。Premiumは元プロジェクトが提供していたクローズドソースの拡張カーネルで、過去にはTUNやルールセットなどの拡張機能を備えていました。mihomoはClash Metaを引き継ぐオープンソースカーネルです。Clash風のYAML設定構造を多く残しながら、プロトコル、ルーティング、DNS機能を拡張し続けています。元プロジェクトはすでにメンテナンスを終了しています。移行時は古いクライアント名を機能一覧とみなさず、実際のバイナリのバージョンを確認してください。

コマンドで実際のバージョンを確認

mihomo -v
mihomo -t -d ./mihomo-data -f ./config.yaml

1つ目のコマンドで現在のバイナリのバージョン情報を確認し、2つ目で作業ディレクトリと設定ファイルを指定して設定テストを実行します。対象のファイルはあらかじめ存在している必要があります。テストに合格しても、設定を読み込めたことを示すだけで、ノードが使えるとは限りません。GUIクライアントが内蔵カーネルを使う場合、ターミナルのmihomoとクライアントが起動するファイルは異なることがあります。クライアントのログも確認してください。

追加プロトコル：VLESS、REALITY、Hysteria2

mihomoと旧カーネルの最もわかりやすい違いは、サブスクリプション内のノード種別とパラメーターを認識できるかどうかです。従来版Clashで一般的なプロトコルには、Shadowsocks、VMess、Trojan、SOCKS、HTTPがあります。mihomoはVLESS、Hysteria2、TUICなどに対応し、特定のプロトコル構成ではREALITYも利用できます。YAMLのtypeを書き換えるだけで、旧ノードを別のプロトコルに変換できるわけではありません。サーバー側に対応する接続先が必要です。

プロトコル対応とネットワーク環境を分けて判断する

Hysteria2とTUICはQUICをベースとしており、接続にはUDPが必要です。LAN、ファイアウォール、通信事業者の回線でUDPが制限されていると、設定テストに合格してもハンドシェイクがタイムアウトすることがあります。VLESSが使えるかどうかは実際の通信方式を踏まえて判断してください。すべてのVLESSノードでネットワーク上の挙動が同じとは限りません。プロトコル名だけで低遅延や高スループットが保証されるわけでもありません。

• 未対応のノード種別と表示される：クライアントが実際にmihomoを起動しているか、サブスクリプションがそのカーネル向けに出力されているかを確認します。
• 認証失敗と表示される：UUID、パスワード、サーバーのプロトコルバージョンを確認します。まずDNSを変更するのは避けてください。
• TLSハンドシェイクエラーと表示される：システム時刻、SNI、証明書の要件を確認します。証明書検証の無効化を常用の解決策にしないでください。
• QUICノードがタイムアウトし続ける：別のネットワークでも試し、UDPの送信とサーバーの状態を確認します。

rule-providers：基本構造を維持しつつbehaviorとformatを確認

rule-providersはmihomo独自の機能ではなく、Clash Premiumもこの仕組みに対応しています。移行時は通常、「ルールセットを宣言し、RULE-SETで参照する」という基本構造をそのまま使えます。ルールセットはマッチ対象を定義し、rules内の参照は一致した場合に適用するポリシーを指定します。両者を混同しないでください。

ローカルのdomainルールセットの例

以下の設定例は既存の設定に統合して使います。例のドメインルールはDIRECTに送られ、ノード名には依存しません。作業ディレクトリにrules/local-domains.yamlが必要です。すでにrule-providersやrulesがある場合は内容を統合し、同じトップレベルキーを重複して作成しないでください。

rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,DIRECT

rules/local-domains.yamlの内容：

payload:
  - '+.example.com'
  - 'intranet.example.net'

+.example.comは、そのドメインとサブドメインに一致します。この例ではフォールバック先にDIRECTを指定しており、参照方法のみを示しています。既存のサブスクリプションをそのまま置き換えられるプロキシ設定ではありません。実際に移行する際は、自分のプロキシグループと末尾のフォールバックルールを残してください。

3種類のbehaviorは相互に置き換えられない

• domain：エントリーにはドメイン、または対応するドメインのマッチ式を記述します。DOMAIN-SUFFIXのプレフィックスは付けません。
• ipcidr：エントリーには192.168.0.0/16のようなアドレス範囲を記述します。ルール文全体を記述する形式ではありません。
• classical：エントリーにはDOMAIN-SUFFIX,example.comのようなルール式を記述します。通常、エントリー末尾にポリシー名は付けません。

DOMAIN-SUFFIX,example.comをbehavior: domainのファイルに記述すると、YAMLのインデントが正しくても内容の形式が一致しません。ルールセットを確認する際は、プロバイダーの宣言とダウンロード後のファイルの両方を確認してください。ファイルの拡張子だけでは判断できません。

mihomoで拡張されたルールセット形式

mihomoはYAML、プレーンテキスト、MRSなどのルールセット形式に対応しています。MRSはルールセット用のバイナリ形式で、domainとipcidrに利用できますが、classicalには使えません。旧Premiumの設定がMRSをそのまま読み込めるとは限りません。こうした形式を導入する前に、使用中のmihomoのバージョンとルールソースの説明を確認し、新しい設定項目を古いカーネルにコピーしないようにしてください。

ルールは引き続き上から順に判定されます。ルールセットの参照より前にMATCHを置くと、それ以降のルールは通常、判定されません。振り分けの誤りを調べる際は、プロキシグループで現在選択されているノードだけでなく、接続の詳細に表示されるマッチルールと実際のポリシーを確認してください。

TUNの仕組み：スタック選択、ルート制御、システム権限

システムプロキシとTUNは、通信を受け取る入口が異なります。システムプロキシでは、システム設定に従うアプリがプロキシポートへ接続します。TUNは仮想ネットワークインターフェースを作成し、ルーティングルールと組み合わせてIPトラフィックを受け取ります。TUNはシステムプロキシに従わないアプリにも適していますが、特定の接続を捕捉できるかどうかは、ルート、インターフェースの選択、除外設定、OSの権限にも左右されます。

従来版Clashのオープンソース版とPremiumでは、TUN機能の範囲が異なります。「ClashならすべてTUNに対応している」と一括りにはできません。Premiumの過去のTUN方式はgVisorスタックに関連していました。mihomoではsystem、gvisor、mixedなどのスタックを選べます。対応状況はプラットフォームとバージョンによって異なるため、別のカーネル向けのTUN設定をそのまま流用しないでください。

デスクトップ環境向けの設定例

mixed-port: 7890
allow-lan: false
mode: rule

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

ここでの7890は混合プロキシポートの例であり、すべてのクライアントに共通する固定値ではありません。auto-routeはルートの自動設定に使い、auto-detect-interfaceは送信インターフェースの選択を補助します。どちらも権限の許可に代わるものではありません。Windowsでは通常、クライアントサービスや昇格の仕組みが必要です。Linuxでは適切なネットワーク管理権限が必要で、macOSではクライアントの実装に応じた認証が必要です。

1. ほかのVPNやプロキシクライアントのTUNを無効にして、ルーティングの競合を減らします。
2. まずシステムプロキシが使えることを確認してからTUNを有効にし、一度に複数の要因を加えないようにします。
3. ログを確認し、仮想インターフェースの作成失敗、ルート追加の失敗、権限不足がないか調べます。
4. Wi-Fi、有線ネットワークへの切り替え後やスリープ復帰後に、送信インターフェースとルートを再確認します。

DNSとFake-IP：仕組みを維持し、名前解決の経路を再確認

Fake-IPはmihomoで初めて導入された仕組みではありません。アドレスを割り当ててドメインと接続を関連付け、カーネルがドメインベースのルールを判定できるようにします。移行時に確認すべきなのは、DNSリクエストがカーネルに届いているか、実IPで応答する必要があるドメインはどれか、プロキシサーバーのドメインがどの経路で名前解決されるかです。

DNSとTUNを分けて検証する

dns:
  enable: true
  listen: 127.0.0.1:7874
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - 'localhost'
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

以下は名前解決の動作例です。DNSはローカルの7874で待ち受け、Fake-IPには198.18.0.1/16の範囲を使い、上流にはIPv4のDNSアドレスを2つ指定しています。上流はネットワーク環境やプライバシー要件に応じて選んでください。ここに示した値がすべての回線に適しているとは限りません。fake-ip-filterはFake-IPの割り当てを除外するだけで、強制的に直接接続するルールではありません。また、ローカルDNSサーバーの設定に代わるものでもありません。

digをインストールした環境では、カーネルのDNSに直接問い合わせできます。

dig @127.0.0.1 -p 7874 example.com A

フィルターに一致しない場合、応答には通常、設定した範囲内のマッピングアドレスが含まれます。これは想定された動作であり、DNSサーバーが誤ったグローバルIPアドレスを返したわけではありません。その後、対象ドメインにアクセスし、カーネルの接続ログでドメインと関連付けられ、想定したルールに一致しているか確認します。

暗号化DNSとノードのドメイン解決

• ブラウザー独自のDoH：ブラウザーがシステムのDNS経路を迂回することがあります。調査時はまず名前解決の入口を統一し、挙動を比較してください。
• TUNによるDNSの横取り：any:53は従来型のDNSトラフィックを対象とします。すべてのDoHやDoTリクエストを自動的に捕捉できるわけではありません。
• ノードのドメイン解決：mihomoではproxy-server-nameserverを使ってプロキシサーバーのドメイン解決に使うリゾルバーを指定でき、起動時に名前解決経路が相互依存する問題を抑えられます。
• ルールに基づくDNSの送信：respect-rulesなどの設定でDNS接続のルーティング動作が変わります。使用中のバージョンの説明に従って関連設定を行い、スイッチを1つ有効にするだけで済ませないでください。

LAN内のサービスにアクセスできない場合は、ローカルドメインのサフィックス、ルーターのDNS、ネットワーク範囲のルールを確認してください。*.lanを追加するだけでは、社内で使われるすべてのドメインをカバーできません。拡張モードに切り替えた後は、ブラウザー、OS、アプリのキャッシュも考慮してください。古いキャッシュに残ったマッピングアドレスがしばらく使われることがあります。

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

移行ではすべてのルールを書き直すのではなく、旧カーネルに依存する部分を特定することが重要です。基本的な設定項目、従来型ノード、ルール文の多くは出発点として使えますが、Premiumのスクリプト設定、古い実験的な項目、特定のTUNパラメーターはそのまま残さないでください。mihomoはPremiumのスクリプトインターフェースをそのまま置き換えるものではありません。

1. 設定と実行環境を保存する：現在使えているYAMLを保管し、待ち受けポート、選択中のプロキシグループ、システムプロキシ、TUNの状態を記録します。サブスクリプションのURLは安全な場所に保管し、公開しないでください。
2. サブスクリプションの出力形式を確認する：サービス提供元が用意しているmihomoまたはClash Meta形式を優先します。ノードにVLESSやHysteria2が含まれる場合は、プロトコルのパラメーターがそろっているか確認してください。
3. 設定をテストする：mihomo -tを実行し、未対応のプロトコル、フィールドの型、ルールファイルのパス、ポリシー名のエラーを先に解消します。
4. システムプロキシだけを検証する：TUNを無効にし、ポートを指定してノードとルールを確認します。実際のポートが7890なら、プロキシ対応アプリで127.0.0.1:7890を指定できます。
5. ルールセットを確認する：behavior、format、ローカルファイルの内容、ルールの順序を確認し、参照先のプロキシグループが実在することを確かめます。
6. DNSとTUNを個別に有効にする：権限、インターフェース、ルート、名前解決の順に問題を切り分けます。一度に変更する設定は1つにし、比較できるようログを残してください。
7. クライアントによる上書きを確認する：最終的な実行設定を確認します。クライアントがポート、DNS、TUN、ルールを統合することがあります。サブスクリプションの元ファイルを編集しても、実際の設定に反映されるとは限りません。

再現可能な条件で速度を比較する

プロトコルの拡張で自動的に通信速度が上がるわけではありません。2つのカーネルを比較する際は、ノード、テスト対象、ネットワーク、時間帯をそろえ、単一接続でのダウンロード速度、同時接続時の性能、CPU使用率を記録します。遅延テストでわかるのは指定した対象への1回のリクエストにかかった時間です。大容量ダウンロード時のスループットを示すものではなく、すべてのサイトが同じ経路を使っている証明にもなりません。

新しいプロトコル、継続的に更新されるルールセット機能、細かなDNS設定が必要なら、mihomoを優先して確認してください。従来型プロトコルとシンプルなシステムプロキシで十分な場合は、クライアントのメンテナンス状況、現在のOSとの互換性、設定管理のしやすさを重視します。Fake-IP、プロキシグループ、ルールセットの概念は用語集で確認し、設定ガイドに沿って順番に検証してください。