mihomoコア
Proxy core · mihomoプロキシ接続、ルール照合、DNS名前解決、TUNトラフィックの処理を担うプログラムの中核で、Clash Metaプロジェクトを起源とします。GUIクライアントからmihomoを利用できますが、画面に表示される名称とコアの名称は異なる場合があります。設定項目がサポートされない場合や読み込みに失敗する場合は、クライアントのバージョンだけでなく、実際に使われているコアとそのバージョンを確認してください。
コアとクライアント
サブスクリプションのインポートからネットワークの制御まで、概念ごとに設定を確認できます。各カードでは用語の意味やよくある誤解に加え、あわせて確認したい設定項目を紹介します。
画面、バックグラウンドプロセス、コントローラーはそれぞれ役割が異なります。問題を調べるときは、まず動作中のコアを確認し、変更がどこに保存されたかを確かめてください。
プロキシ接続、ルール照合、DNS名前解決、TUNトラフィックの処理を担うプログラムの中核で、Clash Metaプロジェクトを起源とします。GUIクライアントからmihomoを利用できますが、画面に表示される名称とコアの名称は異なる場合があります。設定項目がサポートされない場合や読み込みに失敗する場合は、クライアントのバージョンだけでなく、実際に使われているコアとそのバージョンを確認してください。
コアとクライアント
コアにサブスクリプション管理、プロキシ選択、ログ表示、システム設定の画面を提供するアプリです。Clash Verge Revなどが該当します。オーバーライド、サービスモード、設定の保存方法はクライアントごとに異なります。同じサブスクリプションを別のクライアントで使う場合は、インポート成功の表示だけで判断せず、システムプロキシ、TUN、ローカル変更を改めて確認してください。
コアとクライアント
コントロールパネルや管理プログラムから、接続情報の取得、プロキシの切り替え、設定の再読み込みを行うためのインターフェースです。待ち受けアドレスはexternal-controllerで指定します。ブラウザー向けのプロキシポートではないため、プロキシ設定にmixed-portの代わりとして入力しないでください。有効にする場合はsecretでアクセスキーを設定し、信頼できないネットワークに管理権限を公開しないよう、待ち受け範囲を制限してください。
コアとクライアント
外部コントローラーに接続する管理画面で、通常はルール、アクティブな接続、プロキシグループを確認できます。external-uiでパネルの静的ファイルの保存先を指定できますが、パネル自体はプロキシ通信を中継しません。ブラウザーでパネルのページを閉じてもコアが停止するとは限りません。また、パネルが開かなくてもプロキシ接続が切断されたとは限りません。
コアとクライアント
ノードは接続に必要な設定、プロトコルは通信方式です。まず設定がサーバー側と一致しているかを確認してから、テスト結果を判断してください。
プロキシ接続に使うサーバー設定のまとまりで、通常はサーバーアドレス、ポート、プロトコル、認証情報を含みます。設定ファイルに直接proxiesとして記述するか、プロキシプロバイダーから取得できます。ノードは完全な設定ファイルではなく、表示名から実際の接続先を特定することもできません。接続を調べる際は、ログと接続先サイトへのアクセス結果をあわせて確認してください。
プロキシプロトコル
クライアントとプロキシサーバーがデータをやり取りする際の通信方式です。ノードのtypeフィールドで種類を指定します。プロトコル、下位のトランスポート方式、TLS設定はそれぞれ異なる層の項目です。1つの項目だけをもとに、ほかの設定を推測しないでください。コアがプロトコルに対応していても、サブスクリプションに必要な情報がすべて含まれているとは限りません。
プロキシプロトコル
暗号化プロキシプロトコルの一種で、mihomoのノード設定ではtype: ssを使います。サーバーアドレス、ポート、暗号化方式cipher、パスワードをサーバー側と一致させてください。ノード名から設定を推測することはできません。サーバー側で追加プラグインや特定のパラメーターが必要な場合は、コアの対応状況も確認してください。構文を解析できても、接続先サーバーにアクセスできるとは限りません。
プロキシプロトコル
指定したテスト先への接続を確認し、リクエストの往復時間を測定する方法です。結果はテスト先、接続の再利用、ネットワーク環境によって変わります。テストに成功しても、そのリクエストが完了したことを示すだけで、すべてのサイトやプロトコルが使えるとは限りません。遅延の数値はダウンロード速度ではありません。タイムアウトした場合は、ノードに接続できないのか、DNSの名前解決に失敗したのか、テスト先にアクセスできないのかを切り分けてください。
プロキシプロトコル
ルールが照合対象を決め、プロキシグループが処理方法を決めます。ログでは、適用されたルールと最終的な処理先をあわせて確認してください。
ドメイン、IPアドレスなどの条件に応じて、接続の処理方法を選ぶ仕組みです。mode: ruleでルールモードを有効にします。ルールは通常、上から順に照合され、条件に一致すると指定したプロキシや処理方法に振り分けられます。末尾には、ほかのルールに一致しない接続を処理するMATCHを置くのが一般的です。ルールからPROXYという名前のプロキシグループを参照する場合、その名前を設定内で定義しておく必要があります。ルール行だけをコピーしても動作しません。
ルールと分岐
ルールから参照する、proxy-groupsで定義されたプロキシ選択用のグループです。selectは手動選択、url-testはテスト結果に基づく選択、fallbackは利用可能性と順序に応じた切り替えに使います。それぞれ用途が異なります。グループ名、ノード名、ルール内の参照名を一致させてください。自動テストで選ばれたノードが、利用中のサイトに最適とは限りません。
ルールと分岐
多数の照合条件を独立したファイルにまとめ、rule-providersで管理するデータです。メインのルールからRULE-SETで参照し、そのルールで処理方法を指定します。ルールセットのbehaviorは、ファイルの内容形式に合わせてください。更新に成功しても、ファイルを取得できたことを示すだけです。参照先と、前のルールが先に一致していないかも確認してください。
ルールと分岐
IPアドレスの割り当て地域に基づいて照合するデータと仕組みです。たとえばGEOIP,CN,DIRECTは、該当するIPアドレスを直接接続します。MMDB形式では、Country.mmdbが一般的なデータベースファイルです。データベースがない場合や更新に失敗した場合、ルールが正しく動作しないことがあります。IPアドレスの登録地域は、サーバーの実際の所在地と一致するとは限らず、個別のドメインルールの代わりにもなりません。
ルールと分岐
ドメイン名の名前解決と、接続でドメイン名の情報を保持することは、関連していますが別の問題です。設定を変更する前に、実際の問い合わせ経路を確認してください。
ドメイン名をIPアドレスなどのレコードに変換する仕組みです。mihomoではdns設定で関連する動作を制御します。OS、ブラウザー、コアはそれぞれDNS設定を持つ場合があり、アプリで暗号化DNSを有効にすると別の経路が使われることもあります。サイトが開けない場合は、名前解決の失敗と接続の失敗を切り分けてください。nameserverを変更するだけで解決したと判断しないようにしましょう。
DNSとネットワークスタック
ドメイン名に合成IPアドレスを返し、接続がコアに入った後でドメイン名との対応を復元するDNS動作モードです。enhanced-mode: fake-ipで有効にします。ドメイン名によるルール照合を維持しやすくなりますが、合成IPアドレスはWebサイトの実サーバーのアドレスではありません。一部のLANサービスや特殊なアプリはfake-ip-filterへの追加が必要です。設定変更後は、アプリやシステムに残っている古いDNSキャッシュにも注意してください。
DNSとネットワークスタック
DNSクエリが想定した経路を通らず、別のDNSリゾルバーに送られる現象です。たとえば、プロキシ経由で問い合わせる想定なのに、ローカルネットワークのDNSリゾルバーに送信されるケースがあります。システムDNS、ブラウザーの暗号化DNS、TUNによる通信制御、コアから上流への問い合わせ経路をあわせて確認してください。検査ページに特定地域のリゾルバーが表示されただけでは、DNSリークの証明にはなりません。まず想定する経路を明確にし、実際の問い合わせと照らし合わせてください。
DNSとネットワークスタック
識別可能な接続ハンドシェイク情報からドメイン名の手がかりを取得する機能で、sniffer設定で制御します。接続先IPアドレスしか含まない通信の処理を補助できます。HTTPSの本文を復号する機能ではなく、すべてのドメイン名を取得できるわけでもありません。ハンドシェイク情報を確認できない場合もあります。誤検出や特定アプリの不具合が起きた場合は、すべての接続を強制的に上書きするのではなく、スニッフィングの対象範囲と除外設定を確認してください。
DNSとネットワークスタック
完全な設定、ノードの取得元、ローカルでの変更は、それぞれ分けて考える必要があります。サブスクリプションの更新後に消える設定は、オーバーライド層に保存すると保持しやすくなります。
リモートURLから取得し、更新できる設定やノード情報です。ClashのYAML設定、エンコードされたノード一覧、プロトコルリンクの一覧などが含まれます。URLを開けても、現在のインポート方法に適した形式とは限りません。HTMLのログインページが返された場合も、有効な設定ファイルではありません。サブスクリプションURLに含まれる認証情報はパスワードと同様に扱い、スクリーンショットやサポート依頼、不審な変換サービスに貼り付けないでください。
サブスクリプションと設定ファイル
mihomoの設定でよく使われる構造化テキスト形式です。インデントで階層を表し、ハイフンでリスト項目を示します。インデントにはスペースを使い、タブを混在させないでください。特殊文字を含む文字列は、YAMLの構文に従って引用符で囲めます。yaml: unmarshal errorsは、設定項目の型や構造が合っていない場合などに発生します。ファイルを解析できても、ノード、プロキシグループ、ルールの参照が正しいとは限りません。
サブスクリプションと設定ファイル
proxy-providersで定義するノードの取得元で、リモートファイルまたはローカルファイルを指定できます。通常はプロキシグループのuseフィールドから参照します。ノードを提供する仕組みであり、DNS、ルール、待ち受けポートを含む完全な設定ではありません。プロキシプロバイダーのURLを完全なサブスクリプションとしてインポートすると、動作に必要な設定が足りない場合があります。ファイルの内容とクライアントが対応するインポート方法を確認してください。
サブスクリプションと設定ファイル
サブスクリプションの元データとは別に変更を保存し、クライアントが実行用設定を生成するときに適用する仕組みです。カスタムルール、DNS、待ち受け設定などの保持に使えます。ダウンロードしたサブスクリプションを直接編集しても、次回の更新で変更が上書きされる場合があります。配列の置換、ルールの追加、スクリプトの実行順序はクライアントによって異なるため、保存後は編集画面の一部だけでなく、最終的に適用された設定を確認してください。
サブスクリプションと設定ファイル
プロキシの待ち受け、システム設定、ルーティングによる通信制御は、それぞれ別の機能です。有効化後は実際のアプリで動作を確認し、無効化後はシステム設定が元に戻ったか確認してください。
OSが対応アプリに提供するプロキシの接続先で、通常はクライアントがローカルで待ち受けるアドレスとポートを指定します。独自のプロキシ設定を使うアプリや、プロキシを経由せず直接接続するアプリもあります。システムプロキシを有効にしても、デバイス全体の通信がコアを経由するわけではありません。クライアント終了後もブラウザーにプロキシ接続エラーが表示される場合は、システムプロキシの設定が残っていないか、待ち受けプロセスが動作しているかを確認してください。
システムとプラットフォーム
仮想ネットワークデバイスとルーティング設定を使い、制御対象のIPトラフィックをコアに渡して処理します。システムプロキシに従わないアプリの通信を制御する際によく使われます。有効化には管理者権限、システムサービス、プラットフォームの許可が必要な場合がありますが、スイッチがオンでもルートが正しく設定されているとは限りません。インターネットに接続できなくなった場合は、ネットワークスタックを変更する前に、DNSの制御、ルートの除外設定、ほかのVPNとの競合を確認してください。
システムとプラットフォーム
ほかのデバイスから、このデバイスのプロキシ待ち受けポートへ接続できるようにします。関連する設定はallow-lan、待ち受けアドレス、OSのファイアウォールなどです。ほかのデバイスには、このデバイスのLAN内アドレスを指定してください。自分自身を表す127.0.0.1を指定しても接続できません。プロキシを共有しても、ネットワーク全体のデフォルトゲートウェイが自動で変更されるわけではありません。接続元を制限し、プロキシポートを公共のネットワークに公開しないようにしてください。
システムとプラットフォーム
サービスモードは、バックグラウンドのコアをシステムサービスなどとして実行する機能です。自動起動は、システムの起動時やユーザーのログイン時にアプリを実行する設定で、両者は同じではありません。ウィンドウを閉じたとき、トレイに最小化されるだけなのか、コアが動作し続けるのかはクライアントによって異なります。設定後は、画面が起動しているか、コアが動作しているか、システムプロキシやTUNが想定どおりに復元されるかをそれぞれ確認してください。
システムとプラットフォーム