Clashオリジナル版、Clash Meta、mihomoの違い｜カーネル機能・対応プロトコル・設定構文を比較
Clashのオリジナル版・Premium・Meta・mihomoの系譜を整理し、プロトコルやルール、TUN機能を比較。mihomoへの設定移行で見直す項目も解説します。
まずはクライアント・カーネル・サブスク設定を区別する
「Clashが特定のプロトコルに対応しているか」は、ソフトの画面に表示された名前だけでは判断できません。GUIクライアントはサブスクの管理、設定の切り替え、システムプロキシのオン・オフ、ログの表示を担当します。カーネルはYAMLの解析、プロキシ接続の確立、ルールによる振り分け、DNS処理を担います。クライアントの画面が似ていても、同じカーネルが動作しているとは限りません。
サブスクは設定の取得元です。proxies、proxy-groups、rulesを含む完全な設定を返す場合もあれば、proxy-providersで読み込むプロキシ項目だけを返す場合もあります。リンクからデータを取得できたとしても、現在のカーネルがすべてのノードやルールを解析できるとは限りません。
- クライアントを選ぶ：対応OS、インストール方法、権限管理、設定の上書き方法を確認します。
- カーネルを選ぶ：必要なノードのプロトコル、ルール構文、DNS、TUN機能への対応を確認します。
- サブスク形式を選ぶ：提供元が返すのは完全なClash設定か、特定のカーネル向けの拡張設定かを確認します。
系譜を整理：オリジナル版・Premium・Meta・mihomo
Clashオリジナル版とClash Premium
一般にClashオリジナル版と呼ばれるのは、Dreamacro/clashのオープンソースプロジェクトです。Clash Premiumは同じ歴史的なエコシステムに属するクローズドソースの拡張カーネルで、TUN、ルールプロバイダー、スクリプトなどの機能を提供していました。Premiumの機能をオープンソース版のものとして扱うことはできません。また、名前にPremiumと付いていても、特定のGUIクライアントの有料版という意味ではありません。
2023年11月、Clashオリジナル版プロジェクトとPremiumの通常の公開メンテナンスは終了しました。古いバイナリが起動する場合はありますが、後続プロトコルへの対応、OSとの互換性、問題修正について、継続的なメンテナンスを前提にすることはできません。旧環境を比較テスト用に残すことと、日常のネット接続に使い続けることは、別々に判断する必要があります。
Clash Metaとmihomo
Clash MetaはClashのオープンソース派生版として始まり、従来の設定モデルにプロトコルやルール機能を追加しました。プロジェクト名は2023年末にmihomoへ変更されています。古い解説にあるMetaやClash.Meta、現在のmihomoは、通常、互いに無関係な3種類のカーネルではなく、同じプロジェクトの変遷を指します。
名称が変わっても、過去のすべてのバージョンが同じ機能を備えているとは限りません。サブスクの説明に「Meta対応」とあっても、対象がこの設定エコシステムに属することをおおまかに示すだけです。新しいプロトコル用のフィールドを使えるかは、実際に動作しているバージョンで確認してください。クライアントのダウンロードページに表示されるバージョンが、カーネルのバージョンとは限りません。
- クライアントの「バージョン情報」、カーネル管理画面、または起動ログでカーネル名とバージョンを確認します。
- 単体バイナリを使う場合は、
mihomo -vを実行して出力を記録します。 - クライアントのインストーラー名だけで判断せず、この結果をサブスクの要件や機能ドキュメントと照合します。
機能を比較：プロトコル・ルール・TUN
以下の表は移行先を判断するための目安であり、各バージョンの機能を網羅した一覧ではありません。特にプロトコルの伝送方式、暗号化方式、認証フィールドは、使用するバージョンごとに確認してください。同じプロトコルでも、パラメーターが合わなければ接続に失敗することがあります。
| 機能 | Clashオープンソース版 | Clash Premium | mihomo／Meta系 |
|---|---|---|---|
| 主なプロキシタイプ | SS、VMess、Trojan、SOCKS5、HTTPなどに対応 | Clashで一般的な従来のプロキシタイプに対応 | 従来のタイプに加え、VLESS、Hysteria2、TUICなどに対応 |
| VLESSとREALITY | 非対応 | 非対応 | 対応する設定をサポート。REALITYは関連するTLSハンドシェイク設定であり、独立したノードタイプではありません |
| 基本ルール | DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP、MATCHなど | 基本ルールに対応し、拡張機能も提供 | 基本ルールに加え、GEOSITEや論理ルールなどに対応 |
| rule-providersとRULE-SET | Premiumの機能を前提とした使い方はできません | 対応。ルールセットの形式を合わせる必要があります | 対応。より多くの形式や動作オプションを利用可能 |
| TUN | PremiumのようなTUN機能は内蔵していません | 対応。ただしプラットフォームや旧ビルドによる制限があります | 対応。プラットフォームの権限やネットワーク環境に依存します |
| Premium script | 非対応 | スクリプトによる通信振り分け機能を提供していました | Premiumのスクリプトを互換性のある設定としてそのまま読み込むことはできません |
プロトコルに対応していても、任意のノードをインポートできるとは限りません
たとえばVLESSノードでは、uuid、network、TLSパラメーター、REALITYの公開鍵などが必要になることがあります。ノードのtypeをvlessに変えるだけでは、これらのパラメーターは補われません。Hysteria2と旧Hysteriaも、名前が似ているという理由だけで設定を使い回すことはできません。
未対応のプロキシタイプが見つかったら、まずサブスクがmihomo向けに出力されているかを確認し、次にカーネルのバージョンを調べます。エラーを回避するために認証フィールドを削除したり、証明書検証を無効にしたりしないでください。設定の解析、リモートとのハンドシェイク、実際のリクエスト成功は、それぞれ別に確認が必要です。
古いYAML設定の移行：引き継ぐ項目と確認事項
基本的な設定の骨組みは、多くの場合そのまま引き継げます。ローカルの待ち受けポート、プロキシ項目、プロキシグループ、順序付きルールは引き続き使用できます。移行ではファイル全体の名称を変えるのではなく、カーネル固有のフィールドを整理し、クライアントからカーネルへ最終的に渡される実行時設定を確認します。
よくある設定項目の扱い
| 旧設定の項目 | 移行時の対応 | 確認ポイント |
|---|---|---|
mixed-port、mode |
通常は引き継ぎ可能。クライアントによる上書きを確認 | 実際の待ち受けアドレスとポート、現在のモードがruleかどうか |
proxies、proxy-groups |
プロトコルのフィールドと、グループ内で参照する名前を確認 | 大文字・小文字、空白、プロバイダー名が完全に一致しているか |
rule-providers |
behavior、format、ペイロードの構造を確認 | テキスト形式のルールセットとYAMLペイロードでは、解析方法を混同できません |
Premiumのscriptとscriptモード |
移行先カーネルが対応するルール、ルールセット、または論理ルールに書き換える | スクリプトを削除しただけで、振り分け動作が変わらないと判断しない |
tun、dns |
移行先カーネルとOSに合わせて再確認 | ルーティング、DNSの横取り、LAN内の名前解決が想定どおりか |
フィールド名よりルールの順序を見落としやすい
ルールは通常、上から順に照合され、一致すると対応するポリシーで処理されます。先頭にMATCHを置くと、それ以降の通常ルールが適用されません。RULE-SETが参照する名前は、rule-providersに定義されている必要があります。ルールが指定するポリシー名も、有効なプロキシ、プロキシグループ、または組み込みポリシーでなければなりません。
proxy-providersはプロキシノードを提供し、rule-providersは照合ルールを提供します。両者は置き換えられません。移行後に「プロバイダーが見つからない」と表示されたら、2種類の参照関係を確認してください。サブスクのURLを適当に入れ替えるのは避けましょう。
最小構成の設定と移行確認コマンド
まず元に戻しやすい設定でカーネルを検証してから、実際のサブスクを追加します。以下はmihomoの基本構成例です。ローカルの7890番ポートで混合プロキシを待ち受け、ルールモードを使用し、TUNは無効にしています。プロキシグループにはDIRECTだけを指定しているため、構造とルールの読み込み確認用であり、リモートプロキシへの接続は行いません。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups:
- name: PROXY
type: select
proxies:
- DIRECT
rules:
- DOMAIN-SUFFIX,example.com,PROXY
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,PROXY
tun:
enable: falseファイルをconfig.yamlとして保存したら、単独のターミナルで確認できます。以下のコマンドはmihomoがPATHに追加されている環境向けです。Windowsでは通常、コマンド名を.\mihomo.exeに置き換えてください。
mihomo -v
mkdir clash-test
mihomo -t -d ./clash-test -f ./config.yaml-tは現在のカーネルで設定を読み込めるかを確認するもので、リモートノードへの接続を保証するものではありません。テスト用ディレクトリは、キャッシュやリソースファイルが干渉しないよう、普段使うクライアントのデータディレクトリと分けてください。設定が外部ルールや地理データを参照する場合は、該当ファイルやダウンロード元が利用可能かも確認します。
- 元の設定をバックアップし、旧カーネルのバージョン、ポート、適用中の上書き設定を記録します。
- 実際のサブスクを移行先クライアントに読み込み、まずTUNを無効にして通常のプロキシ接続だけを確認します。
- 起動ログで未対応のタイプ、ファイル不足、無効な参照、ポートの使用中エラーを確認します。
- 移行先クライアントの接続ログで適用ルールと実際の出口を確認してから、DNS、ルールセット、TUNを一つずつ有効に戻します。
ローカルのHTTPプロキシ接続を確認するには、curl -x http://127.0.0.1:7890 https://example.com/を実行します。このコマンドはプロキシポートを明示的に指定するため、システムプロキシの設定が有効かどうかは確認できません。また、上記のサンプル設定では最終的に直接接続されます。
TUNとDNS：古い設定のスイッチをそのまま引き継がない
システムプロキシが影響するのは、通常、OSのプロキシ設定を参照するアプリだけです。TUNは仮想ネットワークインターフェースとルーティングで通信を取り込み、より多くのアプリの通信を処理したい場合に役立ちます。ただし、有効にすればすべての通信が必ずプロキシを通るわけではありません。カーネルはルールに従って直通、プロキシ、拒否を決定し、ルートの除外設定や他のVPNも結果に影響します。
まず権限とルーティングを確認する
- Windows：クライアントが要求するサービスモードや管理者権限を確認します。設定画面の場所は、使用中のクライアントのバージョンによって異なります。
- Linux：TUNデバイス、プロセスのケイパビリティまたはroot権限、既存のルーティングテーブルを確認します。
- macOS：クライアントの補助サービスとシステムの許可を確認し、ルートを取り合う複数のVPNを同時に有効にしないようにします。
mihomoのTUN設定では、auto-route、auto-detect-interface、stack、dns-hijackなどを使います。これらのフィールドはプラットフォームの設定と合わせて確認してください。あるOSで動いた設定が、すべてのOSで標準的に使えるとは限りません。変更前の値を記録し、機能ごとに一つずつ調整すると、権限の問題とDNSの問題を切り分けやすくなります。
DNSが引けても、通信の振り分けが正しいとは限らない
fake-ipモードはアドレスのマッピングを利用してドメイン名を復元しやすくします。一方、redir-hostは実際の名前解決結果を返す方式です。ドメインの識別やアプリとの互換性への影響は異なります。移行時はenhanced-mode、fake-ip-filter、上流DNS、LAN内ドメインの処理をまとめて確認してください。
DNSの横取り先としてよく使われるのは、通常のDNSが利用する53番ポートです。アプリ内蔵のDoHは通常、HTTPSの443番ポートで通信するため、53番ポートを対象としたルールで自動的に処理されるとは限りません。ブラウザーとほかのアプリで結果が異なる場合は、ノードを何度も切り替えるのではなく、ブラウザーのセキュアDNS、キャッシュ、カーネルの接続ログを確認してください。
選び方の結論と移行後の確認リスト
新しい設定でVLESS、REALITY、Hysteria2、TUIC、または拡張ルール機能が必要なら、必要な機能に対応すると明記されたmihomoのバージョンを選び、クライアントが実際にそのカーネルを使っていることを確認してください。古いSS、VMess、Trojanの設定を移行するだけなら、基本構成は引き継げる場合が多いものの、DNS、スクリプトによる振り分け、TUNは個別に検証が必要です。
オリジナル版とPremiumは、過去の設定を理解したり、古い動作を再現したりする用途に向いています。mihomoへ移行する利点は、対応プロトコルやルール機能を利用でき、カーネルの実装も継続的に更新されることです。ただし、無効なサブスク、誤った認証情報、接続できないサーバーが自動で修復されるわけではありません。
- バージョン：クライアントのバージョンだけでなく、実際のカーネル名とバージョンを記録した。
- 設定：構文チェックに合格し、ノード、プロキシグループ、ルールプロバイダーの参照に漏れがない。
- ポート：ローカルの接続先とアプリの設定が一致し、旧クライアントと7890などのポートを同時に使用していない。
- 振り分け：直通リクエストとプロキシ経由のリクエストを少なくとも1件ずつ確認し、ログのポリシーが想定どおりである。
- TUN：権限、ルーティング、DNSを確認してから継続利用し、クライアント終了後にネットワークが復旧する。
- 更新：サブスクを手動で一度更新し、カスタム上書きが残っていることを確認してから自動更新を有効にする。
フィールドの意味はプロトコルリファレンスで確認できます。インポート失敗、ポート競合、システムプロキシの不具合が起きた場合は、ヘルプセンターで症状から原因を調べてください。移行後は、まず通常のプロキシ接続を確認し、その後TUNや複雑なルールを追加すると、問題を切り分けやすくなります。