Clashコアの互換性比較

クライアント・コア・設定を切り分ける

Clashクライアントの名前だけでは、実際に使える機能は判断できません。画面側はサブスクリプションの取り込みや設定管理、システムプロキシの設定を担当し、コアはノードの解析、ポートの待ち受け、ルール判定、接続の確立を担います。同じクライアントでも、配布バージョンによって同梱されるコアが異なる場合があります。サブスクリプションが使えるかどうかは、デスクトップのショートカット名ではなく、実際に動作しているコアで判断しましょう。

この記事でいう「旧版」は初期のClashオープンソースコアを指し、Premiumは当時提供されていたクローズドソースの拡張コアを指します。両者は同じものではありません。オープンソース版の開発とPremiumの従来の公開配布が2023年に終了した後も、古いプログラムが起動することはあります。しかし、それだけで新しいプロトコルへの対応やOSとの互換性が継続しているとは限りません。

3段階で確認する

1. クライアント：カスタムルールの保存、サブスクリプションの更新、TUNに必要な権限の取得ができるか。
2. コア：ノードのtype、トランスポート設定、DNS項目を認識するか。
3. 実行時の設定：画面での操作、サブスクリプション変換、設定のマージ後に、コアへ渡される最終的なYAMLが想定どおりか。

たとえば、エディターでmixed-port: 7890を保存しても、クライアント側のポート上書きによって別の値に変更されることがあります。調査時は、ローカルに保存したサブスクリプションの内容だけでなく、クライアントの設定と実行時の設定も確認しましょう。

旧版・Premium・mihomoの比較

以下の表は各コア系統のおおまかな対応範囲を比較したもので、過去のすべてのバージョンを保証するものではありません。特にmihomoでは、新しいプロトコルや設定項目、ルール形式にバージョン要件があります。「mihomoを使っている」だけでは、古いバイナリが現在の設定をすべて扱えるとは限りません。

Premiumという名称だけで、現在もmihomoより多機能だとは判断できません。また、利用にサブスクリプションの購入が必要という意味でもありません。コアの系統、クライアントの配布形態、プロキシサービスの契約は、それぞれ別のものです。サブスクリプション経由でサーバーに接続できるかどうかは、サーバー側の設定、認証情報、ネットワーク経路、証明書の設定にも左右されます。

プロトコルは個々のパラメーターまで確認する

プロトコル名を認識しても接続できるとは限らない

ノードにtype: vless、type: hysteria2、type: tuicが指定されている場合は、これらに明確に対応したバージョンのmihomoを選びましょう。ノードの種類を示す文字列をvmessやtrojanに書き換えても、プロトコルは変換されません。サーバー側にも、該当プロトコルの接続口が必要です。

どちらのコアもtype: ssを認識できたとしても、対応する暗号化方式は異なる場合があります。「Shadowsocks対応」という説明だけで、Shadowsocks 2022系の方式も使えるとは判断できません。同様に、VLESSのREALITY設定、トランスポート方式、フィンガープリントも、サーバー側の設定と一致し、使用するコアのバージョンが対応している必要があります。

• 解析時に「不明なタイプ」と表示される：まずコアの系統、バージョン、サブスクリプションの形式を確認します。
• 項目がない、またはパラメーターが不正と表示される：そのバージョンの設定ドキュメントを参照し、項目名、階層、データ型を確認します。
• 設定の読み込みは成功するが、ハンドシェイクに失敗する：ルールの順序を変更するのではなく、サーバーアドレス、ポート、認証、SNI、証明書関連の設定を確認します。
• Webページは表示できるが、UDPを使うアプリが失敗する：ノード、サーバー側、ローカルの通信経路がすべてUDPに対応しているか確認します。

サブスクリプション形式にも互換性の限界がある

「Clash用サブスクリプション」は、対応バージョンを正確に示す言葉ではありません。サービス提供者によって、旧版向けの簡易設定が用意されていることも、mihomoの拡張機能を含む設定が配布されていることもあります。サブスクリプション変換を経由して取り込む場合、変換ツールが認識できないノードや設定項目を削除することもあります。ノード数が減った場合は、元の応答、変換後の結果、クライアントの実行時設定を比較し、どの段階で内容が変わったか確認してください。

設定の互換性：基本項目から拡張項目まで

移行時は、待ち受けポート、基本的なプロキシグループ、一般的なルールを残し、拡張機能をひとつずつ追加していくとよいでしょう。以下はmihomoで読み込めるかを確認するための最小構成で、リモートのプロキシノードは含みません。「出口選択」には直接接続しかなく、プロキシサーバーへの接続確認には使えません。

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,出口選択

7890は、この例でHTTPとSOCKSに共用するローカルポートです。すべてのクライアントで固定の既定値というわけではありません。allow-lan: falseは、LANからのアクセスを制限します。取り込む前に別のプログラムが同じポートを使用している場合は、ポートを変更するか、競合しているプロセスを停止してください。同じ待ち受けポートを使うコアを2つ同時に起動しないでください。

ルールの順序とポリシー参照も重要

一般的なルールは上から順に評価されます。先に一致したルールが接続先を決めると、後続のルールは適用されません。MATCHは最後のフォールバックとして配置します。ルール末尾で参照するポリシー名は実際に存在し、記述が完全に一致している必要があります。コアを移行しても、誤記されたポリシーグループ名は自動修正されません。

no-resolveはIP系のルールでよく使われ、ルール判定のためにドメイン名の解決を行わないことを示します。リクエスト全体でDNSを一切使わないという意味ではありません。rule-providersを導入する場合は、behavior、formatとルールファイルの内容が一致しているかも確認します。ドメイン名だけのリストを、完全なルール文を含むclassical形式のルールセットとして扱うことはできません。

Premiumのスクリプトをそのまま流用しない

Premiumのスクリプト機能を、mihomoで共通して使える互換インターフェースと見なすことはできません。古い設定にscriptが含まれている場合は、使用するコアが同じ仕組みに対応しているか確認してから、ルールセット、論理ルール、ポリシーグループへの置き換えを検討してください。YAMLを読み込めても、すべての未知の項目が反映されるとは限りません。無視される項目もあるため、実際の接続ログでルールの適用状況を確認しましょう。

DNSとTUNは別々に確認する

Fake-IP、DNSの振り分け、TUNはチュートリアルで一緒に扱われることが多いものの、それぞれ役割が異なります。DNSモジュールは名前解決とアドレスの対応付けを処理し、TUNは仮想ネットワークインターフェースとルーティングを通じて通信を取り込みます。TUNを有効にしただけで、すべてのDNSクエリが想定どおりに処理されるとは限りません。また、DNSチェックページに表示されるサービス名だけでは、コアの互換性を判断できません。

DNS設定の移行時に確認する4項目

1. 待ち受けアドレス：たとえば127.0.0.1:1053はローカルホストからのみ利用できます。システムが別のアドレスへ問い合わせている場合、コアのDNSが使われないことがあります。
2. 拡張モード：enhanced-modeがfake-ipとredir-hostのどちらを使うか確認します。以前の画面でのスイッチ状態だけを引き継がないでください。
3. 名前解決の振り分け：nameserver、fallback、nameserver-policyの実際の意味を確認します。fallbackは、メインのリゾルバーがタイムアウトした際の予備アドレスと単純に解釈できるものではありません。
4. 追加の名前解決経路：ブラウザーのセキュアDNS、アプリ内蔵のDoH、ルーターのDNS転送によって、想定していた名前解決経路が迂回されることがあります。

TUNを有効にしても、すべての通信がプロキシ経由になるわけではない

mihomoのtun.enable、auto-route、dns-hijackは、それぞれ仮想ネットワークインターフェースの有効化、ルート設定、指定したDNS通信のリダイレクトを担います。最終的な接続先はルールで決まり、DIRECTに一致した通信は直接接続されます。権限不足、ルートの競合、VPNの同時利用などにより、一部の通信が取り込まれないこともあります。

古い解説との互換性を保つために、stackの値をそのままコピーしないでください。利用できるスタックとその動作は、コアのバージョンやOSによって異なります。まずはクライアントが現在のプラットフォーム向けに用意している既定値を使い、具体的な問題に応じて調整しましょう。テストでは、まずTUNを無効にしてシステムプロキシを確認し、ノードが正常に動作することを確かめてからTUNを有効にすると、同時に変わる要因を減らせます。

移行前後の動作を確認する方法

移行には、元に戻せる設定のコピーを使いましょう。旧コアの名称とバージョン、待ち受けポート、サブスクリプションの更新日時を記録してから、設定を複製してテストします。コマンドラインを使う場合は、実際に使用するバイナリに対して以下の確認を実行できます。デスクトップクライアントの場合はコアのログを確認し、テスト対象がクライアントによって実際に起動されたコアであることを確かめてください。

mihomo -v
mihomo -t -f ./config.yaml

1つ目のコマンドでバージョンを確認し、2つ目で設定を解析・読み込みできるかチェックします。検査に通っても、確認できるのは設定が所定の条件を満たしていることだけです。リモートノードとのハンドシェイク、DNS経路の正しさ、TUNルートの有効性までは保証されません。設定からリモートのルールやノードプロバイダーを参照している場合は、必要なリソースを取得できるかも確認してください。

不具合が起きた場合は、「読み込み失敗 → ローカル待ち受け → ノード接続 → ルール適用 → DNS/TUN」の順に確認します。一度に変更する項目はひとつにしましょう。詳しい一般的な確認方法はトラブル対処を、初めて設定を取り込む場合は設定ガイドを参照してください。

クライアント選びの最終チェック

• 新規導入：メンテナンスが継続され、使用するmihomoのバージョンが明記されたクライアントを優先し、OSとCPUアーキテクチャも確認します。
• 安定稼働中の旧環境：まず動作する設定を複製して残し、新しいサブスクリプションに旧コアが対応していないプロトコルが含まれていないか確認します。設定全体をすぐに上書きしないでください。
• TUNが必要：コアの機能だけでなく、クライアントが必要な権限を取得し、サービスを管理できること、終了時にルートを削除することも確認します。
• 複雑なルールが必要：ルールプロバイダー、論理マッチング、設定の永続化と上書き方法を重点的に確認し、サブスクリプションの更新でローカルの変更が削除されないか確かめます。

選定は、実際に動作しているコアのバージョン、設定検査の結果、ログに記録されたプロトコルエラー、接続ログに表示されるルールと出口など、確認可能な情報をもとに判断しましょう。Metaとmihomoの名称の違いは主な問題ではありません。移行時によく起きるのは、古いバイナリ、拡張設定項目、クライアントによる上書きの不整合です。