mihomoとオリジナルClashの違い｜追加プロトコル・ルールセット・TUN機能を解説

クライアント・コア・設定ファイルの違い

「サブスクリプションのインポートには成功したのに、ノードに接続できない」場合も、すぐにサブスクリプションを変更する必要はありません。GUIクライアントはサブスクリプション管理や画面表示、システム設定を担当し、コアは設定の解析、プロキシ接続の確立、通信の振り分けを担当します。画面にノード名が表示されていても、バックグラウンドのコアがそのプロトコルに対応しているとは限りません。トラブル時は、クライアント画面のバージョン番号だけでなく、ログに記録されたコア名とバージョンを確認しましょう。

mihomoは、旧Clash Metaプロジェクトが名称変更した後のコアで、Clashの設定体系を引き継ぎながら機能を拡張しています。「オリジナルClash」を比較する場合は、過去のオープンソース版コアと、クローズドソースのPremium版コアを区別する必要があります。両者の機能は同一ではなく、特にルールプロバイダーやTUNには違いがあります。ひとまとめにすると、「旧Clashにはルールセットが一切なかった」といった誤解につながります。

独立したコアを直接実行している場合は、mihomo -vでバージョンを確認できます。GUIクライアントでは、コア情報または起動ログで実際に読み込まれたバイナリを確認してください。画面のアプリを更新しても、想定したコアに切り替わっているとは限りません。

追加プロトコル：ノードの接続可否を左右するポイント

過去のオリジナルClashと比べたmihomoの大きな違いの一つは、VLESS、Hysteria2、TUICなど、より多くのプロキシプロトコルと伝送方式の組み合わせに対応していることです。これらは同じプロトコルの別名ではなく、設定のtypeを書き換えるだけで相互に変換できるものでもありません。サーバー側で使われているプロトコルに合わせて、認証、伝送方式、TLSの各パラメーターを設定する必要があります。

VLESSとREALITYは別々に確認

VLESSはプロキシプロトコルで、REALITYは関連する接続で利用できるセキュリティ機構です。同じ意味ではありません。VLESSノードは通常のTLSを使う場合も、REALITYを使う場合もあります。組み合わせによってはnetwork、servername、flow、reality-optsなどの設定項目が関係します。サーバー側で指定されたパラメーターに従って設定し、VLESSだからといってREALITYの設定を独自に追加しないでください。

• UUID：VLESSのユーザー認証に使います。他のプロトコルのパスワードで代用することはできません。
• サーバー名：servernameはTLSハンドシェイクに関係します。誤った値を設定すると、証明書エラーやハンドシェイクエラーが発生する可能性があります。
• REALITYのパラメーター：公開鍵やShort IDなどはサーバー側の設定と一致させる必要があります。ノード名が同じでも、設定値が一致しているとは限りません。
• 伝送方式：TCP、WebSocket、gRPCなどの設定はクライアントとサーバーで一致させる必要があります。一方の設定項目だけを変更しても接続できません。

Hysteria2とTUICはUDP経路が必要

Hysteria2とTUICはQUICベースの伝送方式を使うため、サーバーへの接続には利用可能なUDP経路が必要です。現在のネットワークでUDPが制限されている場合、通常のHTTPSサイトを開けても、これらのノードに接続できるとは限りません。その場合はルールモードを何度も変更するのではなく、ログでタイムアウト、認証、TLSのエラーを確認してください。

Hysteriaの初代とHysteria2も互換性はありません。サブスクリプション変換で第2世代のノードが初代の形式に出力されたり、必要な認証パラメーターが欠落したりした場合、プロキシグループを変更しても解決しません。サブスクリプションサービスが明示的に提供するmihomo対応設定を選び、生成後のノードタイプを確認するのが確実です。

ルールセット：ルールを再利用し、マッチ順を制御

rule-providersを使うと、ルールを独立したリソースとして管理し、メインルールからRULE-SETで参照できます。これはmihomo独自の機能ではなく、過去のClash Premiumにも同様の機能がありました。mihomoでは、この仕組みを基に対応形式やマッチング機能が拡張されています。利用できる設定項目は、実行するコアのバージョンによって異なります。

3種類のルール形式を使い分ける

• domain：ドメインの一覧に使います。DOMAIN-SUFFIX,example.orgのような形式を、通常のドメイン名としてそのまま入れないでください。
• ipcidr：IPアドレスの範囲に使います。例：192.168.0.0/16。
• classical：ルールタイプを含む形式を使います。例：DOMAIN-SUFFIX,example.org。

以下はプロキシノードを含まないローカルルールセットの例です。前半を既存の設定に追加してください。パスはコアの実際の作業ディレクトリを基準に解決されるため、そのディレクトリに後半で示すファイルがあることを確認してください。参照方法を示す例であり、サブスクリプション設定一式の代わりにはなりません。

rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

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

rules/local-direct.yamlの内容は次のとおりです。予約済みのサンプルドメインとプライベートネットワークをそれぞれマッチします。

payload:
  - DOMAIN-SUFFIX,example.org
  - IP-CIDR,192.168.0.0/16,no-resolve

実際に移行する際は、最終的に使うポリシーを維持してください。例のMATCH,DIRECTをそのままコピーしても、通信がプロキシ経由になるわけではありません。ルールは通常、上から順に評価されます。広範囲を対象とするDIRECTルールを先に置くと、後続のプロキシルールにマッチしなくなります。参照するプロキシグループ名が実際に存在することも確認してください。大文字・小文字や空白も一致させる必要があります。

ルールセットの形式は自由に置き換えられない

mihomoが対応するMRSバイナリルール形式には用途の制限があり、主にdomainとipcidrの動作に使います。任意のclassicalファイルを拡張子だけ変更して使うことはできません。リモートルールセットのintervalは秒単位で、たとえば86400は1日を表します。これはルールリソースの更新間隔であり、クライアントのサブスクリプションProfileの更新間隔とは異なります。

TUN機能の強化：通信の制御範囲が広がる一方、切り分け項目も増加

システムプロキシの影響を受けるのは、主にプロキシ設定に従うアプリです。一方、TUNは仮想ネットワークインターフェースとルーティングを使って、より多くのIP通信を制御します。システムプロキシを参照しないアプリへの対応に適しています。過去のPremium版にもTUN機能があったため、「旧版にはなく、新版で初めて追加された」と単純化するのは正確ではありません。mihomoでは、継続的に保守されているTUNの実装、ネットワークスタックの選択、ルーティングやDNSと連携する設定が主なポイントです。

スタック・ルーティング・DNSの役割を分けて確認

LinuxでTUNデバイスを作成し、ルートを変更するには適切な権限が必要です。GUIクライアントでは、インストール済みの特権サービスを介して操作する場合があります。独立したコアを使う場合は、権限とサービスの管理を自分で行う必要があります。権限エラーが発生したら、ノードを何度も切り替えるのではなく、サービスの状態やログ、/dev/net/tunが利用可能かを先に確認してください。

以下は一般的なTUN設定の一部です。既存のDNS、ノード、ルール設定に統合してからテストしてください。DNSのリスナー設定一式は含まれておらず、すべての環境で自動ルーティングをそのまま有効にできるわけではありません。

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

設定の互換性：読み込めても動作が同じとは限らない

proxies、proxy-groups、rulesなどの基本構造は引き続き使えますが、設定をコピーするだけで移行できるとは限りません。古い設定項目の推奨記述が変わっていたり、新しい項目が旧コアで拒否または無視されたりすることがあります。構文チェックを通過しても、DNS、プロキシグループの選択、プロセス判定の結果は実際に確認してください。

通信を制御する前に設定ファイルを検証

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

2つ目のコマンドは設定チェック用で、ネットワーク全体の疎通を確認するものではありません。チェックに通った後も、ノードとのハンドシェイク、DNS名前解決、通信の振り分けを確認してください。GUIクライアントでは、起動前にサブスクリプションを結合または上書きする場合があります。手元で確認した元のYAMLと、最終的にコアへ渡される実行設定が同じとは限りません。

1. リスニングポートを確認：たとえばmixed-port: 7890を使う場合、ブラウザーやシステムプロキシの接続先も、古い設定の別ポートではなくローカルの7890に設定されていることを確認してください。
2. コントローラーのポートを確認：external-controllerはプロキシポートとは用途が異なります。127.0.0.1:9090を使う場合、9090は管理用インターフェースであり、ブラウザーがインターネットに接続するためのHTTPプロキシポートではありません。
3. サブスクリプションの内容を確認：ノード一覧だけのサブスクリプションには、プロキシグループ、DNS、ルールが含まれていない場合があります。クライアントがそれらをどのように補完するか、設定の結合方法を確認してください。
4. ローカルの上書き設定を確認：カスタムルール、ポート、DNSは、クライアントが提供する永続的な上書き機能に設定してください。リモートのサブスクリプションファイルを直接編集すると、更新時に上書きされる可能性があります。

DNSとプロセスルールを個別に検証

fake-ipとredir-hostはDNSの処理モードであり、プロキシモードではありません。コアの切り替えと同時にDNSモード、上流DNSサーバー、TUNの設定も変更すると、問題の原因を特定しにくくなります。まずは従来のDNS設定を維持して基本的な接続を確認し、その後で項目を一つずつ変更してください。

プロセス名やプロセスのパスを使うルールは、システムとコアの対応状況や、接続情報を正しく取得できるかにも左右されます。ルールの記述が正しくても、プロセスを識別できずマッチしないことがあります。接続ログのプロセス情報と適用されたルールを確認し、マッチしない原因をすべてルールの順序に求めないでください。

移行時の検証：変更する条件は一度に一つだけ

移行では、どの機能が追加され、既存の設定が想定どおりに動作するかを確認します。以下の順で一つずつ検証し、それぞれ結果を記録してから次に進みましょう。拡張機能を一度にすべて有効にするより、問題を特定しやすくなります。

1. バックアップ：元のProfile、ローカルルール、上書き設定に加え、使用中のポートとDNS設定を保存してください。サブスクリプションURLにはアクセス用の認証情報が含まれる場合があるため、全体を公開ログに貼り付けないでください。
2. 基本のプロキシ接続：まずTUNを無効にし、接続可能と確認済みのノードを使って、ローカルの7890番ポート経由でテストします。プロトコルや認証のエラーを切り分けます。
3. ルールの検証：DIRECTにすべきサイトとプロキシ経由にすべきサイトへそれぞれアクセスし、ページが開くかだけでなく、接続ログに表示されるマッチしたルールと最終的なポリシーを確認します。
4. ルールセットの読み込み：providerの読み込み状態を確認します。ファイルパスの誤り、ダウンロード失敗、ルール項目の形式エラーはそれぞれ別の問題です。ログに応じて個別に対処してください。
5. TUNによる通信制御：最後にTUNを有効にし、システムプロキシに従わないアプリで動作を確認します。LANへのアクセス、他のVPN、ネットワーク切り替えも検証してください。
6. サブスクリプションの更新：一度手動で更新し、カスタム設定が保持されていることを確認してから、自動更新を設定してください。

移行する価値があるかは、実際のニーズで判断できます。サブスクリプションにVLESSやHysteria2などのノードが含まれている場合や、より細かなルールと継続的に保守されるTUN機能が必要な場合は、mihomoのメリットが明確です。現在の接続に問題がある場合は、ノード障害、設定ミス、システムのネットワーク競合をまず切り分けてください。コアの変更で機能不足は補えますが、サーバー側のパラメーターやローカルルートの確認に代わるものではありません。

設定項目やルールについて詳しくはコアと設定のリファレンスをご覧ください。仮想インターフェースを初めて設定する場合は、TUNモードの設定ガイドに沿って、権限と通信の制御範囲を確認してください。