mihomoとオリジナルClashコアを比較｜対応プロトコル・rule-providers・TUNの違い

オリジナルのオープンソースコア、Premium、mihomoを区別する

結論として、mihomoはClashの設定体系を引き継いでいますが、名前だけが変わった同一のバイナリではありません。mihomoはClash.Metaの開発路線を継承し、対応プロトコルやルール、トラフィック制御機能を拡張しています。移行時は基本的な設定項目を引き継げる場合が多いものの、新しい設定を旧コアで読み込めるとは限りません。

「オリジナルClash」には、オリジナルのオープンソースコアと、当時のClash Premiumという2つの対象がある点にも注意が必要です。PremiumにはルールセットやTUNなどの拡張機能がありました。これらを一括りにして「Clashはrule-providers非対応で、TUNに対応するのはmihomoだけ」と説明すると、実態と異なります。

• クライアント：画面表示、サブスクリプション管理、システムプロキシの切り替え、コアの起動を担当します。クライアントのバージョンとコアのバージョンは別です。
• コア：設定の読み込み、プロキシ接続の確立、DNSの解決、ルールの適用を担当します。実際に利用できる設定項目は、実行中のコアによって決まります。
• サブスクリプション変換：変換先のコアに応じて、異なるノード設定を生成する場合があります。出力形式は変換できますが、旧コアに新しいプロトコルの実装を追加することはできません。

まずクライアントのコア情報や起動ログで名称を確認し、実際の実行ファイルも調べてください。以下のコマンドは単体で実行するバイナリ向けです。GUIクライアントに内蔵されたファイルは別の名称の場合があるため、確認のために別のコアを起動しないでください。

mihomo -v
clash -v

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

Shadowsocks、VMess、Trojanなどは、どちらの系統でも広く使われるプロトコルです。mihomoはVLESS、Hysteria2、TUICなどにも対応しています。具体的なトランスポートの組み合わせやパラメーターは、使用中のコアのドキュメントで確認してください。オリジナル版も過去のビルドごとに差があるため、特定の旧バージョンの結果をすべてのビルドに当てはめることはできません。

移行時はノードのレイヤー4設定を確認

1. プロトコルの種類：まずtypeを確認します。たとえばvlessやhysteria2です。コアがその種類を認識しない場合は、コアを変更するか、サブスクリプションの出力先を変更してください。
2. 認証情報：パスワード、UUID、認証フィールドを確認してください。VMessノードのタイプをVLESSに変更するだけでは、プロトコルを変換できません。
3. トランスポート：WebSocketやgRPCなどの設定がサーバー側と一致しているか確認します。特にパス、Host、サービス名に注意してください。
4. TLSパラメーター：サーバー名、証明書の検証設定、REALITYのパラメーターを確認してください。証明書検証を無効にして問題を回避しないでください。

Hysteria2とTUICはQUICベースの通信を使うため、ネットワークで該当するUDP通信が許可されている必要があります。設定テストに成功しても、確認できるのは項目を読み込めたことだけです。外向き通信でUDPが制限されていれば、接続に失敗することがあります。コアを変更しても、ネットワーク側の制限は解消されません。

rule-providers：まずbehavior、次にファイル形式を確認

rule-providersはルールセットを読み込むためのもので、ノードのサブスクリプションではありません。ノードプロバイダーにはproxy-providersを使います。ルールセットを定義した後、rules内でRULE-SETを使って参照する必要があります。参照しなければルール判定に使われません。

Premiumからmihomoへ移行する場合、既存の一般的なYAMLルールセットはそのまま使えることが多いです。behaviorとファイルの内容が一致しているかを重点的に確認してください。classicalには完全なルール式、domainにはドメインの照合項目、ipcidrにはIPネットワークを記述します。定義だけ変更して、異なる形式の内容を混在させることはできません。

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

以下の断片を既存のメイン設定に追加してください。Proxyはポリシーグループ名の例です。実際に存在するグループ名に置き換えるか、元の設定でグループを定義してください。パスはコアの作業ディレクトリからの相対パスであり、GUIクライアントのインストール先からの相対パスとは限りません。

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

rules:
  - RULE-SET,local-sites,Proxy
  - MATCH,DIRECT

rules/local-sites.yamlを作成し、以下の内容を記述します。example.comは例示用のドメインです。実際に使う際は、振り分けたいドメインに置き換えてください。

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

• format: yamlのルールファイルにはpayloadが含まれます。プレーンテキスト形式では、形式の指定に従って項目を1行ずつ記述してください。YAMLの構造で囲むことはできません。
• mihomoのmrsはバイナリ形式のルールセットです。domainとipcidrに使用でき、任意のclassicalファイルの拡張子を変えるだけでは利用できません。
• HTTPタイプのプロバイダーには、実際にアクセス可能なurlも必要です。interval: 86400は更新間隔が86400秒であることを表し、接続タイムアウトではありません。
• ルールは引き続き上から順に評価されます。広い範囲に一致するルールを先に置くと、後続の詳細なルールが適用されないことがあります。通常、MATCHは最後に置きます。

ドメインスニッフィング：ドメイン情報を補完する機能であり、HTTPSを復号するものではない

IPアドレスへの接続には、ドメインルールとの照合に使える宛先名が含まれないことがあります。mihomoのsnifferは、HTTP Host、TLSハンドシェイク内のサーバー名、識別可能なQUICハンドシェイク情報からドメインを抽出し、通信の振り分けを補助します。HTTPSの復号機能ではなく、すべての接続からドメインを特定できるわけでもありません。

以下はmihomoのスニッフィング設定例です。まずはoverride-destination: falseのままルールの適用状況を確認し、その後、接続先を上書きする必要があるか判断してください。すべての設定で有効にする必要がある項目ではありません。

sniffer:
  enable: true
  override-destination: false
  sniff:
    HTTP:
      ports: [80, 8080-8880]
    TLS:
      ports: [443, 8443]
    QUIC:
      ports: [443, 8443]

スニッフィングとFake-IPの違い

• Fake-IPはDNSでドメインと合成IPの対応関係を保持します。一方、スニッフィングは接続内容からドメインを抽出します。情報の取得元は異なります。
• プログラムにIPアドレスがハードコードされている場合、識別できないプロトコルが使われている場合、またはハンドシェイク情報が暗号化されている場合、スニッフィングで有効なドメインを取得できないことがあります。
• ドメインルールを使いたいのに宛先IPしか確認できない場合は、スニッフィングの範囲を広げる前に、DNSがコアで処理されているか、マッピングが有効かを確認してください。その後、スニッフィングの設定を調べます。

移行後に一部のサイトだけで問題が起きる場合は、比較のため一時的にスニッフィングを無効にできます。変更は一度に1項目にし、接続詳細で宛先ドメイン、適用ルール、出口ポリシーを確認してください。スニッフィング、DNS、ノードの問題を混同しないためです。

TUN機能：プロトコルスタック、ルーティング、DNS制御を個別に確認

TUNは仮想ネットワークインターフェースに通信を流します。システムHTTPプロキシとは異なり、システムプロキシ設定に従わないアプリも、ルーティングによってTUNを通る場合があります。オリジナルのPremiumにもTUN機能があり、mihomoはこの分野をさらに拡張しています。「TUN対応」自体をmihomoだけの機能とみなすことはできません。

mihomoのTUN設定では、system、gvisor、mixedなどのスタックを選択できます。利用可否はプラットフォームとビルドによって異なります。mixedはシステムのTCPスタックとgVisorのUDPスタックを組み合わせます。スタック名は速度の順位を示すものではありません。問題がある場合は、同じネットワークと同じノードで比較してください。

最小構成のTUN確認用設定

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

これは既存の設定に追加するTUN部分のみの例であり、有効なdns設定も必要です。auto-routeはルートの自動設定に、auto-detect-interfaceは出口インターフェースの自動検出に使います。複数のVPNや仮想NICを併用している場合、自動検出の結果を必ず確認してください。

1. まず権限を確認：Windowsでは通常、クライアントのサービスまたは管理者権限を使って仮想インターフェースを設定します。Linuxでは適切なネットワーク管理権限が必要です。権限エラーをノードの障害と混同しないでください。
2. 次にルーティングを確認：仮想インターフェースが作成され、対象の通信が実際にコアへ届いているか確認します。ログに接続記録がまったくない場合は、まずトラフィックの経路を調べてください。
3. DNSは個別に確認：any:53は、通信制御経路に入った通常のポート53のDNSを対象とします。ブラウザー内蔵のDoHはHTTPSで通信するため、この設定だけで自動的にコアのDNSクエリへ切り替わることはありません。
4. 最後にUDPを確認：UDPの利用可否は、ノードのプロトコル、サーバー、外向きネットワーク、クライアントアプリの影響を受けます。Webページを開けても、ゲームや音声通話が正常に動作するとは限りません。

旧設定の移行：段階的に読み込み、切り戻し手段を確保

最も安全な手順は、まず設定の読み込みを確認し、次に通常のプロキシを検証してから、DNS、ルールセット、TUNを有効にすることです。コアを入れ替えて新機能も一度に有効にすると、失敗時にどの層の変更が原因か特定しにくくなります。

手順1：実際に適用される設定をテスト

以下のコマンドはconfig.yamlを検査します。クライアントで上書き、スクリプト、設定のマージを行っている場合は、サブスクリプションから取得した元ファイルではなく、最終的に生成された実行用ファイルを検査してください。

mihomo -t -f config.yaml

未知のプロキシタイプが見つかった場合は、サブスクリプションの出力先がmihomoか確認します。存在しないポリシーが見つかった場合は、ルールの参照先とポリシーグループ名を確認します。ルールセットの読み込みに失敗した場合は、作業ディレクトリ、ファイルパス、形式を確認してください。テストに成功しても、ノード認証、ネットワーク接続、リモートルールセットの更新まで成功したとは限りません。

手順2：通常のプロキシで基準状態を確認

まずTUNを無効のままにし、既存設定のmixed-portを使います。値が7890の場合は、以下のリクエストを実行してください。ここではHTTPプロキシを明示し、システムプロキシの設定による影響を除外します。

curl -I --proxy http://127.0.0.1:7890 https://example.com

レスポンスが返るか、接続ログが記録されるか、どのルールが適用されたかをあわせて確認してください。このテストで確認できるのは現在のHTTPプロキシ経路だけです。UDPの動作や、すべてのアプリが通信制御されていることは確認できません。ポートが旧プロセスに使用されている場合は、先に旧コアを終了してください。複数のポートを同時に動かすために、むやみに設定を変更しないでください。

手順3：拡張設定を一つずつ戻す

1. ルールセットを戻し、各RULE-SETの参照先とダウンロード状況を確認します。
2. DNS設定を戻し、enhanced-mode、nameserver、nameserver-policyで実際にどの経路が使われるか確認します。
3. 必要に応じてスニッフィングを有効にし、宛先ドメインと適用ルールを照合します。
4. 最後にTUNを有効にして、インターフェース、ルーティング、DNS、UDPを確認します。

旧コアで読み込める設定のコピーを保管してください。切り戻す際は、バイナリだけでなく、対応するルールセット形式と設定項目も元に戻す必要があります。新しいコアが生成した設定で、唯一の旧設定バックアップを上書きしないでください。

選定のポイントと参考資料

既存の設定が基本的なプロトコルと通常のルールだけを使う場合は、メンテナンス状況、プラットフォーム対応、クライアントとの連携を重視して移行を検討してください。VLESS、Hysteria2、TUIC、mrs、詳細なスニッフィング設定が必要な場合は、mihomoを採用し、必要な機能を提供するクライアントを選びましょう。クライアント画面にボタンが表示されていても、選択中のコアがその機能を実行できるとは限りません。

この記事では機能の対応範囲を比較しており、特定のリリースの挙動を恒久的な結論として扱っていません。プラットフォームの制約、設定項目の初期値、新しいプロトコルのパラメーターについては、実際にインストールしたバージョンと対応ドキュメントを確認してください。以下の資料は、プロジェクト情報、設定項目の定義、変更履歴の確認に利用できます。

• mihomoプロジェクトのリポジトリ：プロジェクト概要、ソースコード、課題の追跡。
• mihomoルールセット設定ドキュメント：プロバイダーの種類、behavior、ファイル形式。
• mihomo TUN設定ドキュメント：スタック、ルーティング、プラットフォーム固有のオプション。
• mihomoドメインスニッフィングのドキュメント：対象プロトコルと宛先の上書き設定。
• mihomoリリース履歴：使用中のバージョンに応じて、修正内容や挙動の変更を確認できます。

設定全体の構造を確認するには、当サイトの応用設定をご覧ください。初回インストールやサブスクリプションの追加は、入門ガイドに沿って進められます。移行後は「設定を読み込める」「ノードに接続できる」「ルールが正しく適用される」「通信制御の範囲が想定どおり」の4点を確認してください。