mihomoコア
Proxy coremihomoは、Clash Metaプロジェクトを引き継いで発展したプロキシコアです。プロトコル接続、ルール照合、DNSなどのネットワーク処理を担います。コアは単独で動作するほか、GUIクライアントから呼び出して使うこともできます。そのため、クライアントとコアの名称が異なる場合があります。設定が利用できるかどうかは、アプリ名にClashが含まれるかではなく、実際に動作しているコアとその対応状況で判断してください。
用語集
設定項目から用語を調べ、通信の仕組みから違いを理解できます。コア、プロトコル、振り分け、サブスクリプションの用語を5つのテーマに整理しました。
実行コンポーネント
画面、処理エンジン、プロキシの出力先はそれぞれ別の要素です。問題を調べる際は、まずどの層で発生しているかを確認しましょう。
mihomoは、Clash Metaプロジェクトを引き継いで発展したプロキシコアです。プロトコル接続、ルール照合、DNSなどのネットワーク処理を担います。コアは単独で動作するほか、GUIクライアントから呼び出して使うこともできます。そのため、クライアントとコアの名称が異なる場合があります。設定が利用できるかどうかは、アプリ名にClashが含まれるかではなく、実際に動作しているコアとその対応状況で判断してください。
GUIクライアントは、サブスクリプションのインポート、ポリシーの選択、ログの確認などを画面上で操作できるようにします。システムプロキシの設定やサービス管理を担う場合もあります。同じコアでも異なるクライアントと組み合わせられ、メニュー名や設定の保存方法も異なります。クライアントを変更する前に、対応OS、コアの種類、設定の移行方法をそれぞれ確認してください。
クライアントの比較を見る ›ノードは通常、設定に記述する個々のプロキシ出力先を指し、プロトコル、サーバーアドレス、ポート、認証パラメーターなどを含みます。ノード名は識別用のラベルにすぎず、サーバーの所在地、回線品質、プロトコルの機能を保証するものではありません。同じサーバーに複数の異なる出力設定を用意できるため、接続ログや実際のアプリでの動作を踏まえて選びましょう。
クライアントの遅延テストは、指定したプロキシ経由でテスト先に接続し、所要時間を記録する方法が一般的です。ICMP Pingとは限りません。結果はテスト先、DNS、接続確立の過程、その時点のネットワーク状況に左右され、ダウンロード速度にそのまま換算することはできません。テストがタイムアウトしても、すべてのサイトが利用できないとは限らないため、テスト先への到達性と個別の接続ログも確認してください。
クライアントやコントロールパネルがコアを操作するための管理インターフェースです。通常は external-controller で待ち受けアドレスを設定します。接続情報の取得、ポリシーの切り替え、実行状態の確認などに使いますが、アプリの通信に使うプロキシポートではありません。アクセス範囲は必要最小限に制限してください。リモート管理を行う場合は、認証を設定し、ファイアウォールのルールも確認しましょう。
プロキシ接続
プロトコルは通信方式を定めるもので、速度の順位を示すものではありません。サーバー側の実装、ネットワーク経路、端末の性能も通信速度に影響します。
Shadowsocksは暗号化プロキシプロトコルの一つで、設定では通常 ss と表記します。クライアントとサーバーで暗号化方式と認証情報を一致させる必要があります。プロトコルの拡張機能やプラグインによっては、追加のパラメーターも必要です。アプリ側で利用するSOCKSプロキシの入口とは別の概念なので、名前が似ているだけで設定を流用しないでください。
VMessとVLESSは、V2Rayエコシステムで使われる別々のプロトコルであり、同じ設定形式の表記違いではありません。VLESS自体はデータを暗号化しないため、TLSやREALITYなどと組み合わせて接続の安全性を判断します。インポート時は通信方式、サーバー名、認証パラメーターも確認してください。typeだけを変更しても、プロトコルの変換はできません。
Trojanは通常、TLSを使ってプロキシ接続を確立します。設定ではパスワード、サーバーアドレス、TLS関連のパラメーターを一致させる必要があります。証明書の検証に失敗した場合は、検証を無効にする前にサーバー名、端末の時刻、証明書チェーンを確認してください。ノード名が同じでも通信設定が異なる場合があり、接続できるかどうかは両端の設定が一致しているかで決まります。
Hysteria2はQUICベースで、接続にはUDPで通信できることが必要です。パケットロスや経路の変動がある環境では、従来のTCP通信とは異なる特性があります。すべてのネットワークで高速になるわけではなく、帯域幅や輻輳制御の設定も使い勝手に影響します。現在のネットワークでUDPが制限されている場合は、DNSやルールを何度も変更する前に、まず通信できる条件が整っているか確認してください。
TUICもQUICベースで、TCPとUDPの通信をプロキシできますが、認証、設定、実装の詳細はHysteria2とは異なります。クライアントとサーバーで、対応するTUICのプロトコルバージョンを一致させてください。モバイル端末では、接続の維持、ネットワークの切り替え、バックグラウンドでの動作も考慮して消費電力を判断しましょう。プロトコル名だけで省電力かどうかは決まりません。
プロトコルの設計と選び方を見る ›照合とポリシー
ルールは接続を照合し、ポリシーグループは出力先をまとめます。接続の詳細を確認する際は、両方をあわせて確認しましょう。
ルールモードでは、コアが設定順に接続を確認し、ドメイン名、アドレスなどの条件に一致するかを判定します。通常、最初に一致したルールが出力ポリシーを決定するため、条件の広いルールを先に置くと、後続の詳細なルールが適用されない場合があります。Clashのカスタムルールを追加した後は、接続詳細で一致したルールを確認し、最後のフォールバックルールが想定したポリシーを指しているかも確認してください。
ルールの使い方を見る ›ポリシーグループは複数のノードや他のポリシーグループをまとめた論理的な出力先で、ルールから共通して参照できます。selectは通常、手動選択に使います。url-testはテスト結果に基づいて選択し、fallbackは可用性を重視して順番に切り替えます。グループ名だけでは動作を判断できません。問題を調べる際は、グループ内の参照先をたどり、最終的に使われるノードを確認してください。
GeoIPはIPアドレスの分類による照合に、GeoSiteはドメイン名の集合による照合に使われます。参照するデータと照合対象はそれぞれ異なります。データ上の分類は、接続先サービスの現在の物理的な所在地を示すとは限らず、更新の遅れによる誤差もあります。意図しない照合が起きた場合は、ノードだけを変更するのではなく、ドメインの名前解決結果、データの提供元、ルールの順序をあわせて確認してください。
ルールセットは rule-providers で定義し、ルール一覧から RULE-SET で参照します。照合条件を独立して管理するための仕組みです。通常、ルールセット自体はノードを選択せず、参照元のルールが最終的なポリシーを指定します。データ形式と動作タイプを適切に合わせ、リモート更新に失敗した際に古いデータが使われていないかも確認してください。
ルールモードはルール一覧に基づいて出力先を決め、グローバルモードは主に GLOBAL ポリシーグループを使用します。ダイレクトモードでは、コアに渡された接続を直接出力します。グローバルモードでも、システムの全通信が自動的にコアに取り込まれるわけではありません。対象範囲はシステムプロキシ、TUN、各アプリの動作によって異なります。モードを切り替えた後は新しい接続で確認してください。既存の接続は以前の経路を使い続ける場合があります。
通信の入口と名前解決
接続の取り込みとドメイン名の名前解決は、関連していますが別々の経路です。モードを切り替えるだけでなく、実際の通信経路も確認しましょう。
TUNモードは仮想ネットワークインターフェースでIPパケットを受け取り、システムプロキシに従わないアプリの一部も対象にできます。有効化には管理者権限、サービスコンポーネント、またはシステムのVPN許可が必要な場合があり、ルーティングやDNSの設定も求められます。特定のプロキシノードを常に使うモードではなく、取り込まれた接続の出力先は現在のモードとルールで決まります。他のVPNとルーティングが競合する場合もあります。
システムプロキシは、プロキシのアドレスとポートをOSに登録し、この設定に対応したアプリの接続をクライアントに渡す仕組みです。独自のネットワーク設定を使うアプリは対象外になる場合があるため、ブラウザーが使えてもすべてのプログラムが取り込まれているとは限りません。クライアントを終了またはアンインストールした後にネットワークへ接続できない場合は、停止したローカルポートを指すプロキシ設定がシステムに残っていないか確認してください。
Fake-IPはドメイン名に仮想アドレスを返し、コア内でドメイン名とアドレスの対応を保持することで、接続を取り込む際にドメイン名に基づく処理を可能にします。返されるのは接続先サーバーの実際のアドレスではないため、そのアドレスを使って外部の位置情報を調べても意味はありません。実際の名前解決結果を必要とするアプリでは fake-ip-filter に登録が必要な場合があります。設定変更後は、関連するDNSキャッシュの消去も必要になることがあります。
redir-hostはアプリに実際の名前解決結果を返す方式で、Fake-IPが仮想アドレスを返す方式とは異なります。ドメインルールが正しく照合されるかは、コアが保持するドメインの対応情報やスニッフィングなどにも左右されます。拡張モードの切り替えは万能な解決策ではありません。まず、問題が名前解決、接続の取り込み、ルール照合のどこで起きているかを確認し、キャッシュと名前解決の経路を調べてください。
DNSリークとは、ドメイン名の問い合わせが想定した名前解決経路から外れることを指します。たとえば、接続はプロキシ経由でも、DNSクエリは想定外のシステムリゾルバーに送信される場合があります。ブラウザーの暗号化DNS、システムDNS、IPv6、クライアントがDNS通信を取り込む範囲をあわせて確認してください。検出ページに特定のDNS事業者が表示されたことだけでは、リークの証明にはなりません。想定した設定と実際の問い合わせ経路を照らし合わせて判断しましょう。
設定の取得元と管理
リモート設定、ローカルファイル、クライアントの上書き設定には、それぞれ適用範囲があります。変更する前に、現在どの設定が読み込まれているか確認しましょう。
Profileはクライアントが管理し、コアが読み込む設定です。通常、ノード、ポリシーグループ、ルール、DNS、待ち受けポートなどを含みます。クライアントには複数のProfileを保存できますが、通常、現在の設定元として選択されるのはそのうちの1つです。インポートに成功しても、切り替えが適用されたとは限りません。選択状態、コアの読み込み結果、接続ログを確認してください。
サブスクリプションURLからリモート設定やノードデータを取得できます。返される内容は、完全なYAMLの場合もあれば、特定形式のノード一覧だけの場合もあるため、適切なインポート方法を選ぶ必要があります。サブスクリプションの更新はコンテンツを再取得する操作であり、プロキシ接続の確立を意味するものではありません。URLにアクセス認証情報が含まれることが多いため、公開画像に載せないでください。Clashのサブスクリプション更新に失敗した場合は、URLの無効、リクエストの失敗、形式の解析エラーを切り分けましょう。
サブスクリプションのFAQを見る ›YAMLは、Clash系の設定でよく使われる構造化テキスト形式です。インデント、キーと値、リストで階層を表します。インデントにはTabではなく半角スペースを使い、文字列に含まれる特殊文字には引用符が必要な場合があります。構文が正しくても、現在のコアが項目に対応しているとは限りません。保存後は読み込みログを確認し、エディターにエラーがないことだけで設定の正しさを判断しないでください。
プロキシプロバイダーは proxy-providers で個別に更新できるノードソースを定義し、ポリシーグループから参照する仕組みです。ノード管理とルール管理を分けて行えます。完全なProfileとは異なり、通常、DNSやルール振り分けの設定全体は提供しません。インポートする前にリモートデータの形式を確認してください。どのサブスクリプションURLでもそのまま使えるとは限りません。
上書きやマージを使うと、リモート設定を維持したまま、ルールの追加やDNSの変更などをローカルに反映できます。サブスクリプションの更新によってローカルの変更が失われるのを防ぐための仕組みです。通常はクライアントが処理するため、項目の優先順位、リストの追加や置き換えの方法はアプリによって異なります。変更後は上書きの編集画面だけでなく、最終的にコアへ渡される設定も確認してください。元に戻せるよう、元の設定も保存しておきましょう。