設定リファレンス / 用語集

Clash用語集

カーネル、プロトコル、ルール、サブスクリプションに関する用語を解説します。設定シーンごとに意味を確認し、画面上の項目、接続パラメーター、実際の適用範囲を区別できます。

初めて設定する場合は使い方ガイドを、プロトコルやカーネルの機能を比較する場合はプロトコルリファレンスをご覧ください。各用語の見出しからリンクをコピーして、解説へ直接移動できます。

CORE / CLIENT

カーネルとクライアント

まず、接続を処理するものを特定し、次に設定がどの層に作用するかを確認します。クライアント名とカーネル名は同じ意味ではありません。

mihomo

Proxy core

Clash Metaプロジェクトを引き継ぐプロキシカーネルで、接続処理、ルール照合、DNS、各種プロトコルを担います。GUIクライアントは設定ファイルや制御インターフェースを通じてカーネルを操作します。ウィンドウのレイアウトはカーネルの機能ではありません。設定項目が使えるかどうかは、クライアント名だけでなく、実行中のカーネルのバージョンとドキュメントで確認してください。

Clash Meta

Historical project name

mihomoプロジェクトの旧称で、一部のクライアントやサブスクリプションの説明、古いチュートリアルでも使われています。Meta設定とは一般に、このカーネル系統の拡張機能を使うClash形式のYAMLを指し、独立したファイル形式ではありません。オリジナルのカーネルでは新しいプロトコルやフィールドを認識できないことがあるため、移行時に互換性を確認してください。

GUIクライアント

Graphical user interface · GUI

サブスクリプションの読み込み、プロキシグループの選択、システム設定、ログ確認などの画面を備えたアプリです。Clash Verge Revなどが該当します。クライアントは操作をカーネル設定に反映するほか、サービス権限、起動タスク、設定の上書きを管理することもあります。画面に項目が表示されていても、OS、カーネルのバージョン、権限などの利用条件を満たしているとは限りません。

OSのプロキシ設定をクライアントのローカル待ち受けアドレスに向け、システムプロキシに対応したアプリの通信をカーネルに転送します。システム全体の通信をすべて処理する共通の入口ではありません。コマンドラインツール、ゲーム、独自のネットワーク処理を行うアプリなどは、この設定を無視することがあります。アプリがプロキシを経由しない場合は、まずそのアプリのプロキシ対応状況を確認し、必要に応じて個別設定やTUNによる通信制御を検討してください。

TUNモード

Virtual network interface

仮想ネットワークインターフェースでIPパケットを受け取り、カーネルで接続処理や通信分岐を行う方式です。システムプロキシを使わない一部のアプリにも適用できますが、範囲はルーティング、除外設定、権限、DNS設定に左右されます。有効にした後はサービスの状態と通信先を確認してください。スイッチがオンになっているだけでは、通信がカーネルに入ったとは確認できません。

TRANSPORT / AUTHENTICATION

プロキシプロトコル

プロトコルによってクライアントとサーバー間の通信方式が決まります。アドレス、認証情報、トランスポート層、セキュリティ層を一式で合わせる必要があります。プロトコル名だけで速度は判断できません。

Shadowsocks

Shadowsocks · SS

一般にSSと略される暗号化プロキシプロトコルです。通常、サーバーアドレス、ポート、暗号化方式、パスワードを設定します。クライアントとサーバーで互換性のある方式を使う必要があり、どちらもShadowsocksと書かれていても、任意のパラメーターが使えるとは限りません。追加プラグインや特定のプロトコルバージョンが指定されている場合は、現在のカーネルが対応しているか確認してください。

VMess

VMess protocol

V2Rayエコシステム由来のプロキシプロトコルで、UUIDなどのパラメーターでユーザーを識別します。システム時刻が大きくずれていると、認証に影響することがあります。VMessはプロトコルの種類で、WebSocketなどは通信トランスポートです。両者は置き換えられる選択肢ではありません。インポート後にハンドシェイクに失敗する場合は、認証情報、トランスポート経路、TLS設定、端末の時刻を個別に確認してください。

VLESS

VLESS protocol

V2Rayエコシステム由来の軽量プロキシプロトコルで、ペイロード自体は暗号化しません。実際の運用では通常、TLSやREALITYなどのセキュリティ層を組み合わせます。UUIDは設定の一部にすぎず、通信方式、サーバー名、関連するセキュリティパラメーターも一致させる必要があります。特定の通信方式やセキュリティ層への対応を、あらゆるVLESS設定に対応しているという意味に捉えないでください。

Trojan

TLS-based proxy protocol

通常はTLSで通信を保護し、パスワードで認証するプロキシプロトコルです。接続の問題を調べる際は、サーバーアドレス、パスワード、サーバー名、証明書の信頼性を個別に確認してください。ポート番号だけでは設定の正否を判断できません。証明書エラーが出た場合は、ドメイン名、システム時刻、証明書チェーンを確認し、証明書検証のスキップを常用しないでください。

Hysteria2

QUIC-based proxy protocol

QUICベースのプロキシプロトコルで、下位層にUDPを使用します。利用の適否はネットワークのUDP対応状況、パケットロス、サーバー設定に左右されます。設定中の帯域幅パラメーターは通信動作に関わる値であり、実際のダウンロード速度を保証しません。ネットワークでUDPが制限されている場合、認証情報が正しくても接続できないことがあります。まずネットワーク経路と設定値のどちらに問題があるか切り分けてください。

TUIC

QUIC-based proxy protocol

QUICベースのプロキシプロトコルで、コネクションの多重化やUDP転送などに対応します。プロトコルのバージョンによって認証項目や実装の詳細が異なる場合があるため、プロトコル名だけを変更するのではなく、サーバーから提示されたパラメーター一式を使ってください。モバイル端末の電池消費は、接続の稼働状況、ネットワークの切り替え、アプリの動作にも左右されます。TUICなどのプロトコル名だけで一律に比較することはできません。

RULES / POLICY

ルールと通信分岐

ルールが通信に適用するポリシーを選び、プロキシグループが接続先を選びます。この2つの関係を理解すると、ノードを切り替えたときにどの接続が変わるか判断できます。

ルールによる通信分岐

Rule-based routing

ルールモードでは、宛先ドメインやIPアドレスなどの条件に応じて、接続に適用するポリシーを決めます。ルールは上から順に照合され、通常は最初に一致した時点で処理が決まるため、具体的な例外を広い条件より前に配置してください。たとえばDOMAIN-SUFFIX,github.com,Proxyは、設定にProxyというポリシーが存在する場合、該当するドメインをそのポリシーに渡します。

プロキシグループ

Proxy group

プロキシノード、ほかのプロキシグループ、組み込みポリシーなどをまとめたもので、ルールから参照する接続先です。selectは手動選択、url-testはテスト結果に基づく選択、fallbackは利用可否と設定順に応じた選択に使います。グループ内の選択を切り替えると、通常は新しい接続に影響します。既存の長時間接続は元の出口を使い続けることがあり、既存接続が閉じられるかどうかはクライアントの操作によって異なります。

プロキシノード

Proxy endpoint

クライアントで、プロキシサーバーへの接続情報をまとめたものを指す一般的な呼び方です。通常、アドレス、ポート、プロトコル、認証情報が含まれます。表示名は識別用のラベルにすぎず、サーバーの所在地、回線品質、利用範囲を証明するものではありません。ノードのテストに成功しても、すべての通信で使われるとは限りません。実際の出口は、現在のモード、適用されたルール、プロキシグループの選択を確認してください。

GeoIP

IP geolocation matching

IPデータベースを使い、国や地域のコードで宛先を判定するルール機能です。たとえばGEOIP,CN,DIRECTのように記述します。判定結果はデータベースの内容に依存し、企業の登記地、ユーザーの所在地を示すものではありません。宛先がドメイン名の場合、判定に名前解決が関わることがあります。no-resolve付きのルールでは、照合のために積極的な名前解決を行わないよう制限されます。

MATCH

Final catch-all rule

一致条件を指定しないフォールバックルールで、それ以前のルールに一致しなかった通信を処理します。たとえばMATCH,Proxyのように記述します。通常はrulesリストの末尾に置きます。前のほうに置くと、後続ルールには残りの通信が渡りません。フォールバック先にはプロキシグループや組み込みポリシーを指定でき、具体的な意味は設定内で使われている名前によって決まります。

遅延テスト

URL latency test

ノード経由で指定のテスト先に接続し、所要時間を測る方法です。通常、サーバーに対するICMPテストではありません。結果はテスト先、コネクションの再利用、DNS、現在のネットワーク状況に左右され、ファイルのダウンロード速度とは異なります。1回テストに成功しても、そのときの経路が使えたことを示すだけです。他のサイト、UDPアプリ、以降の接続でも同じ結果になるとは限りません。

DNS / NETWORK STACK

DNSとネットワークスタック

ドメイン名の解決と接続の転送は、関連していても別の処理です。問題を調べる際は、システム、ブラウザー、カーネルを確認し、1つのスイッチだけで判断しないでください。

DNS

Domain Name System

ドメイン名をIPアドレスなどのレコードに変換するシステムで、多くのネットワーク接続を確立する前に行われる処理です。カーネルが処理するDNS、OSのリゾルバー、ブラウザーのセキュアDNSは異なる経路を使うことがあります。そのため、カーネルのDNSサーバーを設定しても、すべてのアプリの問い合わせが自動的に切り替わるわけではありません。ドメイン名では接続できず、IPアドレスへの直接接続は成功する場合、名前解決の結果、キャッシュ、ログを確認してください。

Fake-IP

Synthetic IP mapping

ドメイン名に仮想アドレスを返し、カーネル内にドメイン名とアドレスの対応関係を保存するDNS方式です。その後の通信がカーネルに入ると、この対応関係を利用して元のドメイン名を特定できます。仮想アドレスは実際のWebサーバーのアドレスではありません。実際の名前解決結果に依存する一部のアプリでは、fake-ip-filterに例外を追加する必要があります。対象の項目は、実際に起きている問題を確認して決めてください。

DNSリーク

DNS leak

DNS問い合わせが想定した経路を通らず、別のリゾルバーに届く現象です。想定から外れているか判断するには、まず設定で実現したい名前解決のポリシーを明確にしてください。システムDNS、ブラウザーのセキュアDNS、IPv6、通信制御の設定、実際の問い合わせ記録をあわせて確認します。テストサイトに表示されたリゾルバーの地域は手がかりの1つにすぎず、それだけでは結論を出せません。直接名前解決する設定が意図どおりの場合もあります。

ドメインスニッフィング

Domain sniffing

HTTP HostやTLS SNIなどの接続メタデータから、宛先ドメイン名を推定する機能です。もともとIPアドレスしか含まない接続を、ドメインルールの照合対象にできる場合があります。HTTPSの本文を復号する機能ではなく、すべてのプロトコルや暗号化方式でドメイン名を取得できるわけでもありません。利用の必要性や適用範囲は、DNSモード、設定範囲、互換性の要件に応じて判断してください。

SUBSCRIPTION / CONFIGURATION

サブスクリプションと設定ファイル

設定全体、ノードの集合、ルールの集合は、それぞれ異なる入力です。インポート前にファイルの構造を確認し、更新後は実際に有効な内容を確かめてください。