Clash用語集

Clashは、ルールマッチング、ポリシー分岐、ローカルプロキシを中心とするネットワークプロキシのエコシステムです。日常的な文脈でのClashは、初期のカーネル、互換設定形式、または関連カーネルを採用したGUIクライアント全般を指すことがあります。

ドキュメントを読む際は、まず対象を確認してください。クライアントは画面とシステム連携を担当し、カーネルは接続、名前解決、転送を担当します。両者でバージョン、対応項目、更新ペースが異なる場合があります。

mihomoはClash Metaから発展したプロキシカーネルです。設定ファイルを読み込み、プロキシプロトコル、ルールマッチング、DNS、TUNによるトラフィック制御、コントロールインターフェースなどの低レイヤー機能を処理します。

Clash Verge RevやFlClashなどのGUIクライアントはmihomoを呼び出したり管理したりできますが、クライアント名とカーネル名は同じではありません。項目の利用可否を確認する際は、クライアントに組み込まれたカーネルと設定構文を併せて確認します。

GUIクライアントは、カーネルに設定のインポート、ポリシー切り替え、ログ確認、システムプロキシ制御、更新管理の画面を提供します。通常はシステム権限の取得、ユーザー設定の保存、カーネルプロセスの起動も担当します。

画面に接続成功と表示されても、関連するスイッチやプロセスが想定状態になったことを示すだけです。実際にトラフィックがプロキシを通っているかは、システムプロキシ、TUNルート、ルールの一致、ログを併せて判断します。

システムプロキシは、OSがアプリへHTTP、HTTPS、SOCKSプロキシのアドレスを公開する仕組みです。ブラウザやシステムのネットワーク設定に従う多くのデスクトップアプリはこのアドレスを読み取り、Clashのローカル待受ポートへリクエストを送ります。

一部のゲーム、コマンドラインツール、独自のネットワークスタックを使うアプリはシステムプロキシを無視することがあります。その場合はプロキシ環境変数を個別に設定するか、TUNモードで制御します。

TUNモードは、仮想ネットワークインターフェースでOSから渡されたIPトラフィックを受け取り、カーネルがルールに基づいて直接接続、プロキシ、拒否を決定します。システムプロキシより広い範囲のアプリをカバーし、プロキシ設定を読み取らないプログラムにも対応できる場合があります。

TUNの有効化には通常、管理者権限、VPN権限、または対応するシステム拡張が必要です。ルートの競合、別のVPN、仮想マシンのNIC、ファイアウォールポリシーが制御結果に影響することもあります。

ノードは、リモートプロキシの入口を設定内で表すオブジェクトです。通常はサーバーアドレス、ポート、プロトコル、認証パラメータ、転送オプションを含みます。プロキシグループはノード名でこれらを参照します。

ノード名は主に識別用で、名前に含まれる地域や倍率の情報は設定提供者が定義します。利用可否は実際の接続、対象サイトへのアクセス、継続的な安定性を併せて判断してください。

プロキシプロトコルは、クライアントとリモートサービスが接続を確立し、認証を行い、トラフィックをカプセル化する方法を定めます。TLS、転送層、UDP、プラグインパラメータ、サーバー実装への要件はプロトコルごとに異なります。

設定のプロトコル項目はサーバー側の設定と一致している必要があります。プロトコル名を変更するだけでは形式変換にならず、項目不足やパラメータ不一致は通常ハンドシェイク失敗につながります。

遅延は通常、クライアントが計測リクエストを送信してから応答を受け取るまでの時間を指し、単位はミリ秒です。クライアントの遅延テストは指定URLへアクセスするため、テスト先、DNS、当時のネットワーク経路にも左右されます。

低遅延だからといってダウンロード速度が速いとは限らず、長時間のパケットロスや帯域の変動も分かりません。ノード選びでは遅延を初期選別に使い、対象サービスでの実際の性能も確認します。

UDP転送は、プロキシ経路でUDPデータグラムを処理できることを示します。リアルタイム通信、一部のゲーム、QUIC、DNSクエリなどで使われます。TCPと同じ信頼性のあるバイトストリームを確立しないため、タイムアウトやセッション管理の方法が異なります。

実際の対応状況は、カーネル、プロキシプロトコル、ノードのサーバー、プロキシグループによって決まります。ノード項目にUDP対応とあっても、経路上のすべての要素が正しく有効とは限りません。

多重化は、少数の基盤接続で複数の論理リクエストを運ぶ仕組みです。主な目的は繰り返しのハンドシェイクや接続確立のコストを減らすことであり、回線帯域を直接増やすものではありません。

パケットロスが目立つネットワークや、サーバー実装が合っていない環境では、多重化によって複数のリクエストが互いに影響することもあります。利用するかどうかはプロトコルのドキュメントと実測結果で判断します。

プロキシグループは、ノード、子プロキシグループ、組み込みアクションをまとめた集合です。手動選択、自動速度テスト、フォールバック、負荷分散などが一般的ですが、利用可能な種類はカーネルによって異なります。

ルールは通常、プロキシグループ名を指定するため、出口の選択とルール条件を分離できます。これにより、ルールを変更せずにノードや選択ロジックを切り替えられます。

ルール分岐は、ドメイン、IP、ポート、プロセス、ルールセットなどの条件に応じて、リクエストを指定したプロキシグループへ渡します。対象ごとに異なる出口を使うための仕組みで、すべてのトラフィックを1つのノードへ固定するものではありません。

ルールは通常、記載順に上から下へ照合されます。広すぎる条件を前に置くと、後続の精密なルールが隠れてしまいます。分岐結果を確認する際は、まず接続記録で実際に一致したルールを確認します。

DIRECTは、リクエストをリモートプロキシノードへ渡さず、ローカルネットワークから対象アドレスへ直接接続することを示します。ローカルネットワークのリソースや、現在のネットワーク出口を使う必要がある対象に適しています。

直接接続でもClashによる処理がすべて省略されるわけではありません。リクエストはカーネルのDNS、ルール判定、TUNルートを通過したうえで、最終的な出口としてローカルネットワークを使う場合があります。

REJECTは、条件に一致する接続またはリクエストを拒否することを示します。指定したドメイン、IPアドレス、ルールセットのトラフィックを遮断するためによく使われます。

拒否されたアプリでは、接続が即座に失敗する、タイムアウトする、リソースを読み込めないといった症状が現れます。挙動はカーネルの応答方式とアプリのネットワーク実装によって異なります。誤ブロックの確認では、ルール順序とルールセットの内容を調べます。

GeoIPはデータベースを使ってIPアドレスを国または地域コードに分類し、その結果でルールを照合します。ネットワークアドレスの帰属に基づく大まかな分岐に適しています。

データベースの記録はアドレス割り当ての変化に伴って更新され、コンテンツ配信ネットワークは場所によって異なるIPを返すことがあります。GeoIPの結果をサーバーの正確な物理的位置とみなしてはいけません。

MATCHはルールリストの最終フォールバック条件で、それまで一致しなかったリクエストを受け取ります。通常はルール欄の末尾に置き、汎用プロキシグループまたはDIRECTを指定します。

MATCHをリストの前方に置くと、後続ルールが一致する機会を失います。分岐結果が異常な場合は、フォールバックルールの位置と指定先を確認してください。

DNSはドメインをIPアドレスやその他のリソースレコードへ変換する分散システムです。ClashカーネルはローカルDNSリクエストを待ち受け、設定に応じて異なる上流リゾルバーへクエリを送信できます。

DNSが成功しても、対象への接続が利用できるとは限りません。接続にはルール照合、ルート選択、プロキシのハンドシェイク、対象サービスの応答も必要です。

Fake-IPモードは、まずドメインに予約アドレスを返し、そのアドレスとドメインの対応をカーネル内部に記録します。アプリがこの予約アドレスへ接続すると、カーネルは元のドメインを復元し、ルール照合とリモート解決を続行できます。

この方式はドメイン情報を保持しやすい一方、実際のLANアドレスに依存するアプリや特殊なDNS検証を行うアプリでは、フィルター対象から外す必要がある場合があります。フィルターの調整は具体的なドメインごとに行ってください。

Redir-Hostは通常のDNS解決を先に行い、実際のIPをアプリへ返します。後続接続はそのアドレスを基にカーネルへ入るため、Fake-IPとは処理経路が異なります。

このモードは一部のLAN環境や特殊なアプリで分かりやすい一方、ドメイン情報の保持度合いはスニッフィングや接続方式の影響を受けます。モード変更後は、ドメインルールの実際の一致状況を再確認してください。

DNSリークとは、指定した解決経路で処理する予定だったクエリが、システム、ルーター、ブラウザ内蔵機能、その他のネットワークソフトによって別のリゾルバーへ直接送信される状態です。DNSの制御範囲が想定と一致していないことを示します。

確認時は、システムDNSアドレス、クライアントの待受ポート、TUNのDNSハイジャック設定、ブラウザのセキュアDNS設定、他のVPNを調べます。上流アドレスを1つ変更するだけでは、経路全体の特定には不十分です。

nameserver-policyはドメイン条件に基づいてDNSクエリの上流リゾルバーを選択します。ドメインごとに異なるDNSサービスへ振り分けたり、特定ドメイン用の固定的な解決経路を設定したりできます。

この項目が扱うのはDNSクエリの送信先であり、アプリの接続をプロキシ経由にするか直接接続にするかを直接決めるものではありません。接続先の出口はルールとプロキシグループで決まります。

サブスクリプションは、リモートアドレスからノード一覧または完全な設定を取得する更新ソースです。クライアントはユーザー操作または設定した間隔で再取得し、利用可能な設定として保存します。

サブスクリプションの応答は、YAML、エンコードされたノード一覧、サーバーで変換された専用形式などの場合があります。インポートに失敗したら、まず応答内容とステータスを確認し、次にクライアントが対応する項目を調べます。

YAMLはClashでよく使われる構造化テキスト形式です。スペースによるインデントでオブジェクトの階層を表し、ハイフンでリスト項目を表します。項目名の後のコロン、文字列の引用符、インデント幅が解析結果に影響します。

YAMLではタブとスペースを混在させないでください。同じ階層の項目はインデントを統一し、特殊記号を含む値は引用符で囲むと解析の曖昧さを減らせます。

設定ファイルは、ポート、実行モード、DNS、ノード、プロキシグループ、ルールなどの項目を保存するYAMLドキュメントです。カーネルは起動時に設定を読み込み、待受と転送のロジックを構築します。

GUIクライアントは、YAMLとは別に起動時実行、システムプロキシのスイッチ、カーネルのパスなどの画面設定を保存することがあります。設定ファイルをコピーしても、クライアントの設定まで同期されるとは限りません。

プロキシプロバイダーは通常、proxy-providersで定義し、独立したファイルまたはリモートアドレスからノードの集合を読み込みます。プロキシグループはprovider経由でこれらのノードを参照でき、主設定に各ノードを重複して記述する必要がありません。

集合の更新間隔、保存先、ヘルスチェック、形式はそれぞれ設定する必要があります。集合の読み込みに成功しても、含まれるすべてのノードが接続できるとは限りません。

上書きとマージは、クライアントがサブスクリプションの内容にローカル項目を追加、置換、結合する処理です。カスタムルールの挿入、DNSの調整、プロキシグループの追加、ローカルポート設定の保持などに使われます。

マージ構文と優先順位はクライアントごとに完全には一致しません。同名項目の最終値は処理順序で決まるため、変更後は上書き断片だけでなく、クライアントが生成した最終設定を確認してください。