クライアント・カーネル・サブスクリプション設定を区別する
クライアントが「Clash設定」に対応していても、Clash.Metaやmihomoのすべてのフィールドを使えるとは限りません。クライアントは画面表示やサブスクリプション管理、システムプロキシの切り替え、サービスのインストールを担当します。カーネルはポートの待ち受けやドメインの名前解決、ルール判定、プロキシ接続を担い、サブスクリプションはノードや設定全体を提供します。この3層はそれぞれ別に更新されます。「サブスクリプションの読み込みは成功したのに、ノードを起動できない」場合、原因はインポート操作ではなくカーネルの機能にあるかもしれません。
たとえば、画面上ではClashの名称を使い続けていても、内部ではmihomoを利用している場合があります。反対に、YAMLを読み込める古いクライアントが、旧世代のカーネルを搭載したままのこともあります。互換性を判断するときは、アプリ名だけでなく、まずカーネル名とバージョンを確認し、次に設定内のプロトコルや機能に関するフィールドを確認してください。
- クライアントのバージョン：通常は「設定」→「バージョン情報」で確認できます。画面やサービスコンポーネントのバージョンを把握するために使います。
- カーネルのバージョン：クライアントのカーネル情報や実行ログの冒頭で確認します。バイナリを直接実行する場合は、
mihomo -vを使います。 - 実際に適用される設定：クライアントの実行設定プレビュー、または起動ログに記録された設定ファイルのパスを確認します。サブスクリプションの内容と、実際に読み込まれるファイルは一致するとは限りません。
Clashオリジナル版・Clash.Meta・mihomoの変遷
Clashオリジナル版はオープンソース版とPremiumを区別する
従来のClashには、オープンソースのカーネルとPremiumの派生版がありました。両者を同じ機能一覧で考えることはできません。TUNやルールセットプロバイダーなどの機能は、Premiumでのみ利用できる時期がありました。古い解説に「ClashはTUNに対応」とだけ書かれ、どの派生版を指すのか明記されていないと、オープンソース版の利用者は該当機能を見つけられないことがあります。
Clash関連プロジェクトは2023年に公開メンテナンスを終了しました。古いバイナリが既存のシステムで動作する場合はありますが、その後追加されたプロトコルや設定項目を認識できるとは限りません。新しい設定を読み込めるかどうかは、そのバイナリが実際に備えている機能で判断する必要があります。
Clash.Metaは派生版で、後継の名称がmihomo
Clash.MetaはClashをベースに、プロトコルやDNS、ルーティング機能を拡張した派生版です。その後、プロジェクト名はmihomoに変更されました。つまり、Clash.Metaとmihomoは、設定を一行ずつ相互変換しなければならない完全に別個の体系ではありません。古い解説やサブスクリプションのボタン、ファイル名にMetaの表記が残っていても、実際にはmihomo用の設定を指している場合があります。
ただし、同じ系譜にあるからといって、過去のすべてのバージョンで機能が同じとは限りません。古いMetaのバイナリでは、新しいmihomoの設定項目に対応していないことがあります。フィールドのエラーが出た場合は、利用中のバージョンに対応したドキュメントとリリースノートを確認してください。「Metaならすべて使える」と決めつけないようにしましょう。
| 対象 | 主な用途 | 移行時の確認点 |
|---|---|---|
| Clashオリジナル版（オープンソース） | 基本的なプロキシ、プロキシグループ、ルールによる振り分け | PremiumやMetaの拡張機能に対応しているとは限らない |
| Clash Premium | オリジナル版から派生した拡張版 | スクリプトモードなどをmihomoの同等機能とみなさない |
| Clash.Meta | プロトコルやルーティング機能を拡張した派生版 | 名称が広く使われていても、機能はバージョンによって異なる |
| mihomo | Metaの後継プロジェクト名 | 新しいフィールド、クライアントの制御方法、実際の実行設定を確認する |
プロトコル・ルール・TUNの実際の違い
ノードのプロトコル対応状況が、サブスクリプションを実際に使えるかを左右する
オリジナル版でよく使われる設定では、Shadowsocks、VMess、Trojan、SOCKS5、HTTPなどのプロキシタイプが利用されます。mihomoはこれらに加えて、VLESS、Hysteria2、TUICなどの拡張プロトコルにも対応しています。ただし、各プロトコルの通信方式や認証パラメーター、個別のオプションには、バージョンごとの要件があります。「プロトコルに対応」とは、そのプロトコルのあらゆる実装やパラメーターを使えるという意味ではありません。
旧カーネルがtype: hysteria2のような未知のプロキシタイプに遭遇すると、そのノードを正常に読み込めないことがあります。クライアントによっては、変換やインポートの段階でノードが除外されます。サブスクリプション更新後にノード数が20から0になった場合は、すぐにDNSを変更するのではなく、まずインポートログとプロトコルタイプを確認し、その後サービスの有効期限を確認してください。
基本的なルールは引き継げることが多いが、拡張ルールは要確認
DOMAIN、DOMAIN-SUFFIX、IP-CIDR、MATCHなどの基本ルールは、比較的引き継ぎやすい形式です。より複雑な論理ルールやプロセス判定、ルールセットの形式については、カーネルの対応状況に加え、OSの機能やデータファイルが利用可能かも確認してください。ルールは基本的に上から順に照合されます。最後に適用するMATCHを先頭に置くと、後続のルールが機能しなくなります。
以下は単独のルール例で、設定全体ではありません。既存の設定に「プロキシ選択」という名前のプロキシグループがあることを前提としています。名前は一字一句一致させてください。YAMLの書式が正しくても、参照名が異なるとエラーになります。
rules:
- DOMAIN-SUFFIX,example.com,プロキシ選択
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,プロキシ選択ここでのno-resolveは、このIPルールの照合時にドメイン名の名前解決を行わないことを示します。カーネル全体でDNSを無効にする設定ではありません。また、192.168.0.0/16が対象とするのはプライベートネットワークの1つの範囲だけです。この例は、LAN内の通信をすべて除外する設定ではありません。
TUNは通信を取り込む方式であり、ノードのプロトコルではない
システムプロキシが通常影響するのは、システムのプロキシ設定に従うアプリだけです。TUNは仮想ネットワークインターフェースを使って通信を取り込むため、より広範囲をカバーできますが、権限やルーティング、DNSとの連携が必要です。オリジナル版のPremiumとmihomoのどちらにもTUN機能がある場合があります。画面に「TUN」のスイッチがあるだけで、同じカーネルだとは判断できません。
移行時は、旧クライアントの仮想ネットワークアダプターやバックグラウンドサービス、ルーティング設定を、新しいクライアントでも必要なものと決めつけないでください。まず旧クライアントを終了して通信の取り込みを停止し、その後、新しいクライアントでサービスをインストールまたは有効化します。2つのTUNが同時に動作すると、デフォルトルートの競合やDNSループ、LANへのアクセス不具合が起こることがあります。
旧設定をmihomoへ移行する際に、引き継ぐ項目と見直す項目
旧設定を丸ごと貼り付け、すべての機能を一度に有効にする方法はおすすめできません。まずバックアップを取り、ノードへの接続、プロキシグループの選択、ルールの照合ができる最小限の構成を作ります。その後、DNSの拡張機能、TUNの順に追加してください。各段階で、問題の範囲を切り分けやすくなります。
| フィールド・項目 | 対応方法 | 具体的な確認内容 |
|---|---|---|
proxies、proxy-groups | まず基本構成を維持する | プロトコルのオプションが有効で、プロキシグループの参照先が存在する |
rules | 順序を維持し、項目ごとに確認する | 転送先のプロキシグループが存在し、最後にフォールバックルールがある |
rule-providers | 参照元と形式を確認する | behaviorと実際のルール内容が一致している |
dns、tun | 新しい環境で再確認する | ポート、ネットワーク範囲、権限、ルートに競合がない |
script | そのまま流用しない | Premiumのスクリプトによる振り分けは、対応するルールロジックで書き直す |
external-controller、secret | クライアントの通信制御を確認する | コントローラーポートが競合せず、アクセスキーが設定ファイルで公開されていない |
ポートとローカルパスは特に見落としやすい
たとえば、旧設定がmixed-port: 7890を使い、新しいクライアントも7890で待ち受けている場合、旧プロセスが終了していないとポートが競合することがあります。新しいクライアントのポートを7897に変更しても、ターミナルのプロキシ環境変数が127.0.0.1:7890を指したままなら、ターミナルからの通信は引き続き旧ポートへ接続しようとします。ここでの数字は一般的な設定例であり、すべてのクライアントの固定値ではありません。
ルールプロバイダーやプロキシプロバイダーの相対pathは、通常、カーネルの作業ディレクトリを基準に解釈されます。YAMLファイルを別のディレクトリに移動しても、対応するキャッシュファイルまで一緒に移るとは限りません。新しいクライアントでプロバイダーを更新し、ログでファイルの書き込みが成功したことを確認してください。画面に古いノード名が残っているだけで、更新済みと判断しないようにしましょう。
サブスクリプションの上書きで変更が消えることがある
サブスクリプションの更新時に設定を再生成するクライアントでは、手動で変更したdnsやrulesが上書きされることがあります。クライアントが対応するオーバーライド、マージ、拡張設定の機能を優先して使い、最終的な実行設定で反映結果を確認してください。マージルールを追記・置換・前置きのどれにするかはクライアントによって異なります。オーバーライドファイルの内容だけから、最終的な順序を判断することはできません。
DNSとfake-ip：移行時は名前解決の経路を再確認
fake-ipは、ドメイン名に仮想アドレスを返し、後続の接続でカーネルが元のドメイン名と対応付ける仕組みです。ノードのプロトコルではなく、すべてのDNSリクエストが指定したリゾルバーを通ることを自動的に保証するものでもありません。システムDNSやブラウザーのセキュアDNS、アプリ内蔵の名前解決、TUNがDNSを横取りする範囲によって、実際の経路は変わります。
以下はmihomoのDNS設定例です。既存の設定に統合して使ってください。例では一般的な53番ポートを直接使わず、ローカルの1053番ポートで待ち受けます。ただし、待ち受けを有効にしただけでは、OSからの問い合わせが自動的にここへ送られるわけではありません。
dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- https://1.1.1.1/dns-query
nameserver-policy:
"+.example.com":
- https://1.1.1.1/dns-query- 仮想アドレスの範囲：
198.18.0.1/16はテスト用アドレス空間に属します。ローカルの検証用ネットワークですでにこの範囲を使っている場合は、先に競合を解消してください。 - ドメインごとの名前解決：
nameserver-policyは、指定したドメインに使うリゾルバーを設定します。そのドメインへの通信を特定のプロキシノードに固定する設定ではありません。 - 暗号化された名前解決：DoHは該当するDNSリクエストの通信を保護します。ただし、接続先に到達できるか、リクエストがどの経路を通るかは、実際のネットワーク環境に応じて確認する必要があります。
- アドレスのマッピング：fake-ipの設定を変更しても、OSやブラウザーに古いアドレスがキャッシュされている場合があります。キャッシュを消去するか、テスト対象のアプリを再起動してから、新しい接続を確認してください。
TUNでDNS通信を取り込む場合は、既存のTUN設定でdns-hijackを確認してください。よく使われる記述はany:53とtcp://any:53で、それぞれ通常のDNSのUDP通信とTCP通信を対象にします。実際の取り込み結果は、プラットフォームやルーティングの実装にも左右されます。アプリがHTTPSで直接送信するDoHは、53番ポート宛ての通常のDNS通信ではありません。この種の通信がDNSの横取りによって自動的に書き換わるとは限りません。
設定移行後の検証：構文チェックからTUNの通信取り込みまで
手順1：設定を読み込めるか確認する
カーネルを直接使う場合は、まず次のコマンドを実行してください。Windowsでは、コマンド内のプログラム名を手元のmihomo.exeに置き換え、設定ファイルのあるディレクトリで実行します。GUIクライアントを使っている場合は、別プロセスが使用中のポートと競合しないよう、クライアント内の設定チェック機能を優先してください。
mihomo -v
mihomo -t -f ./config.yamlチェックに合格しても、その時点で設定を読み込めたことを示すだけです。ノードのサーバーに接続できることや、すべてのルールが意図どおりに機能することを保証するものではありません。エラー箇所が示されたら、その行だけでなく、直前の行のインデントやコロン、リスト記号も確認してください。YAMLでのタブによるインデントや、同じ階層にあるキーの重複も、気づきにくい原因になります。
手順2：ノードを1つだけ使ってプロキシ経由の接続を確認する
- 旧クライアントを終了し、新しいクライアントのTUNを一時的に無効にします。ルールモードに切り替え、動作確認済みのノードを1つ選んでください。
- 実際に使われている混合ポートを確認してください。設定が
7890の場合は、以下のコマンドでテスト用ドメインへのリクエストをそのポート経由で明示的に送信できます。 - 接続ログで、対象ドメイン、適用されたルール、最終的に使われたノードを確認してください。明示的なプロキシ接続が成功したら、システムプロキシを有効にして通常のアプリでも検証します。
- 最後にTUNを有効にし、ブラウザー、ターミナル、システムプロキシに従わないアプリをそれぞれテストします。同時に、LANへ正常にアクセスできることも確認してください。
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.comここでの接続タイムアウト10秒、全体のタイムアウト20秒は、テスト時の待ち時間を設定する値であり、通信速度の指標ではありません。ローカルポートへの接続失敗が表示された場合は、まず待ち受け状態を確認してください。ログにプロキシのハンドシェイクエラーが記録されている場合は、ローカルポートを変更し続けるのではなく、ノードの認証情報や通信パラメーター、回線を確認します。
手順3：サブスクリプションの更新と切り戻しを確認する
サブスクリプションとルールプロバイダーを手動で一度更新し、カスタムルールやDNSのオーバーライド、プロキシグループの選択が維持されるか確認します。完了後は、新しいクライアントで有効な設定のバックアップを保存し、旧設定もオフラインで保管してください。以前の環境へ戻す場合は、まず新しいクライアントによる通信の取り込みを停止してから旧環境を復元します。両方の環境が同時にシステムプロキシやルートを変更しないようにしてください。
カーネル選びの結論：設定要件とメンテナンス状況で判断する
既存のClash形式のサブスクリプションを使い続けながら、新しいプロトコルやルール、DNS機能も利用したい場合は、mihomoを明確に組み込み、カーネルのバージョンと実行ログを確認できるクライアントを選びましょう。旧設定がPremium由来なら、ファイル名を置き換えるだけでなく、スクリプトのロジックやプロバイダー、TUN、DNSを中心に見直してください。
- 基本的な振り分けだけが必要：まずノード、プロキシグループ、基本ルールを安定させましょう。機能名にこだわって、すべてのオプションを一度に有効にする必要はありません。
- 新しいプロトコルが必要：カーネルのバージョンとプロトコル関連のフィールドを確認し、サービス提供元がMetaまたはmihomo対応と明記した設定を優先してください。
- すべての通信を取り込みたい：プラットフォームの権限、TUNサービス、DNSの経路を確認し、「明示的なプロキシ → システムプロキシ → TUN」の順で検証してください。
- 長期的に使いたい：クライアントとカーネルの両方の更新状況を確認してください。画面の更新とカーネルの更新は別々です。アップグレード後も重要な設定を再確認しましょう。
Clash.Metaとmihomoの名称の関係は、確認事項の出発点にすぎません。設定を移行できるかどうかを実際に左右するのは、稼働中のカーネルのバージョン、有効な設定内容、ローカルのポートや権限、名前解決の経路です。これらを一つずつ記録しておけば、問題が起きたときに該当する層から原因を調べられます。