GLOSSARY
5分類・28語の常用語を収録。各用語には専用アンカーが付いており、設定リファレンスや使い方ガイドと合わせて参照できます。Clash のエコシステムに初めて触れる方は「コアとプロトコル」と「サブスクリプションと設定」の2グループから読むのがおすすめです。
CORE & PROTOCOL
コアはすべてのクライアントの背後で動く実行エンジンであり、プロトコルはノードとサーバー間の通信方式を決めます。このグループの用語は、ほとんどの設定ドキュメントに登場します。
Clash Meta コアの現在の名称です。従来の Clash コアをベースにプロトコル対応、ルール構文、DNS 機能を拡張しており、現在活発に開発されているメインラインのコアです。Clash Verge Rev、ClashX Meta、FlClash など主要なクライアントはこれを標準搭載しています。
仮想ネットワークアダプタを作成し、システムのネットワーク層で入出力トラフィック全体を引き受ける動作モードです。一部のアプリにしか効かないシステムプロキシと違い、TUN はコマンドラインツールやゲームなどプロキシ設定を読まないプログラムもカバーできます。有効化には管理者権限またはシステム拡張の許可が必要です。
軽量な暗号化プロキシプロトコルで、設定項目が少なく実装も広く普及しており、多くのサブスクリプションで最もよく見かけるノード種別の一つです。mihomo は主要な暗号化方式に対応し、obfs、v2ray-plugin などの難読化プラグインにも対応しています。プラグインのパラメーターはノード項目内に記述します。
V2Ray エコシステム由来のプロキシプロトコルで、ユーザーの UUID によって認証を行い、固定パスワードに依存しません。実運用では WebSocket トランスポートと TLS 暗号化を組み合わせることが多く、ノード設定時はトランスポート層と暗号化関連のフィールドを同時に記入する必要があります。
QUIC をベースにした比較的新しいプロキシプロトコルで、パケットロスの多い回線向けの輻輳制御戦略を内蔵しており、不安定な回線でのスループットが主な特徴です。mihomo は標準対応済みで、ノードは設定内で type: hysteria2 として記述します。
RULES & ROUTING
分流は Clash の核心的な価値です。どのトラフィックを直接接続にし、どれをプロキシ経由にし、どれを拒否するか——すべてこのグループの概念によって決まります。
ドメイン、IPセグメント、プロセス名などの条件によって、異なるトラフィックを異なる出口へ振り分ける仕組みで、設定の rules セクションに記述します。ルールは上から順に1件ずつマッチし、最初に一致したルールがすぐに適用され、それ以降は評価されません。リストの末尾には通常 MATCH ルールを置いて残りを処理します。
複数のノードをまとめ、ルールから参照できるグループとして構成する仕組みで、proxy-groups セクションに記述します。よく使われるタイプ:手動選択の select、レイテンシに基づいて自動選択する url-test、主系・待機系を切り替える fallback、負荷を分散する load-balance。グループは他のグループを入れ子で参照することもできます。
IPアドレスの所属地域を示すデータベースで、GEOIP,CN,DIRECT のようなルールが国や地域コードで対象 IP をマッチさせる際に利用します。データベースが古いと判定にズレが生じ分流の精度が落ちるため、多くのクライアントにはワンクリック更新機能があり、設定でデータソースを指定することも可能です。
ドメインを用途別に分類したデータベースで、多数のドメインを名前付きの集合にまとめています。GEOSITE 系ルールは集合名で一括マッチできるため、1つのルールで数千のドメインをカバーでき、個別に管理する必要がありません。GeoIP と同様、定期的な更新が必要です。
rule-providers で読み込む外部ルールファイルで、コアが設定した間隔で自動的にダウンロード・更新します。規模の大きいルールリストや、複数の設定間で再利用したい場合に向いており、メイン設定では集合名を参照する RULE-SET ルールを1行書くだけで済みます。
コアがトラフィックを処理する全体の切り替え設定で、設定内の mode フィールドに対応します。Rule はルールに従って1件ずつマッチ、Global はすべてプロキシ経由、Direct はすべて直接接続です。通常使用では Rule が主となり、Global と Direct は一時的な検証や特殊な場面で使われます。
DNS & RESOLUTION
「ルールを正しく書いたはずなのに効かない」という問題の多くは、名前解決の段階に原因があります。このグループの概念を理解しておくと、トラブルシューティングの見通しがはるかに良くなります。
DNS 強化モードの一つです。コアはドメインの問い合わせに対して 198.18.0.0/16 という予約セグメント内の仮想アドレスを返し、実際の名前解決は接続確立時まで遅延させます。名前解決の待ち時間が減り、解決結果の汚染を防げる一方、実IPに依存する場面では追加で除外設定が必要になります。
もう一つの DNS 強化モードで、問い合わせに対して実際の解決結果をそのまま返す、従来のDNSに近い動作です。mihomo ではこのモードの重要度は下がっており、通常は Fake-IP の使用が推奨されます。旧設定で redir-host が指定されている場合も、多くはそのまま移行できます。
Fake-IP モード時の除外リストです。リストに一致したドメインは仮想アドレスではなく実際の名前解決に切り替わります。LAN内デバイスの検出、プリンター、NAS、オンラインゲームなど実IPを必要とする場面では、通常これらのドメインをリストに追加する必要があります。
ドメイン解決リクエストがプロキシ経路を経由せず、そのまま現地のISPのDNSへ直接送られてしまう現象です。通信自体はプロキシを経由していても、解決記録からアクセス先が推測できてしまいます。対策としては、設定で nameserver を指定する、暗号化DNSを上流として使う、TUN モードで名前解決を一括して引き受けるなどがあります。
DNS over HTTPS と DNS over TLS の略称で、平文のDNSクエリを暗号化通信に包んで送信し、途中での傍受や改ざんを防ぎます。dns.nameserver で上流アドレスの先頭に https:// または tls:// を付けて記述するだけで有効になります。
SUBSCRIPTION & CONFIG
1本のサブスクリプションリンクから、実際に動く config.yaml が出来上がるまでに関わる用語をこのグループでまとめています。設定を書く前に一通り確認しておく価値があります。
設定全体またはノードリストをホストしているURLです。クライアントに取り込むと、設定した間隔で自動的に取得し、ローカルのノード情報をサーバー側と同期し続けます。リンク自体がアクセス資格情報に相当するため、公開したり他人に転送したりしないでください。
設定ファイルの proxies 配列内にある個々のプロキシサーバーの項目です。プロトコル種別、サーバーアドレス、ポート、認証情報などのフィールドを含みます。ノードは名前でプロキシグループから参照され、同じノードを複数のグループに含めることもできます。
通常 config.yaml という名前で保存される YAML 文書です。ポート、プロキシモード、DNS、ノード、プロキシグループ、ルールをまとめて記述し、コアの動作を決める唯一の基準となります。フィールドの構造や書き方は、本サイトの設定リファレンスでセクションごとに解説しています。
設定ファイルで使われるデータ形式で、インデントによって階層関係を表し、空白の数に敏感です。編集時はスペースでのインデントを統一する必要があり、タブ文字が混在するとそのまま解析エラーになります。コロンの後に半角スペースを1つ入れることも、見落としがちな細部です。
サブスクリプションの内容にローカルの変更を重ねる仕組みで、設定の断片を統合する方式やスクリプトによる処理として実装されることが多いです。オーバーライドを使えば、サブスクリプションが更新されても、自分で追加したルールやプロキシグループが消されることがなく、独自の分流設定を長期的に維持する際の推奨手段です。
クライアントが指定したテスト用アドレスにリクエストを送り、応答時間を計測する機能で、結果はミリ秒単位でノード一覧に表示されます。url-test 系のプロキシグループはこの計測結果に基づいて、レイテンシの低いノードへ自動的に切り替えます。この数値は接続時のハンドシェイク時間を反映するもので、実際の帯域幅とは別物です。
CLIENTS & PLATFORMS
同じコアであっても、プラットフォームごとにグラフィカルクライアントやシステムの仕組みは異なります。クライアントを選んだりトラブルを調べたりする際、これらの用語は避けて通れません。
Windows、macOS、Linux に対応するデスクトップクライアントで、mihomo コアを内蔵し、システムプロキシのオンオフ、サービスモード、TUN 設定用の画面を提供するほか、サブスクリプション管理や設定オーバーライドにも対応しています。デスクトップ版は上級機能が比較的充実しており、本サイトの設定リファレンスにおける主な検証環境の一つです。
macOS のメニューバー常駐クライアントで、ClashX が Meta コアに切り替えた分岐版です。軽量で常駐しながらすぐに切り替えられる点が特徴でしたが、プロジェクトは現在開発を停止しており、旧バージョンはダウンロードして利用できます。継続的な更新を重視するなら、同プラットフォームの他のクライアントも検討するとよいでしょう。
Android 向けクライアントで、システムの VpnService をもとに仮想ネットワークアダプタを作成し、デバイスのトラフィックを引き受けます。アプリ単位の分流や複数設定ファイルの管理に対応しています。バックグラウンドでの常駐安定性はメーカーの省電力機能に左右され、初回利用時には VPN 権限の許可が必要です。
OSレベルの HTTP/SOCKS プロキシ設定で、ブラウザなどこの設定に従うアプリは自動的にプロキシポート経由で通信します。コマンドラインツールや一部のアプリはこの設定を読み取らないため、環境変数を個別に設定するか、TUN モードに切り替えて全体を引き受ける必要があります。
Android が提供するシステムインターフェースで、root権限なしでもアプリが仮想ネットワークアダプタを作成し、デバイスのトラフィックを引き受けられます。初回利用時にはユーザーの許可確認が必要で、メーカー独自の省電力機能によってプロセスが終了させられると仮想ネットワークアダプタも切断され、通知バーのアイコンが消えたりネットワークが直接接続に戻ったりする形で現れます。
NEXT STOP
用語集が担うのは「これは何か」の説明です。以下の3つのページは、それぞれ「どう書くか」「どう使うか」「どう選ぶか」を担当します。
config.yaml をセクションごとに解説:共通フィールド、ノードの書き方、プロキシグループの種類、ルール構文を YAML の例付きで紹介。書きながら参照するのに向いています。
各プラットフォームのクライアントを機能面で横断比較:コアのバージョン、TUN対応、開発状況、向いている用途をまとめ、ダウンロード前の選定に役立てられます。