Clash 用語集

初期から使われている軽量な暗号化プロキシプロトコルで、対称鍵暗号を組み込んだ SOCKS5 の派生形とも言える。プロトコル構造が単純でハンドシェイクの負荷が低く、モバイル端末での消費電力も抑えやすい。ほぼすべての Clash 系クライアント・コアが標準対応しており、SS と略される。

V2Ray プロジェクトが設計した暗号化プロトコルで、UUID によるユーザー認証と時刻検証の仕組みを内蔵する。システム時刻に敏感で、端末の時刻が約90秒以上ずれるとハンドシェイクに失敗する――「ノードが全部タイムアウトする」典型的な原因の一つ。WebSocket や TLS などのトランスポートと組み合わせて使われることが多い。

「普通の HTTPS 通信に見せかける」ことを目的としたプロトコルで、実在の TLS 証明書を用いてハンドシェイクを行う。通信の特徴が標準的な Web アクセスに近く、設定項目が少ないため誤設定も起きにくい。サーバー側に有効なドメインと証明書が必要で、ノード設定には必ず SNI フィールドが含まれる。

VMess を軽量化した後継プロトコル。プロトコル内蔵の暗号化レイヤーを廃止し、暗号化を外側の TLS に完全に委ねることで二重暗号化による性能の無駄を避ける。Reality などの新しいトランスポート方式と組み合わせることが多い。Clash 原版コアはこの種のノードを認識できず、mihomo 系コアが必要。

QUIC(UDP)をベースにしたプロキシプロトコルで、独自の輻輳制御アルゴリズムを採用し、パケットロスが多い長距離回線でも高いスループットを発揮する。UDP ポートを使用するため、UDP を制限する学内ネットワークなどでは通信できない場合がある。mihomo などの新しいコアのみ対応。

同じく QUIC をベースとしたプロキシプロトコルで、0-RTT による低ハンドシェイク遅延とネイティブな UDP 転送を強みとし、接続確立の速さが重視される場面に向く。Hysteria2 と同様に新世代のプロトコルであり、TUIC ノードを含むサブスクリプションを取り込む前にクライアントのコアが mihomo 系であることを確認する必要がある。

Clash 生態系の最初のコアプログラムで、現在まで使われる config.yaml の設定形式とルール分流モデルを定義した。上流リポジトリはアーカイブされ更新が停止しており、VLESS や Hysteria2 など新しいプロトコルには対応していない。現存するクライアントの多くは mihomo コアへ移行済み。

Clash Meta プロジェクトを継承した現行の活発なコアで、現在の事実上の標準となっている。原版の設定形式に下位互換を保ちつつ、新プロトコル対応、GEOSITE ドメインデータベース、より完全な TUN 実装を拡張している。Clash Verge Rev や FlClash など主流クライアントに標準搭載されている。

Tauri で構築されたクロスプラットフォームの GUI クライアントで、Windows、macOS、Linux をカバーし mihomo コアを内蔵する。サブスクリプション管理、TUN モードの切り替え、Merge/Script による設定拡張などの機能を備え、デスクトップ環境での定番選択肢となっている。インストーラーは本サイトのクライアントページから入手可能。

コアにグラフィカルなインターフェースを付与したソフトウェアの総称で、サブスクリプションの取り込み、システムプロキシの切り替え、ノード選択といった日常操作を担う。実際の通信転送はコアが担当する。クライアントとコアのバージョンは独立しているため、プロトコル未対応のエラーが出た場合は画面側ではなくコアのバージョンを先に確認すべき。

コアが公開するローカル HTTP 管理インターフェースで、設定項目は external-controller、多くは 127.0.0.1:9090 でリッスンする。クライアント画面や Web パネルはこれを通じて接続一覧の取得、プロキシグループの切り替え、速度テストの実行を行う。ローカルアドレスのみでリッスンしている場合、外部ネットワークには公開されない。

サービス提供者から発行される1本の URL で、クライアントはここから定期的にノードリストや完全な設定を取得する。リンクの期限切れ、トラフィック超過、サーバーが User-Agent を見てリクエストを拒否している場合などは、いずれも「更新失敗」または「更新後にノードが消える」といった症状として現れる。具体的な見分け方はサブスクリプション失効のトラブル対処を参照。

config.yaml のことで、コアの完全な動作定義書。ポート、DNS、ノード(proxies)、プロキシグループ(proxy-groups)、ルール(rules)の順に記述される。クライアントの「サブスクリプション取り込み」の実体は、このファイルをダウンロードまたは生成してコアに読み込ませることに等しい。

インデントで階層関係を表す平文形式のデータフォーマットで、Clash 系の設定はすべてこの形式を採用している。空白の扱いに極めて厳格で、インデントはタブではなくスペースのみを使い、コロンの後には必ず1つのスペースが必要。手動編集で「解析失敗」と表示される場合、ほとんどはこの2点が原因。

あるサブスクリプション形式を別の形式に変換するサービスやツールで、典型的な用途は汎用的な base64 ノードリストを Clash の YAML 構造に変換し、既存のルールテンプレートを併せて適用することである。変換サービスはノード情報を完全に経由するため、公開の変換サイトを利用する際は運営元の信頼性に注意が必要。

設定ファイル内のリソースプロバイダー機構で、proxy-provider(ノード集合)と rule-provider(ルール集合)の2種類に分かれる。ノードやルールを独立した外部ファイルに切り出し、指定した間隔で自動的に更新を取得できるため、複数のサブスクリプションを同時に管理したりコミュニティ製ルールセットを参照したりする場合に適している。

ドメイン、IP、ポート、プロセス名などの条件に基づいて各接続を異なる出口に振り分ける仕組みで、Clash が単純なプロキシツールと一線を画す中核機能。ルールは上から順に照合され、一致した時点で確定する。リスト末尾の MATCH ルールがすべての未マッチ通信を受け止める。

複数のノードをまとめて1つの選択可能なグループとし、ルールの指定先は個々のノードではなくグループとなる。代表的な種類:select(手動選択)、url-test(遅延最小を自動選択)、fallback(フェイルオーバー)、load-balance(負荷分散)。ノードを変える際はグループ内で切り替えるだけでよく、ルールを変更する必要はない。

IP アドレスの所属地域に基づいて照合するルールタイプで、コアに付属する位置情報データベースに依存する。GEOIP,CN,DIRECT は中国本土の IP を直接接続させる典型的な書き方。データベースが古いと所属地の誤判定が起きやすく、クライアントには通常データベース更新の入口が用意されている。

mihomo コアが対応するドメイン分類データベースで、大量のドメインをサイトカテゴリごとに事前にまとめてある。GEOSITE,category-ads-all,REJECT と1行書くだけでカテゴリ全体をカバーできる。DOMAIN ルールを個別に積み重ねるより設定が短く、更新もデータベースの維持者に任せられる。

すべての分流ルールをスキップし、全通信を同一ノードに流す動作モードで、ルールモード(Rule)、直接接続モード(Direct)と並ぶ選択肢。「ノードの問題かルールの問題か」を一時的に見極めたい場合に有用。日常使用ではルールモードを維持し、ローカル通信の無駄な迂回を避けることが推奨される。

組み込みの2つの特殊ポリシー。DIRECT はプロキシを経由せず直接接続すること、REJECT は接続を直接拒否することを表す。広告ドメインを REJECT に、LAN やローカルサイトを DIRECT に振り分けるのが、ほとんどのルールテンプレートに共通する定石。

利用可能なリモートプロキシサーバーの1件のレコードで、サーバーアドレス、ポート、プロトコル種別、認証情報を含む。サブスクリプション内の各行のプロキシ設定が1つのノードにあたる。ノード自体はサービス提供者が維持し、クライアントはプロキシグループに従って出口を選び通信を転送するだけ。

クライアントが指定のテストアドレス(Google の generate_204 が一般的)にリクエストを送り、応答にかかった時間をミリ秒単位で計測してノードの応答速度を示す指標。値はあくまで往復時間を反映するもので、ダウンロード帯域とは異なる。全ノードが同時にタイムアウトする場合は、まず近い順のチェックに従ってローカルネットワークとシステム時刻を確認する。

OS レベルで登録される HTTP/SOCKS プロキシの入り口で、システム設定に従うブラウザなどのアプリケーションは自動的にこれを経由して転送される。一部のコマンドラインツールやゲームクライアントはこの設定を読み取らず、それらの通信はプロキシに入らない――こうしたアプリには TUN モードによる捕捉が必要。

仮想ネットワークアダプタを作成し、ネットワーク層でデバイスの全通信を捕捉するモード。システムプロキシに従わないアプリケーションもカバーできる。有効化には管理者権限やシステム拡張の許可が必要で、Windows では通常サービスコンポーネントの事前インストールが、macOS ではネットワーク拡張の許可ポップアップが表示される。

コアの DNS 応答方式の一種で、まず予約アドレス帯(例:198.18.0.0/16)内の仮想 IP を返してアプリに即座に接続を確立させ、転送時に本来のドメイン名に復元する。実際の名前解決を待つ時間を省け、ドメインによる分流にも有利だが、実 IP に依存するアプリ(一部の LAN 探索サービスなど)は fake-ip-filter による例外指定が必要になる。

ドメイン名の解決リクエストがプロキシを経由せず、ローカルの ISP の DNS へ直接送られてしまう現象――通信自体はプロキシを経由していても、アクセスしたドメインが解決側に記録されてしまう。コアの DNS 処理(dns.enable: true)や TUN モードを有効にし、システムのネットワークアダプタの DNS 設定を確認することで、こうしたリークを防げる。

各プロキシプロトコルの誕生背景、速度とリソース消費の比較、コア系統の関係、シーン別の選び方をまとめている。プロトコル解説を見る →

サブスクリプションの取り込みから接続確認までの手順を段階的に解説。用語集の各項目はガイド内の具体的な画面操作に対応している。ガイドを見る →

基礎知識、インストールと設定、使い方のコツ、トラブル対処の4カテゴリでまとめた Q&A 集。FAQ を見る →