glossary(7) · 26 entries

Clash 用語集

設定ファイル・クライアント画面・トラブルシューティングログに繰り返し登場する用語を、5つの分類ごとに解説する。各用語カードには個別のアンカーがあり、アドレスバーのリンクをそのまま共有できる。チュートリアルやガイドを読んでいて分からない概念が出てきたら、このページで確認すればよい。

01 / core & clients

コアとクライアント

まず「コア」と「クライアント」の違いを整理しておこう。コアは通信の送受信とルールマッチングを担い、クライアントはコアにグラフィカルインターフェースを被せたものだ。エコシステム内ではこの2つの層がよく混同されるが、切り分けられれば後々のトラブルシューティングが楽になる。

mihomo

コアとクライアント

現在のClashエコシステムにおける主力コアで、コミュニティがClash.Metaを土台に開発を継続している。オリジナルコアと比べ、VLESSやHysteria2といった新しいプロトコルに対応し、より完成度の高いTUN実装とGeosite対応を備える。本サイトのダウンロードページに掲載されているGUIクライアントの多くはmihomoを内蔵しているので、選ぶ際はコアのバージョンを確認するとよい。

Clash(オリジナルコア)

コアとクライアント

Go言語で書かれたルールベースのプロキシコアで、現在まで使われているYAML設定フォーマットを定義した。プロジェクトは2023年に開発が停止している。現在「Clash」と言う場合、多くはこの設定フォーマットを中心に形成されたエコシステム全体を指し、具体的なコアプログラムそのものを指すことは少ない。現役のコアは主にmihomoだ。

GUIクライアント

コアとクライアント

コアの上にグラフィカルインターフェースを被せたデスクトップまたはモバイルアプリ。Clash Verge Rev、Clash Plus、FlClashなどが代表例。サブスクリプション管理、ノード切り替え、システムプロキシとTUNのオン/オフといった操作を担い、実際の通信処理とルールマッチングは下層のコアが行う。トラブルシューティングでは問題がインターフェース層かコア層のどちらにあるかを先に見極める必要がある。

Clash Verge Rev

コアとクライアント

Tauriベースのクロスプラットフォームデスクトップクライアントで、mihomoコアを内蔵し、Windows・macOS・Linux版を提供する。Linux版にはdebとrpmの2種類のパッケージがあり、Debian系とRed Hat系の各ディストリビューションに対応する。Linuxデスクトップ環境での定番の選択肢だ。

ClashX Meta

コアとクライアント

macOS向けのメニューバークライアントで、初期のClashXがMeta系コアに切り替わって進化したもの。シンプルなUIでメニューバーに常駐する。現在プロジェクトの開発は終了しており、既存インストールはそのまま動作するが機能更新は行われない。新規に使う場合は現在も開発が続いているクライアントを選ぶことを勧める。

02 / protocols

プロキシプロトコル

サブスクリプション内の各ノードには対応するプロトコルがある。プロトコルは通信の暗号化・偽装方法を決め、どの世代のコアが必要かも決まる。「未対応のtype」といったエラーが出たら、まずここでプロトコルの分類を確認しよう。

Shadowsocks

プロキシプロトコル

軽量な暗号化プロキシプロトコルで、構造がシンプルかつ動作負荷が低く、エコシステム内で最も早くから広く対応されたプロトコルの一つ。Clash設定ではtypeをssと記述し、暗号化方式にはaes-128-gcmやchacha20-ietf-poly1305がよく使われる。新旧いずれのコアでも利用できる。

VMess

プロキシプロトコル

V2Rayプロジェクトが設計した通信プロトコルで、UUIDによる身元認証を行い、時刻検証機能を持つ。ローカル時刻のズレが大きいと接続に失敗する。WebSocketやgRPCなど複数のトランスポート層と組み合わせられ、さらにTLS暗号化を重ねられるため、組み合わせのパターンが非常に多い。

Trojan

プロキシプロトコル

プロキシ通信を標準的なHTTPSに偽装するプロトコルで、有効な証明書を持つTLS上で動作する必要があり、通常443番ポートを使う。ハンドシェイクから通信まで一般的なWebアクセスと同じ特性を持つため識別されにくい。設定内のsni項目は証明書のドメインと一致させる必要がある。

VLESS

プロキシプロトコル

VMessを軽量化した後継プロトコルで、プロトコル自体の暗号化機能を廃止し、安全性を外部のTLSまたはREALITYに完全に委ねることで負荷を下げている。オリジナルのClashコアはこのプロトコルに対応していないため、サブスクリプションにVLESSノードが含まれる場合はmihomo系コアのクライアントが必須となる。

Hysteria2

プロキシプロトコル

QUICベースのプロキシプロトコルで、パケットロスや高遅延の回線向けに輻輳制御を最適化しており、不安定な回線環境でのスループットに優れる。下層はUDPを使用するため、経路上のファイアウォールで該当ポートを開放する必要がある。こちらもmihomo系コアのみ対応。

03 / rules & routing

ルールと分流

「どの通信をプロキシ経由にし、どれを直結にするか」はルールシステムが決定する。ルールのマッチング順序とプロキシグループの関係を理解することが、「動くだけ」から「使いやすい」への分かれ道になる。

ルール分流(rules)

ルールと分流

設定ファイル内で上から順にマッチングされるルール一覧で、各行は「マッチタイプ,マッチ値,ポリシー」の3要素で構成される。例:DOMAIN-SUFFIX,example.org,PROXY。マッチした時点で処理を終了し、以降のルールは適用されないため順序が重要になる。末尾には通常デフォルトルールとしてMATCHを置く。

プロキシグループ(proxy-groups)

ルールと分流

複数のノードを一つの選択可能なグループにまとめる機能。select(手動選択)、url-test(自動で最速ノードを選択)、fallback(フェイルオーバー)、load-balance(負荷分散)といったタイプがある。ルールの出口は個別ノードではなくプロキシグループを指すことが多く、これによりノードを変更してもルールを書き換えずに済む。

GeoIP

ルールと分流

対象IPの所属地域でマッチングするルールタイプで、クライアント側のローカルGeoIPデータベースに依存する。GEOIP,CN,DIRECTは中国本土のIPを直結させる代表的な書き方。データベースは古くなるため、多くのクライアントの設定に更新機能があり、地域判定がおかしいときはまずこれを更新するとよい。

Geosite

ルールと分流

コミュニティが管理するドメイン分類データベースでマッチングするルールタイプで、1行のルールで一つのカテゴリのサイト全体をカバーできる。例えばGEOSITE,category-ads-allは広告ドメインのブロックによく使われる。mihomoが標準対応しており、GeoIPと併用すれば手書きルールを大幅に減らせる。

rule-providers(ルールセット)

ルールと分流

大量のルールを外部ファイルにまとめ、URLでサブスクライブしてinterval項目で定期更新する仕組み。設定本体にはRULE-SETの一行を記述するだけでよく、数千行のルールを手動管理する手間を省ける。コミュニティが継続更新している公開ルールセットも多数あり、そのまま利用できる。

04 / network & ports

ネットワークとポート

通信がどのようにコアへ入り、ドメイン名がどう解決され、遅延の数値が何を意味するか——この分類は、プロキシ経路上のネットワーク層に関する概念をカバーし、「プロキシを有効にしても効かない」というトラブルシューティングで最もよく確認される部分でもある。

TUNモード

ネットワークとポート

コアが仮想ネットワークカードを作成し、ネットワーク層でシステム全体の通信を横取りする動作モード。システムプロキシの設定に従わないアプリやコマンドラインツールも対象にできる。Linuxでは相応の権限を付与するか、コアを特権モードで実行する必要があり、通常はauto-routeと組み合わせてルーティングテーブルを自動的に引き継がせる。

システムプロキシ

ネットワークとポート

OSレベルで設定されるHTTP/SOCKSプロキシ。クライアントを有効にすると、デスクトップ環境のプロキシ設定がローカルのリスニングポート(例:127.0.0.1:7890)を指すようになる。この設定に自発的に従うアプリのみがプロキシを経由し、ブラウザはほぼ対応しているが、コマンドラインツールの多くは対応していない——これがTUNモードが存在する理由でもある。

Fake-IP

ネットワークとポート

DNSの動作モードの一つで、enhanced-mode項目で制御される。コアはドメイン名の問い合わせに対して予約アドレス帯(デフォルトは198.18.0.0/16)の仮想アドレスを返し、通信到達後は直接ドメイン名でルールをマッチングする。実際のDNS解決を省けるため応答が速く、DNS汚染の影響も受けにくい。実IPに依存する一部のアプリではfake-ip-filterで除外設定が必要。

DNSリーク

ネットワークとポート

プロキシを有効にしても、ドメイン名解決のリクエストがローカルのISPのDNSに送られてしまう現象。アクセス先が露見するだけでなく、解決結果が汚染されて接続異常を引き起こすこともある。Fake-IPを有効にするか、設定のdnsセクションでDoH/DoTなどの暗号化された上位DNSを指定すれば回避できる。

UWPループバック

ネットワークとポート

WindowsのUWPアプリ(ストアアプリ)は標準でローカルループバックアドレス127.0.0.1へのアクセスがシステムによって禁止されているため、ローカルのプロキシポートに接続できない。他のアプリは正常なのにストアアプリだけプロキシを経由しない、という症状として現れる。ループバック除外ツールで個別に許可する必要がある。LinuxとmacOSにはこの制限はない。

ノードの遅延

ネットワークとポート

クライアントがノードに対して1回のHTTP測定(GoogleのGenerate_204アドレスがよく使われる)を行って計測した往復時間で、単位はミリ秒。この数値は接続性と応答速度を示すものであり、ダウンロード帯域幅とは直接関係しない。タイムアウトやエラーは、そのノードが単に「遅い」のではなく現在利用不可であることを意味する。

05 / config fields

設定ファイルの項目

config.yamlのトップレベルにあるいくつかの重要な項目は、コアがどこでリスニングするか、誰が接続できるか、外部パネルからどう制御されるかを決定する。設定を変更する前に、まずどの項目を操作しているのかを確認しよう。

mixed-port

設定ファイルの項目

同一ポートでHTTPとSOCKS5の両方のプロキシプロトコルを同時にリスニングする項目で、よく使われる値は7890。システムプロキシもブラウザ拡張もこのポートを指定すればよく、portとsocks-portを別々に設定する手間を省ける。ポートが競合している場合はここを変更し、システムプロキシの設定も同期して更新する。

allow-lan

設定ファイルの項目

同一LAN内の他デバイスからローカルのプロキシポートへの接続を許可するかどうかを制御する項目。trueに設定してbind-addressと組み合わせれば、同一ネットワーク内のスマートフォンやテレビボックスがこの端末のアドレスとポートを指定するだけでClashプロキシを共有できる。公共のネットワーク環境では必ず無効にしておくこと。

external-controller

設定ファイルの項目

コアが外部に公開するRESTful APIのリスニングアドレスで、通常127.0.0.1:9090に設定される。metacubexdやyacdといったWebパネルはこれを通じてノード一覧の取得、プロキシグループの切り替え、リアルタイム接続の確認を行う。付随するsecret項目はアクセス用のパスワードを設定するもので、ローカル以外のアドレスでリスニングする場合は必ず設定すること。

mode

設定ファイルの項目

動作モードの項目で、rule(ルールに従って分流)、global(すべてプロキシ経由)、direct(すべて直結)の3つの値がある。通常はruleのままでよい。「あるサイトがプロキシを経由すべきかどうか」を調べる際は、一時的にglobalやdirectに切り替えて比較テストを行い、確認できたら元に戻すこと。

YAML

設定ファイルの項目

Clashの設定ファイルが採用するデータ形式で、インデントによって階層を表現する。半角スペースのみ使用可能でタブは使えず、コロンの後には必ず半角スペースを1つ入れる必要がある。サブスクリプションのインポートで「解析失敗」が出る場合、その多くは実はYAMLの構文エラーが原因。エディタのYAML検証機能を使えば、エラー箇所の行番号を素早く特定できる。

用語の先へ

概念を理解したら、次は実践だ。サブスクリプション導入から接続確認までの手順は使い方ガイドを、ルール分流・TUN・日常メンテナンスまで体系的に学びたい場合は上級テクニックを、プラットフォーム別のインストールパッケージはクライアント一覧ページを参照してほしい。