mihomoの新機能とは？旧Clashとの違いを設定別に解説

比較対象：旧Clash、Premium、mihomo

mihomoは、Clash Metaプロジェクトの改称後に使われているコアの名称です。ClashのYAML設定を引き継ぎながら、アウトバウンドプロトコル、ルール表現、DNS、トラフィックの取り込み機能を拡張し続けています。クライアント画面に「Clash」や「Meta」と表示されていても、実際に旧Clashが動作しているとは限りません。画面上の名称、設定形式、コアの名称は分けて確認しましょう。

この記事でいう「旧Clash」は、元のプロジェクトがメンテナンスを終了する前のオープンソース版コアを指し、Clash Premiumの機能は含みません。PremiumにはTUNやルールプロバイダーなどの拡張機能がありました。そのため、「旧オープンソース版にこの機能がない」ことから「過去のすべてのClash派生版にもなかった」とは言えません。この区別は、古い設定を移行する際に特に重要です。

プロトコルの拡張：サブスクリプションのtypeと通信パラメーターを確認

違いを最も実感しやすいのは、対応するアウトバウンドプロトコルの追加です。旧コアでは type: hysteria2 や type: vless を読み込むと、プロキシタイプが未対応だと設定の読み込み時にエラーになることがあります。この場合、プロキシグループを変更したりルールの順序を調整したりしても解決しません。アウトバウンド接続自体を確立できていないためです。

VLESSとREALITYは、互換性のあるノードタイプではない

VLESSはプロキシプロトコルで、REALITYは対応するアウトバウンド設定で利用できるセキュアなハンドシェイク方式です。mihomoでは、通常VLESSノードを type: vless と指定し、REALITY関連の設定を reality-opts に記述します。ノードタイプを単に reality に書き換えても、同等の設定にはなりません。

• uuid は認証パラメーターです。サーバー側の設定と一致させてください。
• servername、reality-opts.public-key、short-id は、サーバーから提供された値を設定します。ドメイン名から推測してはいけません。
• flow、通信方式、フィンガープリントの各設定には組み合わせの制約があります。フィールドを1つ追加しただけで、既存のVMessノードをVLESSノードに変更することはできません。

Hysteria2とTUICではUDP通信が必要

Hysteria2とTUICはQUICをベースにしており、接続できるかどうかはコアの対応状況だけでは決まりません。利用中のネットワークでUDPが遮断または大幅に制限されている場合、TCPノードは使えても、これらのノードがタイムアウトすることがあります。HysteriaとHysteria2も、名前だけを変えればよい同一の設定ではありません。サブスクリプションに記載されたプロトコルタイプを使ってください。

たとえばサーバーが UDP 443 を待ち受けている場合、端末のファイアウォール、上位ネットワーク、サーバーのセキュリティグループで該当ポートが許可されているか確認します。ブラウザーで TCP 443 を使ってページを開けても、同じアドレスのUDP通信が使えるとは限りません。また、プロトコルを切り替えれば必ず速くなるわけではありません。回線のパケットロス、サーバーの処理能力、速度制限の設定によって結果は変わります。

ルールセットの拡張：設定内のrulesから独立したデータファイルへ

旧Clashにも、ルールを上から順に評価する仕組みがあります。mihomoでも「最初に一致したルールでアウトバウンドが決まる」という基本動作は変わりません。拡張されたのは、主にルールの取得元と表現方法です。rule-providers で外部ルールセットを管理し、RULE-SET から参照できます。また、AND、OR、NOT などの論理ルールで条件を組み合わせられます。

ローカルルールプロバイダーの最小構成

以下の2つのコードを、それぞれメイン設定ファイルとルールファイルとして保存します。例では DIRECT のみを使い、ルールの読み込み構造を確認します。プロキシノードは自動作成されません。作業ディレクトリに rules フォルダーを作成してファイルを置いてください。相対パスはコアの実行環境を基準に解決されるため、デスクトップで見えるサブスクリプションの保存先とは限りません。

# メイン設定の関連箇所
rule-providers:
  work-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/work-domains.yaml

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

# ./rules/work-domains.yaml
payload:
  - '+.example.com'
  - 'example.org'

behavior: domain は、ファイルの内容がドメイン照合用であることを示します。IP-CIDR,192.168.0.0/16 をそのまま混在させないでください。複数種類のルールを1つのルールセットにまとめる場合は、classical を選び、指定形式に沿って記述します。

• domain：ドメインのリストに適しています。
• ipcidr：IPアドレス範囲のリストに適しています。
• classical：複数種類のルールを含むルールセットに適しています。
• mrs：mihomoが対応するバイナリ形式のルールです。主にdomainとipcidrの動作モードで使われ、任意のYAMLファイルの拡張子を変更したものではありません。

ルールプロバイダーとプロキシプロバイダーも混同しないでください。rule-providers が提供するのは照合条件で、proxy-providers が提供するのはプロキシノードです。サブスクリプションの更新が成功しても、更新されたのは該当するリソースだけで、もう一方のリソースがダウンロードまたは有効化されたとは限りません。

GEOデータ：GEOIPはIPアドレス、GEOSITEはドメイン分類を照合

GEOIP ルールはmihomo独自の機能ではありません。旧Clashでも地域データに基づくIPアドレスの照合が可能でした。mihomoでは、GEOSITE などのデータを使った機能や、GEOデータの読み込み・更新方法が拡張されています。照合対象はそれぞれ異なるため、一方のキーワードをもう一方に置き換えても同じ結果にはなりません。

geodata-mode: true はGEOIPのデータ処理方式を切り替える設定で、通常は GeoIP.dat を使用します。もう一方の方式では、デフォルトでMMDBデータが使われます。GEOSITEは独自のドメイン分類データを使うため、GEOIPモードを有効にしても、すべてのドメイン分類が使えるわけではありません。データファイル、コアのバージョン、分類名をあわせて確認してください。

cn は、リアルタイムのネットワーク測定結果ではありません。データセットはメンテナーが整理しており、ドメインの分類やIPアドレス範囲の地域情報は、バージョンによって変わる可能性があります。意図しない振り分けが起きた場合は、まず実際に一致したルールとローカルデータの更新日時を確認し、そのうえで、より優先度の高い位置にドメインを個別指定したルールを追加するか判断してください。

TUNの拡張：取り込む範囲と全通信のプロキシ経由は別

システムプロキシの影響を受けるのは、通常、システムのプロキシ設定に従うアプリだけです。TUNは仮想ネットワークインターフェースとルーティングを使い、より多くのIP通信を取り込みます。mihomoのTUN機能は、システムプロキシを参照しないアプリにも適していますが、ルーティング、権限、ルールの影響を受けます。TUNを有効にしても、DIRECT に一致した通信は直接接続されます。

# 既存の正常に接続できるmihomo設定に追加
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1

この設定例は、通信の取り込みとDNSの関係を示すもので、プロキシノードは含みません。1053 は内蔵DNSの待ち受けポート、dns-hijack の 53 は横取りする従来型DNSの宛先ポートです。両方を同じ番号にする必要はありません。例にある上流DNSは説明用です。実際の環境では、接続可能でネットワークのポリシーに合ったDNSサーバーに置き換えてください。

stackと権限を分けて確認

• system、gvisor、mixed は、それぞれ異なるネットワークスタックの処理方式です。mixed では通常、TCPをシステムスタック、UDPをgVisorで処理します。利用できるかどうかは、使用中のプラットフォームとバージョンも確認してください。
• Windowsでは通常、管理者権限またはクライアントがインストールする特権サービスが必要です。Linuxでは適切なネットワーク管理権限を確認し、/dev/net/tun も確認してください。macOSではクライアントの案内に従って権限を許可します。
• auto-route はルーティング設定を変更します。他のVPN、仮想マシンのネットワーク、企業向け接続ツールと併用する場合は、まずもう一方の通信取り込み機能を無効にして比較テストしてください。
• アプリ内蔵のDoHはHTTPSを使用するため、従来型DNSの53番ポートを横取りしても、自動的に同じ名前解決経路を通るわけではありません。

DNSとスニッフィング：ドメイン情報を補完する機能で、プロキシルールの代わりではない

Fake-IPは、まずドメインに対応するアドレスを割り当て、接続がコアに入った時点でドメイン情報を復元する方式です。例にある 198.18.0.1/16 は、この用途によく使われるベンチマーク用の予約アドレス範囲に含まれます。このような名前解決結果を見ても、すぐにパブリックDNSの障害だと判断しないでください。接続元のアプリも同じコアによって通信を取り込まれているか確認しましょう。

mihomoのスニッフィング機能は、HTTP HostやTLS SNIなどのプロトコル情報からドメイン名を取得し、宛先IPしか分からない通信をドメインルールの照合に利用できるようにします。HTTPSを復号する機能ではなく、すべての通信からドメイン名を取得できるとは限りません。ハンドシェイク情報が暗号化されている場合、標準外のプロトコルを使う場合、アプリ固有の接続方式では、有効なドメイン名を取得できないことがあります。

sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080]
    TLS:
      ports: [443, 8443]

上の例では、スニッフィングの対象プロトコルとポートを限定しています。指定したIPアドレスへの接続や内部証明書のドメイン名に依存する場合、または有効化後に接続動作が変わった場合は、まずスニッフィングを無効にした状態と比較してください。そのうえで、使用中のバージョンが対応する除外条件を使い、対象範囲を絞りましょう。ルールに一致しない問題をすべて解決する設定として、スニッフィングを使わないでください。

移行手順：構文チェック、ノード接続テスト、ルール確認、最後にTUNを有効化

移行のために古い設定をすべて書き直す必要はありません。既存のmixed-port、ノード、シンプルなルールを維持し、新機能を1つずつ追加しましょう。問題の原因がノードのパラメーター、ルールデータ、システムの通信取り込みのどれなのかを切り分けやすくなります。以下の手順は、単体のコアにもGUIクライアントのチェックリストにも使えます。

1. 復元できるバックアップを保存する。元のクライアント、コアのバージョン、設定の入手元、作業ディレクトリを記録します。クライアントにサブスクリプションの上書き設定やマージ機能がある場合は、その内容も保存してください。
2. 設定を読み込めるか確認する。以下のテストコマンドを実行します。YAMLの構文、一部のフィールド、リソースの読み込みに関する問題を検出できますが、リモートノードに接続できることまでは確認できません。
3. まずプロキシの入口をテストする。mixed-port で指定したポートが実際に待ち受けていることを確認し、ローカルプロキシ経由でリクエストを送信します。以下の例では 7890 を使っています。設定が異なる場合は、コマンドの値も合わせて変更してください。
4. ルールの適用状況を確認する。接続ログで宛先ドメイン、適用されたルール、最終的なアウトバウンドを確認します。GEOSITEまたはRULE-SETを追加したら、同じ宛先をもう一度テストしてください。
5. 最後にTUNをテストする。先にシステムプロキシ経由の通信が使えることを確認してから、TUNを有効にします。ブラウザー、システムプロキシを参照しないアプリ、LANへの接続、DNSの名前解決をそれぞれテストしてください。

mihomo -v
mihomo -t -d ./mihomo-data -f ./config.yaml
curl -I --proxy http://127.0.0.1:7890 https://example.com/

メイン設定で相対パスを使う場合、テスト時の -d は想定する作業ディレクトリに合わせ、ルールファイルも事前に用意してください。テストコマンドが成功しても、クライアントから最終的にコアへ渡される設定を確認しましょう。サブスクリプション、上書き設定、画面上の設定をクライアントが統合してから実行する場合があり、ディスク上のサブスクリプション原文がそのまま有効な設定になるとは限りません。

エラーの種類ごとに異なる対処方法

• 未対応のプロキシタイプ：まずコアの名称とバージョンを確認し、サブスクリプションがmihomo互換形式を出力しているか確認してください。DNSの設定変更から始める必要はありません。
• ルールセットまたはGEOデータの読み込み失敗：パス、ファイル形式、アクセス権、ダウンロード先への接続を確認してください。問題を隠すために、すべての振り分けルールを削除しないでください。
• プロキシは使えるがTUNが使えない：権限、デフォルトのネットワークインターフェース、競合するルート、DNSの取り込み設定を確認してください。これだけでリモートノードの障害と判断しないでください。

クライアントの入手先とインストール方法はダウンロードセンターをご覧ください。サブスクリプションを初めて読み込む場合は使い方ガイドを参照できます。DNS、プロキシグループ、TUNの設定項目を詳しく確認する場合は、設定リファレンスで項目ごとに調べられます。