まず名称を整理：クライアント、カーネル、プロジェクトの変遷
Clash無印版、Clash.Meta、mihomoを比較する前に、「クライアント」と「カーネル」を分けて考えましょう。カーネルはYAML設定の読み込み、プロキシ接続の確立、ルール照合、DNS処理を担い、GUIに制御インターフェースを提供します。一方、デスクトップクライアントはサブスクリプション管理、設定の切り替え、システムプロキシのオン・オフ、ログ確認、アップデートなどを担当します。画面に表示されるアプリ名が、実際に呼び出しているカーネル名と一致するとは限りません。同じGUIクライアントでも、バージョンによってカーネルが変わる場合があります。
一般にClash無印版とは、Dreamacroが保守していた従来のClashオープンソースカーネルと、その設定体系を指します。プロキシノード、プロキシグループ、ルール、外部コントローラーといった基本構造を確立し、多くのサブスクリプション変換サービスやGUIクライアントがこの形式を基盤にしています。過去には機能範囲の異なるPremiumビルドも存在したため、「Clash」と表示されているだけで対応フィールドを判断することはできません。
Clash.Metaは当初、Clashの設定思想との互換性を保ちながら、対応プロキシプロトコル、DNSオプション、ルール機能、透過プロキシ関連機能を拡張したカーネルでした。その後、プロジェクト名は正式にmihomoへ変更されています。Clash.Metaとmihomoは、まったく別のカーネルを二者択一する関係ではなく、同じプロジェクトの前後の呼び名と考えると分かりやすいでしょう。古い解説にあるMeta設定や、旧クライアントのMeta Coreは、多くの場合、現在のmihomo系に相当します。
Clash無印版のプロジェクトが活発な保守を終了した後も、エコシステムまで名称とともに止まったわけではありません。サブスクリプション形式、ルール構文、制御インターフェースは今も多くのソフトウェアで使われ、継続的に更新されるクライアントは次第にmihomoへ移行しました。新規インストールや長期運用では、最初期の名称を探すのではなく、保守状況、プラットフォーム対応、必要なプロトコル、設定フィールドの適合性を確認することが重要です。
対応機能：共通基盤とmihomoの拡張
両系統のカーネルに共通する基本機能には、YAML設定、プロキシノード、プロキシグループ、ドメイン・IPルール、DIRECTとREJECTのアクション、HTTP/SOCKS混在ポート、外部制御インターフェースがあります。一般的なノード、単純なプロキシグループ、基本ルールだけを含む設定なら、違いを意識しないこともあります。差が出やすいのは、サブスクリプションに新しいプロトコルが含まれる場合、複雑なDNSを使う場合、TUNモードを有効にする場合、大規模なリモートルールセットを読み込む場合です。
プロキシプロトコルと通信パラメータ
Clash無印版は、保守されていた時期に主流だったプロトコルに対応しますが、その後登場した新しいプロトコル、暗号方式、トランスポート拡張が自動的に追加されるわけではありません。mihomoは従来の設定との互換性を保ちながら、プロトコル実装とパラメータ項目を継続的に拡張しています。サブスクリプションのノードが「未対応のタイプ」と表示される場合や、ログにプロキシフィールドを解析できないと出る場合は、同じサブスクリプションを何度も再インポートするのではなく、まずカーネルを確認してください。
プロトコルの数だけが判断基準ではありません。ノードの種類が同じでも、TLSフィンガープリント、UDP、多重化、トランスポート層、証明書関連パラメータの対応範囲はカーネルによって異なる場合があります。選定時はノード名が一覧に表示されるかだけでなく、実際にサブスクリプションが生成するフィールドを確認しましょう。画面にノードが表示されても、接続パラメータが完全に認識されているとは限りません。
DNSとルールシステム
従来のClash設定には、ドメインルール、IPルール、GEOIP、ルールプロバイダーなど、一般的な構造がすでに備わっています。mihomoはこれを基盤に、より豊富なDNS処理方式、ルールセット機能、マッチングオプションを提供します。中国本土と海外の名前解決を分けたい場合、Fake IPの例外を扱う場合、大規模なルールセットを読み込む場合、通信を細かく制御したい場合に適しています。具体的なフィールドはカーネルのバージョンによって変わるため、現在のカーネルドキュメントと起動ログを基準にしてください。
ルール機能が増えるほど、設定ミスが長いファイルの中に埋もれやすくなります。たとえば、ルールセット名は宣言されているのに参照先へアクセスできない、DNSのnameserverには接続できるのに現在のルーティングルールによって再びプロキシへ送られてループする、ルールの順序は正しいのに前方の広範なマッチによって後方の細かな条件へ到達しない、といった問題です。カーネルのアップデートだけでルールの確認を代替することはできません。ログに記録されるマッチ結果が、引き続き主要な判断材料です。
TUNと透過プロキシ
システムプロキシは、OSのプロキシ設定を参照するアプリに主に作用します。TUNモードは仮想ネットワークインターフェースを通じて、より広い範囲のIP通信を取り込みます。システムプロキシに従わないアプリ、UDPが必要なアプリ、アプリ通信を一括処理したい環境に適しています。Clash無印版はビルドによってTUN対応が完全には統一されていません。一方、mihomoはTUNスタック、ルーティング、DNS横取り、プラットフォーム固有のオプションを継続的に保守しているため、現在のデスクトップクライアントやゲートウェイ環境ではmihomoが選ばれる傾向にあります。
TUNを有効にしたからといって、インストール直後から通信が速くなるわけではありません。権限、ルーティングテーブル、仮想NIC、ファイアウォール、DNS経路など、追加の要素が発生します。Web閲覧が中心でアプリがシステムプロキシに従うなら、システムプロキシのほうが管理しやすいことが多いでしょう。ゲーム、コマンドラインツール、サンドボックスアプリ、個別にプロキシを設定できないソフトウェアまで取り込みたい場合に、TUNを有効にするのが適切です。
設定の互換性：基本設定は読み込めても、拡張フィールドの逆方向互換は保証されない
mihomoはClash設定エコシステムを引き継ぐことを設計目標の一つとしているため、従来のポート、ノード、プロキシグループ、ルール構造は通常そのまま読み込めます。ただし、互換性は「新しいカーネルが古い形式を読む」関係に近く、どの方向でも完全に同等という意味ではありません。mihomo専用のプロトコル、ルールタイプ、DNSフィールド、TUNパラメータを使った設定をClash無印版へ渡すと、起動失敗、未知のフィールドの無視、ノードの欠落、動作の変化が起こる可能性があります。
以下は基本的な構造例です。ノード、プロキシグループ、ルールの参照関係を示すもので、そのまま本番環境へ投入できる設定ではありません。サーバーアドレスと認証情報は実際のサブスクリプションから取得してください。
mixed-port: 7890
mode: rule
log-level: info
proxies:
- name: example-node
type: socks5
server: 192.0.2.10
port: 1080
username: demo
password: demo
proxy-groups:
- name: PROXY
type: select
proxies:
- example-node
- DIRECT
rules:
- DOMAIN-SUFFIX,example.org,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXYこのような設定を移行するとき、最初に確認すべきなのはインデント以外の見た目ではなく、参照関係です。プロキシグループ内のノード名はノード定義と完全に一致させ、ルール末尾のプロキシ名は実在するものにし、リモートプロバイダーの名前もプロキシグループやルールからの参照先と一致させる必要があります。YAMLはインデントに敏感です。タブとスペースの混在、コロンの後のスペース不足、同じ階層のフィールドのインデントずれは、読み込み失敗の原因になります。
サブスクリプションURLは固定のカーネル形式を意味しない
サブスクリプションサービスは、クライアントのリクエストヘッダー、URLパラメータ、変換テンプレートに応じて異なる内容を返すことがあります。同じサブスクリプションURLでも、あるクライアントではClashの基本形式、別のクライアントではmihomoの拡張フィールドを含む設定が返される場合があります。クライアント移行後にノード数が変わっても、すぐにサブスクリプションの障害とは判断しないでください。まず設定を書き出し、ノードタイプ、プロキシプロバイダー、プロキシグループ、ルールセットの各フィールドを比較しましょう。
クライアントによってはサブスクリプションの入口だけを保存し、更新時にローカル編集を上書きします。ルールを追加したい場合は、クライアントが上書き設定、拡張スクリプト、設定のマージ機能を提供しているか確認してください。キャッシュファイルを直接編集しても、次回のサブスクリプション更新までしか維持できないことが多いです。カーネルは最終設定を解釈し、クライアントはサブスクリプションのダウンロード、変換、マージを決めます。この二つの工程を分けて確認してください。
制御インターフェースは似ていても、管理画面には対応関係が必要
多くのClash管理パネルは、外部コントローラーを通じてプロキシ、接続、ルール、ログを読み取ります。mihomoは一般的なインターフェースの多くを引き継いでいるため、古いパネルでも動作する場合があります。ただし、新機能が旧画面に完全に表示されるとは限りません。カーネルが正常に動作しているのに画面に特定の設定が表示されない場合、カーネル設定が無効なのではなく、クライアントやパネルがその制御項目にまだ対応していない可能性があります。
用途別の選び方：デスクトップ、サーバー、既存設定を分けて判断
新しくデスクトップクライアントをインストールする場合
Windows、macOS、Linuxのデスクトップ環境に新規インストールするなら、現在も保守が続き、mihomoカーネルの採用を明記しているクライアントを優先してください。新しいプロトコルへの対応、最近のOSへの適合、継続的な修正を受けやすくなります。インストーラーを選ぶ際は、OSのバージョンとCPUアーキテクチャも確認しましょう。x64とARM64は、ファイルサイズだけでは判断できません。
デスクトップでサブスクリプションを取り込み、プロキシグループを選び、システムプロキシを有効にするだけなら、「機能が多いから」といって最初から高度な設定を変更する必要はありません。まずはクライアントが生成した標準のポートとDNS設定を使い、ブラウザーのアクセス、ルール切り替え、切断後の復旧が正常か確認してください。その後、必要に応じてTUNを有効にします。初回の設定項目を減らすほど、トラブルの切り分けは簡単になります。
サーバー、ルーター、コンテナへの導入
サーバーや透過ゲートウェイには、完全なGUIがないことが多いため、カーネル自体のアーキテクチャ向けビルド、起動パラメータ、設定パス、サービス管理方法が重要になります。mihomoは、ルールセット、透過プロキシ、リモート制御、継続的な更新が必要な環境に適しています。ただし、実行権限、転送ルール、DNSの入口、ログローテーションも同時に整備する必要があります。コンテナでTUNを有効にする場合は、適切なデバイスとネットワーク権限をコンテナへ付与してください。
ゲートウェイ環境では、デスクトップ用設定をそのまま流用しないでください。デスクトップの待受アドレスはローカルホストだけにバインドされていることがあります。LAN上で使う場合は、許可するインターフェースとアクセス制御を明確にしてください。外部コントローラーも、認証やネットワーク制限なしで公開してはいけません。ルール数が多い場合は、起動時間、メモリ使用量、リモートルール更新に失敗したときの動作にも注意が必要です。
現在も安定して動作しているClash無印版の設定
機能がシンプルで、実行環境が固定され、現在の接続も安定しているClash無印版の設定なら、名称が変わっただけですぐに書き直す必要はありません。より安全なのは、隔離したディレクトリにmihomoを用意し、設定をコピーして構文チェックと並行検証を行う方法です。ノード、プロキシグループ、DNSの結果、ルールのマッチが一致することを確認してから、サービスを切り替えましょう。
古いカーネルを使い続ける主な制限は、今後のプロトコルやシステムの変化に継続対応できないことです。サブスクリプション提供元がノードタイプを変更すると、古いカーネルでは突然解析できなくなる可能性があります。OSのアップデート後に、旧クライアントで権限、トレイ、仮想NIC、署名の互換性に問題が出ることもあります。利用できる設定は保管しつつ、移行ルートも準備しておきましょう。
古いフィールドや旧クライアントへの依存が残っている場合
自動化スクリプト、管理パネル、組み込み機器の中には、特定のClash APIやファイル構成だけを前提に作られたものがあります。まず依存している対象が、設定構文、制御インターフェース、バイナリ名、起動パラメータのどれなのかを確認してください。mihomoは適切なパラメータやパスを設定することで、多くの処理と互換性を持たせられますが、周辺ツールをすべて無調整で使えるとは限りません。既存のコントローラーや待受ポートとの競合を避けるため、まずテスト用ポートで実行してください。
Clash無印版からmihomoへ移行する手順：項目別チェック
- 現状を記録する。元の設定、サブスクリプションURL、クライアントのバージョン、カーネルのバージョン、待受ポート、現在有効なプロキシモードを保存します。問題が起きた場合も、正確に元へ戻して比較できます。
- 環境に合うビルドを選ぶ。OSとCPUアーキテクチャを確認します。デスクトップクライアントでは内蔵カーネルの種類を確認し、コマンドライン環境では対象プラットフォーム向けのmihomo実行ファイルをダウンロードしてください。
- まず設定を検証する。稼働中のサービスを最初から置き換えないでください。新しいカーネルでYAMLを検査し、未対応のプロキシタイプ、重複ポート、存在しないプロキシグループ、読み込めないプロバイダーを処理します。
- 起動ログを確認する。設定の解析、ルールセットのダウンロード、DNSの待受、外部コントローラー、TUNデバイス、ポートの使用状況を重点的に確認します。ログに「起動完了」と出ても、すべてのリモートリソースの読み込みが成功したとは限りません。
- プロキシグループを検証する。手動選択、自動速度テスト、フォールバックなどのプロキシグループを一つずつ確認し、想定したノードが含まれているか調べます。サブスクリプション変換後にノード名が変わると、古い参照が無効になることがあります。
- DNSを検証する。日本国内のドメイン、プロキシ経由の対象ドメイン、IPアドレスだけを使った接続をそれぞれ確認します。ブラウザーでは開けるのにコマンドラインでは失敗する、またはドメインだけ失敗してIPでは接続できる場合は、まずDNSの待受と横取り経路を確認してください。
- 最後にTUNを有効にする。システムプロキシモードが正常に動作することを確認してから、仮想NICによる通信の取り込みをテストします。ネットワーク全体が切断された場合は、管理者権限、デフォルトルート、DNS横取り、他のVPNソフト、ファイアウォールルールを確認してください。
移行時によくあるミス
- クライアントはアップデートしたのに、実際のカーネルは旧バージョンのまま。画面に表示されるクライアントのバージョンと、カーネルのバージョンを混同している。
- Metaとmihomoを互いに無関係な二つの形式だと考え、サブスクリプションを何度も変換した結果、プロキシグループやルールが二重に加工される。
- mihomo専用フィールドをClash無印版へそのままコピーし、設定の読み込み時になって初めて、タイプやパラメータが未対応だと気づく。
- ホームページが開くかだけを確認し、ルールのマッチ、UDP、DNS、LANアクセス、切断後のネットワーク復旧を確認していない。
- システムプロキシとTUNを同時に有効にして異常が起きたのに、二つの通信取り込み経路を別々にテストしていない。
新しいカーネルの起動後にネットワークが完全に使えなくなった場合は、まずモードをルールモードの基本設定へ戻し、TUNを一時的に無効にしてください。混在ポートの待受、ノードのハンドシェイク、プロキシグループの選択に問題がないことを確認してから、DNS拡張とルールセットを一つずつ戻します。高度なオプションを一度にすべて読み込むより、段階的に有効化するほうが原因を特定しやすくなります。
まとめ：新規導入はmihomoを優先、既存設定は必要に応じて移行
Clash無印版は、現在も広く使われている設定とルールの基盤を築きました。Clash.Metaは拡張路線における旧称で、mihomoは現在使われているプロジェクト名です。三者は単純なバージョン番号の上下関係ではなく、保守段階、機能範囲、エコシステムの継承関係でつながっています。
デスクトップクライアントを新規導入する場合や、最新プロトコル、複雑なDNS、ルールセット、TUNが必要な場合は、mihomoの採用を明記し、継続的に保守されているクライアントを選ぶのが一般的です。既存のClash無印版設定が長期間安定しているなら、まず保管し、テスト環境で移行を完了させてから切り替えましょう。適性を判断する確かな基準は名称ではありません。現在のカーネルがサブスクリプションを完全に解析し、ルールを正しく実行し、OSに適合し、継続的な更新経路を提供できるかどうかです。
インストール後は、まずカーネル情報を確認してからサブスクリプションを取り込みます。まずシステムプロキシを検証し、用途に応じてTUNを有効にします。まず起動ログを確認し、その後で高度なフィールドを変更してください。この順序で進めれば、Clash無印版、Meta、mihomoの名称の違いがトラブル対処の妨げになることはありません。