コア・クライアント・サブスクリプション形式を区別する
Clashの設定が使えるか判断するには、デスクトップのアイコンではなく、実際に動作しているコアを確認します。コアはYAMLの解析、プロキシ接続の確立、ルールの適用、DNS処理を担当します。クライアントは設定のインポート、システムプロキシの切り替え、サービスの管理、画面表示を担当します。同じ名前のクライアントでも、配布版やコアの切り替え、カスタムコアのパスによって、実際に動くプログラムが異なる場合があります。
サブスクリプションは設定の取得元です。完全な設定を返す場合もあれば、プロキシノードの一覧だけを返す場合もあります。配布元のページに「Clash」と書かれていても、すべてのノードをオリジナル版Clashで認識できるとは限りません。vless、hysteria2、reality-optsなどが含まれている場合は、コアと具体的なバージョンを確認してください。
- コアの確認：起動ログやコア情報の画面を確認するか、コアのバージョン表示コマンドを実行します。
- 実際に使われる設定：サブスクリプションの元データだけでなく、クライアントがマージや上書きを行った後、コアに渡す設定を確認します。
- 失敗した段階：設定の解析エラー、ルールの読み込みエラー、ノードへの接続エラーを区別します。それぞれ対処方法が異なります。
名称の変遷：オリジナル版、Premium、Meta、mihomo
オリジナル版ClashとClash Premiumは対応機能が異なる
オリジナル版Clashは、一般にDreamacroが公開したオープンソースのClashコアを指します。一方、Clash Premiumは、オリジナル開発者がかつて公開していたクローズドソースの拡張コアで、TUN、ルールセット、スクリプトなどの機能が追加されていました。Premiumの機能がすべてのClashクライアントに標準搭載されているわけではありません。オリジナル版のオープンソースコアとPremiumの設定項目も、混同しないようにしましょう。
2023年に元プロジェクトの公開メンテナンスが終了した後も、これらのコアを引き続き搭載する旧クライアントがあります。既存の設定が動作する場合はありますが、サブスクリプションを更新しても新しいプロトコルが自動で使えるようになるわけではありません。旧版のインストーラーが起動することと、現在のサブスクリプションを処理できることは、別々に確認する必要があります。
Clash Metaからmihomoへ名称変更
Clash MetaはClashの系統から派生した拡張ブランチで、後にmihomoへ名称が変更されました。両者は同じプロジェクトの発展過程にあり、設定を全面的に書き換える必要のある無関係なコアが2つあるわけではありません。クライアントの画面に「Meta」と表示されていても、実際には後継のmihomoビルドを指している場合があります。
ただし、プロジェクトが継続しているからといって、あらゆるバージョンに完全な互換性があるわけではありません。初期のMetaビルドでは、後のmihomoで追加された設定項目やプロトコルに対応していないことがあります。過去の機能が変更または削除されている場合もあります。移行時はバージョン情報をすべて記録し、そのバージョンに対応した設定ドキュメントと起動時の検証結果を確認してください。
| 名称 | 位置づけ | 移行時の確認事項 |
|---|---|---|
| オリジナル版Clash | オープンソースの基本コア | 基本的なプロトコル、ルール、DNSに対応。Premium専用の設定は使わない |
| Clash Premium | 過去に提供されていたクローズドソースの拡張コア | TUN、ルールセット、スクリプトに対応。スクリプトは代替方法を個別に検討 |
| Clash Meta | 拡張ブランチで使われていた旧名称 | ビルドのバージョンを確認し、名称だけで新機能の対応を判断しない |
| mihomo | Metaから名称変更されたプロジェクト | プロトコルのパラメーター、ルールセット形式、DNS、TUNのバージョン要件 |
設定項目の互換性一覧：引き継げる項目と要確認の項目
基本的な設定項目は引き継げる場合が多いものの、互換性は「項目を解析できるか」「値に対応しているか」「実行結果が同じか」の3段階で確認する必要があります。たとえば、dnsの項目を認識できても、その配下にある新しいオプションすべてを旧コアが理解できるとは限りません。未知の項目が無視される場合もあり、設定チェックに通っただけでは機能が有効になった証拠にはなりません。
| 項目・機能 | オリジナル版オープンソースコア | Premium | Meta / mihomo |
|---|---|---|---|
mixed-port、mode、log-level | 通常は利用可能 | 通常は利用可能 | 通常は引き継ぎ可能 |
proxies、proxy-groups | 基本構造に対応 | 基本構造に対応 | 基本構造は継承。新しいタイプは要確認 |
DOMAIN-SUFFIX、GEOIP、MATCH | 対応 | 対応 | 対応。データファイルも利用可能であること |
proxy-providers | 対応。ペイロードが形式に適合すること | 対応 | 対応。拡張オプションはバージョンによる |
rule-providers、RULE-SET | Premiumの機能を前提にした使用は不可 | 対応 | 対応。形式と動作タイプを確認 |
tun | Premiumに組み込まれたTUN機能は非対応 | 対応。プラットフォームと権限による | 対応。スタックとルーティングのオプションは再確認 |
sniffer | そのまま適用できない | mihomoの設定項目をそのまま適用できない | 対応。具体的なオプションはバージョンによる |
Premiumのscriptモード | 非対応 | 過去の機能 | Premiumのスクリプトはそのまま引き継げない |
dns.enhanced-mode: fake-ip | 基本機能に対応 | 対応 | 対応。フィルタリングと解析の方式は要確認 |
ポリシーグループ名は設定内の参照先に影響する
ルール末尾のポリシー名は、実在するノード、ポリシーグループ、または組み込みアクションに対応している必要があります。ポリシーグループ「プロキシ選択」を「ノード選択」に変更した場合、そのグループを参照するすべてのルール、ルールセットの参照先、ほかのポリシーグループのメンバーも合わせて変更します。この種のエラーはコアの世代とは関係ありませんが、移行時にプロトコルの非互換と誤認されがちです。
Premiumのスクリプトはルール振り分けのロジックを書き換える
古い設定でmode: scriptやscript:を使っている場合、コアのファイルを置き換えるだけでは不十分です。まず、スクリプトが実際に判定するドメイン、アドレス、ポリシーを洗い出し、移行先のコアに対応したルールやルールセットへ書き換えてください。動的な判定を含む箇所は、同等の機能があるか個別に確認します。モードをruleに変更するだけで移行が完了するわけではありません。
プロトコル対応を比較：サブスクリプションの名称よりノードの種類を確認
オリジナル版とPremiumでは、Shadowsocks、VMess、Trojanのほか、HTTPやSOCKS5プロキシが一般的な対応プロトコルです。ここでいう対応はプロトコルの種類を指し、後から追加されたすべての暗号方式、トランスポートの組み合わせ、拡張項目を含むものではありません。mihomoは対応プロトコルを拡張していますが、サーバー側のパラメーターとの照合が必要です。
| 設定内容 | オリジナル版 / Premium | mihomoでの確認項目 |
|---|---|---|
ss、vmess、trojan | 基本的な対応あり。すべての拡張機能が使えるわけではない | 暗号方式、トランスポート方式、TLSパラメーター |
vless | 非対応 | UUID、トランスポート方式、flowとTLSの組み合わせ |
reality-opts | 非対応 | 公開鍵、short-id、サーバー名などのパラメーター |
hysteria2 | 非対応 | UDPの到達性、認証、TLSパラメーター |
tuic | 非対応 | サーバー側のプロトコルバージョン、認証、輻輳制御オプション |
「unsupported proxy type」などのエラーが出た場合は、DNSを変更するのではなく、まずコアとノードの種類を確認してください。設定を読み込めても接続できない場合は、サーバーアドレス、ポート、認証、TLS、基盤ネットワークを順に確認します。Hysteria2とTUICはUDPに依存します。クライアントをグローバルモードに切り替えても、外部ネットワークでUDPが遮断されている問題は解決できません。
ルールセット、DNS、TUN：移行後に重点確認
ルールセットのbehaviorとペイロードの形式を合わせる
rule-providersのbehaviorでよく使われる値は、domain、ipcidr、classicalです。ドメイン一覧を完全なルール一覧として読み込むことはできません。また、ファイルの拡張子を変えただけで、完全なルールをドメイン形式のペイロードに変換することもできません。mihomoのMRS形式は、旧Premiumにそのまま渡す用途には適していません。移行時はformat、実際のファイル内容、移行先のバージョンを確認してください。
ルールは設定に記載された順に照合されます。ドメインルールとアドレスルールのどちらを先に置くかによって、名前解決の挙動や最終的な通信経路が変わる場合があります。末尾のMATCHはフォールバック用のため、後続ルールでの照合が必要な位置より前に置かないでください。ルールセットをダウンロードできても、それを参照するRULE-SETが正しい位置にあるとは限りません。
Fake-IPの予約アドレスはノードのアドレスではない
198.18.0.0/16は、Fake-IPでよく使われるアドレス範囲です。アプリがこの範囲のアドレスを取得した場合、通常は同じコアが後続の通信を引き継ぎ、マッピングからドメイン名を復元する必要があります。DNSで偽のアドレスを返すだけで、通信を引き継ぐ経路がないと接続に失敗することがあります。移行後は、偽のアドレスを異常なサーバーとして扱うのではなく、DNSの向き先、システムプロキシ、TUN、アプリ独自のプロキシ設定を確認してください。
TUNにはOSの権限とルーティング設定が必要
tun.enable: trueは、TUNを有効にする設定を示すだけです。実際の動作には、サービスの権限、仮想ネットワークアダプター、ルーティング、DNSの引き継ぎ、ネットワークスタックの実装が関わります。Windowsではクライアントサービスや管理者権限が必要になる場合があります。Linuxでは適切なネットワーク管理権限が一般的に必要です。クライアントの「サービスモード」と設定ファイル内のTUNスイッチは、別の階層の設定です。
- ルートを複数のプログラムが同時に引き継がないよう、古いクライアントとバックグラウンドサービスを終了します。
- まずシステムプロキシで基本接続を確認し、その後TUNを個別に有効にして、問題の範囲を絞ります。
- 元の設定をバックアップし、通常のドメイン、LAN上の端末、IPv6への接続をそれぞれ確認します。
- 画面上のスイッチだけで通信が引き継がれたと判断せず、ログで実際に有効なネットワークスタックを確認します。
既存設定の移行手順：まず基本ポートを検証し、その後に拡張機能を戻す
次の設定は、ローカルの待ち受けと基本的なルール解析を確認するためのものです。リモートノードを含まず、サブスクリプションの完全な代替にはなりません。混合ポートを7890に設定し、LANからの接続を無効にして、すべての通信を直接接続にします。ポート番号は例です。ほかのプログラムが使用中の場合は、ポートを変更するか、そのプログラムを先に終了してください。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
- MATCH,DIRECT- 現状を保存します。サブスクリプションの元データ、上書きルール、現在の実行設定をバックアップします。インポート用リンクだけでなく、クライアントとコアのバージョンも記録してください。
- 新しいコアを確認します。mihomoのバイナリを使う場合は、
mihomo -vを実行してバージョンを確認できます。実際のプログラムのパスとファイル名は、インストール先に応じて確認してください。 - 構文を確認します。
mihomo -t -f config.yamlを実行します。相対パスのリソースを使う設定では、作業ディレクトリとデータディレクトリが、クライアントの実行環境と一致していることも確認してください。 - ノードとポリシーグループを戻します。まず動作確認済みのノードを1つ追加し、認証とTLSを検証してから、自動選択やフェイルオーバーなどのポリシーグループを戻します。
- ルールセットとDNSを戻します。リソースの読み込み、ポリシー名、ルールのマッチ状況を確認してから、Fake-IPや特殊な名前解決ポリシーを追加します。
- 最後にTUNを有効にします。権限、デフォルトルート、LANへの接続を確認し、クライアント終了後にネットワークが想定どおり復旧することを確かめます。
基本ポートはcurl -x http://127.0.0.1:7890 -I https://clash-dl.com/で確認できます。このコマンドで検証できるのは、HTTPプロキシの入口がリクエストを処理できるかどうかです。SOCKS5、UDP、TUN、すべてのノードの動作を保証するものではありません。コマンドが失敗した場合は、ログを確認し、待ち受けが起動していないのか、接続先へのアクセスに失敗しているのか、外向きの通信経路に問題があるのかを切り分けてください。
クライアントの選び方とよくある互換性の問題
クライアントを選ぶときは、まずOSとCPUアーキテクチャを確認し、次にコアの提供元とメンテナンス状況を確認します。Clash Verge RevやFlClashなどはmihomo系のコアを採用していますが、実際の対応範囲はインストールしたクライアントのバージョンとコアのビルドによって異なります。Clash for WindowsやClash for Androidの旧配布版も、名前にClashが含まれるだけでmihomoの拡張プロトコルに対応しているとは限りません。
クライアントが表示するコア情報、サブスクリプションの上書き機能、サービス管理機能も確認しましょう。バイナリを置き換えて起動できても、古い画面では新しい項目が表示されなかったり、設定を保存する際に手動変更が上書きされたりする場合があります。OSとクライアントの対応関係はクライアント比較を、基本的な設定項目の意味はプロトコルリファレンスを参照してください。
Clash Metaの設定はmihomoでそのまま使えますか？
基本的な設定の多くは引き継げますが、過去のすべてのオプションがそのまま使えるとは限りません。まず設定を検証し、ログに出る非推奨の警告、リソースの読み込み、実際の接続状況を確認してください。旧Metaビルドと後継のmihomoの違いは、それぞれのバージョンに基づいて判断します。
mihomoの設定をオリジナル版Clashにダウングレードできますか？
プロトコルと設定機能の両方がオリジナル版の対応範囲に収まる場合に限り、可能性があります。VLESS、Hysteria2、スニッフィング、拡張ルールなどはそのまま引き継げません。サーバー側のプロトコルが関わる場合、YAMLの設定項目を削るだけではダウングレードできません。
設定チェックは通るのに、なぜアクセスできないのですか？
設定チェックで主に検証されるのは、構造と認識可能な設定内容です。リモートサービスへの接続性までは保証されません。ノード認証、DNSの応答、証明書、システムプロキシの適用範囲、UDPの通信経路、ルールで最終的に選ばれる出口も確認してください。
古いサブスクリプションは買い直すか、変更する必要がありますか？
コアの名称だけでは決まりません。まずサブスクリプションが実際に返すプロトコルと設定形式を確認してください。利用中のサービスがmihomo向けの設定取得先を提供している場合は、その案内に従って切り替えます。基本的なプロトコルだけの設定なら、そのまま移行できる場合もあります。クライアント側の形式の問題と、サーバー側で利用できるかどうかは分けて考えてください。
最終的には「コアのバージョン、設定項目、サーバー側のプロトコル、OSで通信を引き継ぐ機能」の4点がすべて一致するかで判断します。基本的なルールは優先して引き継ぎ、Premiumのスクリプトは個別に対応し、新しいプロトコルは実装範囲を確認します。TUNとDNSは移行先の端末で検証してください。これらを確認したうえで、既存設定を維持するか、サブスクリプションの形式を調整するか、クライアントを変更するか決めましょう。