まず結論：Metaからmihomoへ、同じプロジェクトの名称が変わった

新しい設定を選ぶときは、クライアント名だけでなく、実際に動作しているカーネルを確認しましょう。Clash、Clash Premium、mihomoでは機能の範囲が異なります。Clash Metaは後にmihomoへ名称変更されたため、別個の第4のカーネルをインストールする必要はありません。古い解説にある「Meta向け設定」は通常このプロジェクトの設定体系を指しますが、項目が使えるかは対象バージョンごとに確認してください。

古い設定をmihomoへ移行する場合、基本的なノード、プロキシグループ、一般的なドメインルールは引き継げることが多い一方、追加プロトコル、Premiumのスクリプト、DNS、TUN、ルールセットの形式は個別の確認が必要です。逆方向の移行にはさらに制約があります。mihomoで読み込める設定が、元のClashでも動作するとは限りません。

プロジェクトの系譜：Clash、Premium、Meta、mihomo

ClashとClash Premium

Clashは一般に、Dreamacro/clashのオープンソースカーネルを指します。一方、Clash Premiumは元プロジェクトが提供していた、機能を拡張したクローズドソース版で、両者を同じ機能として扱うことはできません。TUN、ルールプロバイダー、スクリプトルールなどは、歴史的にPremiumとオープンソース版を見分ける手がかりでした。元プロジェクトは2023年に開発を終了しました。古いバイナリが動く場合はありますが、新しいプロトコルへの対応を継続的に得る基盤としては適しません。

Clash Metaとmihomo

Clash MetaはClashのエコシステムから発展し、プロトコルやルーティング機能を拡張した後、mihomoへ名称変更されました。フォルダー名、サブスクリプションの説明、旧バージョンの画面にMetaと表示されていても、カーネルが古いとは限りません。実際に使われているバイナリのバージョン情報と、該当するリリースノートで判断しましょう。

  • Clash：基本的なYAML、HTTP/SOCKSの受け入れ、ルールによる振り分けを理解するための出発点です。
  • Clash Premium：古い設定にある高度なルール、TUN、スクリプト機能の提供元の一つです。
  • Clash Meta / mihomo：同じプロジェクトの旧称と現名称で、より多くのプロトコルや設定拡張に対応します。

クライアントでカーネルを切り替えられても、実行ファイルを自由に入れ替えてよいわけではありません。起動オプション、制御インターフェース、サービス権限、インストール先をクライアントが管理している場合があります。まずクライアント内蔵の更新機能を使い、対応するカーネルの種類を確認してください。

機能の違いを比較：プロトコル、ルールセット、TUN

機能の変遷と移行時の確認ポイント
確認項目 Clash（旧オープンソース版） Clash Premium mihomo
主なプロキシプロトコル SS、VMess、Trojanなどに対応。旧バージョンの実装による制約があります 当時のバージョンの機能が基準です。新しいプロトコルへの対応を前提にしないでください VLESS、Hysteria2、TUICなどに対応
基本ルール ドメイン、IP CIDR、GEOIP、最終マッチなどに対応 基本ルールと拡張機能に対応 一般的なルールを引き継ぎ、より多くのマッチ条件を利用できます
rule-providers Premiumの機能がそのまま使えるとは限りません 対応。ルールの動作と形式を確認してください 対応。拡張形式は対象バージョンを確認してください
TUN接続 Premium内蔵のTUN機能はありません 対応。プラットフォームと権限に依存します 対応。ネットワークスタックと設定項目はバージョンによって異なります
Premium script 非対応 旧版固有の機能 そのまま互換とは見なせません。移行時に書き換えが必要です

プロトコル名が同じでも、トランスポートや暗号化の設定項目を確認してください

ノードにVMessと記載されていても、接続に必要な設定がすべて揃っているとは限りません。UUID、TLS、サーバー名、WebSocketのパスやヘッダーなども確認しましょう。VLESSの場合は、サーバー側のトランスポートやセキュリティ層、関連パラメーターも確認してください。typeだけを変更しても、別のプロトコルには変換されません。

Hysteria2とTUICはUDP通信を利用します。カーネルがノードを解析できても、現在のネットワークでタイムアウトが続く場合は、UDPの通信経路、サーバーのポート、証明書の設定を確認してください。すぐに設定形式の問題と決めつけないようにしましょう。プロトコルに対応していることは必要条件ですが、接続できることを保証するものではありません。

設定の互換性：基本構造を維持し、拡張項目を個別に確認

一般的な設定にはproxies、proxy-groups、rulesが含まれ、proxy-providersやrule-providersを使う場合もあります。名前は似ていますが役割は異なります。前者は外部からノードを読み込み、後者は振り分けルールを読み込みます。サブスクリプションURLを相互に流用することはできません。

ルールの順序とプロキシグループ名をセットで確認

以下はmihomoでよく使われる設定構造の例です。この例では手動選択グループの接続先をDIRECTにしているため、プロキシ経由の通信は行われません。実際に使う際は、DIRECTの選択肢を残したうえで、有効なノードまたは正しいノードプロバイダーへの参照を追加してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,手動選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,手動選択
  • mixed-port: 7890は、HTTPとSOCKSで共用する待ち受けポートの例です。すべてのクライアントで既定値として使われるわけではありません。
  • allow-lan: falseは、まずローカル環境で動作確認する場合に適しています。LANから接続する必要がある場合は、待ち受けアドレスとファイアウォールの範囲を確認してください。
  • ルールは記述順に評価されます。MATCHを先に置くと、それ以降のルールが意図どおりに機能しなくなります。
  • ルールで指定する「手動選択」は、プロキシグループ名と完全に一致させてください。スペースや大文字・小文字も区別されます。
  • no-resolveは、そのIPルールの評価時にドメイン名の逆引きを行わない指定です。カーネル全体のDNSを無効にする意味ではありません。

Premiumのスクリプトと新しいルールセット形式は個別に移行

旧設定のscriptは、そのままmihomoで使えるとは限りません。スクリプトが行っていたドメイン、IP、プロセスの判定を洗い出し、移行先のカーネルが対応するルールに書き換えます。同等の表現ができない処理は、設計を見直す必要があります。移行後は構文チェックだけでなく、代表的なリクエストで実際にルールが適用されるかも確認してください。

ルールプロバイダーでは、behaviorとファイルの内容が一致しているかも確認してください。domain、ipcidr、classicalでは、対応するルールの内容が異なります。YAML、テキスト、mihomoのMRS形式は、拡張子を変更するだけでは相互変換できません。MRSなどの拡張形式はルールの種類やカーネルのバージョンにも依存するため、古いカーネルでは読み込めない場合があります。

DNSとTUN：「起動するのに使えない」が起きやすい設定

DNS設定では問い合わせの入口と上流サーバーを分けて考える

DNSの待ち受けアドレス、上流サーバー、Fake-IPモード、ドメインの除外リストは、それぞれ異なる問題に対応します。enhanced-mode: fake-ipとあっても、Fake-IP方式を使うことが分かるだけで、システムのDNS問い合わせが必ずカーネルに届くとは限りません。システムが別のDNS経路を使っている場合や、アプリが独自の暗号化DNSを使っている場合もあります。

  • 移行前に、元のnameserver、fallback、fake-ip-filterと関連するルールを保存してください。
  • ローカル機器名やLAN内ドメインだけで問題が起きる場合は、上流サーバーを一括で変更せず、LAN内の名前解決経路とFake-IPの除外設定を確認しましょう。
  • ログに上流サーバーのドメイン名解決エラーが表示される場合は、DNSサーバー自身のホスト名を解決するためのブートストラップ設定を確認してください。
  • 設定を変更した後は、関連するアプリを再起動してみてください。カーネルを再読み込みしても、OSやアプリのDNSキャッシュが同時に消去されるとは限りません。

TUNは通信を取り込みますが、ノード設定の問題は解決しません

TUNは仮想ネットワークインターフェースを通じて通信を取り込み、通常は管理者権限または該当するネットワーク権限が必要です。Windowsのサービスモード、Linuxのルーティングと権限、macOSのネットワーク拡張や仮想インターフェースの扱いは、クライアントの実装に応じて確認してください。まず通常のシステムプロキシが動作することを確認してからTUNを試すと、問題の切り分けが容易になります。

tun.auto-route、tun.auto-detect-interface、tun.dns-hijackは、それぞれルーティング、出口インターフェースの検出、DNSの取り込みに関する設定です。互いに置き換えられる「強化スイッチ」ではありません。例のany:53はDNSポートを対象にする指定で、アプリ内の暗号化DNSをすべて遮断するものではありません。ほかのVPNと同時に使う場合は、ルートの優先順位や仮想ネットワークアダプターの競合も確認してください。

mihomoへの旧設定移行：6つの手順で確認

  1. 元の設定を保存する。サブスクリプションの取得元、ローカル上書き、ルールセット、現在の設定ファイルをバックアップします。GUIクライアントからエクスポートしたファイルには上書き設定がすでに反映されている場合があるため、編集可能な元ファイルも保存してください。
  2. カーネル情報を記録する。クライアントのカーネル情報画面またはログで、実際のバージョンを確認します。単体で導入している場合はmihomo -vを実行し、出力結果とシステムのアーキテクチャを記録してください。
  3. まず構文をチェックする。単体で実行する場合はmihomo -t -f config.yamlを使えます。相対パスのリソースは、本番と同じ作業環境で確認してください。パスの誤りを設定形式の互換性問題と取り違えないためです。
  4. ローカルのプロキシポートを確認する。設定が実際に7890番ポートで待ち受けていることを確認してから、下記のコマンドを実行してください。ポートが異なる場合は、コマンドも合わせて変更します。
  5. ルールの適用結果を確認する。クライアントの接続ログで、対象ドメイン、適用されたルール、プロキシグループ、最終的な出口を確認してください。リクエストが成功しても、すべての振り分けが正しいとは限りません。
  6. 拡張機能を一つずつ戻す。ルールプロバイダー、DNSの上書き、TUN、自動起動の順に追加します。各段階でログを確認し、設定を再読み込みした後も機能することを確かめてください。
mihomo -v
mihomo -t -f config.yaml
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

前述の接続タイムアウト10秒、全体のタイムアウト20秒は診断用の設定であり、速度を示す指標ではありません。Windows PowerShellでは、システムにあるcurlを呼び出すためにcurl.exeを明示して実行できます。テスト前に既存のクライアントが7890番ポートを使用していないか確認してください。カーネルを二重に起動するとポートが競合する場合があります。

移行時によくある問題：エラー箇所から原因を絞る

サブスクリプションをインポートできても、ノードがすべて使えない

まず、サブスクリプションがClash用の完全な設定ファイルなのか、ノードプロバイダーの内容なのか、別のクライアント向け共有リンク集なのかを確認します。GUIクライアントに「インポート成功」と表示されても、URLが保存されただけの場合があります。ダウンロード結果、ノードの解析ログ、プロトコルへの対応状況も確認してください。認証情報を含むサブスクリプションURLを、公開の変換サービスや質問掲示板に貼り付けないでください。

設定チェックは通るのに、ルールが適用されない

動作モードがruleか、実際に読み込まれているファイルが編集したファイルかを確認してください。サブスクリプションの更新時にクライアントが設定を再生成したり、上書き設定によって優先順位の高いルールが追加されたりする場合があります。変更を維持するには、生成済みファイルを直接編集するのではなく、クライアントが対応する上書きまたはマージ機能を使ってください。

起動時にポートが使用中と表示される

クライアントを二つ同時に起動していないか、バックグラウンドサービスに古いカーネルプロセスが残っていないか確認してください。プロキシの受け入れポートと制御インターフェースのポートは用途が異なります。たとえば7890番をローカルプロキシ用、9090番を制御インターフェース用にできますが、実際の設定を確認してください。プロキシのポートを変更した場合は、システムプロキシ、ターミナルの環境変数、アプリ内の手動プロキシ設定も合わせて変更します。

旧カーネルを使い続けるべき？mihomoへ切り替えるべき？

Hysteria2、TUIC、VLESSや新しいルール・DNS機能が必要な場合は、それらに明確に対応するmihomoクライアントを選び、同梱カーネルのバージョンも確認してください。Premiumのスクリプトや特定の旧動作に依存している環境では、本番環境を入れ替える前に、独立した設定で移行を検証しましょう。クライアントのインストーラーは選び方ガイドを、基本的な設定手順は使い方ガイドをご覧ください。

最終的には、設定を読み込めること、ノードに接続できること、ルールが想定どおりに適用されること、システムプロキシまたはTUNの取り込み範囲が正しいことを確認します。名前に「Meta」や「mihomo」とあるだけでは、この4点を確認したことにはなりません。