Clash用語集

Clashエコシステムにおける現行の主力カーネルで、Clash.Metaプロジェクトの後継として発展した。設定解析・ルールマッチング・トラフィック転送を担い、Clash Verge RevやFlClashなど主要クライアントに標準搭載される。対応プロトコルとルールタイプは旧来のClashカーネルより充実している。

プロジェクト発足当初のオープンソースコアで、Clash設定ファイルの書式を定義した。2023年にリポジトリがアーカイブされて以降更新はなく、現在はmihomoがエコシステムの保守を引き継いでいるが、「Clash設定」という書式名は今も使われている。旧いクライアントがこのオリジナル版カーネルを同梱している場合、新プロトコルは利用できない。

軽量な暗号化プロキシプロトコルで、設定項目が少なく接続オーバーヘッドも低い。Clash設定ファイルのproxiesセクションでtype: ssとして宣言し、暗号化方式はaes-128-gcmやchacha20-ietf-poly1305が一般的。

V2Rayプロジェクトが定義した通信プロトコルで、UUID認証に依存し、WebSocketやgRPCなど複数の伝送層をサポートする。設定項目が多く、通常はサブスクリプションから直接配布されるため手書きの必要はない。UUIDの入力ミスや時刻のずれが大きいとハンドシェイクに失敗する。

TLSトラフィックを装うプロキシプロトコルで、通常443番ポートで待ち受け、ハンドシェイクの特徴は通常のHTTPS通信に近い。サーバー側に有効な証明書が必要で、クライアント側はパスワードとSNIを入力するだけで接続できる。

QUICをベースにしたプロキシプロトコルで、パケットロスが多いリンクに最適化されている。弱い回線環境でのスループットはTCP系プロトコルより優れる。オリジナル版Clashカーネルは非対応で、設定にtype: hysteria2と記載されたノードはmihomoカーネルでのみ読み込める。

Clash動作の唯一の根拠となるファイルで、ポート・DNS・ノード・ポリシーグループ・ルールの5大セクションを含む。クライアント画面上の設定項目の多くは、実質このファイルのフィールドを読み書きしているにすぎない。トラブル対処の際はまずどの設定ファイルが読み込まれているかを確認する。

設定ファイルが採用するテキスト形式で、インデントで階層を表す。インデントは半角スペースを使い、コロンの後には半角スペースを1つ入れる必要がある。手動編集時にインデントや記号を1つ間違えるだけで設定全体の読み込みに失敗し、クライアントのログには通常エラー行番号が表示される。

サービス提供者が発行する1本のURLで、アクセスすると完全なClash設定またはノード一覧が返される。クライアントは一定間隔で更新を取得するため、ノードの追加・削除のたびに手動でファイルを書き換える必要はない。サブスクリプションが期限切れやリセットになると、同じURLが空の内容やエラーを返すようになる。

V2RayやSing-boxの共有リンクなど他形式のノード一覧をClash設定に変換する処理。オンライン変換サービスやクライアント内蔵の機能で実行でき、変換時にルールテンプレートやポリシーグループ構造もあわせて注入されることが多い。

rulesセクションの1行のマッチング文で、書式は「タイプ,マッチ値,ポリシー」。例:DOMAIN-SUFFIX,github.com,ノード選択。カーネルは上から順に照合し、一致した時点で処理を止めるため、ルールの順序が分流結果に直接影響する。

大量のルールを個別ファイルとして外部化し、URL経由で定期更新する仕組み。設定ではRULE-SET,名称,ポリシーで参照し、数万件規模になるドメイン分流リストの管理によく使われ、ルールの更新だけならメイン設定を変更しなくてよい。

複数のノードや他のポリシーグループをまとめ、ルールから参照できる集合として扱う仕組み。ルールは具体的なノードを直接指定せずポリシーグループを指す形になるため、ノードの追加・削除はグループ内メンバーにのみ影響し、ルール自体は変更不要のまま保たれる。

最も基本的なポリシーグループタイプで、メンバーはユーザーがクライアント画面上で手動切り替えする。多くの場合「ノード選択」の入口として使われ、url-testなど自動系のグループを内部にまとめておき、必要なときにいつでも手動で切り替えられる。

intervalで指定した周期ごとにurlで指定したアドレスへテストを送信し、遅延が最も低いノードを自動選択する。toleranceパラメータで切り替えのしきい値を設定し、遅延が近いノード同士で頻繁に切り替わるのを防ぐ。

メンバーの順序どおりに1つずつ可用性をテストし、リストの中で最初に利用可能なノードを常に使用する。「メインは固定ノード、失効時は自動で補完」という用途に向き、url-testの最適選択ロジックとは異なり、速さではなく利用可能かどうかだけを重視する。

接続をグループ内の複数ノードに分散させる。strategyにはconsistent-hashing(同一サイトは常に同じノードへ)かround-robin(順番に割り当て)を選択でき、単一ノードへの接続負荷を分散する目的で使う。

rulesセクションの最後の1行で、前の行でマッチしなかった全トラフィックを受け止める。これがない場合、マッチしなかったトラフィックはカーネルの既定動作で処理される。分流がどこまで緻密になるかは、この行がどのポリシーを指しているかに大きく左右される。

クライアントがOSにHTTP/SOCKSプロキシアドレス(例:127.0.0.1:7890)を登録する方式で、システム設定に従うブラウザなどのアプリは自動的にプロキシを経由する。この設定を読まないプログラム(一部のCLIツールやゲームなど)には影響しない。

仮想ネットワークアダプタを作成してシステム全体のトラフィックを引き受ける方式で、アプリがシステムプロキシ設定を読むかどうかに依存せず、システムプロキシよりも網羅性が高い。有効化には管理者権限またはシステム拡張の許可が必要で、通信のループを避けるためシステムプロキシは無効にしておくべき。

同一ポートでHTTPとSOCKS5両方のプロキシリクエストを受け付ける待ち受け方式で、多くのクライアントは7890を既定値とする。アプリはこの1つのポートを指定するだけでプロトコルを区別する必要がなく、そのポートが他のプログラムに使われていると、カーネルの起動に失敗する。

DNS応答方式の1つで、カーネルはドメイン照会に対して即座に予約範囲の仮のIP(198.18.0.0/16)を返し、本当の名前解決は接続確立時まで遅らせる。解決待ちの時間を省けるが、実IPに依存する一部のプログラムはfake-ip-filterに例外登録が必要。

プロキシを有効にしても、ドメイン解決要求がそのままローカルのプロバイダDNSに送られてしまう現象。解決記録からアクセス先が漏れてしまうため、対策としてはカーネルのDNSモジュールを有効化するか、TUNモードに切り替えて解決もプロキシ経路を通すようにするのが一般的。

IP帰属地データベースに基づいてトラフィックを照合するルールタイプで、最も一般的な書式はGEOIP,CN,DIRECT、つまり中国本土のIPは直接接続するという意味。データベースはカーネルやクライアントの更新に伴って更新され、長期間更新しないと帰属地の誤判定や分流のズレが生じる。

Tauriベースのオープンソースデスクトップクライアントで、Windows・macOS・Linuxをカバーし、mihomoカーネルを標準搭載する。TUNモード・サブスクリプション管理・スクリプト拡張に対応し、開発終了した旧Clash Vergeを引き継ぐコミュニティ版として続いている。

Windows・macOS・Android・iOSに対応するマルチプラットフォームクライアントで、iOS版はApp Store経由で配信される。インターフェースはOS標準に近く、サブスクリプションの読み込みやルール切り替えまでの手順が短いため、Clashに初めて触れるユーザーに向いている。

macOSとiOSが提供するシステムレベルのネットワーク引き受けフレームワーク。クライアントがTUNやVPN形態を有効化する際には、システムのポップアップで拡張機能のインストール許可が求められる。誤って拒否すると機能が使えなくなるが、システム設定のネットワークまたはログイン項目から再度許可できる。

Androidが提供するVPNフレームワークで、Clash系クライアントはこれを利用して仮想ネットワークアダプタを作成し、全体のトラフィック接収を実現する。初回起動時にはシステムのVPN接続リクエストが表示され、同時にこの経路を占有できるアプリはシステム上で1つだけに限られる。

カーネルが公開するローカルHTTPインターフェースで、既定では127.0.0.1:9090を待ち受ける。クライアントのパネルやWebダッシュボード(metacubexdなど)はこれを通じて接続一覧の読み取り、ノードの切り替え、ログの確認を行い、設定内でアクセスキーを設定できる。