クライアント・Clash・mihomoの違いを整理

WindowsのClashクライアントは通常、GUI、バックグラウンドサービス、プロキシコアが連携して動作します。GUIではサブスクリプションの読み込みやプロキシグループの選択、システムプロキシの設定を行い、コアはプロトコル接続、DNS処理、ルール判定を担います。同じクライアントでも、バージョンによって異なるコアが使われることがあります。そのため、YAMLを読み込めても、記述されたすべての項目をコアが処理できるとは限りません。

この記事では、元プロジェクトのオープンソース版ClashとClash Premiumを分けて扱います。Premiumは元プロジェクトが提供していたクローズドソースの拡張コアで、オープンソース版Clashとは別のものです。mihomoはClash Metaプロジェクトから派生し、対応プロトコルや設定機能を拡張しています。「Clash形式」という呼び方だけでは、異なるコア間の完全な互換性は保証されません。

対象主な用途移行時の確認ポイント
Clash（オープンソース版）基本的なプロキシプロトコル、プロキシグループ、ルール判定を提供PremiumのTUNやルールプロバイダーなどの拡張機能があるとは限りません
Clash Premium元プロジェクトの拡張コア。ルールプロバイダーやTUNなどに対応既存のrule-providersは移行前に照合できます。Premiumのスクリプト機能をmihomoの機能としてそのまま使えるとは限りません
mihomo / Clash Metaプロトコル、通信の検知、DNS、ルール機能を継続的に拡張するコアサブスクリプションの設定項目、クライアントに同梱されたバージョン、実際に動作中のコアをあわせて確認
Windows用GUIクライアント設定、コアのプロセス、システムプロキシ、サービスを管理GUIクライアントのバージョンとmihomoコアのバージョンは別です

対応プロトコルの違い：ノードが表示されても接続できるとは限らない

mihomoの大きな違いのひとつは、対応プロトコルの幅が広いことです。VLESS、Hysteria2、TUICを含むサブスクリプションを、Clashの旧版やPremiumでそのまま使うことはできません。同じプロトコル名でも、トランスポート方式、TLSフィンガープリント、UDP処理などのオプション対応はコアによって異なる場合があります。使用するバージョンごとに確認してください。

プロトコル・設定項目Clash旧版 / Premiummihomoでの確認ポイント
Shadowsocks、VMess、Trojan基本機能には対応していますが、利用できる暗号方式やトランスポートの選択肢はバージョンによって異なります暗号方式、トランスポートの種類、TLS、サーバー設定が一致しているか確認
type: vless非対応UUIDとトランスポート方式を確認。REALITYを使う場合は、公開鍵とshort-idも正しく設定
type: hysteria2非対応認証情報、SNI、ポート、サーバー側で実際にHysteria2が使われているかを確認
type: tuic非対応サーバー側のプロトコルバージョン、UUID、パスワード、UDP通信の到達性を確認
Shadowsocks 2022系の暗号方式通常のShadowsocksへの対応状況から判断できません暗号方式名と鍵の形式を確認し、その暗号方式に対応したコアを使用

Windowsで「読み込みは成功したのにノードが使えない」ときの確認方法

  1. サブスクリプションまたはノードの詳細画面で type を確認してください。表示名だけで判断しないようにしましょう。「高速」「専用回線」といった名前からプロトコルの種類は分かりません。
  2. ログに非対応のプロキシタイプ、未知の暗号方式、必須項目の不足などが出ていないか確認します。設定の読み込み時点でエラーが出ている場合は、まずコアとの互換性を解決してください。速度測定を繰り返す必要はありません。
  3. Hysteria2やTUICを使う場合は、現在のネットワークで該当するUDP通信が許可されているか確認してください。WebサイトにHTTPプロキシ経由で接続できても、UDP通信が正常とは限りません。
  4. クライアントでコアを選択できる場合は、対応するmihomoコアを選び、コアのプロセスを再起動してから起動ログを確認します。設定ファイル名を変えるだけでは解決しません。

mihomoに切り替えても、誤ったサーバー設定が自動で修正されたり、通常のサブスクリプションが別のプロトコルに変換されたりすることはありません。サーバー側で該当プロトコルが有効になっていない状態で、クライアントの type だけを変更すると接続に失敗します。

rule-providers：Premiumにも対応、mihomoは形式を拡張

rule-providers はmihomo独自の機能ではありません。Clash Premiumもルールプロバイダーに対応しています。移行時に比較すべきなのは、ルールの挙動、ファイル形式、参照順です。mihomoは、大量のドメインやIPルールに適したMRSバイナリ形式にも対応していますが、この形式のファイルを旧コアで使うことはできません。

まずローカルのルールセットで参照関係を確認

以下はメイン設定の抜粋で、サブスクリプション全体ではありません。組み込みのポリシー DIRECT と REJECT を使うため、特定のプロキシグループ名に依存せず、ルールだけを個別に確認できます。ルールセットのファイルは、コアからアクセスできる設定ディレクトリに置いてください。相対パスは手動で開いたYAMLの場所ではなく、コアの作業ディレクトリを基準に解決される場合があります。

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

rules:
  - RULE-SET,local-direct,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - MATCH,DIRECT

対応する rules/local-direct.yaml の内容は以下のとおりです。classical ルールセットにはマッチ条件だけを記述し、DIRECT は付けません。最終的な動作は、メイン設定の RULE-SET で指定します。

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

ルールセットの数よりマッチ順が重要

通常のルールは上から順に評価され、最初に一致したルールで接続先が決まります。ルールセットの参照より前に MATCH を置くと、後続のルールは接続を処理できません。リモートのルールセットを実際のサブスクリプションに追加した後は、ルールのアクションが参照するプロキシグループが存在するかも確認してください。Proxy、PROXY、日本語のグループ名を同じものとして扱うことはできません。

Windowsクライアントでは、設定編集、拡張設定、またはオーバーライド機能から項目を追加し、設定チェックとログでプロバイダーの読み込み成功を確認します。サブスクリプションの取得時に生成されたファイルを直接編集すると、次回更新時に上書きされることがあります。ルールの詳しい書き方はYAMLリファレンスのルール構文をご覧ください。

sniffer（通信の検知）：ドメイン情報を補う機能で、HTTPSを復号するものではない

アプリがIPアドレスに直接接続する場合や、ドメインとIPアドレスの対応関係がコアのDNSに反映されていない場合、ドメインルールの判定に必要な情報が不足することがあります。mihomoの sniffer は、HTTPのHostやTLSハンドシェイクのサーバー名などからドメインを検知できます。QUIC通信の判定にも対応しています。これは、Clash旧版やPremiumとの重要な設定上の違いのひとつです。

sniffer:
  enable: true
  override-destination: false
  sniff:
    HTTP:
      ports: [80, 8080-8880]
    TLS:
      ports: [443, 8443]
    QUIC:
      ports: [443]
  skip-domain:
    - "+.lan"

ここで指定する 80、443、8443 は、検知対象のポートであり、新たにローカルで待ち受けるポートではありません。例では override-destination を false に設定し、接続先の処理方法を最初から変えずに、ドメインの検知とルール判定を確認できるようにしています。

有効化後に確認する3つのポイント

  1. クライアントの設定編集またはオーバーライド画面から、トップレベルに sniffer を追加します。dns の中やノードの設定内に入れないでください。
  2. 設定を再読み込みしたら、新しい接続を開始し、「接続」画面またはログで宛先ドメインと適用されたルールを確認します。既存の長時間接続は、ルールを変更しても自動では再接続されません。
  3. 特定の社内ネットワークサービスで問題が起きた場合は、まずsnifferを無効にして再確認し、実際のドメインに応じて除外項目を追加します。高度な設定を一度に複数有効にすると、どの設定が挙動を変えたのか分かりにくくなります。

DNS設定：基本を保ち、段階的にルーティングを追加

Clash旧版にもDNSモジュールや fake-ip などの機能があるため、「fake-ipを使っている」だけではmihomoを使っていることにはなりません。mihomoはDNSルーティングやポリシーに関する項目を拡張しており、proxy-server-nameserver、direct-nameserver、respect-rules などを利用できます。どの環境でも必ず有効にする必要があるわけではありません。

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

ここでは設定項目の関係を示す基本例を紹介します。127.0.0.1:1053 はローカルホストのみで待ち受けます。198.18.0.1/16 は例でfake-ipを割り当てるためのアドレス範囲で、上流DNSサーバーのアドレスではありません。223.5.5.5 は平文DNSの例です。すべてのネットワークに適しているわけではなく、DNS通信が暗号化されることを示すものでもありません。

設定項目役割よくある誤解
nameserver通常のドメイン検索に使う上流DNSを指定アドレスを設定しても、すべてのアプリのDNSを自動的に処理するわけではありません
nameserver-policy条件に応じて特定のDNSクエリの送信先を選択DNSクエリの送信先を決める項目であり、通信に使うプロキシノードを直接決めるものではありません
proxy-server-nameserverプロキシサーバーのホスト名を解決する専用の上流DNSを指定ノードのホスト名が解決できない場合、通常のnameserverだけを変更しても解決しないことがあります
direct-nameserver直通接続で必要なホスト名を解決する上流DNSを指定直通時の名前解決とルール判定の関係も理解する必要があります
respect-rulesDNS上流への接続にもルーティングルールを適用ノードのホスト名解決にはproxy-server-nameserverも設定し、循環依存を避けてください

Windowsのシステムプロキシが影響するのは、主にシステム設定に従うアプリです。システム内のすべてのDNSリクエストが自動的に 1053 に送られるわけではありません。dns.listen を設定しただけで、実際のDNSクエリが待ち受けポートに届かなければ、設定があっても処理されないことがあります。アプリ独自の暗号化DNSは、独自のネットワーク接続でDNSサーバーにアクセスする場合もあるため、別途確認してください。

まずは respect-rules のデフォルト動作を維持し、通常の通信とノードのホスト名解決を確認してください。DNS上流を振り分ける必要がある場合に限り、この項目を追加し、ルールで上流への接続方法を明示します。詳しい設定項目はDNS設定の解説を参照し、複数の解説記事にある設定例をそのまま重ねて使わないでください。

TUNとシステムプロキシ：通信の入口は個別に有効化

mihomoはTUNに対応していますが、TUNはmihomoがPremiumに対して新たに追加した機能ではありません。設定項目やプラットフォームごとの実装は、そのまま相互に流用できません。Windowsでは、システムプロキシはブラウザーなどプロキシ設定に従うアプリに適しています。一方、TUNは仮想ネットワークアダプターとルーティングを通じて、より多くのIP通信を取り込みます。通常はクライアントのサービスや管理者権限が必要です。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

上記はTUN設定の抜粋です。コアのDNS機能を有効にして併用してください。any:53 はTUN経由の従来型DNSリクエストを処理するための設定で、DoHやDoTなど、ほかのポートを使う暗号化DNSまで自動的に取り込むものではありません。auto-detect-interface も、複数のネットワークアダプターがある環境で万能な解決策にはなりません。企業VPNや仮想マシンのアダプターを併用している場合は、実際の出口とルーティングを確認してください。

Windowsクライアントでの有効化手順

  1. まず通常のプロキシモードで、ノードとルールが機能することを確認してからTUNを検討してください。基本接続に問題がある状態で仮想ネットワークアダプターを有効にすると、トラブルの切り分けが難しくなります。
  2. クライアントの「設定」でサービスモードに関する項目を探し、画面の案内に従ってサービスをインストールまたは有効にします。権限が必要と表示された場合は、内容を確認して許可してください。
  3. 画面の「TUNモード」または「仮想ネットワークアダプター」を有効にし、ログを確認します。クライアントが tun の設定項目を自動生成する場合があるため、最終的に統合された設定を確認してください。
  4. ブラウザーと、システムプロキシを使わないアプリをひとつテストし、接続一覧で通信が実際にコアへ届いているか確認します。問題があればTUNを無効にして再テストし、ログを保存したうえでネットワークアダプターとルーティングを確認してください。

クライアントによってメニュー構成は異なるため、特定の画面でのスイッチの位置をコアの仕様と混同しないでください。利用できる機能は、クライアントのサービス管理方法、コアのバージョン、最終的な設定によって決まります。YAMLに enable: true があるかどうかだけでは判断できません。

移行時の確認：最終設定と実際の通信を検証

Premiumや旧版Clashからmihomoへ移行する場合は、元の設定をバックアップし、「基本プロキシ → ルールセット → DNS → 通信の検知 → TUN」の順に有効化するのがおすすめです。Premiumの script 機能を、mihomoの同名機能としてそのまま使うことはできません。また、クライアントのJavaScriptオーバーライドスクリプトは別のレイヤーで設定を生成・変更するもので、コアのルールスクリプトではありません。

設定チェックで構文エラーと接続の問題を切り分ける

テストするファイルを config.yaml として保存し、専用のテストディレクトリで以下のコマンドを実行します。クライアント上で使う場合は、統合後の実行設定を確認してください。サブスクリプション元のファイルがチェックに通っても、オーバーライド後のファイルが通るとは限りません。

.\mihomo.exe -t -f .\config.yaml

設定チェックでは、解析エラー、参照先の不足、一部の不正な設定項目を検出できます。ただし、ノードへの接続や、無効・非対応のすべての項目がエラーになることまでは保証されません。チェックに通っても機能しない場合は、起動ログ、最終設定、実際の接続に適用されたルールを確認してください。

ポートを固定してプロキシ経路を確認

実際に動作している設定が mixed-port: 7890 で、本機からの接続が許可されているとします。Windows PowerShellでは以下のコマンドを実行できます。旧バージョンのPowerShellで同名のエイリアスによる引数の違いが起きないよう、ここでは明示的に curl.exe を使います。

Test-NetConnection 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com/