Clashカーネル
Clash coreプロキシ接続、ルール照合、DNS処理を担うバックグラウンドプログラムです。通常、GUIは制御インターフェースを介してカーネルと連携します。オリジナルのClashと後続の派生カーネルでは機能範囲が異なり、Clash向けと記載された設定でも、すべてのカーネルで動くとは限りません。未知のフィールドや非対応プロトコルに遭遇したら、クライアント名だけで判断せず、実際に使われているカーネルを確認してください。
カーネル、プロトコル、ルール、DNSの役割を整理。分野別に用語を調べ、設定項目をたどってクライアントの実際の設定を確認できます。
接続を処理するプログラム、設定を管理する画面、接続に必要なサーバー情報を区別しましょう。
プロキシ接続、ルール照合、DNS処理を担うバックグラウンドプログラムです。通常、GUIは制御インターフェースを介してカーネルと連携します。オリジナルのClashと後続の派生カーネルでは機能範囲が異なり、Clash向けと記載された設定でも、すべてのカーネルで動くとは限りません。未知のフィールドや非対応プロトコルに遭遇したら、クライアント名だけで判断せず、実際に使われているカーネルを確認してください。
Clash Metaプロジェクトから派生したオープンソースのプロキシカーネルです。ルールベース振り分け、TUN、ドメインスニッフィング、ルールセットなどに対応しています。特定のGUIクライアントを指す名称ではなく、同じカーネルを複数のアプリに組み込めます。古い記事にあるMetaという表記は、このカーネル系統を指すことが多いものの、個々の設定項目は現在のカーネルのドキュメントで確認してください。
サブスクリプション、プロキシグループの選択、システムプロキシ、ログなどを管理するデスクトップまたはモバイルアプリです。カーネルを同梱するものや、カーネル管理機能を備えるものもあります。画面上の設定項目とYAMLのフィールドは一対一で対応するとは限らず、起動時に設定を生成ファイルへ書き込む場合もあります。問題の切り分けでは、画面上の動作とカーネルの動作を分けて考えてください。
プロキシ接続に使うサーバー情報のまとまりで、通常はアドレス、ポート、プロトコル、認証情報を含み、トランスポート層の設定が付く場合もあります。ノードに表示される名前はラベルにすぎず、実際の出口の場所やサービスの利用可否を保証しません。クライアントをインストールしただけではノードは使えないため、インポート前に提供元とプロトコルの互換性を確認してください。
指定された方法でクライアントが測定したリクエストの所要時間です。一般的なURLテストはICMP pingと同じではありません。テスト先、タイムアウト、接続の再利用、現在のネットワーク状況によって結果は変わるため、帯域幅やすべてのWebサイトでの表示速度の目安にはなりません。テストがタイムアウトしてもノードが完全に使えないとは限らないので、実際のアクセス状況や接続ログも確認してください。
プロトコルは接続の確立方法を定めます。トランスポート方式、認証情報、セキュリティ層をあわせて確認してください。
事前共有鍵と指定の暗号化方式を使ってプロキシ接続を確立するプロトコルです。mihomoのノードではtype: ssと指定します。クライアントとサーバーの暗号化方式と鍵を一致させる必要があり、方式によって必要な鍵の形式も異なります。ノードがプラグインを使う場合は、クライアントがそのプラグインとパラメーターに対応しているかも確認してください。
通常はTLS接続上でプロキシ通信を行い、パスワードで認証するプロトコルです。接続の成否はパスワードだけでなく、証明書、サーバー名、トランスポート設定にも左右されます。証明書エラーが出た場合は、システム時刻とサーバー側の設定を確認してください。証明書検証を無効にする方法を常用の対処法にするのは避けましょう。
通常はUUIDでユーザーを識別する軽量なプロキシプロトコルです。プロトコル自体は通信を暗号化しないため、TLSやREALITYなどのセキュリティ層と合わせて確認してください。UUIDが一致していても設定全体が正しいとは限らず、トランスポート方式、サーバー名、関連するセキュリティパラメーターも一致させる必要があります。ノードをインポートする際は、サービス提供元のパラメーター一式をそのまま保持してください。
QUICベースのプロキシプロトコルです。UDPで通信できる必要があり、TLSと認証パラメーターを使って接続します。ネットワークでUDPが制限されていると正常に動作しない場合があり、サーバー側のポートが開いているだけでは利用可能と判断できません。実際の動作は通信品質や設定値に左右され、プロトコル名だけから速度を推測することもできません。
アプリからプロキシサーバーへ接続するための汎用プロトコルで、ローカルのプロキシ入口にもリモートノードにも使えます。TCPとUDPの転送に対応しますが、実際に使うにはアプリ、待ち受け側、出口のすべてが対応している必要があります。SOCKS5自体に通信の暗号化機能はありません。ドメイン名をローカルで解決するかプロキシ側で解決するかは、アプリの使い方によって異なります。
ルールは「どの接続か」を判定し、プロキシグループは「どの出口を使うか」を決めます。
Ruleモードでは、カーネルがrulesリストを上から順に照合し、最初に一致したルールのポリシーを適用します。たとえばDOMAIN-SUFFIX,github.com,Proxyは、該当するドメインをProxyという名前のポリシーに振り分けます。Proxyは別途定義が必要です。残りの接続を処理するMATCH,Proxyは、通常リストの末尾に置きます。
ノードやほかのポリシーをまとめ、各ルールから参照できるようにするグループです。ルールごとに単一のノードを直接指定せずに済みます。selectは手動選択、url-testは定期的なテスト結果に基づく選択、fallbackは利用可能なメンバーを順番に使用します。テスト先や間隔は自動選択の動作に影響します。グループ名だけでは機能は決まりません。
それぞれルールモード、グローバルモード、直接接続モードを指し、カーネルに届いた接続の処理方法を決めます。Ruleはルールに基づいてポリシーを選択し、Globalは全体に適用するポリシーを使い、Directは宛先へ直接接続します。これらのモードはアプリの通信をカーネルへ送る機能ではありません。システムプロキシやTUNが有効かどうかは、別途確認が必要です。
IPアドレスを地理情報データベースと照合して判定するルール方式です。たとえばGEOIP,CN,DIRECTは、データベースでCNに分類されたアドレスへ直接接続します。この判定はドメインの登録地、実際の運営場所を示すものではありません。CDNによってDNSの応答先が変わることもあります。ドメイン名で接続を照合する際に名前解決が必要な場合がありますが、ルール末尾にno-resolveを指定すると、そのための名前解決を抑制できます。
マッチ条件をまとめて個別に保存し、rule-providersで定義してから、RULE-SET,work,Proxyのようなルールで参照します。ルールセットは照合対象を記述し、それを参照するルールが最終的なポリシーを指定します。更新に失敗した場合は、形式とbehaviorの設定が合っているかも確認してください。ノードのサブスクリプションをルールセットとして使うことはできません。
ドメイン名の解決、通信の取り込み、出口の選択は関連していますが、それぞれ別の処理です。
ドメイン名をIPアドレスに変換する仕組みで、アプリが接続を確立する前によく使われます。mihomoではnameserverで上流のDNSサーバーを指定し、nameserver-policyで特定のドメインに別のDNSサーバーを割り当てられます。暗号化DNSはDNSサーバーまでの通信を保護しますが、クエリが選択したプロキシ出口を通るとは限りません。
アプリに仮想IPアドレスを返し、カーネル内でそのIPアドレスとドメイン名の対応を保持するDNSの動作方式です。後からドメイン名でルールを照合しやすくなりますが、実際のWebサイトのアドレスではなく、通信の取り込みを単独で代替するものでもありません。一部のアプリが実際のDNS応答を必要とする場合は、必要に応じてfake-ip-filterを調整し、除外範囲をむやみに広げないようにしてください。
仮想ネットワークインターフェースでシステムのIP通信を受け取り、システムプロキシを参照しないアプリの一部もカーネルで処理できるようにします。tun.enable、auto-route、dns-hijackなどのフィールドを使い、管理者権限が必要になる場合もあります。実際に取り込まれる範囲は、ルーティング、DNS、OSのプラットフォーム、ほかのネットワークソフトに左右されます。
DNSクエリが想定したDNS経路や出口を通らない状態です。たとえば、ブラウザー内蔵のDNS機能が利用する予定のシステム経路を迂回する場合があります。検出ページに特定のDNSサーバーの地域が表示されただけでは、リークの証明にはなりません。対象のポリシーやログとあわせて判断してください。原因を調べる際は、ブラウザーのセキュアDNS、システムの名前解決、TUNによる通信の取り込み、カーネルの上流DNS設定を確認します。
対応するTLS、HTTP、QUICのハンドシェイク情報からドメイン名を識別し、IPアドレスしか分からない接続に照合情報を補います。暗号化された通信内容を汎用的に復号する機能ではなく、すべての接続でドメイン名を識別できるわけでもありません。ルールの適用先や宛先の処理に影響する場合があるため、有効にした後は接続ログで結果を確認してください。
データの取得元、ファイル形式、実際に動作する設定を区別し、更新時に設定が上書きされる問題を防ぎます。
リンク経由でノード一覧または設定全体を配布・更新する方式です。内容はURI一覧、エンコードされたテキスト、YAMLなどで、リンクの見た目だけでは形式を判断できません。クライアントに直接インポートできるかどうかは、対応する形式やプロトコルによります。サブスクリプションURLには認証情報が含まれることが多いため、スクリーンショットやログに載せたり、信頼できない変換サービスに入力したりしないでください。
マッピング、リスト、スカラー値を記述するテキスト形式で、Clashの設定では階層構造の表現によく使われます。インデントにはタブではなくスペースを使い、同じ階層のフィールドの位置をそろえてください。特殊文字を含む文字列は引用符で囲めます。YAMLの構文が正しくても設定が使えるとは限らないため、フィールドの対応状況やプロキシグループ名の参照をカーネルで確認する必要があります。
ポート、ノード、プロキシグループ、DNS、ルールなどを記述するファイルです。config.yamlはよく使われるファイル名ですが、固定の名前ではありません。クライアントからカーネルに渡される最終設定は、サブスクリプション、画面上の設定、オーバーライドから生成される場合があります。設定したフィールドが反映されない場合は、ダウンロードしたサブスクリプションだけでなく、実際に動作中の設定を確認してください。
proxy-providersで定義し、ファイルまたはリモートアドレスから読み込むノードの集合です。プロキシグループからuseで参照します。ノードを保存するものであり、マッチ条件を保存するrule-providersとは異なります。プロバイダーの更新、ヘルスチェック、プロキシグループによる選択はそれぞれ別の処理です。更新に成功しても、すべてのノードに接続できるとは限りません。
サブスクリプションの設定にローカル変更を加え、最終設定の生成に反映する仕組みです。ポートやDNSの固定、ルールの追加などに使われます。オーバーライドはすべてのクライアントで共通する単一のカーネルフィールドではありません。マージの順序、リストへの追加、フィールドの上書き方法はクライアントによって異なります。変更後は生成結果を確認し、更新処理によってルールの位置やプロキシグループの参照が変わっていないか確かめてください。
初めてサブスクリプションをインポートする場合は、チュートリアルに沿って接続を確認してください。すでに接続できていて、ルール、DNS、TUNを調整したい場合は、設定応用ガイドをご覧ください。エラーが発生したら、クライアント名、実際に使用しているカーネル、エラーメッセージを記録しましょう。「Clashが動かない」だけでは原因を特定しにくくなります。