選び方の結論：まずコアを確認し、次にクライアント名を見る

新しい設定でVLESS、Hysteria2、TUICや新しいルール機能が必要な場合は、要件を満たすmihomoビルドを使っているか、まずクライアントを確認しましょう。既存のClash Premium設定は移行元として利用できますが、メンテナンスが終了した旧コアを新規導入の標準にするのは避けてください。Clash Metaとmihomoは同じプロジェクトの変遷に伴う名称で、無関係な2種類のプロトコル体系ではありません。

Clash Apple版を使う場合、ダウンロードページに記載されたアプリ名で分かるのはGUIの種類だけで、内部のプロトコル対応までは判断できません。クライアントによってはコアを切り替えられる一方、特定バージョンが固定で組み込まれている場合もあります。また、アプリとコアの更新が別々に行われることもあります。問題を調べる際は、クライアントのバージョン、コア名とバージョン、macOSまたはiOSのバージョンを記録してください。

Clash、Premium、Meta、mihomoの関係

Clashオリジナル版：オープンソースのコアと基本設定

Clashオリジナル版では、プロキシノード、プロキシグループ、ルール、ローカルのプロキシポートなどを含む、一般的なYAML設定形式が確立されました。多くのクライアントがこの形式を引き継いでいるため、アプリが異なってもproxies、proxy-groups、rulesが使われている場合があります。元プロジェクトは2023年に従来の公開メンテナンスを終了しました。過去のビルドは引き続き動作する可能性がありますが、新しいプロトコルやシステムの変更に継続して対応することは期待できません。

Clash Premium：過去のクローズドソース版。サブスクリプションの有料プランではない

Clash Premiumは、元プロジェクトが提供していたクローズドソースのコアで、TUNやルールセットなどの拡張機能を備えていました。ここでいうPremiumはコアの派生版を指し、プロキシサービス事業者の有料プランではありません。また、サブスクリプションを購入しても、Clashオリジナル版にプロトコルが追加されるわけではありません。Premiumも過去のメンテナンス体制に属するため、クライアントの画面が起動するからといって、コアが継続的に保守されているとは限りません。

Clash Metaからmihomoへ：継承と拡張

Clash MetaはClashをベースに開発された派生版で、その後mihomoに改称されました。古いチュートリアルやサブスクリプション変換の選択肢、クライアントの設定には、今もMetaの表記が残っていることがあります。「Metaコア」と書かれていても、互換性が保証されるわけではありません。実際のバージョンを確認しましょう。新しいmihomo向けの設定が、初期のMetaビルドで動作するとも限りません。

  • プロジェクト名：メンテナンス元と参照すべきドキュメントを確認します。
  • コアのバージョン：具体的な設定項目、プロトコルのオプション、修正が含まれているかを確認します。
  • クライアントのバージョン：画面、補助サービス、設定のマージ方法を確認します。
  • システムのバージョン：ネットワーク権限、サンドボックス、拡張機能の制限を確認します。

プロトコル対応の違い：ノード名だけでは種類を判断できない

ノード名は任意に設定できます。実際にどの方式で解析されるかを決めるのは、YAMLのtypeと関連項目です。たとえば「高速回線」という名前のノードでも、Trojanの場合もあればHysteria2の場合もあります。互換性を確認するには、サブスクリプションの実際の内容を確認してください。設定の一部を他の人に共有する前に、パスワード、UUID、サーバーアドレス、サブスクリプショントークンを削除しましょう。

確認項目 Clashオリジナル版 Clash Premium mihomo
SS、VMess、Trojanなどの基本プロトコル 一般的な設定に対応 一般的な設定に対応 対応。詳細なオプションはバージョンごとに要確認
VLESS・REALITY関連の設定 互換性の対象として想定しない 互換性の対象として想定しない 該当する設定に対応。項目の確認が必要
Hysteria2、TUIC これらの新しいプロトコルには非対応 完全対応とは見なさない 対応。プロトコルのバージョンとパラメーターを合わせる必要あり
TUN機能を内蔵 オリジナルのオープンソース版にはなし 過去の実装を提供 対応。プラットフォームと権限による制限あり
メンテナンス方針 過去の設定との互換性維持と既存環境の移行 過去の設定との互換性維持と既存環境の移行 プロジェクトのリリース履歴を継続的に確認

同じプロトコルでもパラメーターが異なる場合がある

特定のプロトコルに対応していても、すべてのトランスポート方式、暗号化方式、拡張オプションが使えるとは限りません。VLESSノードではflow、TLS、REALITY、トランスポート層の設定が関係する場合があります。TUICも、異なるプロトコルバージョンをそのまま混在させることはできません。ログにunsupported proxy typeと表示されたら、まずコアの種類を確認します。設定の読み込みは成功するのにハンドシェイクに失敗する場合は、認証情報、時刻、TLSパラメーター、ネットワークへの到達性を確認してください。

サブスクリプション変換でできるのは、入力内容を指定した形式に変換することだけです。コアにプロトコル実装を追加することはできません。Hysteria2ノードを「Clash」という名前のYAMLに変換しても、Clashオリジナル版がHysteria2に対応するわけではありません。変換先には、従来のClash互換形式を使うのか、mihomo向けの拡張形式を使うのかを明確に指定しましょう。

ルールとDNS：構文が似ていても、実行結果は同じとは限らない

DOMAIN、DOMAIN-SUFFIX、IP-CIDR、末尾のMATCHは、移行後も引き継ぎやすい一般的なルールです。ルールは上から順に評価され、先に一致したルールで通常、通信の出口が決まります。範囲の広いルールを前に置くと、後続の詳細なルールが適用されないことがあります。また、プロキシグループ名はルール内の参照先と完全に一致させる必要があります。ノードだけを移行して、グループ設定を漏らさないようにしてください。

ルールセットと拡張ルールは項目ごとに確認

  • 外部ルールセット：rule-providersの形式、配布元、更新方法と、RULE-SETの参照が有効かを確認します。Premiumやmihomoのルールセット機能がすべて使えると、あらゆるClashオリジナル版ビルドで想定しないでください。
  • 地理データ：GEOSITEなどのルールには、コアの対応と必要なデータファイルが欠かせません。ルールのテキストをコピーするだけでは、データのダウンロードや読み込みを代替できません。
  • プロセスルール：システムがプロセス情報を取得できるかどうかに依存します。macOSでの動作から、iOSのネットワーク拡張機能での動作をそのまま推測することはできません。
  • スクリプトによるポリシー：Premiumで使われていた過去のスクリプト構文は、mihomoの汎用互換インターフェースではありません。移行時は、明示的なルールとプロキシグループに置き換えることを優先しましょう。

DNS設定によってルールが認識できる情報が変わる

fake-ipとredir-hostは、DNSの動作モードが異なります。fake-ipはIPアドレスを割り当てて、コアがドメインと接続を関連付けられるようにします。一方、redir-hostは名前解決で得たアドレスを返します。どのネットワーク環境でも相互に切り替えられる設定ではありません。移行後に「ノードの遅延テストは成功するのに、Webページが開かない」場合は、DNSの上流への到達性、ドメインごとのルーティング、システムが実際にコアのDNSを使用しているかを確認してください。

macOSとiOSで異なるTUNの実装

システムプロキシとTUNでは、通信を取り込む場所が異なります。システムプロキシは、プロキシ設定に従うアプリが主な対象です。TUNは仮想ネットワークインターフェースとルーティングを通じて通信を受け取り、システムプロキシを参照しないアプリにも適用できます。ただし、すべての通信が必ずプロキシノードを経由するわけではありません。実際の出口は、ルーティング、除外設定、ルール、DIRECTポリシーによって決まります。

macOS：補助サービスとネットワーク拡張機能は別の仕組み

macOSクライアントでは、権限を持つ補助サービスを使ってTUNを作成する場合と、Appleのネットワーク拡張機能を使う場合があります。実装によって許可の手順は異なるため、「TUNを有効にする」ことが一律に「システム拡張機能の承認」を意味するわけではありません。macOS 13以降では、まず「システム設定」→「ネットワーク」でVPNとネットワークサービスの状態を確認してください。クライアントにシステムソフトウェアがブロックされたと明示された場合は、その案内に従って「システム設定」→「プライバシーとセキュリティ」で許可状態を確認します。

mihomoのTUN設定では、auto-route、auto-detect-interface、dns-hijackがよく使われます。自動で出口インターフェースを検出する設定は、一般的な単一回線の環境に適しています。ただし、複数のネットワークインターフェース、別のVPN、特殊なルーティング環境では、実際の動作を確認してください。macOSにutunインターフェースが表示されても、それだけではクライアントが通信を正常に取り込んでいる証明になりません。システムや別のVPNが同種のインターフェースを作成することもあります。

iOS：ネットワーク拡張機能とアプリの機能で動作が決まる

iPhoneやiPadでは通常、アプリのNetwork Extensionトンネル拡張機能を使ってネットワーク機能を動かします。macOS用の実行ファイルをコピーして使うことはできません。初回のトンネル作成時には、VPN構成の追加を確認する必要があります。追加後は「設定」→「一般」→「VPNとデバイス管理」で関連項目を確認できます。アプリがClash形式の設定を読み込めても、実際に対応するプロトコルや設定項目は、そのアプリのコアとドキュメントで確認してください。

したがって、「同じYAMLをMacで読み込めた」と分かるのは、Mac側で設定を解析できたことだけです。iOS側でもプロセスルール、ファイルパス、バックグラウンド更新の方法が完全に同じとは限りません。複数の端末で同じサブスクリプションを使う場合は、ノードと主要なルールを共通化しつつ、プラットフォームの権限、ファイルの保存場所、ネットワークの取り込み設定は端末ごとに管理しましょう。

mihomoへの移行：最小構成から段階的に戻す

以下は、設定の解析、ポートのバインド、基本ルールを確認するための最小構成です。DIRECTポリシーのみでプロキシノードは含まないため、リモートノードの接続確認には使えません。HTTPとSOCKSの混合ポートに7890を指定し、ローカルのループバックアドレスだけにバインドします。ポート番号はこの例で使用する値であり、すべてのクライアントに共通するデフォルト値ではありません。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

proxy-groups:
  - name: DIRECT-TEST
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,DIRECT-TEST

まず構文を確認し、次にネットワークを確認

コアを単独で実行する場合は、次のコマンドでバージョンを記録し、設定をテストできます。ファイルパスは現在のディレクトリを基準にしてください。GUIクライアントを使う場合は、その設定チェック機能で最終的なマージ結果を検証し、2つ目のコアを同時に起動してポートを競合させないようにしましょう。

./mihomo -v
./mihomo -t -f ./config.yaml
lsof -nP -iTCP:7890 -sTCP:LISTEN

-tの実行に成功しても、確認できるのは設定の構文だけです。ノード、DNS、ルールの動作まで検証されたわけではありません。チェックによってはローカルのリソースを読み込んだり、外部データを取得したりします。失敗した場合は、構文エラー、リソース不足、ネットワークリクエストの失敗を切り分けてください。ログにaddress already in useと表示されたら、まず別のクライアントが7890を使用していないか確認しましょう。エラーを回避するために、安易にLANからのアクセスを許可してはいけません。

  1. バックアップ：旧設定、コアのバージョン、クライアントの上書き設定、現在選択中のプロキシグループを保存し、すぐに戻せるコピーを残します。
  2. 基本動作を確認：TUNを無効にし、最小構成で設定の解析とローカルポートを確認してから、接続可能と分かっているノードを1つ読み込みます。
  3. ルーティングを段階的に戻す：プロキシグループ、ルール、ルールセット、DNSの順に追加します。一度に変更するのは1種類だけにし、接続が実際にどのルールに一致したかを確認してください。
  4. 最後にTUNを有効化：権限、デフォルトの出口、DNSの取り込みを確認してから、ブラウザー以外のアプリでもテストします。
  5. 元に戻せることを確認：新しいクライアントを終了し、システムプロキシとトンネルが無効になったことを確認してから旧バージョンに戻します。複数のツールが同時にルートを書き換えないようにしてください。

よくある質問：エラーメッセージから互換性の問題を特定

設定を読み込めるのに、有効化するとすぐ失敗するのはなぜ？

インポート時はYAMLの構造だけを確認し、有効化した段階で初めてコアに設定を渡すクライアントもあります。まず起動ログを見て、未対応のプロトコル、無効な項目、プロキシグループの参照先不足、リッスンポートの競合を切り分けてください。サービス事業者が複数のサブスクリプション形式を提供している場合は、URLの名前を何度も変更するのではなく、現在のコアに合った形式を選びましょう。

古いClash Metaの設定は、そのままmihomoで使える？

一般的なノードや基本ルールは引き継ぎやすいものの、すべての拡張項目、実験的な機能、デフォルト動作の互換性が保証されるわけではありません。まず設定チェックを実行し、リリースノートでDNS、TUN、プロトコルパラメーターの変更点を確認してください。エラーが出なくても、接続ログでルールの適用先と実際の出口を検証しましょう。

Appleシリコン搭載Macでノードの遅延が大きいのは、アーキテクチャの選択ミス？

遅延だけでアーキテクチャの選択ミスと判断するべきではありません。「アプリケーション」→「ユーティリティ」→「アクティビティモニタ」で関連プロセスの種類を確認し、クライアントとコアの動作状況を調べられます。ネットワーク遅延については、ノードの経路、DNS、テスト先、別のVPNの使用状況を確認してください。アプリ内の一度きりの遅延テストは、Webページ全体の読み込み時間を示すものではありません。

コアをアップデートしたら、すぐにTUNを有効にする必要はある？

必要ありません。まずシステムプロキシでノードとルールを確認すれば、権限、ルーティング、DNSの取り込みによる要因を減らせます。対象アプリがシステムプロキシを使わない場合や、より広い範囲の通信を取り込む必要がある場合に限り、TUNを個別に有効にしてください。具体的な問題はトラブルシューティングガイドを参照し、ログとネットワークの各層を確認しましょう。

最終的な選定では、次の3点を確認します。サブスクリプション内のプロトコルを解析できるか、必要なルールが正しく動作するか、使用中のAppleデバイスでネットワークを安定して取り込めるか。コア名は技術的な系統を把握する手がかりです。互換性の確認には、正確なバージョンと再現可能なテスト結果が必要です。