結論：旧設定は多くの場合移行できるが、新機能は互換性に注意

サブスクリプションが一般的なShadowsocks、VMess、Trojanのノードで、ルールも DOMAIN-SUFFIX、IP-CIDR、MATCH が中心なら、mihomoへの移行でYAML全体を書き直す必要は通常ありません。確認が必要なのは、ノード固有の拡張パラメーター、ルールセットの形式、DNS設定、そしてクライアントが手動変更した項目を上書きしないかどうかです。

mihomoはClash Metaプロジェクトの後継名称で、Clashの設定体系を引き継ぎながら、プロトコルやトラフィック処理機能を拡張しています。mihomoはカーネルであり、特定のGUI付きClashクライアントを指すものではありません。クライアントはサブスクリプション管理やシステムプロキシの切り替え、設定の統合を担当し、カーネルは接続の確立、ルールの適用、DNS処理を担います。画面を提供するアプリを変えただけでは、実際に動作するカーネルまで変わったとは限りません。

オリジナルプロジェクトはすでにメンテナンスを終了しています。新しいプロトコルや継続的に更新されるルール機能、最近のOSへの対応が必要な場合は、現在もメンテナンスされているカーネルを優先的に検討しましょう。ただし、カーネルを更新してもすべてのノードが速くなるわけではありません。回線品質、サーバー設定、ネットワークのパケットロス、実際に選択された出力先のポリシーも接続品質に影響します。

プロトコル対応：まずノードの種類、次に接続パラメーターを確認

ノード・機能オリジナルClashオープンソースカーネルmihomoへの移行時の確認事項
Shadowsocks、VMess、Trojan一般的な設定に対応暗号化方式、トランスポート層、TLSパラメーターを確認
VLESS、Reality新しい組み合わせには非対応サーバーが求めるflow、フィンガープリント、公開鍵、short-idを確認
Hysteria2、TUIC非対応UDPの疎通とプロトコル固有の認証項目を確認
新しい暗号化方式とトランスポート拡張旧バージョンの制約ありアルゴリズム、トランスポートの種類、カーネルのバージョンを確認

「VLESS対応」でも、すべてのVLESSリンクをそのまま使えるわけではない

ノードの type は確認項目のひとつにすぎません。VLESSとRealityの組み合わせでは、servername、client-fingerprint、reality-opts 内の公開鍵や短い識別子も確認が必要です。Visionを使う場合は flow も確認してください。これらのパラメーターはサーバー側の設定と一致させる必要があり、別のノードからコピーして使い回すことはできません。

サブスクリプション変換にも限界があります。変換ツールで設定項目の構造を変更することはできますが、Hysteria2サーバーをオリジナルClash対応のVMessサーバーに変えることはできません。クライアントが新しいプロトコルを認識しない場合は、互換性のあるカーネルに切り替えるか、サービス提供元が明示的に対応している別のノードを使ってください。

ルール拡張：基本構文は引き継げるが、ルールセットの形式は要確認

Clashの一般的なルールは上から順に評価され、最初に一致したルールで出力先のポリシーが決まります。移行時は既存ルールの順序を維持し、一度に多数のルールを変更しないようにしましょう。特に、ルールが参照するポリシーグループが実際に存在することを確認してください。最後に MATCH を置き、それまで一致しなかった接続を処理します。

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,Proxy

ここでの Proxy は、設定内に存在するポリシーグループまたは出力先の名前である必要があります。example.com は構文例として使われる予約済みのサンプルドメインです。no-resolve は、このIPルールの評価時にドメイン名の名前解決を行わない指定であり、カーネル全体のDNSを無効にするものではありません。接続に宛先IPが含まれている場合は、そのIPで引き続きマッチングできます。

rule-providersとRULE-SETは別の役割

rule-providers はルールの読み込み元と解釈方法を定義し、RULE-SET はメインのルール一覧からそのルールセットを参照します。mihomoはルールプロバイダーに対応し、さらに多様なルールの組み合わせやマッチング機能を備えています。Premiumを使っていた場合は、その一部をすでに利用していることもあります。

rule-providers:
  private-net:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/private.yaml

rules:
  - RULE-SET,private-net,DIRECT
  - MATCH,Proxy

対応する ./rules/private.yaml ファイルには、次のような内容を記述できます。相対パスは通常カーネルの作業ディレクトリを基準にするため、GUIアプリのディレクトリとは異なる場合があります。ファイルが見つからない場合は、まず起動ログに記録された作業パスを確認してください。

payload:
  - IP-CIDR,10.0.0.0/8,no-resolve
  - IP-CIDR,172.16.0.0/12,no-resolve
  - IP-CIDR,192.168.0.0/16,no-resolve

移行後に多くのWebサイトがフォールバック用ポリシーに振り分けられる場合は、まずルールセットの読み込み状況を確認し、その後ルールの順序を確認してください。ルールセットのURLからファイルを取得できても、内容の形式が behavior と一致するとは限りません。

DNSの違い：基本項目を引き継ぎ、名前解決と出力先を分けて確認

オリジナルClashには、DNSモジュールやFake-IPなどの基本機能がすでにあります。mihomoはこれらに加え、ドメインごとに使用するリゾルバーを選ぶ設定や、ノードのドメイン名を解決する方法などを拡張しています。DNSが正しいアドレスを返すことと、接続が正しいポリシーを通ることは別の問題です。前者は接続先を決め、後者はどの出口から接続するかを決めます。

旧設定から引き継げる項目

一般的な dns.enable、listen、enhanced-mode、fake-ip-range、nameserver は移行の出発点として引き継げます。以下は理解しやすいように抜粋したDNS設定で、ノードやポリシーグループは含まれておらず、システムDNSを自動的に変更するものでもありません。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

1053 はこの例でのローカルDNS待ち受けポートです。通常のシステムDNS設定ではサーバーアドレスを指定するだけで、このポートを併記することはできません。システムの名前解決を取り込むには、別途フォワーディングを設定するか、対応する環境でTUNのDNSハイジャックを有効にしてください。198.18.0.1/16 はFake-IPのマッピング用で、リモートWebサイトの実際のグローバルIPアドレスではありません。

新機能を一度にすべて有効にしない

検証時はクライアントのDNSログ、接続詳細に表示されるドメイン名、最終的に選択されたポリシーをそれぞれ確認します。ブラウザー内蔵のセキュアDNSは独自の名前解決経路を使う場合があります。カーネルのDNSを変更しただけでは、ブラウザーのすべての問い合わせがそこを通るとは限りません。

TUNとトラフィックのスニッフィング：取り込み範囲とルールモードは別

システムプロキシは、システムのプロキシ設定を参照するアプリで主に使われます。TUNは仮想ネットワークインターフェース経由でトラフィックを取り込み、システムプロキシを参照しないアプリにも対応できます。TUNはトラフィックをカーネルに取り込む方法であり、ルールモードは取り込んだトラフィックの出力先を決める方法です。両者は二者択一ではありません。

オリジナルのオープンソースカーネルとPremiumのTUN機能を混同しないでください。mihomoに移行した後も、tun の設定をコピーするだけですべてが有効になるとは限りません。クライアントによってはサービスのインストールや管理者権限が必要な場合があり、GUIが該当項目を生成して上書きすることもあります。

  1. まずシステムプロキシでサブスクリプション、ノード、ルールを確認し、設定の読み込みに成功するまではTUNを追加しないでください。
  2. デフォルトルートの競合を避けるため、ほかのVPNや仮想ネットワークアダプターを無効にして比較してください。
  3. TUNを有効にした後、ログで仮想インターフェースとルートの作成結果を確認し、権限エラーが発生していないことを確かめてください。
  4. LANプリンター、NAS、社内ネットワークのアドレスをテストし、必要に応じて明示的なバイパスルールやルート除外を設定してください。

mihomoのトラフィックスニッフィングは、一部のHTTP、TLS、QUICトラフィックからホスト情報を取得し、ドメインルールのマッチングを補助できます。ただし、HTTPSの内容を復号する機能ではなく、すべての接続を識別できるわけでもありません。暗号化されたClientHelloなどの仕組みにより、確認できる情報が制限される場合があります。スニッフィングは具体的な振り分け要件に合わせて有効にし、あらゆるDNS問題への万能策として扱わないでください。

旧サブスクリプションの移行：設定の出所ごとに確認

設定項目基本的な対応方法必ず確認する点
mixed-port、mode、log-levelまずはそのまま引き継ぐポートの競合、クライアントによる値の上書き
proxies、proxy-groups基本構造を維持プロトコル項目、グループ内のノード名、テスト用URL
rules一般的なルールを引き継ぐ参照名、順序、MATCHの位置
rule-providers形式を確認してから再利用behavior、format、ファイルパス、読み込み結果
dns、tun段階的に有効化システム権限、ルート、名前解決の依存関係、GUIによる設定統合
Premiumのscriptスクリプトルールそのまま互換性があると判断しないmihomo対応のルールまたはルールセットに書き換える

実際の移行手順

  1. 元の設定をバックアップ：サブスクリプションの原文と、クライアントが現在生成している実行用設定を別々に保存します。両者は異なる場合があるため、問題の調査時にサブスクリプションの編集画面だけを見ないでください。
  2. カーネルの種類を確認：クライアントのカーネル情報または起動ログで名前とバージョンを確認します。単体のバイナリを使っている場合は、mihomo -v を実行してバージョンを確認してください。
  3. 先に設定をテスト：設定ファイルのあるディレクトリで mihomo -t -f ./config.yaml を実行します。Windowsの単体実行ファイルでは、.\mihomo.exe -t -f .\config.yaml を使用できます。
  4. まずは接続経路をひとつだけ確認：動作確認済みのノードをひとつ選び、システムプロキシを有効にして、ルールモードでテストページにアクセスします。
  5. 拡張機能をひとつずつ戻す：ルールセット、DNSポリシー、TUNの順に有効にし、変更する設定は毎回ひとつに絞ってログを確認します。
  6. 最後にサブスクリプションを一度更新：カスタムルールが失われていないことを確認してから、自動更新と起動時の自動起動を設定します。

設定テストに成功しても、カーネルが設定を読み込めたことが分かるだけです。サブスクリプションのノードがオンラインであること、ルールセットのダウンロードが成功すること、システムプロキシが有効であることまでは保証されません。GUI付きクライアントは起動前に設定を統合することもあります。そのため、コマンドラインでテストするファイルは、クライアントが実際に使うファイルとできるだけ同じものにしてください。

移行後の確認：ポート、ルール、DNSを個別にチェック

実行用設定の mixed-port が 7890 の場合は、プロキシを明示して接続テストを行えます。システムプロキシの設定が正しいかどうかという要因を切り分けられます。ポート番号はクライアントに表示されている実際の値に置き換えてください。

curl -I --proxy http://127.0.0.1:7890 https://example.com

Windows PowerShellでは curl.exe を使うと、環境によって同じ名前のコマンドに割り当てられたエイリアスによる引数の解釈への影響を避けられます。このテストで確認できるのは今回のHTTPプロキシリクエストのみで、UDP、TUN、ほかのアプリの動作は確認できません。

選び方はシンプルです。VLESS Reality、Hysteria2、TUIC、またはより細かなルールやDNS制御が必要なら、これらに対応したmihomoクライアントを使いましょう。基本的なサブスクリプションを移行する場合は、まず安定している設定を引き継ぎます。カーネルの互換性、設定の統合、ネットワークの疎通を分けて確認すると、設定を一度にすべて置き換えるより問題を特定しやすくなります。

各項目の詳細はClash設定ガイドをご覧ください。ポートの競合、システムプロキシが効かない、権限の問題などは、よくある質問を参考に順番に確認できます。