Clash 用語集:プロキシプロトコル・コア・設定用語を解説

2012年公開の軽量な暗号化プロキシプロトコル。SOCKS5 ベースの転送方式で、通信特徴がシンプルでプロトコルオーバーヘッドが低い設計。フィールド数が少なく実装も多い。Clash 系のすべてのコアが対応し、低スペックルーターでも安定動作する。

V2Ray プロジェクトのネイティブプロトコル。ユーザーID検証とタイムスタンプによるリプレイ攻撃防止機構を内蔵。WebSocket や TCP の伝送レイヤーと組み合わせて使うことが多く、設定項目は比較的多い。Clash と mihomo のいずれも変換なしで直接解析できる。

プロキシ通信を HTTPS 通信に偽装するプロトコル。TLS 暗号化を強制する。サーバー側は有効な証明書とドメインを保持する必要があり、通信の見た目は通常の Web アクセスと同じになる。証明書の期限切れがこのタイプのノードが使えなくなる最大の原因。

V2Ray が後発で導入した軽量プロトコル。内蔵暗号化を排除し、セキュリティを外部の TLSに委ねる。ヘッダーオーバーヘッドが小さく、Reality などの伝送方式と組み合わせて使われることが多い。mihomo など新しいコアのみ対応し、オリジナル版 Clash では解析できない。

QUIC(UDP)ベースのプロキシプロトコル。弱い通信環境や高パケットロス回線向けに設計されている。輻輳制御を内蔵し、状況に応じて速度を上げられ、サーバー側には証明書が必要。mihomo など新しいコアのみ対応し、モバイル回線での性能が優れている。

同じく QUIC ベースのプロキシプロトコル。低遅延と多重化を重視した設計。UDP 転送と 0-RTT ハンドシェイクをネイティブサポートし、パケットロス環境でも揺れが少ない。mihomo コアが必要で、サブスクリプションでは tuic:// のプレフィックスで識別される。

Dreamacro が開発したオリジナルのオープンソースコア。Go 言語で書かれ、2023年に更新が停止。Shadowsocks、VMess、Trojan、Snell などの基本プロトコルに対応。現在のクライアントは多くがその後継コア mihomo に移行している。

オリジナル作者がリリースしたクローズドソースの強化版。かつて TUN、スクリプト、ルールプロバイダーなどの機能を独占していたが、オリジナル版とともに開発が停止した。これらの機能は現在すべて mihomo に引き継がれ、オープンソースのまま提供されている。新規導入時に選ぶ必要はない。

オリジナル版 Clash のオープンソース後継コア。コミュニティによって継続的に開発が行われている。既存機能に加え VLESS、Hysteria2、TUIC、WireGuard などのプロトコルや、より多くのルールタイプに対応。現在の主要クライアントはほぼすべてこれをコアとしており、設定文法もオリジナル版とほぼ互換性がある。

コアが公開するローカル HTTP 制御インターフェース。デフォルトで 127.0.0.1:9090 をリッスンする。GUI クライアントはこれを通じてノード切替、接続確認、モード変更を行う。設定項目は external-controller で、アクセスキーは secret フィールドで制御し、公開ネットワークに晒してはならない。

サービス提供元が発行するノード配信用のアドレス。クライアントが定期的に取得することでノード一覧を得る。返却内容は Base64 エンコードされたリストまたは完全な YAML であることが多い。リンクには認証パラメータが含まれ、アカウント情報と同等のため、外部に漏らしたり公開の場に貼ったりしないこと。

コア起動時に読み込まれるメイン設定ファイル。ポート、モード、ノード、ルールを決定する。GUI クライアントは通常このファイルを自動管理するため、手動での変更が画面操作によって上書きされることがある。文法エラーはコア起動失敗の最も一般的な原因。

Clash の設定で使用されるマークアップ言語。インデントで階層を表現する。インデントはスペースのみを使用し、タブは使えない。階層のズレが最も多い設定ミスの原因となる。編集後はまずクライアントの検証機能で確認し、それから設定を再読み込みすること。

あるサブスクリプション形式を別の形式にオンラインで書き換えるサービス。旧クライアントが新形式を読み取れない場合に使う。変換処理はサードパーティのサーバーを経由するため、ノード情報が変換元に見える。プライバシーに関わるため慎重に利用すること。

設定内でノードを論理的にグループ化したもの。種類には手動選択、自動速度測定(url-test)、ロードバランス、フェイルオーバーがある。ルールが通信をグループに振り分け、グループがさらに戦略に基づいて具体的なノードに落とし込む。クライアント画面上でのノード選択は、実質的にグループ内メンバーの切り替えにあたる。

デフォルトの動作モード。コアが各通信をルールリストに1件ずつ照合し、マッチした通信はプロキシ経由、マッチしなかった通信は直接接続となる。振り分け精度はルールセットの品質と更新頻度に左右され、ルールが古いと本来プロキシ経由になるべきサイトが直接接続になることがある。

すべての接続を GLOBAL グループに統一して渡し、ルールリストは参照しない。振り分け異常の調査や、一時的に全通信をプロキシ経由にしたい場合に使う。長期間使うと国内サイトまで海外経由になり、アクセス速度が低下する。

すべての接続を直接発信する、プロキシを一時停止した状態と同じ。対照テストに使う:同じサイトを直接接続とプロキシ経由でそれぞれ1回アクセスすれば、問題がどの経路にあるか判断できる。

拡張モードにおける DNS 応答戦略。プロキシルールにマッチしたドメインには予約アドレス帯の仮アドレスを即座に返し、実際の DNS 解決を省略することで接続確立が高速化される。アドレスの厳密な検証を行う一部アプリでは、fake-ip-filter に除外設定を追加する必要がある。

仮想ネットワークカードを通じてマシン全体の通信を引き受ける動作方式。システムのプロキシ設定に依存しない。システムプロキシに従わないアプリや UDP 通信もカバーできるが、管理者権限または root 権限でネットワークカードを導入する必要がある。同種の VPN ソフトと同時に有効化すると、ルートを奪い合ってしまう。

転送に利用できるプロキシサーバーとその接続パラメータの総称。サブスクリプション内の1件のレコードが1つのノードに対応する。同じサーバーでもプロトコルやポートが異なれば、サブスクリプション内で複数のノードとして表示されることがある。

クライアントからノードまでの往復時間、単位はミリ秒。クライアントの測定結果は TCP または HTTP のハンドシェイク時間であることが多く、実際のダウンロード速度とは異なる。数値はノードの現在の状態を横並びで比較する用途にのみ適し、小さな変動は正常な現象。

ドメイン、IP レンジ、プロセス名などの条件に基づいて通信を異なる出口に振り分ける仕組み。ルールは上から順に1件ずつ照合され、マッチした時点で処理が止まる。順序の誤りは振り分けが機能しない典型的な原因。トラブル解決時はまず通信がどのルールにマッチしたかを確認する。

IP アドレスを国・地域コードにマッピングするオフラインデータベース。ルール内の GEOIP,CN のような項目はこれを基準に判定を行う。データベースはクライアントとともに定期的に更新され、長期間更新しないと一部の振り分け判定にズレが生じる可能性がある。

システムのドメイン解決リクエストがプロキシを経由せず、直接プロバイダの DNS へ送られてしまう状態。結果としてアクセス履歴がローカルネットワーク側に見えてしまう。Fake-IP を有効にする、あるいは nameserver をプロキシ経由の解決チャネルに向けることで回避できる。

Android システムがプロキシ系アプリに提供する VPN インターフェース。クライアントはこれを利用してローカルトンネルを構築し通信を引き受け、ステータスバーに鍵アイコンが表示される。システムは同時に1つのアプリのみこのインターフェースを利用できるため、2つのプロキシアプリを同時に有効化できない。

Android クライアントがパッケージ名を基準にどのアプリを VPN トンネル経由にするか選択できる機能。リスト外のアプリには一切影響しない。銀行や決済系アプリを直接接続に保ち、リスク判定を回避する目的でよく使われる。

iOS のネットワーク条件に応じた自動接続機構。条件に合致する通信リクエストを検出するとシステムが自動的に VPN を起動し、アイドル状態になると自動的に切断する。ルールはクライアント設定またはシステムの VPN 設定で管理でき、手動で頻繁にオンオフする必要はない。

モバイル端末でプロキシプロセスがシステムに終了させられないようにするための手段の総称。Android 側はフォアグラウンドサービスとバッテリー最適化の除外に依存し、iOS 側はシステムの VPN フレームワークが管理を担う。プロセスが終了させられると、プロキシが無音で切断され、ステータスバーのアイコンが消える。