mihomoカーネル
mihomoはClash Metaのフォークから発展したプロキシカーネルで、設定の解析、ルール判定、DNS処理、プロキシ接続を担います。GUIクライアントから管理できるほか、コマンドライン環境で単独起動することもできます。設定項目が使えるかどうかは、クライアント名だけで判断せず、実際に動作するカーネルのバージョンとドキュメントを確認してください。
関連項目:GUIクライアント →5分野に分けて、よく使われる25の用語を解説します。まずカーネル、クライアント、通信の入口を区別し、次にルール、DNS、設定ファイルを確認しましょう。各項目には個別リンクがあり、説明を直接共有できます。
画面は設定を管理し、カーネルは通信を処理します。画面上のスイッチが機能するかどうかは、権限、実際の設定、通信がカーネルに入っているかによって異なります。
mihomoはClash Metaのフォークから発展したプロキシカーネルで、設定の解析、ルール判定、DNS処理、プロキシ接続を担います。GUIクライアントから管理できるほか、コマンドライン環境で単独起動することもできます。設定項目が使えるかどうかは、クライアント名だけで判断せず、実際に動作するカーネルのバージョンとドキュメントを確認してください。
関連項目:GUIクライアント →GUIクライアントは、サブスクリプションの読み込み、プロキシグループの選択、システムプロキシの切り替え、ログの確認などを行う画面を提供します。Clash Verge Revもこの層のソフトウェアです。クライアントがカーネルのプロセスを管理し、画面上の設定をサブスクリプションにマージする場合があります。そのため、サブスクリプションの元データとカーネルが最終的に受け取る設定は異なることがあります。トラブル対処では実行中の設定を確認してください。
クライアント一覧を見る →システムプロキシは、プロキシのアドレスとポートをOSに登録し、この設定に従うアプリが接続時に利用する仕組みです。一般的な接続先はローカルのループバックアドレスです。端末上のすべての通信を取り込むわけではなく、独自のネットワーク設定を持つアプリはシステムプロキシを無視する場合があります。一部のアプリだけ接続できない場合は、まずアプリ独自のプロキシ設定を確認し、必要に応じてTUNを検討してください。
関連項目:TUNモード →サービスモードでは、クライアントがOSのバックグラウンドサービスを利用し、高い権限が必要なカーネル処理を起動・管理します。デスクトップ版では、仮想ネットワークインターフェースなどの機能と併用することがあります。サービスのインストールには管理者の許可が必要な場合がありますが、システムプロキシ、TUN、スタートアップが有効になるわけではありません。インストール後は各機能のスイッチ、カーネルの状態、関連ログを個別に確認してください。
外部コントローラーは、GUIクライアントや管理パネルから状態の確認、ポリシーの切り替え、接続の管理を行うためのインターフェースです。設定項目は通常 external-controller です。管理用の入口であり、ブラウザーのWebリクエストを転送するプロキシポートではありません。通常はローカルホストだけで待ち受け、認証を設定してください。LANに公開する場合は、アクセス権限とファイアウォールも考慮しましょう。
ノードはサーバーアドレスだけではありません。プロトコル、認証、通信方式、ネットワークの対応状況を確認し、テスト結果は実際の用途に照らして判断しましょう。
プロキシノードは、リモートのプロキシサービスに接続するためのパラメーター一式です。通常、サーバーアドレス、ポート、プロトコル、認証情報、通信方式などが含まれます。ノード名は識別用のラベルにすぎず、名前に含まれる地域名や回線の説明は実際の性能を保証しません。同じノードでも接続先によって結果が異なる場合があるため、接続ログとアクセス結果から利用可否を判断してください。
プロキシプロトコルは、クライアントとリモートサービス間の認証方法やデータ転送方法を定めます。代表的なものにShadowsocks、VMess、VLESS、Trojanがあります。サーバーアドレスが同じでもプロトコルは置き換えられません。パスワード、ユーザーID、その他のプロトコル固有のパラメーターもすべて保持してください。読み込みやハンドシェイクに失敗した場合は、まずカーネルの対応状況を確認し、変換時にノードの項目が失われていないか確認しましょう。
通信方式はデータの運び方を定めます。TCPを直接使う方法や、WebSocketなどを使う方法があります。TLSは接続の暗号化と証明書による認証を提供します。これらはプロキシプロトコルとは別の概念です。サーバー名、証明書、通信経路をサーバー側の設定に合わせてください。証明書エラーが発生した場合は、時刻、名前、証明書チェーンを先に確認し、検証の無効化を恒久的な解決策にしないでください。
UDP転送では、UDPを使うアプリの通信をプロキシ経由で転送します。リアルタイム通信やゲーム、一部のDNSリクエストなどで使われます。ブラウザーでWebページを表示できても、その接続が使えることを示すだけで、UDP転送が正常とは限りません。クライアント設定、プロキシプロトコル、リモートサービス、中継ネットワークが影響するため、実際に使うアプリで確認してください。
クライアントの遅延テストは通常、ノード経由で指定のテスト先にアクセスする所要時間を測るもので、ICMPによるネットワークの往復時間と一致するとは限りません。テスト先、接続の再利用、ネットワークの変動によって結果は変わり、異なるテスト先の数値を単純に比較することもできません。テスト時間が短くてもダウンロード速度が速いとは限らず、タイムアウトした場合はテスト先に到達できないのか、ノード全体が利用できないのかを切り分けましょう。
まず接続に適用されたルールを特定し、そのルールがどのプロキシグループを参照しているかを確認します。最後に、グループ内で選択されているノードを確認しましょう。
ルールベースの振り分けでは、ドメインや宛先IPなどの条件から接続ポリシーを選びます。通常、ルールは上から順に評価され、最初に一致したルールで接続先が決まります。たとえば DOMAIN-SUFFIX,github.com,PROXY は、該当するドメインを PROXY というポリシーに渡します。ただし、そのポリシーが実際に定義されている必要があります。具体的なルールを広い条件より前に置き、最後に MATCH で残りの通信を処理するのが一般的です。
プロキシグループは複数のノードや別のプロキシグループをまとめ、ルールから参照できる入口として機能します。ルールを特定のノードに直接結び付けずに済みます。select は手動選択、url-test はテスト結果に基づく選択、fallback は定められた順番で利用可能な項目を探します。グループ名は自由に付けられます。「自動」と名前にあっても、自動テストで選択するとは限らないため、グループの種類とメンバーを確認してください。
ルールモードではルール表に基づいてポリシーを選びます。グローバルモードでは通常、カーネルに入った接続をグローバルポリシーに渡し、直接接続モードでは宛先に直接接続します。Clashのグローバルモードはアプリの通信を取り込む機能ではありません。カーネルに入っていない接続は、モードを切り替えても経路が変わりません。振り分けを調べる際は一時的にモードを切り替えて比較できますが、グローバルポリシーで現在選択されている項目も確認してください。
GeoIPはIPアドレスの割り当て情報に基づいて判定し、GeoSiteは分類済みのドメインデータを使います。対象もデータソースも異なります。IPアドレスの割り当て先は、ユーザーの所在地やサービスの設置場所と同じとは限りません。CDNを使うサイトでは、特にドメインルールも確認してください。ClashのGeoIPデータ更新とサブスクリプション更新は別の作業です。分類にずれがある場合は、データの取得元、更新時期、ルールの順序を確認しましょう。
ルールセットは多数のマッチ条件をまとめて管理します。rule-providersで定義し、メインのルール表から RULE-SET で参照します。ルールセットの動作タイプ、ファイル形式、内容は一致している必要があり、ドメインのリストをIPアドレス用の形式で読み込むことはできません。更新で新しくなるのはルールセット内の条件だけです。メインのルール表での位置は変わらず、存在しないプロキシグループが作成されることもありません。
ドメインの名前解決と通信のカーネルへの取り込みは関連していますが、互いに代用できる仕組みではありません。
DNS名前解決は、ドメイン名をIPアドレスなどのレコードに変換します。ルール判定や接続の確立に合わせて、カーネルが独自の名前解決経路を提供することもあります。OS、ブラウザー、アプリが別々のリゾルバーを使う場合があり、ブラウザーの暗号化DNS設定がOSの名前解決経路を迂回することもあります。カーネルのDNSを変更した後も、リクエストを実際に送信しているのはどの層か、古いキャッシュの結果ではないかを確認してください。
Fake-IPは予約済みアドレス範囲の仮想IPを返し、ドメインと接続の対応関係を保持することで、接続時のドメインベースの振り分けを可能にします。仮想IPは接続先サイトの実際のIPアドレスではないため、公開IPの割り当て先と直接比較するものではありません。実際のIPアドレスを必要とするアプリや、名前解決の結果を独自に処理するアプリでは、例外が必要な場合があります。fake-ip-filterで対象ドメインを調整し、接続を作り直して確認してください。
TUNモードは仮想ネットワークインターフェースとルーティング設定を利用し、プロキシを直接設定できないアプリを含め、より多くの通信をカーネルに取り込みます。実際に取り込まれる範囲は、ルート、OSの権限、除外設定、DNS設定によって異なります。有効にしただけで、すべてのプロトコルが正常に転送されるとは限りません。他のVPNや仮想NICと併用する場合はルートの競合に注意し、問題があれば一つずつ無効にして比較してください。
DNSリークとは、名前解決が想定した経路から外れることです。たとえば、プロキシ経由で処理するはずのドメインをローカルネットワークのリゾルバーが問い合わせるケースがあります。リークかどうかは、まず想定するポリシーを明確にして判断してください。意図的に直接接続で解決するドメインは、表示された地域だけで異常とは判定できません。ClashのDNSリークを調べる際は、リゾルバーの所在、ブラウザーの暗号化DNS、OSの設定、接続ログを確認し、検査サイトに表示された国や地域だけで判断しないようにしましょう。
混合ポートは、1つの待ち受け口でHTTPプロキシとSOCKSプロキシを提供し、ローカルアプリから利用できるようにする設定です。対応する項目は mixed-port です。ポート番号は実際に動作している設定を確認してください。ガイドの例と現在のクライアントの設定が一致するとは限りません。LANからの接続を許可する場合は、待ち受けアドレス、アクセス認証、ファイアウォールも確認し、ローカル向けの入口を意図せず外部に公開しないようにしてください。
ダウンロードした元データ、ローカルでの変更、最終的な実行結果を区別すると、更新後に設定が消えたり、変更が反映されなかったりする問題を減らせます。
サブスクリプションURLからノードや設定一式を取得できます。一般的なClash向けVPNサブスクリプションはサービス提供元が発行し、アカウントを識別するアクセストークンが含まれる場合があります。公開スクリーンショット、ログ、掲示板などに載せず、機密情報として保管してください。更新しても現在のプロキシグループが切り替わるわけではありません。読み込み後は、設定が有効になっているか、グループに選択可能な項目があるか、通信の入口が正しいかを確認しましょう。
YAMLは、インデント、キーと値、リストを使って構造を記述する一般的な設定形式です。Clashの設定には config.yaml のようなファイル名がよく使われます。インデントにはスペースを使ってください。階層の誤り、キーの重複、引用符が必要な特殊文字は解析エラーの原因になります。解析できても、確認できるのは構造が読み取れることだけです。現在のカーネルが各項目に対応しているか、参照先のポリシーが存在するか、実行ログにエラーがないかも確認してください。
サブスクリプション変換は、ノード情報や設定一式を別のクライアントで読み込める形式に変換する機能です。配布元の形式と利用するクライアントの形式が異なる場合などに使われます。変換では、プロトコルのパラメーター、プロキシグループ、ルール、DNS設定が失われる場合があります。ファイルの拡張子を変えるだけではありません。外部の変換サービスを使うと、元のサブスクリプションをサービスに渡して処理することになります。信頼性を確認し、配布元が提供する互換形式を優先してください。
オーバーライドとマージでは、サブスクリプションの元データに設定を追加・変更できます。ローカルポート、DNS、カスタムルールを保存し、サブスクリプションの更新でローカルの変更が上書きされるのを防ぐのに便利です。オブジェクトのマージ、リストの置き換え、ルールの追加方法はクライアントによって異なるため、別のクライアントでの結果をそのまま当てはめないでください。変更後は合成設定を確認し、特にカスタムルールの位置と参照先のプロキシグループ名を確認しましょう。
プロファイルは、クライアントが保存するローカルファイルやサブスクリプションの記録です。実行設定は、プロファイルの選択後にオーバーライドやマージを適用してカーネルに渡す内容です。エディターに表示される元データ、ディスク上のファイル、カーネルの現在の状態は一致しない場合があり、変更を再適用する必要があることもあります。トラブル対処では、まず有効なプロファイルを確認してから実行設定とログを調べましょう。無効なファイルを何度も変更するより効率的です。