Clash
ClashClashはもともと、ルールに基づいてネットワーク通信を処理するプロキシコアを指す名称です。現在は設定形式やクライアントのエコシステム全体を指す場合もあります。オリジナルのプロジェクトと後続のフォークは運営主体が異なり、似た名称でも機能が完全に同じとは限りません。ガイドを読む際は、名称だけで互換性を判断せず、対象のクライアント、コア、設定が作成された時期も確認してください。
クライアントごとの違いを確認用語集 / 25項目
Clash用語集
コア、接続、ルール、設定ファイルに関する用語を整理します。
用語を分野ごとに確認できます。英語名はクライアントの画面、ログ、YAMLフィールドとの照合に役立ちます。各項目には個別のアンカーがあり、保存や共有に利用できます。フィールドの対応状況は、実際に搭載されているコアとバージョンによって異なります。具体的な操作は入門ガイド、パラメーターの詳細はYAMLハンドブックを参照してください。
Kernel / Client
コアとクライアント
通信を処理するコア、操作画面を提供するクライアント、アプリの通信を取り込む方法を区別しましょう。
mihomo
mihomo / Clash Metamihomoは、Clash Metaの系譜を継ぐオープンソースのプロキシコアです。プロキシ接続、ルール照合、DNSなどの基盤処理を担います。GUIの名称ではなく、同じGUIクライアントでもコアを切り替えられる場合があります。フィールドを利用できるかどうかは、クライアントの製品名ではなく、現在動作しているコアとバージョンで確認してください。
コアの設定構造を確認GUIクライアント
Graphical User Interface / GUIGUIクライアントは、設定のインポートやプロキシグループの選択、接続状況の確認、ログの閲覧などを行う画面を提供し、操作をコアへの設定や制御リクエストに変換します。システムプロキシ、バックグラウンドサービス、設定オーバーライドを管理することもあるため、画面上の設定をそのままYAMLのフィールドと見なすことはできません。同じコアを搭載していても、設定の保存先や更新方法はクライアントごとに異なる場合があります。
クライアントの選び方を確認外部コントローラー
external-controller外部コントローラーを使うと、GUIや管理パネルからコアの状態確認、プロキシグループの切り替え、接続状況の閲覧ができます。これは管理用のインターフェースであり、ブラウザーなどのアプリがプロキシに接続するための通信ポートではありません。管理機能を信頼できないネットワークに公開しないよう、待ち受け範囲を制限して認証を設定してください。画面からコアに接続できない場合は、インターフェースのアドレスと認証設定が一致しているか確認しましょう。
共通設定フィールドを確認システムプロキシ
System Proxyシステムプロキシは、OSがアプリに提供するプロキシサーバーの設定で、すべての通信を強制的に経由させるものではありません。この設定に従うアプリだけが指定のプロキシポートに接続します。独自に通信するアプリは個別設定が必要な場合があり、TUNの利用も選択肢です。有効にした後は、アドレスとポートが現在のコアに対応しているか確認してください。クライアントを終了した後も、使われなくなったプロキシ設定がOSに残っていないか確認しましょう。
接続設定と確認手順を見るProtocol / Transport
プロトコルとトランスポート
ノードは接続パラメーターの集合です。プロキシプロトコル、トランスポート方式、暗号化ハンドシェイクは、それぞれ異なる処理を定めます。
プロキシノード
Proxy Node / proxiesプロキシノードは、接続先と認証方式を記述するパラメーターの集合で、通常はプロトコル、サーバーアドレス、ポート、認証情報を含みます。ノード名は画面表示やプロキシグループからの参照に使うもので、名前に含まれる地域名だけでは実際の出口の所在地を証明できません。接続に失敗した場合は、ノード名を変えたり同じ設定を再インポートしたりするだけでなく、すべてのパラメーターと接続先サーバーの状態を確認してください。
プロキシノードのフィールドを確認プロキシプロトコル
Proxy Protocol / typeプロキシプロトコルは、Shadowsocks、VMess、VLESS、Trojanなど、クライアントとサーバー間の認証、データのカプセル化、転送方法を定めます。トランスポートとは別のレイヤーにあり、同じプロトコルでも異なるトランスポートを組み合わせる場合があります。ノードの type と認証フィールドは、対応するプロトコルの要件に合わせる必要があります。type名を書き換えるだけでプロトコルを変換することはできません。
トランスポート方式
Transport / networkトランスポート方式は、プロキシプロトコルのデータを運ぶ接続形式です。TCP、WebSocket、gRPCなどがあり、パス、リクエストヘッダー、サービス名などのパラメーターはサーバー側と一致させる必要があります。すべてのプロキシプロトコルが、すべてのトランスポート方式に対応しているわけではありません。設定を移行するときにサーバー情報と認証情報だけを残し、トランスポート設定を引き継がないと、ハンドシェイク失敗やタイムアウトが起きることがあります。
トランスポート関連の設定を確認TLS
Transport Layer SecurityTLSは通信を暗号化し、接続相手の身元を確認します。証明書の検証やサーバー名の設定は、ハンドシェイクの成否に影響します。接続先のアドレスと、ハンドシェイクに使うサーバー名が異なる場合もあるため、サーバー側の指定に従って設定し、任意に置き換えないでください。証明書検証を無効にすると相手の確認が弱まるため、接続エラーへの一般的な対処として使うべきではありません。システム時刻と証明書の対象ドメインも確認しましょう。
TLS設定の前提を確認遅延とタイムアウト
Latency / Timeoutクライアントの遅延テストは通常、特定の出口からテスト用アドレスへリクエストしたときの所要時間を測ります。ICMP pingやダウンロード速度とは異なります。テスト先、ネットワーク経路、ハンドシェイク、タイムアウトのしきい値によって結果は変わり、クライアント間の数値をそのまま比較できるとは限りません。タイムアウトは制限時間内にテストが完了しなかったことを示すだけです。ログと実際のアクセス結果も確認しながら、原因を順に切り分けてください。
接続トラブルのQ&Aを見るPolicy / Rules
プロキシグループとルール
ルールは接続の振り分け先を決め、プロキシグループは出口を選びます。モードによって、ルールを使うかどうかが決まります。
プロキシグループ
proxy-groupsプロキシグループはノードや別のプロキシグループをまとめ、グループの種類に応じて接続先を選びます。手動選択の select と、自動で遅延を測定する url-test では選択方法が異なり、画面に表示される現在のノードが固定されるとは限りません。ルールからグループ名を指定すれば、通信の振り分けと出口の選択を分けて管理できます。参照先の名前は定義と一致させてください。
ルール分岐
Rule-based Routing / rulesルール分岐では、ドメイン名、宛先IP、プロセスなどの条件に基づいて、接続の処理方法を選びます。ルールは通常、上から順に照合され、最初に一致したものが適用されます。そのため、個別ルールは適切な位置に置き、MATCHなどのフォールバックルールは通常、末尾に配置します。振り分け結果を調べるときは、Webサイト名から推測するのではなく、実際に一致したルールと最終的なポリシーを確認してください。
動作モード
mode / rule / global / direct動作モードは、コアがルール、グローバル、ダイレクトなど、どの基本方式で通信を処理するかを決めます。ルールモードではルールに従ってプロキシグループを選び、グローバルモードでは全体に適用するプロキシグループを使います。ダイレクトモードは直接接続が基本です。グローバルモードでも、すべてのアプリの通信がコアに取り込まれるわけではありません。通信が取り込まれるかどうかは、システムプロキシ、アプリの設定、TUNのルーティングによって異なります。
モードの選択手順を見るGeoIP
GeoIP / GEOIPGeoIPデータはIPアドレスを国や地域などに分類し、IP関連ルールの照合に利用できます。データベースの更新、アドレスの割り当て、コンテンツ配信ネットワークなどにより結果は変わるため、Webサイトの運営主体の所在地を正確に示すものではありません。ドメインルールとGeoIPルールで分類結果が異なる場合があります。どのルールに一致したかは、ルールの順序、実際に名前解決されたIPアドレス、データベースの提供元を踏まえて確認してください。
IP関連ルールを確認ルールセット
rule-providers / RULE-SETルールセットは複数の条件をまとめて管理する仕組みです。取得元を rule-providers で定義し、RULE-SETルールから参照します。ノードのサブスクとは別物なので、URLをそのまま相互に使うことはできません。内容、形式、照合方法が定義と一致している必要があります。ルールセットを参照しても、上から順に照合する仕組みは変わらず、リスト内で先に一致したルールが優先されます。
DNS / Network Stack
DNSとネットワークスタック
名前解決の経路と通信の経路は、それぞれ個別に確認してください。設定を一つ有効にしても、すべてのアプリが同じ経路を使うとは限りません。
DNS名前解決
Domain Name System / dnsDNS名前解決は、ドメイン名をIPアドレスなどのレコードに変換し、接続先や一部のルール照合に影響します。コア、アプリ、OSそれぞれの名前解決が併存する場合があるため、まず実際のリクエストがどの経路を通るか確認してください。DNSサーバーを変更しても通信の出口が変わるとは限らず、ある層のキャッシュを消しても、アプリ、OS、コアのキャッシュがすべて更新されるわけではありません。
DNSフィールドを確認Fake-IP
enhanced-mode: fake-ipFake-IPモードでは、アプリにマッピング用の仮想IPアドレスを返し、コアが対応関係からドメイン名を復元して接続を処理します。この仮想アドレスは実際の接続先ではないため、OSの名前解決結果だけでは最終的な接続先を判断できません。実IPでの名前解決に依存するアプリでは例外ルールが必要な場合があります。名前解決モードを切り替えた後は、アプリのキャッシュや既存の接続が以前のアドレスを使い続けていないか確認してください。
名前解決モードの説明を見るDNSリーク
DNS LeakDNSリークとは通常、ドメイン名の問い合わせが想定した名前解決経路から外れ、意図しないDNSサーバーやローカルネットワークに送られることです。判定には出口IPだけでなく、アプリ、OS、IPv6、コアの設定も確認してください。テストページに表示されるDNSサーバーの所在地は手掛かりにすぎません。ブラウザーの暗号化DNS、OSのフォールバック、プロキシサーバーのドメイン名解決など、経路ごとに確認が必要です。
DNS設定が適用される範囲を確認TUNモード
TUN / Virtual Network InterfaceTUNモードは仮想ネットワークインターフェースとルーティングルールを使い、IP通信をコアに渡して処理します。システムプロキシに従わない一部のアプリも対象にできます。実際に取り込まれる通信の範囲は、ルート、権限、除外設定、ほかのネットワークソフトとの相互作用によって異なります。有効にした後に通信できなくなった場合は、仮想インターフェース、デフォルトルート、DNSの取り込み状況を確認してください。原因を追えるよう、複数の設定を同時に変更するのは避けましょう。
TUN設定を確認スニッフィング
sniffer / Domain Sniffingスニッフィングは、TLSハンドシェイクのサーバー名など、接続開始時のデータからドメイン名の手掛かりを取得し、ルール照合に役立てる機能です。暗号化された本文を復号するものではなく、取得できる情報はプロトコルやハンドシェイクの暗号化方式によって制限されます。有効にしても、すべての接続からドメイン名を取得できるとは限りません。接続の詳細で取得結果を確認し、必要に応じて特定の通信を例外に設定してください。
ネットワーク関連フィールドを確認Subscription / Configuration
サブスクと設定ファイル
リモートの配信元、テキスト形式、クライアントのプロファイル、最終的な実行設定を区別すると、変更がどこに反映されるか判断しやすくなります。
サブスク
Subscriptionサブスクは通常、URLからノードや設定を取得し、定期的に更新する仕組みです。配信元によって、完全なYAML、ノード一覧、エンコードされたノードリンクなどが返されます。サブスクURLに認証情報が含まれる場合があるため、公開したり公開ログに貼り付けたりしないでください。インポート前にクライアントが形式に対応しているか確認しましょう。内容を取得できても、すべてのノードに接続できるとは限りません。
サブスクのインポート手順を見るYAML
YAML / Mapping / SequenceYAMLは、マッピング、リスト、スカラー値などを記述するテキスト形式です。Clashの設定もYAMLで記述します。インデントにはスペースを使い、同じ階層では統一してください。特殊文字を含む文字列は、構文に従って適切に引用します。構文が正しくても、フィールド名やデータ型、ノードとプロキシグループ間の参照がコアの要件を満たしているとは限りません。
YAMLの構造を確認設定プロファイル
Profile設定プロファイルは、クライアントが管理するローカルまたはリモートの設定情報で、複数の設定を切り替える際に使います。エディター内の内容、クライアントによるマージ結果、コアが実際に読み込んだ内容は異なる場合があり、ファイルを保存しても再読み込みされているとは限りません。変更が反映されたか判断するには、有効なプロファイル、実行ログ、クライアントの最終設定表示を確認してください。
設定を有効にする手順を見るプロキシプロバイダー
proxy-providersプロキシプロバイダーは proxy-providers で独立したノード一覧を読み込み、プロキシグループから参照する仕組みです。ノードの更新とローカルルールを分けて管理できます。ネットワークサービスを提供する事業者そのものを指すわけではありません。プロバイダーファイルは完全な設定ファイルとは構造が異なります。DNSやルールなどのトップレベルフィールドを含むサブスクを、そのままノード一覧として使えるとは限りません。
設定オーバーライド
Override / Merge設定オーバーライドは、ベース設定にローカル設定を追加、置換、またはマージする仕組みです。通常はクライアントが読み込み前に処理し、DNSやルールの変更を個別に保持する用途にも使えます。リスト、同名フィールド、処理順序の扱いはクライアントによって異なるため、すべての内容が保持されるとは限りません。変更後は最終的な設定を確認し、サブスクを更新する前に変更が独立したオーバーライドに保存されているか確認してください。
オーバーライドとマージの説明を見る