mihomoコア
mihomo / Clash Meta設定の読み込み、ルールの照合、プロキシ接続の確立、DNSの処理を担うネットワークコアです。Clash Metaの技術を引き継いでいます。GUIクライアントはその上で設定画面を提供しますが、利用できるプロトコルや設定項目はコアの機能によって決まります。互換性の問題を調べる際は、アプリ名だけで判断せず、クライアントとコアそれぞれのバージョンを確認してください。
コア、プロトコル、ルール、DNSの基本用語を解説。設定に記載された項目名から意味を確認し、どの設定を見直すべきか判断できます。
このページではmihomoの一般的な設定を基準に解説します。クライアントによってボタン名は異なり、各項目が使えるかどうかは利用中のコアによって異なります。初めて設定する場合はサブスクリプションの追加方法を、接続に問題がある場合はトラブルシューティングをご覧ください。
ネットワーク処理を担うコア、操作画面を提供するクライアント、読み込んだ設定内容を区別しましょう。
設定の読み込み、ルールの照合、プロキシ接続の確立、DNSの処理を担うネットワークコアです。Clash Metaの技術を引き継いでいます。GUIクライアントはその上で設定画面を提供しますが、利用できるプロトコルや設定項目はコアの機能によって決まります。互換性の問題を調べる際は、アプリ名だけで判断せず、クライアントとコアそれぞれのバージョンを確認してください。
サブスクリプション管理、モード切り替え、ログ確認、システム連携などを行うアプリケーションです。Clash Verge Revなどが該当します。異なるクライアントが同じ系統のコアを使っていても、メニュー名、設定ファイルの保存場所、サービスの管理方法は異なる場合があります。クライアントを更新しても、コアが更新されるとは限りません。ガイドを参照する前に、アプリ名と使用中のコアを確認してください。
URLからノードや設定一式を取得し、定期的に更新する配信方式です。設定一式にはプロキシグループ、ルール、DNS設定が含まれる場合があり、更新によってノード一覧以外も変わることがあります。認証情報を含むサブスクリプションURLは適切に管理し、スクリーンショットやログを共有する前にURLを隠してください。手動変更はクライアントが対応する上書き設定に加え、更新時に消されないようにしましょう。
クライアントに保存されるプロキシ接続設定で、通常はプロトコル、サーバーアドレス、ポート、認証情報が含まれます。ノード名は識別用のラベルにすぎず、名前だけでサーバーの所在地や接続品質を判断することはできません。ノードを選択できても、認証やネットワーク接続が成功したとは限りません。実際のアクセス結果とログの接続エラーをあわせて確認してください。
プロトコル名が示すのは通信方式であり、速度ではありません。サーバー側の設定、トランスポート層、ネットワーク環境も接続に影響します。
暗号化に対応したプロキシプロトコルで、mihomoの設定では通常、ssタイプを指定します。サーバーアドレス、ポート、暗号化方式、パスワードをサーバー側の設定と一致させてください。接続によっては追加のプラグイン設定も必要です。UDPを利用できるかは両側の設定によって異なります。Webページを閲覧できても、ゲームなどUDPを使うアプリが通信できるとは限りません。
UUIDなどで認証するプロキシプロトコルで、複数の通信方式やTLS設定と組み合わせて利用できます。ノードを追加する際は、サーバーとポートだけでなく、WebSocketのパス、Host、サーバー名なども確認してください。プロトコル名だけを変更しても、別の種類のノードをVMessに変換することはできません。サーバー側が該当する接続方式に対応している必要があります。
認証と転送の仕組みを簡素化したプロキシプロトコルで、通信内容の暗号化は行いません。接続にはTLS、REALITY、通信方式などの設定が関わるため、VLESSという名称だけで暗号化が保証されるわけではありません。ノードを追加できない場合は、まずコアがその組み合わせに対応しているかを確認し、UUID、サーバー名、ハンドシェイク関連の設定を照合してください。
通常はTLS接続を使用し、パスワードで認証するプロキシプロトコルです。パスワードが正しくても、サーバー名や証明書が一致しないと、ハンドシェイク時に接続できないことがあります。システム時刻、サーバー名、証明書のエラーをあわせて確認してください。通常の対処として証明書検証を無効にすると、サーバーの正当性を確認する機能が弱まります。
ルールによって接続先が決まります。設定内容だけでなく、現在のモードでルールが適用されるかも確認してください。
ドメイン名、接続先IPアドレスなどの条件に応じて、接続をDIRECT、プロキシ、REJECTなどの出先に振り分ける仕組みです。ルールは通常、上から順に照合され、最初に一致したルールが適用されます。範囲の広いルールが先にあると、その後の詳細なルールが適用されない場合があります。振り分けを確認する際は、選択中のノードだけでなく、接続ログに表示された一致ルールと最終的な出先を確認してください。
IPアドレスの所在地をもとに照合するデータとルールの仕組みで、地域別の振り分けによく使われます。データベース上の所在地は、企業の登記地やサービスを実際に利用できる地域とは異なる場合があります。データベースの更新状況やコンテンツ配信ネットワークも結果に影響します。ドメイン名をIPアドレスで照合する場合は、DNSの結果も関係します。DNS応答とルールの順序をあわせて確認してください。
外部ルールセットをルール一覧から参照するためのルールタイプです。ルールセット名はrule-providersで定義した名前と一致させます。大量のルールをメイン設定から分離できるため、個別の管理や更新に便利です。参照を追加しただけではルールが適用されるとは限りません。解析方式、ファイル形式、メインのルール一覧での位置も確認してください。
追加条件を指定せず、それまでのルールに一致しなかった接続を処理するフォールバックルールです。通常はrules一覧の末尾に置きます。出先にはプロキシグループやDIRECTなどの組み込み出先を指定できます。先頭に置くと、後続のルールが接続を処理できなくなる場合があります。すべての通信が同じ出先になるときは、まずこのルールの位置を確認してください。
プロキシグループは、選択可能な出先をまとめて管理します。手動選択、応答時間による自動選択、優先順位に沿った切り替え、接続の振り分けは、それぞれ異なる動作です。
グループ内のメンバーをユーザーが手動で選ぶプロキシグループです。メンバーにはノードのほか、別のプロキシグループも指定できます。接続でこのグループが参照されている場合に、選択が反映されます。ノードを切り替えても出先が変わらない場合、選択が失敗したとは限りません。一致したルールからグループの参照先をたどり、新しい接続で動作を確認してください。既存の接続は、切り替え前の出先を使い続けることがあります。
テスト先に定期的に接続し、候補メンバーの応答状況を比較して出先を自動選択します。画面に表示される応答時間は通常、テスト先への応答状況を示すもので、ファイルのダウンロード速度やすべてのサイトでの使いやすさを表すものではありません。intervalはテスト間隔を、toleranceは応答時間の差が小さい場合に頻繁に切り替わるのを抑えるために使います。
メンバー一覧の順に、利用可能な出先を優先して使います。先頭のメンバーが利用できない場合は、次のメンバーに切り替わります。最速のノードを常に選ぶ方式ではなく、あらかじめ設定した優先順位を重視するため、優先回線を固定したい構成に向いています。テスト先に接続できても、実際のサービスが利用できるとは限りません。切り替え後も、実際の通信で動作を確認してください。
指定した方式に従って、異なる接続をグループ内の利用可能なメンバーに振り分けます。単一の接続の帯域を複数ノードで合算する仕組みではありません。宛先ごとに同じ出先を維持する方式もあれば、順番に振り分ける方式もあります。ログイン状態を安定させたいサービスでは、出先の変化に注意してください。メンバーが多いからといって、必ず使いやすくなるわけではありません。
ドメイン名の解決、通信の取り込み、実際の出先経路を分けて確認しましょう。スイッチを有効にするだけでは、通信経路全体の確認にはなりません。
ドメイン名をIPアドレスなどのレコードに変換する仕組みで、多くのネットワーク接続に先立って利用されます。プロキシサーバー自身のドメイン解決、通信先ドメインの解決、DNSリクエストの出先経路には、それぞれ異なる設定が使われる場合があります。ブラウザーが独自の暗号化DNSを利用することもあります。特定のアプリだけサイトに接続できない場合は、アプリ側とコア側のDNS設定を別々に確認してください。
コアがドメイン名に合成アドレスを割り当て、対応関係を保存するDNS拡張方式です。通信がコアに取り込まれた後、元のドメイン名を復元して振り分けるのに役立ちます。アプリが取得した合成アドレスは、サイトの実際のサーバーアドレスではないため、サイトの所在地を判断する用途には使えません。実際のIPアドレスを必要とするLANサービスやアプリでは、DNS機能全体をすぐに無効にせず、問題に応じてフィルター設定を検討してください。
指定した経路で処理するはずのドメイン問い合わせが、想定外のDNS経路を通っている状態です。DNSが直接接続されても、すべてがリークとは限りません。一部のドメインをローカルで解決する設計なら、想定どおりの動作である場合もあります。判断する前に、保護したい対象を明確にし、システムのDNSリゾルバー、ブラウザーの暗号化DNS、IPv6、コアが通信を取り込む範囲を確認してください。テストページに表示された地域だけで結論を出さないようにしましょう。
仮想ネットワークインターフェースとルーティングで通信を取り込む方式で、システムプロキシを参照しないアプリの通信に使われます。通常、適切な権限またはサービスが必要です。実際に処理される範囲は、ルート、DNSの取り込み、コアの設定によって異なります。TUNモードはグローバルモードと同じではありません。コアに取り込まれた通信は、引き続きルールで振り分けられます。有効にした後にネットワークへ接続できなくなった場合は、ルートの競合とDNS経路を確認してください。
ノードの定義、プロキシグループの構成、ルールからの参照には、それぞれ決まった設定場所があります。名称を正しく対応させることで、設定全体がつながります。
mihomoの設定でよく使われる構造化テキスト形式です。インデントで階層を、ハイフンでリスト項目を表します。編集時は空白によるインデントを統一し、タブとの混在を避けてください。特殊文字を含む値は、構文に応じて引用符で囲みます。YAMLとして解析できても、基本的な構造が正しいことを示すだけで、現在のコアが項目に対応していることやノードの認証情報が正しいことまでは保証されません。
メイン設定でプロキシの出先を定義するリスト項目です。各エントリーには通常、name、type、プロトコルに必要な接続パラメーターが含まれます。プロキシグループやルールからノードを参照する際は、ここで定義した名前と一致させ、重複による混同を避けてください。外部のノードプロバイダーを使う設定では、別ファイルにメンバーが定義される場合があります。メイン設定にノードがほとんどなくても、設定が不足しているとは限りません。
プロキシグループの名前、タイプ、候補メンバーを定義するリスト項目です。ルールとノードをつなぐ管理レイヤーとして機能します。グループ内のメンバーはproxiesで指定するほか、設定に応じてノードプロバイダーを参照できます。ルールで使うグループ名は定義と一致させ、グループ同士の循環参照も避けてください。名前を変更した場合は、画面表示だけでなく、すべての参照箇所を確認してください。
外部ルールセットの取得元、解析方式、ファイル形式、保存先、更新方法を定義します。ルールセットを追加しただけでは照合に使われず、rules内でRULE-SETを使って参照する必要があります。更新に失敗した場合は、ダウンロードログとローカルファイルの状態を確認してください。ファイルが存在してもルールが適用されない場合は、解析方式とメインルールの順序を確認しましょう。