コア(Core)
コアとバージョン設定を読み込み、接続を確立してルールを実行するプログラム本体。サブスクリプション、ノード、プロキシグループは最終的にすべてこれが解析します。GUI クライアントはあくまで外殻で、画面とスイッチを担当するだけです。クライアントを変えても分流結果は変わらず、コアを変えて初めて機能の範囲が変わります。
用語ハンドブック
クライアント画面のスイッチの一つひとつ、設定ファイルのフィールドの一つひとつに、明確な技術用語が対応しています。このハンドブックはよく使う用語を6分類で整理し、各項目の定義・登場箇所・隣接概念との違いを示します。設定の照合やトラブルシューティングの際に、目的の項目へ素早くたどり着けます。
実行層
クライアント画面で見える機能は、最終的にすべてコアが実装しています。このグループの用語は、設定が正しく解析できるか、プロトコルが対応しているかを左右します。
設定を読み込み、接続を確立してルールを実行するプログラム本体。サブスクリプション、ノード、プロキシグループは最終的にすべてこれが解析します。GUI クライアントはあくまで外殻で、画面とスイッチを担当するだけです。クライアントを変えても分流結果は変わらず、コアを変えて初めて機能の範囲が変わります。
Clash Meta から名称変更されたオープンソースコアで、現在の多くの新しいクライアントが標準で搭載しています。Clash の設定フォーマットを維持しつつ、対応プロトコルとルール機能を拡張しており、設定ファイルの mixed-port、tun、proxy-providers などのフィールドはすべてこれが解析・実行します。
mihomo の旧称で、コミュニティの多くのチュートリアルや設定ファイルでは今もこの表記が使われています。コアに meta の表記がある場合は同じコアの初期バージョンを指すのが一般的で、設定フィールドは mihomo とほぼ共通です。見慣れないフィールドに遭遇したら、まずコアのバージョンを確認してください。
mihomo コアが採用する自由ソフトウェアライセンスで、使用・改変・再配布が認められ、派生版にも同じライセンス条件が求められます。クライアントのエコシステムが長期間並行して維持されてきたのは、このライセンスの設計によるところが大きいです。
接続層
プロトコルはハンドシェイクの方式、暗号化の位置、リソース消費を決めます。同じサーバーでもプロトコルを変えると、速度やバッテリーの持ちがまったく変わることがあります。
比較的早くから広く使われてきたプロキシプロトコルで、軽量・低オーバーヘッドが設計目標です。設定は通常、暗号化方式・パスワード・ポートの3項目だけ。多重化や追加の転送層を持たず機能の範囲が明確で、低スペック端末やルーターではリソース消費が少なめです。
V2Ray プロジェクト初期の主力プロトコルで、ユーザー ID と時刻検証を備え、クライアントとサーバーの時刻がほぼ同期している必要があります。設定フィールドが多く、パラメータを誤ると接続自体が失敗しがちです。現在はより簡素な VLESS に取って代わられつつあります。
VMess の簡素化された後継プロトコルで、内蔵の暗号化と時刻検証を廃し、安全性は下位の転送層に任せます。そのため設定が短く、ハンドシェイクも高速です。TLS、WebSocket、gRPC と組み合わせて使われることが多く、現在の主要プロトコルの一つです。
TLS を外殻とするプロキシプロトコルで、サーバー側はごく普通の HTTPS サーバーのように振る舞います。設定は主にパスワードとドメインです。標準の TLS ポートを流用でき導入が簡単なのが利点で、代わりにハンドシェイクのオーバーヘッドは素のプロトコルよりやや大きくなります。
QUIC ベースのプロキシプロトコルで、輻輳制御をユーザー空間で実装し、パケットロスが多い回線でもスループットを維持できます。UDP に強く遅延も安定していますが、CPU 負荷は高めで、低消費電力の端末では発熱とバッテリーに注意が必要です。
同じく QUIC ベースのプロトコルで、低遅延とコネクションマイグレーションが特徴です。ネットワークを切り替えても接続が切れにくくなっています。Hysteria2 より設定項目は少ないものの、対応クライアントはやや限られるため、選ぶ前に使用中のクライアントが内蔵しているか確認してください。
分流層
ルール、プロキシグループ、設定ファイルの形式が相まって各接続の行き先を決めます。トラブルシューティングで最も頻繁に触る部分でもあります。
一連のルールで各接続がどのプロキシグループを通るかを決めます。ドメイン、IP、プロセスの条件に一致すればそのルールに従い、どれにも一致しなければ最後の MATCH に落ちます。設定の中核となる部分で、どの通信を直接接続し、どれをプロキシに任せるかを決めます。
大量のルールをメイン設定から切り出して個別に管理するファイル、またはリモートアドレスで、rule-providers から参照します。ルール更新のたびにメイン設定を書き換えなくて済み、複数の設定で同じルールを共有できるのが利点。代わりに読み込みとキャッシュ管理の手間が増えます。
設定内の選択可能な出口のまとまりで、代表的な種類は select、url-test、fallback。手動選択、遅延による自動選択、順番どおりのフォールバックに対応します。ルールが一致するとプロキシグループを指し、画面で切り替えているのは実質的にそのグループが現在選んでいるノードです。
Clash 設定ファイルの記述フォーマットで、インデントで階層を、ハイフンでリスト項目を表します。インデントに敏感で、スペースとタブの混在や階層のずれは解析エラーの原因になります。設定エラーで最も多いパターンの一つです。
ルールは上から下へ順に照合され、一致した時点で打ち切られます。つまり順序そのものが戦略の一部です。範囲の広いルールを前に置くと後ろの精密なルールが隠れてしまうため、分流の異常を調べるときはまず順序を見て、それからルールの中身を確認します。
リソース層
サブスクリプションは遠隔のノードを手元に取り込み、設定ファイルがその結果を保存します。どちらが壊れたかで症状は異なり、調べる方向も変わります。
プロバイダーが提供する URL で、クライアントが定期的に取得してノードとプロキシグループを生成します。URL には通常トークンパラメータが付き、アカウントの資格情報に等しいため公開しないでください。URL が無効になったり空の内容を返したりすると、ノード一覧もそれに伴って消えます。
接続可能なサーバーとそのパラメータ一式で、アドレス、ポート、プロトコル、暗号化方式などのフィールドを含みます。1つのサブスクリプションには通常複数のノードが含まれ、クライアントはそれらをプロキシグループに入れ、手動切り替えや自動速度テストで選べるようにします。
クライアントに保存された1つの完全な設定で、サブスクリプションが生成したノードのほか、ローカルのルール、DNS、プロキシグループの設定も含みます。多くのクライアントは複数の設定ファイルの併存に対応しており、トラブルシューティングでは最小構成の設定を新規作成して切り分けられます。
あるサブスクリプション形式を別の形式に変換する中間サービスで、汎用リンクを Clash が読める YAML に変換する用途が一般的です。変換時にノードパラメータとルールが書き換わるため、問題が起きたら変換前後の元データを比較してから判断してください。
サブスクリプション URL とサーバーリソースを提供する事業者で、ユーザー側から見えるのは URL と複数のノードです。選ぶ際はプロトコルの種類、ノードの地域、更新頻度に注目してください。ノード数が多いからといって品質が高いとは限りません。
ネットワーク層
システムプロキシと TUN が通信をコアに通すかどうかを決め、DNS と Fake-IP が名前解決をどの段階で行うかを決めます。
クライアントがシステムの HTTP と HTTPS プロキシをローカルポートに向け、その通信をコアが引き受けます。対象はシステムプロキシ設定に従うアプリだけで、ターミナルのコマンド、一部のデスクトップアプリ、UDP 通信は自動ではプロキシを通りません。接続できないときの最初の確認ポイントです。
クライアントが仮想ネットワークアダプタを作成し、端末全体の通信を OS レベルで引き受けます。システムプロキシでは届かないアプリや UDP 通信もカバーされます。有効化には通常管理者権限が必要で、DNS とルートを適切に設定しないとループや通信断が起きやすくなります。
本来はコアが処理すべき名前解決リクエストが、OS やブラウザから直接ローカル DNS に送られ、分流の判断材料が欠けてしまう現象です。よくある原因はブラウザ内蔵の暗号化 DNS、複数 NIC の構成、引き受けられていない 53 番ポートです。
コアはまずドメインに対して予約済みセグメント内の仮想アドレスを返し、接続が始まってからドメインでルールを照合し、実際の接続を確立します。実際の名前解決を待たずに済むため初回応答が速くなりますが、実 IP を必要とするアプリは個別に除外する必要があります。
1回のリクエスト往復にかかる時間で、クライアントの速度テストが示す数値は通常、特定のテスト先への疎通から得られます。現在の回線品質を反映するもので、ダウンロード速度とは別物です。クライアントごとにテスト先が異なるため、数値をそのまま比較するのは適切ではありません。
クライアントの3段階の接管方式です。ルールモードは設定どおりに分流し、グローバルモードはすべての通信をプロキシに送り、ダイレクトモードはプロキシを一切通しません。普段はルールモードを使い、モード切り替えは問題がルール側か回線側かを素早く見分けるのに役立ちます。
IP アドレスを国や地域にマッピングするデータベースで、ルールの GEOIP 条件と画面の地域ラベルはこれが提供します。データベースは定期的に更新が必要で、そうしないと新しく割り当てられたアドレス帯が誤った地域と判定されます。
UI 層
クライアントはサブスクリプション管理、オンオフ、ログ表示を担当します。選ぶ際はまず対応プラットフォームと内蔵コアのバージョンを見て、そのうえで画面が自分の使い方に合うかを確認します。
コアのグラフィカルな外殻で、サブスクリプション管理、ノード切り替え、モードのオンオフ、起動時の自動開始などを担当します。ユーザー操作を設定に変換してコアに渡すため、画面の違いは分流結果に影響しません。機能の範囲を決めるのはコアのバージョンです。
Tauri ベースのデスクトップクライアントで、Windows、macOS、Linux に対応し、画面から直接設定を編集したり接続状況やログを確認できます。mihomo コアを内蔵しており、複数の設定を同時に管理したいデスクトップユーザーに向いています。
クロスプラットフォームのクライアントで、デスクトップ版と Android 版が同じ UI ロジックを共有し、設定のインポートとプロキシグループの切り替えはホーム画面に集約されています。複数設定ファイルとルール編集に対応し、スマホと PC で同じ使い勝手を保ちたい人に適しています。
かつて最も広く使われた Windows クライアントですが、原作プロジェクトはメンテナンスを終了し、新しいコアやプロトコルには追随していません。既存の設定はエクスポートして他のクライアントへ移行できますが、新規導入で第一候補にするのはおすすめしません。
Windows、macOS、Android、iOS をカバーする全プラットフォーム対応クライアントで、iOS 版は App Store から入手でき、公式サイトは clashplus.io です。mihomo コアを内蔵し、サブスクリプションのインポートとルール切り替えを同じ画面にまとめています。
早見対照
以下の用語の組は、設定やトラブルシューティングの場面で最も混同されやすいものです。まずそれぞれが何を指すのかを切り分け、そのうえで設定を直すのか、モードを変えるのか、クライアントを替えるのかを判断してください。
| 項目 | 違いの要点 |
|---|---|
| コア / クライアント | コアは接続と分流を担い、クライアントは画面とサブスクリプション管理を担います。クライアントを変えても分流結果は変わらず、コアを変えて初めて機能の範囲が変わります。 |
| ルールモード / TUN モード | 前者は通信がどの回線を通るかを決め、後者は通信を端末全体で引き受けるかどうかを決めます。両者は同時に有効にでき、互いを置き換えるものではありません。 |
| システムプロキシ / TUN モード | システムプロキシはシステム設定に従うアプリだけを対象とし、TUN モードはネットワークアダプタのレベルで端末全体の通信を、UDP も含めて引き受けます。 |
| サブスクリプション URL / 設定ファイル | サブスクリプション URL は遠隔のアドレス、設定ファイルはローカルに保存された結果です。URL が無効になっても既存のノードがすぐに削除されるわけではありません。 |
| DNS リーク / 名前解決の失敗 | リークは解決リクエストが通るべきでない経路を通ってしまうこと、解決失敗はそもそも結果が得られないことで、対処の方向が異なります。 |
| Fake-IP / 実 IP | Fake-IP はコアが返す仮想アドレスで、クライアント内部でのみ有効です。実アドレスを必要とするアプリは個別に除外してください。 |
まず用語がどの層に属するかを見極める
設定に見慣れないフィールドが出てきたら、それがコア、クライアント、サブスクリプションのどの層に属するかを判断してから、どの資料を調べるかを決めます。層をまたいで書き間違えると、エラーメッセージは別の場所を指すことが少なくありません。
続けて読む
用語は言葉の意味を説明するものですが、具体的な操作手順と設定の詳細は以下のページで扱っています。