Clash用語集

画面に表示される名称からコアの概念まで確認できます。各用語では意味、設定箇所、混同しやすいポイントを解説。カードのアンカーは共有や参照にも使えます。

初めて設定を読み込む場合は導入ガイドをご覧ください。ポリシーグループ、ルールセット、DNS設定を組み合わせる場合は応用設定へ。各項目が使えるかどうかは、実行中のコアとクライアントの対応状況によって異なります。

コアとクライアント

管理画面、通信処理エンジン、システム側の入口を区別し、画面のスイッチを接続が有効になった証拠と誤認しないようにしましょう。

コアとクライアント

クライアント

Client

クライアントは設定、プロキシ選択、接続、ログを管理するアプリで、通常はシステムプロキシやサービス権限も扱います。画面が似ていても、同じコアを使っているとは限らず、対応する設定項目も同じとは限りません。設定を移行するときはメニュー名だけで比べず、クライアントの設定処理とコアの機能を確認してください。

コアとクライアント

コア

Core

コアはプロキシ接続、DNS、ルール判定を実際に処理するネットワークエンジンです。GUIクライアントから呼び出すことも、単独で実行することもできます。クライアントとコアは別々に更新される場合があるため、画面で設定を保存できても、現在のコアが実行できるとは限りません。未対応の項目やプロトコルのエラーが出たら、まずコアの名称とバージョンを確認してください。

コアとクライアント

mihomo

mihomo / Clash.Meta

mihomoはClashエコシステムを起源とするプロキシコアで、以前はClash.Metaの名称でチュートリアルやクライアントの説明に登場していました。特定のGUIクライアントを指す名称ではなく、同じコアを異なる管理画面と組み合わせて使えます。古い解説を参照するときは現在の設定項目のドキュメントと照らし合わせ、特にDNS、TUN、スニッフィングのバージョン差に注意してください。

コアとクライアント

システムプロキシ

System proxy

システムプロキシはローカルのプロキシアドレスをOSに登録し、この設定に従うアプリから利用できるようにします。すべてのプログラムを強制的に経由させる機能ではありません。独自にプロキシを設定したブラウザー、コマンドラインツール、ゲームは別の経路を使うことがあります。トラブル対処ではローカルの待ち受けポート、アプリのプロキシ設定、接続ログを確認してください。システムプロキシが有効でも、すべての通信がコアに入るとは限りません。

コアとクライアント

外部コントローラー

External controller

外部コントローラーは、パネルやクライアントからコアの状態にアクセスするための制御インターフェースです。設定項目はexternal-controllerで、接続の確認、ポリシーの変更、実行状態の取得などに使えます。ブラウザーに設定するプロキシポートではありません。通常はローカルホストのみで待ち受けます。リモートアクセスが必要な場合は認証を設定し、ネットワークからのアクセス範囲を制限してください。

プロキシプロトコル

ノードは接続先を、プロトコルは接続方式を表します。テスト結果は特定の接続先と時点におけるネットワーク経路を反映します。

プロキシプロトコル

プロキシノード

Proxy node

プロキシノードは、通常サーバーアドレス、ポート、プロトコル、認証情報、トランスポート設定を含む送信接続の設定です。ノードとサブスクリプションは別物です。サブスクリプションには複数のノードや完全なルール設定が含まれる場合があります。ノードで接続できても、その送信先が基本的に使えることを示すだけです。アプリからアクセスできるかどうかは、通信がそのノードへ振り分けられるルールになっているかにも左右されます。

プロキシプロトコル

Shadowsocks

Shadowsocks / SS

Shadowsocksは、あらかじめ定めた暗号方式と認証情報を使って、クライアントとサーバー間でプロキシ通信を行います。設定ではtype: ssがよく使われ、暗号方式、パスワード、サーバー側の設定を一致させる必要があります。追加プラグインやトランスポート拡張が必要なノードでは、コアが該当機能に対応しているかも確認してください。サーバーアドレスとポートをコピーするだけでは不十分です。

プロキシプロトコル

Trojan

Trojan

Trojanは通常、TLS接続でプロキシ通信を行い、設定にはサーバーアドレス、パスワード、サーバー名などが含まれます。認証の成功と証明書の検証は別の処理です。ドメイン名の不一致やシステム時刻のずれでもハンドシェイクに失敗することがあります。証明書エラーが出たら、サーバー名、証明書チェーン、時刻を確認してください。検証を無効にする方法を恒久的な対処として使うのは避けましょう。

プロキシプロトコル

SOCKS5

SOCKS version 5

SOCKS5は、アプリとプロキシ間で接続先を指定するためのプロトコルです。TCP接続やUDP転送に使えますが、通信自体は暗号化しません。アプリがローカルのSOCKS5ポートに接続した後の送信経路は、コアのルールで決まります。ドメインをローカルとプロキシ側のどちらで名前解決するかはアプリの実装によって異なるため、設定時にプロキシアドレスと名前解決の動作をそれぞれ確認してください。

プロキシプロトコル

レイテンシ測定

Latency test / URL test

クライアントのレイテンシ測定では、プロキシ経由で指定先にリクエストを送り、その所要時間を表示するのが一般的です。ICMP Pingと同じとは限りません。テストサイト、名前解決、ハンドシェイク、ネットワーク経路によって結果は変わり、数値が低くてもダウンロードが速いとは限りません。タイムアウトした場合もノードが完全に使えないとは限らないため、実際の接続先へのアクセスやコアのログも確認してください。

ルールと分岐

ルールは通信の送信先を決め、ポリシーグループは使用する送信先を選びます。まずルールの一致結果を確認してから、ノードを選択してください。

ルールと分岐

ルール分岐

Rule-based routing

ルール分岐では、ルールモードでドメインや接続先IPなどの特徴を照合し、接続を指定の送信先に振り分けます。通常、ルールは上から順に評価され、最初に一致した項目で結果が決まります。そのため、例外ルールは範囲の広いルールより前に配置してください。グローバルモードに切り替えた後は、ルールモードを前提とした通信経路の解釈はできません。

ルールと分岐

ポリシーグループ

Proxy group

ポリシーグループは複数のプロキシや他のポリシーグループをまとめた論理上の送信先で、ルールから名前を指定して参照できます。selectは手動選択、url-testはテスト結果による選択、fallbackは通常、利用可能なメンバーを順に選択します。自動選択はテスト先や測定間隔にも左右されるため、あらゆる接続先で最適な経路が選ばれるとは限りません。

ルールと分岐

ルールセット

Rule provider / Rule set

ルールセットは、複数のドメイン、IP、ルール項目を独立したリソースにまとめ、分類管理や定期更新をしやすくします。mihomoでは通常、rule-providersで定義し、RULE-SETから参照します。リソース形式は指定した動作タイプに合わせる必要があります。更新に成功しても設定が有効になったとは限らないため、参照名、ルールの順序、送信先も確認してください。

ルールと分岐

GeoIP

IP geolocation

GeoIPは、IPアドレスの地理情報データベースを使って接続先の地域を判定します。よく使われる書式はGEOIP,CN,DIRECTです。判定対象はIPアドレスの登録情報であり、企業の登記地やユーザーの実際の所在地を示すものではありません。CDNの振り分けやデータベースの更新によって結果が変わることがあります。ドメインを対象にする場合は判定時に名前解決が必要になることもあります。no-resolveを使う前に、その制限を確認してください。

ルールと分岐

MATCH

Catch-all rule

MATCHは、それ以前のルールに一致しなかった接続を処理するフォールバックルールです。例:MATCH,プロキシ。通常は一覧の末尾に配置します。前の方に置くと、後続ルールが照合されなくなります。ログで多くの接続がMATCHに振り分けられている場合は、ノードを変更するだけでなく、ドメイン情報、ルールセットの読み込み、ルールの対象範囲を確認してください。

DNSとネットワークスタック

通信の取り込み、ドメインの名前解決、プロキシへの送信はそれぞれ異なる層の処理です。TUNを有効にした後も、ルーティングとDNSの経路を個別に確認してください。

DNSとネットワークスタック

DNS

Domain Name System

DNSはドメイン名に対応するアドレスなどのレコードを調べる仕組みです。コアのdnsセクションで関連する名前解決の動作を設定します。DNSリクエストの経路と、アプリの接続が最終的に通る経路は同じとは限りません。nameserverを変更する前に、アプリが実際にコアのDNSを使っているか確認してください。ブラウザー独自の暗号化DNSは別の経路を使う場合があります。

DNSとネットワークスタック

Fake-IP

Fake-IP

Fake-IPはアプリに仮想アドレスを返し、コア内でそのアドレスとドメイン名の対応を保持することで、後続の接続にドメインルールを適用しやすくします。仮想アドレスは接続先サーバーの実アドレスではないため、名前解決結果に表示されても故障とは限りません。実アドレスが必要なLANサービスやアプリには除外設定が必要な場合があります。対象のドメインに応じて設定し、広すぎる範囲をフィルターに加えないようにしてください。

DNSとネットワークスタック

TUNモード

TUN virtual network interface

TUNは仮想ネットワークインターフェースを使い、OSからコアへルーティングされたIP通信を受け取ります。システムプロキシに従わない一部のアプリも対象にできます。実際に通信を取り込めるかは、権限、ルーティング、除外設定、他のVPNの影響によって異なります。TUNを有効にしても、すべての接続がプロキシを通るわけではありません。コアに入った通信もルールによりDIRECTにでき、DNSを取り込むには別途設定が必要です。

DNSとネットワークスタック

DNSリーク

DNS leak

DNSリークとは、DNSリクエストが想定した経路を通らない状態です。たとえばコアで処理する予定のリクエストが、システムやアプリから直接送信されるケースがあります。判断基準は想定するポリシーと実際のリクエストであり、チェックサイトに見慣れたリゾルバー名が表示されるかどうかだけではありません。トラブル対処ではIPv4、IPv6、ブラウザーの暗号化DNS、他のネットワークソフトも確認し、一か所の設定変更だけで済ませないようにしてください。

DNSとネットワークスタック

ドメインスニッフィング

Domain sniffing

ドメインスニッフィングは、識別可能なハンドシェイクやアプリケーション層の情報からドメイン名を抽出する機能です。接続によってはHTTP HostやTLSのサーバー名などが対象になります。ドメイン情報の補完に役立ちますが、任意のアプリ通信を復号したり、すべての接続を識別したりする機能ではありません。有効化後に互換性の問題が起きた場合は、対象プロトコル、除外ドメイン、接続先のカバー範囲を確認してください。

設定とサブスクリプション

完全な設定、プロキシ一覧、ルールリソースの違いを整理してから、適切な方法で読み込みましょう。設定を更新するときは、ローカルの変更が保持されているかも確認してください。

設定とサブスクリプション

サブスクリプション

Subscription

サブスクリプションは、リンクから設定やプロキシ一覧を取得する配布方式です。リンクの内容は完全なYAMLの場合もあれば、別形式のノード一覧の場合もあります。読み込み先が該当形式に対応している必要があり、ブラウザーでリンクを開けてもコアが解析できるとは限りません。サブスクリプションURLにはアクセス情報が含まれることが多いため、ログ、スクリーンショット、設定を共有する際はURL全体を隠してください。

設定とサブスクリプション

YAML

YAML

YAMLはClashの設定によく使われる構造化テキスト形式です。インデントでマッピングやリストの階層を表し、タブではなくスペースを使います。構文を解析できても、項目名、型、参照先が正しいとは限りません。エラーが出たら、まず表示された行の前後でインデント、コロン、引用符を確認し、次にポリシーグループやルールの参照を確認してください。実際の原因が表示行より前にある場合もあります。

設定とサブスクリプション

設定ファイル

Configuration file / config.yaml

設定ファイルには待ち受けポート、プロキシ、ポリシーグループ、ルール、DNSなどを記述します。一般的なファイル名はconfig.yamlです。ファイル名だけで内容が決まるわけではありません。クライアントが元の設定を取得した後、ローカルオーバーライドを適用して実行用の設定を生成する場合があります。画面の設定とファイルの内容が一致しないときは、サブスクリプションの原文だけでなく、クライアントに表示される実際の実行設定を確認してください。

設定とサブスクリプション

プロキシプロバイダー

Proxy provider

プロキシプロバイダーはproxy-providersで更新可能なプロキシ一覧を管理し、ポリシーグループからそのメンバーを参照します。完全な設定のサブスクリプションとは異なり、ルールも提供しません。取得内容はプロキシプロバイダーの形式要件を満たす必要があります。更新に成功してもノードが表示されない場合は、ポリシーグループのuse参照、フィルター条件、リソースの解析ログを確認してください。

設定とサブスクリプション

ローカルオーバーライド

Local override / Merge

ローカルオーバーライドはサブスクリプション元の設定に項目を追加または置き換える方法で、ポートの固定、DNSのカスタマイズ、分岐ルールの追加などに使われます。リストのマージ、ルールの挿入順、スクリプト処理の実装はクライアントごとに異なります。同じ名称の機能でも動作が同じとは限りません。変更後は最終的な実行設定を確認し、サブスクリプションを更新してローカル設定が意図どおり保持されるかテストしてください。