GLOSSARY

Clash 用語集

Clash クライアントを使う過程で何度も出てくる専門用語を、5つのカテゴリに整理した速習用の一覧です。各項目に簡潔な定義と実務上のポイントを付記しているので、チュートリアル技術リファレンスと併せて読むとより理解しやすくなります。

A · PROTOCOL

プロキシプロトコル

ノード項目の type フィールドに対応するトランスポートプロトコルの種類。暗号化方式、ハンドシェイクの挙動、コアの対応範囲を決定します。選定の参考は技術リファレンスを参照してください。

プロキシプロトコルShadowsocks(SS)
軽量な暗号化プロキシプロトコル。対称鍵暗号を用いた SOCKS5 の変種です。構造がシンプルでハンドシェイクの負荷が小さく、リソース消費も少ないためモバイル端末での電池持ちも良好です。ほぼ全ての Clash コア・クライアントが標準対応しており、互換性が最も広いプロトコルです。
プロキシプロトコルVmess
V2Ray プロジェクトが設計したプロトコルで、ユーザーID(UUID)による認証を行い、WebSocket や gRPC など複数のトランスポート層をサポートします。設定項目が比較的多く、alterId や暗号化方式などのパラメータはクライアントとサーバーで完全に一致させる必要があり、不一致だと接続に失敗します。
プロキシプロトコルTrojan
TLS 通信の形でプロキシデータを伝送するプロトコルで、ハンドシェイクの挙動が標準的な HTTPS に近いです。設定項目はサーバーアドレス、ポート、パスワードのみと少ないですが、サーバー証明書に厳しい要件があり、証明書失効やドメイン不一致があるとハンドシェイクに失敗します。
プロキシプロトコルVLESS
Vmess の後継となる軽量プロトコルで、内蔵の暗号化層を省き、安全性は完全に外側の TLS に依存するためプロトコルオーバーヘッドが低くなります。オリジナルの Clash コアはこのプロトコルに対応していないため、サブスクリプションに VLESS ノードが含まれる場合は mihomo コア採用のクライアントが必須です。
プロキシプロトコルHysteria2
QUIC(UDP)をベースにしたプロトコルで、積極的な輻輳制御アルゴリズムを内蔵し、パケットロスや遅延の大きい回線でも TCP 系プロトコルより明らかに高いスループットを発揮します。mihomo コアのみ対応で、UDP を制限するネットワークではこのプロトコル自体が使用不可になります。
プロキシプロトコルTUIC
同じく QUIC をベースにした別のプロトコルで、低ハンドシェイク遅延(0-RTT)とネイティブな UDP 転送能力を強みとし、ゲームやリアルタイム通信に向いています。mihomo コアと対応サーバーの両方が必要で、普及度は Hysteria2 より低めです。
B · CORE & CLIENT

コアとクライアント

「コア」が転送とルールマッチングを担い、「クライアント」がグラフィカルな操作を担うという役割分担です。クライアントのダウンロードと選定はクライアントページ比較評価を参照してください。

コアとクライアントコア(Core)
実際にプロキシ転送、ルールマッチング、DNS 処理を行うコマンドラインプログラムで、それ自体にグラフィカルインターフェースはありません。GUI クライアントは本質的にコアの外観にすぎず、対応プロトコルの範囲や TUN 機能などの上限はコアのバージョンによって決まり、インターフェースとは無関係です。
コアとクライアントmihomo(Clash Meta)
コミュニティが保守する Clash コアのフォークで、以前は Clash Meta と呼ばれていました。オリジナルをベースに VLESS、Hysteria2、TUIC などのプロトコル対応を拡張し、TUN モードとルールセット(rule-providers)の強化機能を内蔵しており、現在の主流クライアントの標準コアとなっています。
コアとクライアントGUI クライアント
コアにグラフィカルインターフェースを提供するアプリケーションで、サブスクリプション管理、ノード切り替え、システムプロキシのオンオフ、自動起動などの操作を担います。例として Clash Plus、Clash Verge Rev、FlClash があります。異なるクライアントが同一コアを搭載していれば、振り分けの挙動は一致します。
コアとクライアントClash for Windows(CFW)
かつての主流 Windows デスクトップクライアントで、2023年に開発が終了しました。オリジナルコアを搭載しているため VLESS や Hysteria2 などの新プロトコルに対応せず、新しいサブスクリプションとの互換性は下がり続けています。現時点では mihomo コア採用の後継クライアントへの移行が推奨されます。
コアとクライアント外部制御インターフェース(RESTful API)
コアが公開するローカル HTTP 管理インターフェースで、デフォルトでは 9090 ポートを監視します。GUI パネルはこれを通じて接続一覧の取得、ノード切り替え、通信量の確認を行います。サードパーティ製 Web パネルも同様にこのインターフェースに依存し、設定内の external-controller フィールドで有効・無効を制御します。
C · CONFIG & RULE

設定とルール

設定ファイルは Clash の動作規約であり、ノードの取得元も通信の行き先もここで決まります。サブスクリプションを初めて導入する完全な手順はチュートリアルページを参照してください。

設定とルールサブスクリプション(Subscription)
サービス提供者が発行する設定配信リンクで、クライアントが決まった周期で取得することで最新のノード一覧とルール内容を反映できます。サブスクリプションは複数デバイスの設定を統一する主な手段で、リンクが失効・期限切れになると更新に失敗し、ノード一覧が古い状態のままになります。
設定とルール設定ファイル(YAML)
Clash はリスニングポート、DNS 方針、ノード、プロキシグループ、ルールを YAML 形式で記述します。YAML はインデントに敏感で、階層はスペースで表現します。タブ文字の混入やインデントのずれがあると、コアの解析に失敗して起動できなくなります。
設定とルールルール分岐(Rule)
ドメイン、IP セグメント、プロセス名などの条件に応じて通信を異なる出口へ振り分ける仕組みです。ルールは上から順に一件ずつ照合され、一致した時点で確定し、末尾の MATCH 項目が兜底役を担います。これが単純な全体プロキシツールとの決定的な違いとなる中核機能です。
設定とルールプロキシグループ(Proxy Group)
複数のノードを選択可能な論理単位としてまとめる仕組みで、ルールの出口は単一ノードではなくプロキシグループを指します。代表的な種類は select(手動選択)、url-test(最も遅延の低いノードを自動選択)、fallback(障害時に順番で切り替え)です。
設定とルールグローバルモード(Global)
すべての分岐ルールをスキップし、全通信が現在選択中の出口に一括で流れる動作モードで、対をなすものにルールモード(Rule)と直結モード(Direct)があります。グローバルモードはルールの問題を一時的に切り分けるのに適しており、通常はルールモードのままにすることが推奨されます。
設定とルールFake-IP
DNS 処理モードの一種で、ドメイン照会に対して 198.18.0.0/16 の予約セグメント内の仮想 IP を即座に返し、実際に接続を確立する際に本来のドメインへ戻してルールに照合します。実際の解決を待つ時間を省けるため初回接続の遅延を大きく短縮でき、対をなすのが Redir-Host モードです。
設定とルールルールセット(Rule Provider)
大量のルール項目をリモート更新可能な外部ファイルに分割し、設定側ではセット名だけを参照する仕組みです。mihomo コアは domain、ipcidr、classical の3形式に対応し、ルールセットはサブスクリプションとは独立した周期で自動更新できます。
D · NETWORK

ネットワーク基礎

これらの基礎概念を理解しておくと、「接続できない」「速度が異常」といった問題の切り分けで無駄な手間を減らせます。体系的な切り分け手順はよくある質問を参照してください。

ネットワーク基礎ノード(Node / Proxy)
利用可能なリモートプロキシサーバーの1件で、サーバーアドレス、ポート、プロトコル種別、認証パラメータを含み、サブスクリプション内容の基本単位です。同じノードなら異なるクライアントでも挙動は一致するはずで、特定の端末だけで利用できない場合は問題の原因はローカル環境側にあることが多いです。
ネットワーク基礎レイテンシ(Latency)
クライアントがノードにテストリクエストを送信し、応答を受け取るまでの所要時間(ミリ秒)で、回線の往復時間を反映する値です。レイテンシとダウンロード帯域幅は独立した2つの指標で、レイテンシが低いことは速度が速いことを意味せず、レイテンシが高くても大容量転送のスループットに影響しない場合もあります。
ネットワーク基礎DNS(ドメイン名解決)
ドメイン名を IP アドレスに変換する基礎サービスです。Clash 内蔵の DNS モジュールが解決プロセスを引き受け、DoH や DoT などの暗号化クエリ方式に対応します。設定内の nameserver と fallback はそれぞれ通常時と代替時の解決元を定義します。
ネットワーク基礎DNS リーク
プロキシは有効になっているのに、ドメイン解決リクエストが依然としてローカルの回線事業者DNSへ直接送られてしまう現象です。アクセス意図が露呈するほか、不正確な解決結果が返る可能性もあります。一般的な回避方法は Fake-IP モードや TUN モードを有効にし、解決リクエストも Clash を経由させることです。
ネットワーク基礎GeoIP
IP アドレスと国・地域を対応付けるデータベースです。ルール内の GEOIP,CN,DIRECT のような項目はこれを利用して宛先 IP の所属地を判定するため、データベースが古いと誤判定が発生します。コアの更新に合わせるか、クライアント内でデータファイルを手動更新することが推奨されます。
ネットワーク基礎UDP 転送
プロキシ経路が UDP パケットに対応する能力で、オンラインゲームや音声・ビデオ通話が大きく依存する機能です。ノードのプロトコル自体が UDP に対応(SS の udp パラメータや Hysteria2 のネイティブ対応など)し、かつサーバー側も有効にしている必要があり、どちらか一方が欠けると該当アプリは直結になります。
E · RUNTIME

運用とデバッグ

クライアント設定パネルで最もよく質問されるいくつかのスイッチです。それぞれの意味を理解した上で、トラブル対処のカテゴリに沿って具体的なエラーに対応してください。

運用とデバッグTUN モード
仮想ネットワークアダプタを通じてシステムのネットワーク層で全通信を受け止める動作方式で、システムプロキシ設定を読まないアプリ(コマンドラインツールや一部のゲームクライアント)にも対応できます。有効化には管理者権限またはシステム拡張の許可が必要で、オリジナルコアは追加コンポーネントが必要ですが mihomo コアは標準で内蔵しています。
運用とデバッグシステムプロキシ
プロキシアドレスを OS のネットワーク設定に書き込み、「その設定に従う」アプリの通信を Clash のローカルポートへ渡すスイッチです。ブラウザはほぼ全て準拠しますが、curl や git などのコマンドラインツールは既定で無視するため、別途環境変数の設定や TUN モードへの切り替えが必要になります。
運用とデバッグ混合ポート(Mixed Port)
HTTP と SOCKS5 の両プロトコルを同時に受け付けるローカルリスニングポートで、デフォルト値は 7890 が一般的です。他のソフトウェアで手動プロキシ設定をする際は、アドレスに 127.0.0.1、ポートにこの値を指定すればよく、プロキシの種別を区別する必要はありません。
運用とデバッグログレベル(Log Level)
コアログの詳細度を制御する設定で、低いものから順に silent、error、warning、info、debug となります。接続トラブルの調査時は一時的に info や debug に切り替え、リクエストがどのルールと出口に一致しているかを観察し、原因判明後は元に戻してログファイルの肥大化を防ぎます。
運用とデバッグ自動起動
OS の起動に合わせてクライアントを自動実行するオプションで、通常は「サイレント起動」と併用され、起動後はそのままタスクトレイに常駐します。Windows で TUN モードも同時に有効にしている場合、自動起動は管理者権限でタスクを登録する必要があり、そうしないと仮想ネットワークアダプタの作成に失敗します。
運用とデバッグレイテンシテスト(URL Test)
クライアントが指定したテストアドレスへ HTTP リクエストを送信し、ノードの応答時間を測定する機能です。テスト URL とタイムアウト閾値は設定でカスタマイズできます。url-test 種別のプロキシグループはテスト結果に基づいて最も遅延の低いノードを自動選択します。

次のステップ

用語の確認が済んだら実際の操作へ:クライアントページでプラットフォームに合わせたインストーラーを取得し、チュートリアルページでサブスクリプション導入から接続確認までの一連の流れを試してみましょう。プロトコルとコアの選定比較は技術リファレンスで体系的に解説しています。

クライアントをダウンロード