mihomo コア · ルール分流リファレンス
Clash Verge 公式サイト ダウンロードと設定
当サイトでは mihomo コアの解説、サブスクリプションのインポート手順、ルール分流の記述方法をまとめています。5 プラットフォームのクライアントとコアファイルのダウンロードはダウンロードページに集約。初めて使う場合は、インストール、サブスクリプションのインポート、モードの選択、接続確認の 4 ステップで完了します。
設定パネル
クライアントの分流を決める 5 つの設定項目
mode、dns、tun、proxy-providers、external-controller は設定ファイルで最もよく変更される 5 つのセクションです。左側で切り替えて各セクションが何を解決するかを確認でき、右側には対応する config.yaml の抜粋を表示します。
mode は、コアが接続を受け取った後の処理方法を決めます。rule はルールテーブルを上から順に照合し、一致したルールに対応するポリシーを適用します。global はすべてのトラフィックを同じ出口に送り、direct はプロキシを一時的にオフにするのと同じです。通常は rule のままで問題ありません。global に切り替えるのは「ルールの書き間違いか、ノードが不通か」を見分けたいときだけにしましょう。クライアント画面のモードスイッチが変更するのはこの行です。rule に戻したら、ポリシーグループに使用可能なノードが少なくとも 1 つあることを確認してください。そうでないと、PROXY に一致した接続はそのまま失敗します。
mode: rule # rule / global / direct log-level: info ipv6: false
dns セクションは、ドメインを誰が解決し、どの経路を通るかを決めます。enhanced-mode を fake-ip にすると、コアはまず仮想アドレスをアプリに返し、実際の名前解決はプロキシ経路内で行われます。平文のクエリがローカルネットワーク上に現れることはありません。redir-host にすると先に解決してから接続するため、互換性は高いものの、中間機器に傍受されやすくなります。nameserver には暗号化された解決先（DoH または DoT）を指定し、fallback は汚染された応答を補うために使います。このセクションを変更したらコアの再起動を推奨します。設定のリロードだけでは解決キャッシュが再構築されないことがあります。
dns: enable: true enhanced-mode: fake-ip nameserver: - https://223.5.5.5/dns-query fallback: - tls://1.1.1.1:853
tun はコアが仮想ネットワークアダプターを作成し、システム全体のトラフィックを引き受ける仕組みです。アプリがシステムプロキシ設定に従うかどうかに依存しません。ターミナルのコマンド、コンテナ、ゲームクライアントなど、プロキシ設定を読み込まないプログラムは、tun を有効にして初めてルールの対象になります。有効にする前に権限を確認してください。Windows では管理者として実行する必要があり、macOS では初回有効時にネットワークコンポーネントのインストール許可を求められます。stack は gvisor が最も互換性が高く、system はシステムのプロトコルスタックを利用するためスループットが向上しますが、一部の環境ではファイアウォールと競合します。システム全体のトラフィックを引き受ける必要がない場合は、オフのままで構いません。
tun: enable: true stack: gvisor # gvisor / system / mixed auto-route: true dns-hijack: - any:53
proxy-providers は、サブスクリプションの URL を proxies から切り出し、コアが一定間隔で取得するようにする仕組みです。複数のポリシーグループで同じノードセットを共有でき、サブスクリプションの URL を変更するときもここ 1 か所を直すだけで済みます。health-check は可用性チェックの宛先と間隔を決め、チェックに失敗したノードはポリシーグループ内で一時的にスキップされます。path はキャッシュファイルの場所を指定し、取得に失敗した場合はコアが前回のキャッシュを使い続けるため、一度のネットワークの揺らぎでノードが消えることはありません。interval の単位は秒で、短すぎるとサブスクリプションサービス側でレート制限を受けるため、通常は 3600 から始めます。
proxy-providers: sub-a: type: http url: "https://example.com/api/v1/client/subscribe?token=xxxx" interval: 3600 path: ./providers/sub-a.yaml health-check: enable: true url: https://www.gstatic.com/generate_204 interval: 300
external-controller はコアが公開する制御インターフェースで、クライアント画面やサードパーティ製パネル、スクリプトがこれを通じて現在のポリシーの読み取り、ノードの切り替え、接続一覧の表示を行います。GUI クライアントはコア起動時にこの行を自動で書き込み、ランダムなシークレットを生成します。手動でコアをデプロイする場合にのみ、自分で指定する必要があります。既定では 127.0.0.1:9090 をリッスンし、ローカルマシンからのみアクセスできます。LAN やサーバーに公開する場合は secret を必ず設定してください。設定しないと、同じネットワーク内の誰でも分流ルールやノードの選択を変更できてしまいます。
external-controller: 127.0.0.1:9090 secret: "your-password"
プラットフォーム別の入口
OS 別にクライアントを選ぶ
5 つのプラットフォームには、それぞれ現在も更新が続くクライアントがあります。ダウンロードページではプラットフォームごとに選択可能なすべてのモデル、システム要件、インストール手順を掲載し、コアファイルは別セクションにまとめています。
オープンソースエコシステム
コア、クライアント、ルールセットの保守範囲
同じ設定ファイルを別のクライアントで使えるのは、実際に解析しているのがコアだからです。3 つの層がそれぞれ何を担うのかを整理しておけば、クライアントやコアを乗り換えてもルールを書き直す必要はありません。
クライアントとコアは別の層
mihomo は設定の解析、接続の確立、ルールの実行を担当します。Clash Verge Rev や FlClash といったクライアントは、画面、サブスクリプション管理、コアプロセスの起動と停止を担当します。同じコアを別のクライアントから利用でき、設定ファイルの形式も共通です。クライアントを乗り換えるときは profile をエクスポートしてインポートするだけで、ルールとポリシーグループを書き直す必要はありません。
フォークの関係と設定の互換性
オリジナルの Clash コアはメンテナンスが終了し、コミュニティがその設定フォーマットを引き継いで開発を続けた結果、Meta と mihomo の系統が生まれました。VLESS、Hysteria2、TUIC などのプロトコル対応や、rule-providers、proxy-providers といった設定機能が追加されています。現在も更新が続くクライアントは基本的に mihomo をコアとして採用しており、設定ファイルにどのフィールドを書けるかは mihomo のドキュメントが基準です。
ルールセットは独立した保守ライン
分流ルールはドメイン、IP、プロセスなどの種類ごとのリストファイルに分割され、それぞれ別のプロジェクトが保守しています。コアは rule-providers を通じて必要なときに取得します。この仕組みにより、ルールを更新しても設定ファイルを変更する必要はなく、クライアント側は参照を残しておくだけで済みます。ルールセットを選ぶときは、エントリの総数よりも更新頻度と分類の粒度に注目するほうが有用です。
更新の仕組みは 3 つの層に分かれる
クライアントの更新は、画面、コア、サブスクリプションとルールセットの 3 つの層に分かれます。多くのクライアントはコアを差し替え可能なコンポーネントとして扱い、設定でバージョンを指定したり、バイナリを手動で置き換えたりできます。サブスクリプションとルールセットは、それぞれに設定した間隔で定期的に取得されます。接続に問題が起きたときは、まず 3 つの層の設定とタイミングが噛み合っているかを確認し、そのうえで具体的なエラーを調べましょう。
よくある質問ピックアップ
使い始める前によくある 4 つの疑問
ここでは特によく聞かれる 4 つを紹介します。カテゴリ別の質問と回答は FAQ ページに、用語の解説は用語集にまとめています。
サブスクリプションの更新に失敗したとき、まず何を確認するか
まず、サブスクリプションの URL 自体がブラウザで開けて内容が返ってくるかを確認し、そのうえでクライアントの更新ログとタイムスタンプを確認します。失敗の多くは、URL の期限切れ、ローカル DNS によるブロック、サブスクリプションサービスの一時的なレート制限です。URL を再インポートすると、キャッシュや古い設定の影響を排除できることがほとんどです。
クライアントは接続済みなのに Web ページが開かない
次の 3 点を順に確認します。dns セクションが有効で暗号化された解決先を向いているか、モードが direct に切り替わっていないか、接続ログで目的のドメインがどのルールに一致したか。3 つとも問題なければ、別のノードに切り替えて出口そのものの問題かどうかを確かめます。
rule モードと global モードの違いは何か
rule はルールテーブルを 1 件ずつ照合し、ドメインごとに異なる出口を使い分けます。global はすべてのトラフィックを同じ出口に送ります。モードはコアの処理方法を変えるだけでノード自体には影響しないため、問題の切り分けでは global に切り替えて比較するのが最も手早い方法です。
カスタムルールは設定ファイルのどのセクションに書くか
rules セクションに書きます。書式は「タイプ, マッチ条件, ポリシー名」の 3 つの部分です。ルールが増えたら、別のルールセットファイルに分割し、rule-providers で読み込むこともできます。そうすればルールの更新時にメインの設定を変更せずに済みます。
技術ノート
最近のトラブルシューティングと選定の記録
問題の種類ごとに整理した記事：プラットフォーム別の導入、クライアントの比較、サポート終了後の移行、証明書のトラブルシューティング。いずれも手順に沿って実行できる形でまとめています。
iOS 入門：App Store でのクライアント入手と設定インポートの完全手順
iOS 版について、App Store での検索、地域による違い、サブスクリプション URL のインポート、オンデマンド接続の有効化までの設定手順を整理し、初回接続後にルール分流が機能しているかを確認する方法を説明します。
全文を読む →クライアントの更新終了後に：設定のエクスポート、コアの差し替え、代替案
クライアントのメンテナンス終了は、設定が無効になることを意味しません。まず profile とルールをエクスポートし、プラットフォームに応じて更新が続くクライアントを選ぶか、mihomo コアに直接乗り換えます。移行前後のチェックリスト付きです。
全文を読む →主要 Clash クライアントの比較：プラットフォームと使い方に合わせた選び方
コアのバージョン、対応プラットフォーム、設定方法、更新ペースの 4 つの観点から主要クライアントを比較し、Windows、macOS、モバイル、デスクトップ向けの選定アドバイスを提示します。インストールしてから合わないと気づく事態を避けられます。
全文を読む →