クライアント・コア・設定形式を区別する

mihomoはネットワークプロキシのコアで、Clash Metaを前身としています。設定の解析、アウトバウンド接続の確立、ルールの照合、DNS処理を担います。一方、クライアントは設定のインポート、システムプロキシの切り替え、TUNモード、プロキシグループの選択、ログ表示などを提供します。クライアント名にClashが含まれていても、実際に動作するコアがオリジナルClashとは限らず、mihomoのすべての項目を読み込めるとも限りません。

「オリジナルClash」と比較する場合は、オープンソースのコアと、過去に提供されていたClash Premiumも区別する必要があります。両者には機能差があり、特にTUNやルールプロバイダーなどの機能で違いがありました。そのため、すべての拡張機能を「mihomoで初めて対応」と説明するのは正確ではありません。また、旧クライアントの画面だけでコアの機能を判断することもできません。

  • クライアントのバージョン：画面の項目、権限管理、設定の上書き方法を左右します。
  • コアのバージョン：利用できるプロトコルや設定項目の解析、ネットワーク機能を左右します。
  • サブスクリプションの形式：インポートされるのがノード一覧なのか、DNS・ルール・プロキシグループを含む設定一式なのかを左右します。

プロトコルの拡張：ノードを読み込めても接続設定が正しいとは限らない

オープンソース版のオリジナルClashと比べ、mihomoは複数のアウトバウンドプロトコルや伝送方式に対応しています。VLESS、REALITY、Hysteria2、TUICへの対応が、移行を検討する主な理由です。ただし、利用できる設定項目はインストール済みのコアのバージョンによって異なります。サブスクリプション変換サービスで旧Clash形式を選ぶと、インポート前にノードや設定項目が欠落することもあります。

機能mihomo設定で確認する項目よくある移行時の問題
VLESStype: vless、UUID、トランスポート層、TLSの設定サブスクリプション変換でタイプが除外される、またはトランスポート設定が不足している
REALITYTLS、servername、reality-opts公開鍵やShort IDがサーバー側の設定と一致しない
Hysteria2type: hysteria2、認証、TLS、UDPの到達性ネットワークでUDPが制限されている、または旧世代のプロトコル項目を誤って使っている
TUICtype: tuic、認証、サーバー側のプロトコルバージョンクライアントとサーバーで必要なバージョンが一致しない

REALITYは独立したノードタイプではない

VLESSの代わりにノードをtype: realityとして設定することはできません。一般的にはVLESSノードでTLSを有効にし、reality-optsを設定します。サーバー側がVisionを使用している場合は、対応するflowも確認してください。プロキシ画面にノードが表示されるのは設定が読み込まれたことを示すだけで、認証やハンドシェイクの成功を保証するものではありません。

まず1つのノードで動作確認してから全体を移行する

  1. サブスクリプションの出力先がmihomoまたはClash Metaに対応していることを確認します。旧Clashのみ対応の形式は避けてください。
  2. ノードタイプ、サーバーポート、認証項目、TLS設定が揃っているか確認します。
  3. まず動作確認済みのノードで接続先サイトにアクセスし、ログでハンドシェイクや認証のエラーを確認します。
  4. Hysteria2やTUICを使う場合はUDPのネットワーク条件も確認してください。TCPポートへの接続結果でプロトコルの動作を判断することはできません。

コアを更新しても、旧ノードが新しいプロトコルに自動変換されたり、サーバー側の設定が変更されたりすることはありません。新しいプロトコルが適切かどうかは、名称の新しさではなく、サーバーの対応状況と現在のネットワーク環境で判断してください。

rule-providers：ルールの取得元と適用を分けて管理する

rule-providersで個別のルールセットを管理し、ルール一覧からRULE-SETで参照します。過去のClash Premiumにもルールプロバイダー機能があり、mihomoはその機能をもとにルール形式などを拡張しています。そのため、一般的なオープンソース版Clashから移行する場合と、Premiumから移行する場合では、必要な変更が異なります。

以下では、リモートからのダウンロード失敗を切り分けやすいよう、ローカルのルールセットを使います。2つのファイルはいずれもサンプルです。メイン設定の断片は既存の設定に統合してください。置き換えてノード、プロキシグループ、DNS設定を失わないよう注意しましょう。

メイン設定のサンプル

rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,DIRECT

ルールセットファイル：rules/local-direct.yaml

payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve

この例はルールセットの参照方法を示すもので、すべての通信をデフォルトで直接接続する設定です。そのまま使えるプロキシ振り分け設定ではありません。pathはコアの作業ディレクトリを基準に解決されます。GUIクライアントでは専用の設定ディレクトリが使われることがあるため、実際の場所は実行中の設定またはログで確認してください。

  • behavior: domainはドメインルールセット用です。内容に完全なDOMAIN-SUFFIX,...形式のルール行を記述するものではありません。
  • behavior: ipcidrはIPアドレス範囲のルールセット用です。ドメインルールを混在させないでください。
  • behavior: classicalでは上記のような従来形式のルール項目を使用できます。ただし、コアが対応するルールタイプに従う必要があります。
  • formatは実際のファイル形式と一致させてください。mihomoのmrs形式はdomainやipcidrタイプのルールセット用です。任意のYAMLファイルの拡張子を変えてMRSとして使うことはできません。

ルールは記述順に照合されます。RULE-SETより前にMATCHを置くと、後続のルールセットが照合されません。リモートプロバイダーに切り替えた場合は、ダウンロードの成否、ファイルの解析結果、リクエストがルールに一致したかを個別に確認してください。これらはそれぞれ別の状態です。

DNSの変更：アクセス先のドメインとノードのドメインを分けて考える

mihomoのDNS設定では、nameserver-policyやproxy-server-nameserverなどを使って、名前解決の経路を細かく制御できます。DNS接続にルーティングルールを適用する設定もあります。移行時に起こりやすい問題は、DNSサーバーのアドレスの記入漏れではなく、まだ解決されていないノードのドメイン名をDNSクエリの送信先に使い、依存関係が循環することです。

まず最小構成で動作を確認する

以下の例はfake-ipとノードのドメイン名解決を分けて示しています。127.0.0.1:1053はローカルDNSの待ち受けアドレスであり、システムプロキシのポートではありません。待ち受けを設定しただけでは、すべてのアプリが自動的に利用するわけではありません。サンプルで使われているパブリックDNSが現在のネットワークで使えるかは、実際に確認してください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
  nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 223.5.5.5

nameserverは通常のドメイン名解決に使い、proxy-server-nameserverはプロキシノードのドメイン名解決専用です。上の例では各項目の役割を示すために同じDNSサーバーを指定していますが、すべての環境でこのアドレスを使うことを推奨するものではありません。暗号化DNSを使う場合は、DNSサーバー自身のドメイン名を解決する方法と、ネットワークから到達できることも確認してください。

fake-ip-filterは直接接続ルールではない

fake-ipモードではアプリに合成アドレスを返し、コアがアドレスとドメイン名の対応を管理します。ドメインをfake-ip-filterに追加すると、そのドメインへのfake-ip割り当てを避けられますが、通信が直接接続になるわけではありません。最終的な接続先はルール、プロキシグループ、出力モードによって決まります。

移行の初期段階では、上流DNSの変更、TUNの有効化、スニッファーの有効化、全ルールの書き換えを同時に行わないでください。まずDNSが想定どおりに応答することを確認し、その後、接続が正しいルールに一致するかを調べましょう。respect-rulesを有効にする場合は、先にノードのドメイン名解決経路を設定し、現在のバージョンのドキュメントも確認してください。DNSクエリが、まだ確立していないプロキシに依存する事態を避けられます。

スニッファー：ドメイン情報を補う機能であり、HTTPSを復号する機能ではない

通信がコアに届いた時点で宛先IPしか分からない場合、ドメインルールの照合に必要な情報が不足することがあります。mihomoのsnifferは、HTTP HostやTLSハンドシェイク内のサーバー名などをもとに、ドメインの特定を試みます。HTTPS本文を復号する必要はなく、すべての暗号化通信からドメイン名を取得できるとも限りません。

sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080]
    TLS:
      ports: [443]

この例では指定ポートでHTTPとTLSのスニッフィングを試みるだけで、宛先アドレスの上書きなどの追加機能は有効にしていません。サービスが別のポートで動作する場合は、実際の環境に合わせて調整してください。旧設定にある過去のスニッファー項目を、そのまま新しい構成に追加するのは避けましょう。項目の階層が合わない場合は、現在のコアによる設定チェックの結果を基準にしてください。

  • 確認に適したケース：TUNがIP接続を受け取っているものの、ドメイン名に基づく振り分けを行いたい場合。
  • 代替できない設定：DNS設定、プロキシグループの定義、ルーティングの除外設定、アプリ側のプロキシ設定。
  • 注意すべき制限：ECHなどの仕組みによってサーバー名が見えない場合や、識別可能なドメイン名が含まれない通信があります。

スニッフィングを有効にして特定サイトの挙動が変わった場合は、まずそのドメインのスニッフィング範囲を調整するか、機能を一時的に無効にして接続ログを比較してください。DNSやルーティングの問題を、スニッフィング対象ポートの拡大で覆い隠さないようにしましょう。

TUNとシステムプロキシ：コアを更新しても通信の入口は自動で切り替わらない

システムプロキシは、アプリがOSのプロキシ設定に従うことで機能します。TUNモードは仮想ネットワークインターフェースを通じてIP通信を取り込み、クライアント側で権限、ルーティング、DNSを適切に処理する必要があります。mihomoはTUNに対応していますが、接続方法はプラットフォーム、クライアント、バージョンによって異なります。tun:の設定を貼り付けただけで、すべての通信が取り込まれたと判断しないでください。

たとえば、ローカルの混合ポートが7890の場合、システムプロキシに従うアプリはこのポート経由でコアに接続できます。一方、DNSの待ち受けポート1053は別の入口です。用途が異なるため、システムHTTPプロキシのアドレスにDNSの待ち受けポートを指定しないでください。

移行時は、まずTUNを無効にし、システムプロキシでサブスクリプションとノードを確認してから、TUNを個別に有効にすると切り分けやすくなります。LAN、プリンター、他のVPNへのアクセスに問題が出た場合は、ノードのプロトコルを疑う前に、ルートの競合、DNSの取り込み、除外設定を確認してください。

旧設定の移行：構文・リソース・接続の3段階で確認する

第1段階：実際に動作している設定を確認する

サブスクリプションファイル、カスタムオーバーライド、プロキシグループの選択内容を先にバックアップしてください。クライアントはコアの起動前に複数の設定を統合することがあるため、エディターで見ているファイルが実際の設定とは限りません。クライアントから実行中の設定をエクスポートし、dns、rules、proxy-groupsが別の内容で上書きされていないことを確認しましょう。

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

-tは設定の検証に使います。検証を通過しても、コアが設定を受け付けたというだけで、リモートルールのダウンロードやノードへの接続が成功するとは限りません。クライアント管理のコアを使っている場合は、別バージョンのバイナリを誤って実行しないよう、クライアント内の検証機能を優先してください。

第2段階：外部リソースと参照名を確認する

  1. プロキシグループが参照するノードまたはプロバイダーが存在し、名前が完全に一致しているか確認します。
  2. RULE-SETで指定した名前が、rule-providers内のキーと一致しているか確認します。
  3. ルールファイルのパス、リモートリソースへのリクエスト、解析エラーを確認し、ネットワークの失敗とファイル形式の不一致を切り分けます。
  4. サブスクリプションを更新した後もカスタム設定が有効か確認してください。次回の更新で上書きされるキャッシュファイルだけを編集しないようにしましょう。

第3段階：固定したリクエストで結果を確認する

混合ポートが実際に7890で、コアが起動していることを確認したうえで、以下のコマンドからHTTPプロキシ経由で明示的にリクエストを送信できます。テストツールがシステムプロキシに従うかどうかによる曖昧さを避けられます。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

ここでの10秒と20秒は、それぞれ接続待ち時間とリクエスト全体の制限時間です。通信速度の評価値ではありません。テスト後は接続画面で、宛先ドメイン、適用されたルール、実際のアウトバウンド先を確認してください。エラーが出た場合はログ画面で詳細を確認します。ハンドシェイクに失敗したらノード設定、ルールが一致しない場合はルール順序とドメイン情報、接続記録がない場合は通信の入口を確認してください。

移行完了の目安は、設定チェックに合格すること、必要なリソースを読み込めること、アプリの通信がコアに入ること、ルールが想定どおりに適用されること、ノードに正常接続できることです。この5項目を順番に確認すれば、新機能を一度にすべて有効にするより問題を特定しやすく、復元可能な旧設定も保てます。