まずコア、クライアント、設定体系を切り分ける
mihomoと従来版Clashを比較するとき、最も起こりやすい誤解は、コア、GUIクライアント、サブスクリプション設定を1つの製品として扱うことです。従来版Clashとは通常、Dreamacroが保守していたClashオープンソースコアを指します。ローカルポートの待ち受け、プロキシ接続の確立、ルールの実行、DNS処理を担い、外部コントロールAPIを通じてGUIに実行状態を提供します。元プロジェクトが継続的な保守を停止した後も、従来版コアは既存設定を実行できますが、新しいプロトコルやルール機能、各プラットフォームのネットワーク変化には対応しません。
mihomoはClash.Metaから発展したコアプロジェクトです。Clashの設定体系、プロキシグループ、ルールマッチング方式を引き継ぎながら、プロトコル、DNS、TUN、ルールセット、トラフィック制御の機能を拡張しています。名称が変わっても設定体系が一から設計し直されたわけではありません。Clash.Metaの表記が残るクライアント、設定ディレクトリ、ドキュメントでも、実際にはmihomoを組み込んでいる場合があります。判断する際はアプリ名だけでなく、クライアントの設定画面に表示されるコア名とバージョンを確認してください。
GUIクライアントはコアの外側にある管理層で、通常はサブスクリプションの取得、設定の切り替え、プロキシグループの編集、システムプロキシの制御、接続履歴の表示などを担当します。1つのクライアントで異なるコアを切り替えられる場合があり、同じ設定を複数のクライアントで読み込むこともできます。そのため「クライアントが特定の設定項目に対応している」という場合、実際には2つの意味が含まれます。付属するコアがその項目を解釈できるか、そして画面上で正しく表示・編集できるかです。コアは正常に実行できても、画面に対応するスイッチがないケースは珍しくありません。
プロトコル対応の違い：mihomoは幅広く対応するが、設定とネットワークの制約は残る
従来版ClashはShadowsocks、VMess、Trojan、Snell、HTTP、SOCKSなど一般的なプロキシ方式に対応し、従来のClash設定に必要な基本機能を備えています。mihomoはこれを基盤に、VLESS、Reality関連のトランスポート、Hysteria、Hysteria2、TUIC、WireGuardなどの機能を追加・維持し、プロトコルパラメータの変更にも継続して対応しています。ただし、実際に利用できる範囲はインストールされているmihomoのバージョンに左右されます。古いクライアントに組み込まれたコアでは、新しい設定項目を認識できないことがあります。
あるプロトコルに対応しているからといって、インポート後に必ず接続できるとは限りません。VLESSノードではTLS、Reality、WebSocket、gRPCなど複数のトランスポートパラメータが必要になる場合があります。Hysteria2とTUICは主にUDPを使用するため、UDPが制限されたネットワークではハンドシェイクがタイムアウトすることがあります。WireGuard設定にはアドレス、秘密鍵、公開鍵、ルート、MTUも関係します。サブスクリプション変換の途中で項目が失われると、コアがプロトコルに対応していても不足したパラメータを復元できません。
従来版Clashからmihomoへ移行する場合、既存のShadowsocks、VMess、Trojanノードは通常、最も高い互換性を保ちやすい部分です。逆方向の移行は同じようには考えられません。VLESS、Hysteria2、TUIC、mihomo固有のオプションを含む設定を従来版コアに渡すと、未知のプロキシ方式としてエラーになることがあります。また、未対応項目を解析した時点で読み込みが停止する場合もあります。設定互換性は「mihomoが従来のClash構文に高い互換性を持つ」と捉えるのが近く、2つのコアが完全に双方向互換という意味ではありません。
プロトコル切り替え前に確認すること
- クライアントに組み込まれている実際のコアのバージョンと、コアを個別に更新できるかどうか。
- ノードのプロトコル、トランスポート層、TLS、サーバー名、証明書検証などの項目が完全に揃っているか。
- 現在のネットワークでUDPが許可されているか、ルーター、ファイアウォール、企業ネットワークが関連トラフィックを制限していないか。
- サブスクリプション更新後に変換サービスを経由しているか、変換時に新しいプロトコルのパラメータが保持されているか。
- 同名のプロキシグループが有効なノードを参照しているか。ノードが存在していても、どのグループにも選ばれていない状態を避ける。
ルールとプロキシグループ：基本モデルは共通、拡張機能は異なる
両者の基本的な振り分けモデルは近いものです。トラフィックはルールに順番に照合され、マッチするとプロキシノードまたはプロキシグループへ渡されます。マッチしなかった接続は通常、末尾のMATCHルールが処理します。DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、PROCESS-NAMEなどの一般的なルールは移行しやすく、select、url-test、fallback、load-balanceなどのプロキシグループもClashユーザーに馴染みのある構成を引き継いでいます。
mihomoはルール表現を拡張し、より多くのルールタイプ、論理演算、インバウンド条件、ネットワークタイプ、ルールセットに対応しています。AND、OR、NOTなどの論理ルールを使えば、「特定のドメインかつ特定のインバウンドからの通信」といった複合条件を表現できますが、括弧、カンマ、子ルールの構造は現在のコア構文に従わなければなりません。複雑なルールにしただけで精度が自動的に上がるわけではありません。条件が増えるほど、接続ログやルール追跡情報と照らし合わせてマッチ結果を確認する必要があります。
ルールセットではデータ形式も区別する必要があります。従来のドメインリスト、IP CIDRセット、クラシック形式のルールテキスト、バイナリルールセットは、behavior、format、読み込み方法がそれぞれ異なります。rule-providerでdomainを指定しているのに、内容へカンマ区切りの完全なルールを入れていると、更新自体は成功しても期待どおりにマッチしないことがあります。mihomoではGEOSITEとGEOIPのデータで分類することもできますが、分類名は使用する地理データファイルに左右され、すべてのデータソースが同じタグを収録しているわけではありません。
mode: rule
proxy-groups:
- name: 手動選択
type: select
proxies:
- DIRECT
rule-providers:
local-direct:
type: file
behavior: domain
format: text
path: ./rules/direct.txt
rules:
- RULE-SET,local-direct,DIRECT
- MATCH,手動選択上の例は、ルールセットとプロキシグループの参照関係だけを示しています。実際の設定を移行する際は、既存のプロキシノード、プロキシプロバイダー、完全なプロキシグループも保持してください。断片だけを現在使用中のファイルへ上書きしてはいけません。設定がサブスクリプション由来の場合は、次回の更新で変更が失われないよう、クライアントのオーバーライドまたはマージ機能からカスタムルールを追加するのがおすすめです。
DNSとTUN：機能が充実する一方、システム環境への依存も大きい
Clash系コアのDNSモジュールは、ドメインをIPアドレスへ解決するだけでなく、ルールマッチング、プロキシサーバーのアドレス解決、システムDNSによる迂回の防止にも影響します。従来版Clashには、fake-ip、redir-host、nameserver、fallback、fallback-filterなどの仕組みがすでに用意されています。mihomoはさらにnameserver-policy、proxy-server-nameserver、direct-nameserver、fake-ip-filterなどの設定を拡張し、プロキシノードのドメイン、ダイレクト接続のドメイン、通常の問い合わせで異なる解決経路を使えるようにしています。
これらの項目には明確な役割分担があります。nameserverは通常の問い合わせを担当します。proxy-server-nameserverはプロキシサーバー自身のドメイン解決に使え、プロキシ確立前にDNSへ依存する循環を避けられます。nameserver-policyではドメインごとにリゾルバーを指定できます。fake-ip-filterは仮想アドレスを返すのに適さないドメインを除外します。respect-rulesのようにルールに応じて解決経路を選ぶ設定を有効にする場合は、プロキシノードのドメインに独立した利用可能なリゾルバーがあることも確認してください。そうでなければDNS問い合わせがプロキシを必要とし、プロキシ接続がDNS結果を待つ循環に陥ることがあります。
fake-ipモードではドメインに仮想アドレスを割り当て、コアが接続を引き受けた時点でドメインへ戻します。そのため、ルールマッチングは比較的安定します。LAN内の機器検出、一部のゲーム、プリンターサービス、実アドレスを必要とするアプリでは、フィルターリストへの追加が必要になる場合があります。redir-hostは実際の解決結果を返すため、従来のDNSに近い動作ですが、複雑な振り分けやDNS汚染がある環境では、上流リゾルバーをより慎重に設計する必要があります。移行時はenhanced-modeの1行だけをコピーせず、リスニングアドレス、IPv6、フィルター範囲、上流プロトコルも合わせて確認してください。
TUNモードは、システムプロキシ設定に従わない通信を引き受けるために使います。対象には一部のコマンドラインプログラム、ゲーム、独自のネットワークスタックを使うアプリなどがあります。mihomoはTUNルーティング、DNSハイジャック、自動ルート、インターフェース識別に幅広く対応していますが、利用可否はOSの権限、仮想NICドライバー、ファイアウォール、ほかのネットワークソフトに左右されます。system、gVisorなどのネットワークスタックは性能、互換性、プラットフォーム対応が異なるため、まずはクライアントが推奨する既定値を使い、具体的な障害に応じて調整してください。
設定互換性はYAMLを読み込めるかどうかだけでは決まらない
設定をmihomoが正常に解析できたとしても、それは項目の構文チェックを通過したことを意味するだけです。ノードが利用できること、ルールが正しくマッチすること、外部コントロール画面が完全に対応していることまでは保証されません。移行評価は少なくとも4層に分ける必要があります。YAML構造、コアの設定項目、実行リソース、クライアントによる制御です。インデントの誤り、重複キー、誤ったデータ型はYAML層、未知のプロキシ方式やプロキシグループのパラメータ不一致はコア層、ルールファイルの欠落や地理データベース未取得はリソース層、外部コントロールのアドレス、認証キー、APIの差異はGUIクライアントに影響します。
mihomoは通常、proxies、proxy-groups、rules、proxy-providers、rule-providersという従来の構造を読み込め、mixed-port、socks-port、redir-port、allow-lan、mode、log-levelなどの一般的な項目も維持しています。ただし、過去の設定の中には特定のClash Premiumの動作に依存するものがあり、別の設定ではクライアント独自のオーバーライドが追加されています。同じ項目名であっても、値の形式と現在のバージョンの仕様を照合してください。拡張子だけで互換性を判断することはできません。
外部コントロールAPIは全体としてClash APIの使い方を引き継いでいるため、多くのコントロールパネルで通信量、接続、プロキシグループ、ログを引き続き確認できます。ただし、画面側がmihomoで追加されたプロキシ方式や設定項目に対応していない場合、基本情報しか表示されなかったり、設定保存時に未知の内容が削除されたりすることがあります。重要な拡張項目は独立した設定またはオーバーライドファイルで管理し、クライアントの保存操作が元のサブスクリプションを書き換えないことを確認してください。
よくある互換性問題と切り分け方
- 起動直後にエラーが出る：まずエラーの行番号を確認し、YAMLのインデント、項目の型、現在のコアが対象のプロキシ方式に対応しているかを調べます。
- 設定は読み込めるが、すべてのノードがタイムアウトする：ノードのパラメータ、プロキシサーバーのDNS、システム時刻、UDPの利用条件、サブスクリプション項目の欠落を確認します。
- プロキシグループが空になる：proxies、use、filter、exclude-filterを確認し、プロバイダー名とフィルター式がノードにマッチしているかを調べます。
- ルールが期待どおりにマッチしない：ルールの順序、ルールセットのbehavior、解決結果、そして接続がTUNまたはシステムプロキシによって実際に引き受けられているかを確認します。
- 画面から接続できるが編集できない：クライアントが該当フォームをまだ提供していない可能性があります。対応しているオーバーライド方法で拡張項目を管理してください。
従来版Clashからmihomoへ移行する手順
安定した移行のポイントは、変数を絞り込むことです。コアの変更と同時にDNSを作り直し、すべてのルールセットを入れ替え、TUNまで有効にしてはいけません。障害が起きたときに原因を特定しにくくなるためです。まず既存設定を新しいコアで解析し、基本的な接続を確認してから、mihomoの拡張機能を1つずつ有効にします。
- 現在の設定とクライアント設定を保存する。リスニングポート、システムプロキシの状態、現在選択中のプロキシグループ、DNSモード、外部コントロールのアドレスを記録します。サブスクリプションURLとローカルオーバーライドは別々に保存してください。
- 設定の取得元を確認する。ローカルYAML、リモートサブスクリプション、プロキシプロバイダー、クライアント生成設定を区別します。キャッシュファイルを直接編集すると、サブスクリプション更新時に上書きされることがあります。
- mihomoで構文を確認する。コマンドライン環境では
mihomo -t -f config.yamlを実行して設定を検査できます。GUIクライアントでは、コアのログに表示される具体的なファイル名と行番号を確認してください。 - まず基本プロキシをテストする。既存のルールモードを維持し、動作確認済みのノードを1つ選んで、ウェブアクセス、DNS問い合わせ、プロキシグループの切り替えが正常か確認します。この段階では新しいプロトコルのノードを追加しません。
- ルールとプロバイダーを検証する。リモートルールセットを取得できるか、プロキシグループにメンバーがあるか、末尾にMATCHルールが存在するかを確認します。接続ログで、よく使うドメインが実際にどのルールへマッチしたかも確認してください。
- DNS拡張を個別に有効にする。必要に応じて、プロキシサーバーの名前解決、ドメインポリシー、fake-ipフィルターを設定します。一度に変更するのは1グループの項目だけにし、名前解決のタイムアウトや循環依存が発生していないか確認してください。
- 最後にTUNをテストする。ほかのプロキシクライアントを終了し、仮想NICの権限とルート復旧の仕組みを確認してから、システムプロキシを使わないプログラムをテストします。接続できなくなった場合は、ノードのパラメータを連続して変更するのではなく、まずTUNを終了してください。
mihomo -t -f config.yaml構文チェックを通過した後も、実際の動作を検証する必要があります。コアのログ、プロキシグループの選択、DNS問い合わせ、接続詳細、システムルートの順に確認するのがおすすめです。古い設定に多数のカスタム項目がある場合は、まずローカルポート1つ、ノード1つ、プロキシグループ1つ、末尾ルールだけを残した最小構成をコピーします。最小構成で接続できたら、ルールプロバイダー、DNS、TUN設定を段階的に戻してください。
選び方：設定要件と保守状況で判断する
従来のノード、単純なドメインルール、長期間変化しないネットワーク環境を使い続ける端末では、従来版Clashの設定が動作し続ける場合があります。ただし、従来版コアは継続的な保守が停止しているため、新しいプロトコル、OSのネットワーク変化、長期的な互換性問題に直面した際の修正手段は限られます。新規インストール環境、新しいプロトコル、複雑なルールセット、細かなDNS設定、TUNによる通信制御が必要なユーザーには、mihomoが通常より適したコアです。
GUIクライアントを選ぶ際は、内蔵mihomoのバージョン、コアの更新方法、設定オーバーライドの仕組み、ログの確認場所を確認してください。「Clash設定に対応」とだけ書かれていても、mihomoの拡張機能を完全に管理できるとは限りません。長期運用する設定では、クライアント固有の項目への依存を減らし、ノードの取得元、プロキシグループ、ルールセット、ローカルオーバーライドを分けて管理することも重要です。
最終的な判断基準は機能の数ではなく、現在の設定を検証・更新・ロールバックできるかどうかです。mihomoはClashの設定体系を拡張しますが、拡張機能ごとに追加のパラメータと環境条件が必要になります。「まず既存設定との互換性を確認し、その後で新機能を追加する」順序で移行すれば、プロトコル、DNS、ルール、システムによる通信制御の問題を分けて扱えます。コア更新後の変化も特定しやすくなります。