Clash 用語集
チュートリアルの読解や設定ファイルの編集で見慣れない用語に出会ったら、このページで分類別にすぐ探せます。全項目はプロキシプロトコル、コアとクライアント、ルールと分岐、ネットワークと DNS、設定ファイルフィールドの5方向で整理し、各項目に実践で使える2〜4文の解説と、mihomo コアの対応関係を明記しています。
プロキシプロトコル
ノード項目の type フィールドに対応する伝送プロトコル。プロトコルによって通信の暗号化方式や偽装方法が決まり、コアの対応範囲に直結します。
Shadowsocks プロキシプロトコル
初期から広く使われている暗号化プロキシプロトコル。対称鍵暗号を用いてクライアントとサーバー間で SOCKS5 通信を伝送します。軽量・低オーバーヘッドを目標に設計され、設定項目が少なく各プラットフォームでの実装も成熟しています。Clash 設定では type を ss と記述し、現在は AEAD 系の暗号方式と組み合わせるのが一般的です。
VMess プロキシプロトコル
V2Ray プロジェクトが設計した伝送プロトコル。UUID による認証を採用し、クライアントとサーバーの時刻がおおむね同期している必要があります。WebSocket + TLS など複数の偽装・伝送方式を組み合わせ可能。mihomo コアは標準で対応し、設定の type は vmess と記述します。
VLESS プロキシプロトコル
VMess の後継となる軽量プロトコル。内蔵暗号化層を廃止し、暗号化の責務を完全に TLS 伝送層に委ねることでハンドシェイクのオーバーヘッドを下げています。XTLS や REALITY などの伝送方式と組み合わせて運用されることが多いです。旧版 Clash コアは対応しておらず、mihomo コアが必須です。
Trojan プロキシプロトコル
プロキシ通信を通常の HTTPS アクセスに偽装するプロトコル。実際の TLS 証明書でハンドシェイクを行うため、通信の特徴が一般的なウェブサイト閲覧に近くなります。設定はサーバーアドレス、ポート、パスワードの3項目のみとシンプル。type は trojan と記述し、主要なクライアントとコアはいずれも対応しています。
Hysteria2 プロキシプロトコル
QUIC(UDP)をベースとした高速伝送プロトコル。独自の輻輳制御により高パケットロス環境でもスループットを維持できます。海外への高遅延回線や不安定な通信環境に適しています。mihomo の拡張プロトコルであり旧版コアでは利用できません。設定の type は hysteria2 と記述します。
コアとクライアント
コアは通信転送とルール照合を担い、クライアントはグラフィカルな操作とサブスクリプション管理を担います。この2層の関係を理解しておくと、選定やトラブルシューティングがしやすくなります。
mihomo コアとクライアント
Clash エコシステムにおける現在のデファクトスタンダードコア。Clash Meta プロジェクトが継続開発を引き継いだものです。旧版コアと比べて VLESS、Hysteria2 などのプロトコル対応、より多くのルール種別、より充実した DNS 機能を備えています。Clash Plus、Clash Verge Rev、FlClash などの主要クライアントはいずれもこのコアを内蔵しています。
旧版 Clash コア コアとクライアント
最初期の clash オープンソースコアと、クローズドソースの強化版 Premium を指します。関連リポジトリはアーカイブされ更新が停止しています。旧設定ファイルの多くは mihomo でそのまま読み込めるため、移行コストは低いです。クライアントを選ぶ際はコアが mihomo であることを確認し、新プロトコルが使えない事態を避けましょう。
GUI クライアント コアとクライアント
コアの上にグラフィカルインターフェースを実装したデスクトップ・モバイルアプリ。サブスクリプション管理、ノード切り替え、システムプロキシの ON/OFF、TUN モードなどの操作窓口を担います。通信転送はコアが処理し、クライアントはユーザーとのやり取りを処理します。両者は代替関係ではなく包含関係にあり、同じ設定ファイルを異なるクライアント間で共通利用できます。
サブスクリプション コアとクライアント
プロキシサービス提供者や自前構築のサーバーが提供する URL で、アクセスすると全ノード情報を含む設定内容が返されます。クライアントが定期的にこのアドレスを取得することでノードの変更が自動的に同期され、手動で1つずつサーバー情報を入力する必要がありません。サブスクリプションアドレスはアカウント情報と同等に扱い、公開共有は避けるべきです。
サブスクリプション変換 コアとクライアント
別形式のノードサブスクリプションを Clash の YAML 設定に変換するサービスやツールで、代表的な実装が subconverter です。サブスクリプション元が他クライアント形式しか提供していない場合、変換 API を通じてルールテンプレート付きの完全な設定を生成できます。公開の変換サービスはサブスクリプション内容を経由するため、機密性の高い用途では自前で構築したインスタンスの利用を推奨します。
ルールと分岐
Clash と一般的なプロキシツールとの最大の違いがここにあります。どの接続をどの条件でどの出口に振り分けるかは、すべてこの階層が決定します。
ルーティング分岐 ルールと分岐
Clash の核となる動作方式:ドメイン、IP、プロセスなどの条件により各接続を異なる出口ポリシーに振り分けます。ルールは上から順に照合され、一致すると照合を停止します。設定内の rules リストの記述順序が最終的な分岐結果を直接左右するため、分岐の異常を調査する際はまず順序を確認しましょう。
ポリシーグループ ルールと分岐
複数のノードや他のポリシーグループを選択可能な1つのグループにまとめる仕組み。種類には手動選択の select、自動速度テストの url-test、フェイルオーバーの fallback、負荷分散の load-balance などがあります。ルールの出口は単一ノードではなくポリシーグループを指すことが多く、ノードを切り替える際はグループ内で選択し直すだけで済みます。
ルールセット ルールと分岐
rule-providers フィールドで参照する外部ルールファイルで、HTTP サブスクリプションとローカルパスの両方に対応し、interval で指定した周期で自動更新されます。多数のルールをメイン設定から分離した後は、メイン設定側で RULE-SET を一行記述するだけで参照でき、保守コストを大きく下げられます。
GeoIP ルールと分岐
IP 帰属地データベースを用いて接続先の国や地域を判定するルール種別で、典型的な記述は GEOIP,CN,DIRECT です。照合は接続先の IP を取得した後に行われ、ルールリストの後方に置いてフォールバックとして使われることが多いです。データベースファイルはコアが自動でダウンロードし、更新先アドレスは設定で指定できます。
GEOSITE ルールと分岐
事前コンパイルされたドメイン分類データベースで照合するルール種別で、データはコミュニティが保守するドメイン分類プロジェクトから提供されます。1行の GEOSITE ルールであるカテゴリー内の数百〜数千のドメインをカバーでき、ルールリストを大幅に短縮できます。mihomo の拡張機能であり、旧版コアは対応していません。
ネットワークと DNS
通信がどのように引き受けられ、ドメインがどのように解決されるかは、多くのトラブルの根本原因です。この一群の概念はトラブルシューティング時に最も頻出します。
ノード ネットワークと DNS
設定ファイルの proxies リストにある1つのプロキシサーバー項目で、プロトコル種別、アドレス、ポート、認証情報を含みます。クライアント画面で選択できる各サーバーの行がそれぞれ1つのノードに対応します。ノードの品質は物理回線とサーバー側で決まり、クライアントソフト自体とは無関係です。
レイテンシテスト ネットワークと DNS
クライアントが指定のテスト用 URL に探測リクエストを送り所要時間を計測する機能で、結果はノード横にミリ秒で表示されます。この数値は1回の HTTP ハンドシェイクの往復時間を反映するもので、ノード間の比較用にとどまり、実際のダウンロード速度とは異なります。url-test ポリシーグループはこの結果に基づいて現時点で最適なノードを自動選択します。
DNS リーク ネットワークと DNS
プロキシを有効にしていても、ドメイン解決のリクエストがローカルのプロバイダー DNS に直接送られ、アクセス意図が漏れてしまう現象です。よくある原因はシステムプロキシモードで UDP 53 番ポートの解決通信が引き受けられていないことです。Clash 内蔵 DNS を有効にし、TUN モードや Fake-IP モードと組み合わせることで回避できます。
Fake-IP ネットワークと DNS
Clash 内蔵 DNS の応答モードの1つで、ドメインクエリに対して即座に予約済みセグメント内の仮の IP を返し、実際の名前解決は接続確立時まで遅延させます。上流 DNS の応答待ちを省略できるほか、解決結果が汚染される問題も避けられます。実際の IP に依存する一部のアプリケーションは fake-ip-filter で除外する必要があります。
TUN モード ネットワークと DNS
仮想ネットワークカードを作成し、ネットワーク層で全システム通信を引き受ける動作方式で、アプリケーションがプロキシ設定に自主的に従うことに依存しません。コマンドラインツール、ゲーム、UDP 通信もすべて分岐対象になります。有効化には管理者権限または root 権限が必要で、設定フィールドは tun.enable です。
システムプロキシ ネットワークと DNS
OS のネットワーク設定に HTTP/SOCKS プロキシのアドレスを登録し、各アプリケーションが自主的に読み取り従う従来型の方式です。実装が簡単で特殊な権限も不要ですが、この設定に従わないアプリケーションはプロキシを直接迂回してしまいます。TUN モードと相互補完的な関係にあり、利用シーンに応じて選択します。
ドメインスニッフィング ネットワークと DNS
通過する TLS や HTTP 通信から SNI や Host に含まれる実際のドメインを解析し、IP ではなくドメインでルール照合を行う機能です。Fake-IP や純粋な IP 接続のシーンでドメインルールが一致しない問題を補正できます。mihomo では sniffer.enable で有効化します。
設定ファイルフィールド
config.yaml で最も頻繁に登場するトップレベルフィールドをまとめました。値の意味を理解すれば、大半のサブスクリプション設定が読めるようになります。
YAML 設定ファイルフィールド
Clash 設定ファイルが採用するテキスト形式で、インデントにより階層を表し、コロンの後には必ず1つのスペースが必要です。インデントはスペースのみを使用し、タブが混入すると即座に解析エラーになります。設定変更後にエラーが出た場合は、まずインデントの階層とコロンの書式を確認しましょう。
mixed-port 設定ファイルフィールド
単一ポートで HTTP と SOCKS5 両方のプロキシプロトコルを受け付けるリスニングフィールドで、デフォルト値は 7890 が一般的です。ブラウザ拡張機能やコマンドラインツールはこの1つのポートを共用でき、別々に指定する必要がありません。LAN 内でプロキシを共有する場合、他のデバイスが入力するのもこのポート番号です。
allow-lan 設定ファイルフィールド
同一 LAN 内の他デバイスから本機のプロキシポートへの接続を許可するかどうかのスイッチです。true に設定すると、同一ネットワーク上のスマートフォンやテレビボックスからこのパソコンをプロキシ先に指定できます。有効化時はシステムファイアウォールでポートを許可することに注意し、必要に応じて authentication フィールドでアクセス認証を追加します。
mode 設定ファイルフィールド
通信処理方式を決めるグローバルフィールドで、rule はルールに基づく分岐、global は全通信をプロキシ経由、direct は全通信を直接接続とする意味です。通常は rule のままにするのを推奨します。クライアント画面のモード切り替えボタンが変更しているのはこのフィールドです。
proxy-providers 設定ファイルフィールド
サブスクリプション形式でノード集合を取り込むフィールドで、複数のソースを設定して周期的に自動更新でき、手書きの proxies リストとも共存できます。ポリシーグループの use 参照方式と組み合わせることで、複数サブスクリプションの統合管理と一括グループ化が実現できます。
external-controller 設定ファイルフィールド
コアが RESTful 制御 API を公開するリスニングアドレスのフィールドで、一般的な値は 127.0.0.1:9090 です。Web 管理パネルはこの API を通じて接続一覧の取得、ノードの切り替え、ログの確認を行います。ローカル以外のアドレスでリスニングする場合は、必ず secret アクセスキーも設定してください。
用語を実際の設定に活かす
用語はあくまで索引であり、実際に手を動かしてこそ理解が深まります。以下の2ページでは、本ページの概念を異なる深度で実践的に扱っています。
初めて使う場合はインストールとサブスクリプション導入ガイドを参照し、手順に沿ってクライアントを設定してください。DNS の最適化、ポリシーグループの設計、ルールセットの管理まで深く学びたい場合は上級設定ガイドをご確認ください。まだクライアントをインストールしていない場合はクライアントダウンロードページからプラットフォームを選択してください。