mihomoとオリジナルClashの違い：対応プロトコル、DNS設定、移行時の注意点

Clash、Clash Meta、mihomo、クライアントの違いを整理する

オリジナルClashとは、通常Dreamacroプロジェクトが公開したClashカーネルを指します。YAML設定を読み込み、HTTP、SOCKS、mixedの待受ポートを作成し、プロキシグループとルールに従って接続先を決定します。Clash Metaはこの設定思想を拡張したカーネルの派生版で、後にプロジェクト名としてmihomoが使われるようになりました。実際の移行では、「Clash Meta設定」と「mihomo設定」は同じ技術系統における異なる段階の呼び方と考えられますが、すべてのバージョン間で完全互換とは限りません。

Clash Verge RevやFlClashなどのGUIクライアントは、設定のインポート、システムプロキシの切り替え、ログ表示、カーネル管理を担当します。プロトコル、DNS、ルール、TUNによる通信の取り込みを実行するのはmihomoです。サブスクリプションサービスはノードとポリシー設定を提供します。この3つはそれぞれ画面、実行層、設定の提供元に分かれるため、トラブル対処ではまずエラーがどの層から出ているかを確認します。

コマンドで実行中のカーネルを確認する

コマンドラインで導入する場合は、まずバージョンを確認します。ビルドによって追加表示される情報は異なりますが、結果にはmihomoの名称、バージョン、対象OS、プロセッサーアーキテクチャが表示されるはずです。

mihomo -v

たとえば、あるマシンでは Mihomo Meta v1.19.3 linux amd64 と表示されることがあります。ここでの v1.19.3 はバージョンの読み方を示す例にすぎず、すべての機能に共通する最低要件ではありません。プロトコル、設定項目、デフォルト動作はリリースごとに変わるため、移行前には使用中バイナリのバージョン情報と対応するリリースノートを確認してください。

マシン上で clash という旧実行ファイルをまだ使っている場合は、clash -v も一度実行してください。新しいファイルを旧名称に変更しただけでは、旧カーネルがmihomoへ更新されることはありません。判断材料にするのはファイル名ではなく、プログラムの出力と実際のプロセスパスです。

プロトコルとルール機能の実際の違い

オリジナルClashは、Shadowsocks、VMess、Trojan、HTTP、SOCKS5などの一般的なプロキシ方式に対応し、DIRECT、REJECT、プロキシグループ、ルールモード、基本的なDNS機能を備えています。mihomoはこれらの設定構造を引き継ぎながら、VLESS、Reality、Hysteria2、TUIC、WireGuardなどの機能を追加・拡張しています。特定のプロトコルを利用できるかどうかは、カーネルのバージョン、サブスクリプションの生成方法、サーバー側パラメータが揃っているかによって決まります。

プロトコル名が同じでも、パラメータをそのまま再利用できるとは限らない

移行時に最も起こりやすい誤解は、「サブスクリプションにノードが表示されるので、必ず接続できる」と考えてしまうことです。クライアントがYAMLを正常に解析できても、設定形式が基本的に読めたことを示すだけで、ハンドシェイク用パラメータが正しいとは限りません。たとえばVLESS Realityでは、通常サーバー名、公開鍵、Short ID、クライアントフィンガープリント、フロー制御パラメータなどが関係します。Hysteria2では、サーバーアドレス、認証情報、TLSサーバー名、証明書検証設定を確認する必要があります。項目が不足していてもノードは一覧に表示される場合がありますが、接続ログではハンドシェイク段階で失敗します。

• まず確実に利用できるノードを1つ選び、最初から自動速度テストのグループ経由で確認しないでください。
• ログレベルを一時的に debug に設定し、対象への接続を1回行ったら、すぐにハンドシェイクエラーを確認します。
• タイムアウト、DNS解決失敗、TLS名の不一致、認証失敗を切り分けてください。それぞれ対処方法が異なります。
• サブスクリプション変換ツールが項目を書き換える場合があるため、必要に応じてサブスクリプションの元データとクライアントの保存設定を見比べます。

ルールは引き続き上から順に評価される

mihomoでもルールモードの基本原則は変わりません。上から順に評価され、最初に一致したルールで接続先が決まります。移行後に「すべての通信がプロキシ経由になる」「特定のドメインが直​​接接続にならない」といった問題が出たら、まずルールの順序を確認し、ノードを何度も切り替えるのは避けてください。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN,blocked.example,REJECT
  - MATCH,PROXY

ここでの PROXY は設定内ですでに定義されているポリシーグループであり、カーネル組み込みの出口ではありません。no-resolve は、このIPルールに一致させる際にドメインを自動でIPへ解決しないことを示します。すべてのDNSを無効にするという意味ではありません。旧設定にPROXYという名前のポリシーグループがなければ、設定テストの段階で参照エラーとして検出されるべきで、接続段階まで持ち越すものではありません。

DNS設定が移行時の高リスク項目になる理由

旧Clash設定をmihomoへ移行した後、プロキシノードには接続できても、Webページの表示が遅い、LAN内ドメインが使えない、中国本土と海外の名前解決結果が想定と異なる、TUNを有効にするとまったく名前解決できない、といった問題が起こることがあります。こうした問題は通常、プロトコルの非互換ではなく、システムDNS、mihomo DNS、プロキシノードのドメイン解決、fake-ipのマッピングが誤った経路を形成していることが原因です。

fake-ipとredir-hostを理解する

enhanced-mode: fake-ip は、まずアプリに予約済みアドレスを返し、カーネルがドメインとの対応関係を保存したうえで、取り込んだ接続を処理する際に本来の宛先へ戻します。よく使われるアドレスプールは 198.18.0.1/16 です。ドメイン単位のルール処理が必要な環境に適していますが、LAN内探索、プリンター、一部のゲームプラットフォーム、独自に証明書やアドレスを検証するアプリでは、除外リストへの追加が必要になることがあります。

redir-host は、先に実際のアドレスを解決してから接続を処理する方式に近いものです。fake-ipがLANアプリへ与える影響を抑えられますが、ドメインルールの一致、解決の遅延、キャッシュ動作は異なります。移行時は、あるテンプレートがfake-ipを使っているという理由だけで既存設定を上書きせず、現在の取り込み方式とアプリの要件を先に確認してください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

この例ではDNSの待受を 127.0.0.1:1053 に限定し、ポートと待受アドレスの関係を示しています。TUNのDNSハイジャックでリクエストを取り込む場合は、クライアントが生成するTUN設定とも整合させる必要があります。1053 は必須の値ではなく、OSのDNSを自動的に変更するものでもありません。

プロキシノードのドメインは個別に考える必要がある

プロキシサーバー自体にドメイン名を指定している場合、プロキシ接続を確立する前にカーネルがそのドメインを解決しなければなりません。その解決リクエストまで、まだ確立していないプロキシへルールで送られると、起動ループになる可能性があります。mihomoでは、proxy-server-nameserver でプロキシノードのドメイン解決に使うDNSサーバーを指定し、nameserver-policy で特定ドメインの解決経路を選択できます。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query

この設定例は項目同士の関係だけを示したもので、完全なプロキシ、ポリシーグループ、ルール定義は含みません。暗号化DNSを使う場合は、そのドメインの初期解決が完了することも確認してください。移行後もDNSタイムアウトが続く場合は、まず通常のIPアドレス指定DNSで基本経路を検証し、その後DoH、ポリシー別解決、ルール連動を1項目ずつ戻します。4つや5つの変数を同時に変更するのは避けてください。

TUNモード移行で確認すべき権限、ルート、インターフェース

システムプロキシの影響を受けるのは、システムプロキシ設定を明示的に読み取るアプリだけです。ターミナルのコマンド、ゲーム、仮想マシン、一部の更新プログラムはシステムプロキシを迂回することがあるため、mihomoへの移行時にTUNも同時に有効にするユーザーは少なくありません。TUNは仮想ネットワークインターフェースを作成してルートを変更するため、対象範囲が広い一方、OSの権限とルーティング設定への依存も大きくなります。

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

stack で利用できる値と動作は、現在のmihomoバージョンに合わせて確認してください。一般的な選択肢には system、gvisor、mixed があります。移行時はまずクライアントのデフォルト値を使い、ログを見ながら互換性の問題に対処します。ルーター用テンプレートをデスクトップOSへそのままコピーすると、インターフェース名、ルーティングテーブル、DNSハイジャック方式まで持ち込まれ、通信が途切れることがあります。

TUNの障害範囲を順番に絞り込む

1. TUNを無効にし、mixedポートだけを有効にして、プロキシノード自体が動作することを確認します。
2. 待受ポートを確認します。よくある例は mixed-port: 7890 で、ブラウザーのHTTPおよびSOCKS5プロキシを一時的に 127.0.0.1:7890 へ設定できます。
3. TUNを有効にし、仮想インターフェースの作成とルート変更に必要な権限をクライアントが取得していることを確認します。
4. VPN、仮想マシンのネットワーク、ゲーム用アクセラレーター、別の透過プロキシが同時に動作していないか確認します。
5. IPアドレスとドメインを分けてテストします。IPには到達できるのにドメインだけ失敗する場合は、まずDNS設定を確認してください。
6. LAN内の機器へアクセスし、プライベートアドレスのルールがフォールバックルールより前にあることを確認します。

Windowsでは、通常クライアントが権限の要求を処理します。macOSではVPN設定やネットワーク拡張機能の許可が必要になる場合があります。Linuxでサービスとして動かす場合は、サービスユーザー、ネットワーク機能、ルート操作権限を確認してください。これらの手順のまとめ方はクライアントごとに異なるため、特定クライアントのメニュー項目をmihomoカーネル共通の設定項目とみなすことはできません。

旧設定をmihomoへ移行する再現可能な手順

手順1：旧ファイルと実行情報を保存する

現在の config.yaml、ルールセット、ローカル上書き、クライアント設定ディレクトリをコピーし、旧カーネルのバージョン、システムプロキシのポート、制御ポート、TUNの状態、正常に使えているノードを記録します。サブスクリプションURLは公開ログやスクリーンショットに記載しないでください。クライアントが複数の設定を扱える場合は、どの設定が有効なのかを明確にし、未選択のファイルを編集しないようにします。

手順2：まず静的設定テストを行う

mihomoには設定テスト用の引数があり、サービスを起動する前にYAML構文、ポリシーグループの参照、一部の項目エラーを確認できます。設定ファイルがカレントディレクトリにある場合は、次のように実行します。

mihomo -t -f config.yaml

テストに合格しても、カーネルが設定を読み込めることを示すだけです。すべてのノードが接続できることや、リモートルールセットを必ず取得できることまでは保証しません。失敗した場合は最初のエラーから修正してください。後続のエラーは、先行するインデントや項目構造の問題から連鎖しているだけかもしれません。

手順3：最小構成で待受ポートを確認する

移行時は、プロキシを1つ、ポリシーグループを1つ、少数のルールだけ一時的に残し、mixedポートを 7890、制御インターフェースを 127.0.0.1:9090 に限定できます。外部制御インターフェースを有効にする場合はアクセスキーも設定し、クライアントに入力したアドレス、ポート、キーが一致していることを確認してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: "change-this-local-secret"

ここでのキーは例示用の値です。実際の設定では置き換えてください。制御ポートは管理画面による状態確認とポリシー切り替え専用で、Webプロキシの通信は扱いません。ブラウザーのプロキシを 9090 に向けても正しく動作しません。

手順4：ルールセット、DNS、TUNを1項目ずつ戻す

「ノード接続 → ポリシーグループ → ローカルルール → リモートルールセット → DNS → TUN」の順に戻すことをおすすめします。各層を追加するたびに、ドメインアクセス、IPアクセス、LANアクセス、ログ確認を行います。問題が発生しても、戻す範囲を1つの手順に限定できます。

• ルールプロバイダー：behavior、ファイル形式、更新間隔、参照名を確認します。
• 地理データ：GEOIP、GEOSITEのデータファイルを現在のカーネルが読み込めることを確認します。
• ポリシーグループ：ルールの対象名と proxy-groups の名称が完全に一致しているか確認します。
• サブスクリプションの上書き：サブスクリプション更新時にクライアントがローカルのDNSやTUN設定を上書きしないか確認します。
• LAN：他の機器から接続する必要がある場合だけ allow-lan を有効にし、待受アドレスとファイアウォールを設定します。

移行時によくある症状と確認項目

ターミナルでテストする際は、プロキシを明示的に指定して、「ターミナルがシステムプロキシを読み取っていない」ことをカーネルの障害と誤判定しないようにします。たとえばmixedポートが 7890 の場合、SOCKS5に対応したツールを socks5h://127.0.0.1:7890 へ接続できます。プロキシ側でドメインを解決する方式は、mihomoのドメインルール経路を検証するのに適しています。

移行完了後の受け入れ基準

移行完了の判断を、クライアントのトレイアイコンが変色したかどうかだけに頼ってはいけません。少なくとも、設定テストに合格していること、選択したノードで接続を確立できること、DIRECTとプロキシのルールがそれぞれ一致すること、拒否ルールが実際に通信を遮断すること、DNSタイムアウトが継続していないこと、システムプロキシとTUNの適用範囲が想定どおりであること、サブスクリプション更新後もローカル上書きが保持されることを確認してください。

1. 現在のmihomoバージョンとクライアントバージョンを記録し、今後のアップグレード比較に備えます。
2. ログで、直接接続、プロキシ接続、拒否された接続を1件ずつ確認し、どのルールに一致したかを確認します。
3. システムプロキシを無効にしてもTUNが想定どおり通信を取り込むか確認し、TUNを無効にしてもmixedポートを単独で利用できるか確認します。
4. サブスクリプションを1回更新して設定を再読み込みし、ポリシーグループ名、DNS、ルールプロバイダーが上書きされていないことを確認します。
5. クライアントまたはシステムを再起動し、カーネル、設定、権限の状態が復元されることを確認します。