Clashクライアント
Client applicationサブスクリプションのインポート、プロキシの選択、接続管理を行う画面を備えたアプリです。画面上の操作は通常、設定ファイルの変更やコアへの制御リクエストに反映されます。利用できる機能はクライアントとコアの組み合わせによって異なります。設定項目の場所、上書き方法、バックグラウンドでの動作もクライアントごとに異なるため、あるクライアントのメニュー操作を別のクライアントにそのまま当てはめないでください。
設定項目とネットワークの基礎
Clash用語集
mihomo、サブスクリプション、ルール、TUN、Fake-IPを、設定上の役割から確認できます。画面上の設定、コアの動作、リモートサービスの違いも整理できます。
よく使われる用語を25項目収録しています。カードの見出しから各項目に移動できます。実際の操作はスタートガイドを、設定項目の組み合わせは高度な設定をご覧ください。
コアとクライアント
クライアントは操作画面と設定管理を担い、コアは接続を処理します。機能の違いを調べる際は、両方の対応状況を確認しましょう。
mihomo
Proxy kernelプロキシ接続、ルール判定、DNSリクエストを処理するネットワークプロキシのコアです。以前はClash.Metaという名称が使われていました。GUIクライアントから起動することも、単独で実行することもできます。チュートリアルに記載された設定項目を使えるかどうかは、まず現在のコアが対応しているかで決まります。画面にスイッチがあっても、古いコアがその機能に対応しているとは限りません。
Clash Meta
Clash.Meta / historical project nameClash.Metaはmihomoプロジェクトで以前使われていた名称です。古いチュートリアルや一部クライアントには、今もMetaの表記が残っています。Metaという名前を見かけたら、コアの旧称なのか、特定のクライアント名なのかを区別しましょう。たとえばClash Meta for AndroidはAndroidクライアントの名称です。名前だけで、実際に組み込まれたコアのバージョンや機能範囲を判断することはできません。
外部コントローラー
external-controllerクライアントやコントロールパネルから状態の確認、プロキシの切り替え、接続の管理を行うAPIです。通常、待ち受けアドレスはexternal-controllerで指定します。ブラウザーの通信を中継するプロキシポートとは異なります。自分の端末だけで使う場合はループバックアドレスに限定してください。他の端末からアクセスできるようにする場合は、アクセス認証を設定し、接続元も制限しましょう。
プロキシプロトコル
ローカルアプリがプロキシの入口に接続する方式と、コアがリモートノードに接続する際のプロトコルは、異なる階層の仕組みです。
HTTPプロキシ
HTTP proxy / CONNECTアプリからのリクエストをプロキシサーバーに処理させる方式です。HTTPSサイトへのアクセスでは、通常CONNECTでトンネルを確立します。ローカルのHTTPプロキシ入口と、クライアントからリモートノードへの接続に使うプロキシプロトコルは別物です。たとえばブラウザーからPC上のHTTPプロキシポートに接続し、mihomoがルールに応じて直接接続するか、別のプロトコルでリモートに接続します。
SOCKS5
SOCKS version 5アプリとプロキシの間で接続先を指定するためのプロトコルです。TCPの転送に使えるほか、UDPの転送方式も定義されています。ドメイン名の名前解決がプロキシ経由になるかは、別途確認が必要です。SOCKS5自体には通信を暗号化する機能がありません。また、UDPを実際に転送できるかは、アプリ、ローカルの入口、選択した出力先、ネットワーク環境がすべて対応しているかによります。
Shadowsocks
Encrypted proxy protocol暗号化に対応したプロキシプロトコルです。ノード設定には通常、サーバーアドレス、ポート、暗号方式、パスワードが含まれます。クライアントがサーバー側の暗号方式や拡張機能に対応している必要があります。インポート後に接続できない場合は、ノード名の確認やルールモードの変更だけでなく、暗号方式、認証情報、トランスポート設定を確認してください。
Trojan
TLS-based proxy protocol通常、TLSで暗号化接続を確立するプロキシプロトコルです。サーバーアドレスやパスワードに加え、証明書の検証、サーバー名、トランスポート設定が互いに一致しているか確認しましょう。証明書エラーが発生した場合は、端末の時刻、証明書に対応するドメイン名、サブスクリプションの設定を確認してください。証明書検証の無効化を常用するのは避けましょう。
ルールとプロキシグループ
ルールは接続をどこへ送るかを決め、プロキシグループは具体的な出口を選びます。ルールの順序と参照名の両方が最終的な結果に影響します。
ルールベースの振り分け
Rule-based routing / rulesドメイン、IPアドレス、プロセスなどの条件に応じて、接続にプロキシ、DIRECT、拒否などの出力ポリシーを割り当てます。ルールは通常、上から順に評価され、最初に一致したルールで接続の処理方法が決まります。たとえばDOMAIN-SUFFIX,github.com,Proxyは、設定にProxyというポリシー名があれば、github.comとそのサブドメインをそのポリシーに振り分けます。
プロキシグループ
proxy-groupsノード、ほかのプロキシグループ、組み込みポリシーをまとめ、ルールから参照できる出口名を作ります。selectは手動選択、url-testはテスト結果に基づく選択、fallbackは通常、候補の順に利用可能な出口を選びます。自動選択の結果はテスト先や検出条件によって異なり、すべてのサイトで同じ結果になるとは限りません。
GeoIP
IP geolocation / GEOIPIPアドレスの所在地に基づいて照合するためのデータとルール機能です。判定結果は使用するデータファイルによって異なり、ウェブサイトの運営主体やユーザーの実際の所在地を判断できるものではありません。GEOIP,CN,DIRECTは、その地域のデータに一致した接続先をDIRECTポリシーに振り分ける設定です。CDN、IPアドレスの変更、データ更新の遅れによって判定が変わる場合があります。
ルールセット
rule-providers / RULE-SET複数の条件を独立したファイルにまとめ、rule-providersで設定に取り込みます。rulesではRULE-SETで該当する名前を参照し、一致した場合のポリシーを指定します。ファイルを読み込む際は、内容が指定した形式や動作タイプと一致しているか確認してください。ルールセットの更新はノードサブスクリプションの更新とは異なり、内容も用途も別です。
DIRECT、REJECT、MATCH
Built-in policies / catch-all ruleDIRECTとREJECTは組み込みの出力ポリシーで、それぞれ直接接続と接続拒否を表します。MATCHは残りすべての接続に一致するルールタイプで、MATCH,Proxyのように後ろにポリシーを指定します。通常はルール一覧の末尾に置きます。早い位置に置くと、その後の通常ルールが評価されなくなります。
DNSとネットワークスタック
ドメイン名の名前解決、通信の取り込み、出力先の選択は、連携するように設定する必要があります。スイッチを一つ有効にしただけでは、通信経路全体が変わったとは限りません。
DNS
Domain Name Systemドメイン名をIPアドレスなどのレコードに変換する仕組みです。mihomoのDNSモジュールは、振り分け設定に応じて名前解決の経路を選べます。ただし、モジュールを有効にしても、すべてのアプリがそれを利用するとは限りません。システムのリゾルバー、ブラウザーのセキュアDNS、アプリ内蔵の名前解決では経路が異なる場合があります。調査時は問い合わせ先と、最終的な接続先アドレスの両方を確認しましょう。
Fake-IP
Synthetic address mapping合成IPアドレスを使ってドメイン名と接続の対応関係を保持し、接続を受け取ったコアが本来のドメイン名を復元できるようにします。合成アドレスは接続先サイトの実際のIPアドレスではなく、正しい通信の取り込み経路と組み合わせる必要があります。LAN内の一部サービスや、実際の名前解決結果に依存するアプリでは、fake-ip-filterへの追加が必要な場合があります。ドメイン処理全体を無効にするのではなく、具体的な互換性の問題に応じて設定してください。
TUNモード
Virtual network interface仮想ネットワークインターフェースでIPパケットを受け取る通信取り込み方式です。システムプロキシ設定を参照しない一部のアプリも対象にできます。実際に取り込める範囲は、ルーティング、権限、除外設定、OSの制限によって異なります。グローバルプロキシモードと同じではなく、TUNで取り込んだ接続もルールに従って直接接続、プロキシ経由、拒否に振り分けられます。他のVPNとのルート競合にも注意してください。
DNSリーク
Unexpected DNS resolution pathドメイン名の問い合わせが想定した名前解決経路を通らず、別のDNSサービスに届く状態です。調査時は、システムDNS、ブラウザーのセキュアDNS、アプリ内の名前解決、TUNの取り込み範囲を確認しましょう。検出ページに表示されたDNSサービスの所在地だけでは判断できません。想定したポリシー、接続ログ、IPv6などの迂回経路の有無も合わせて確認してください。
システムプロキシ
Operating system proxy settingsOSがアプリに提供するプロキシサーバーの設定です。この設定に従うアプリは指定された入口に接続を渡しますが、設定を参照しないアプリは直接インターネットに接続する場合があります。そのため、システムプロキシを有効にしても、すべての通信が取り込まれるわけではありません。クライアント終了後にブラウザーが接続できなくなった場合は、システムに終了済みポートを指す設定が残っていないかも確認してください。
ドメインスニッフィング
sniffer / protocol metadata一部の接続のハンドシェイクやプロトコルメタデータから接続先のドメイン名を識別し、ドメインルールの判定に役立てます。取得できる情報は、プロトコル、暗号化方式、クライアントの設定によって異なります。HTTPSの本文を復号する機能ではなく、すべての接続からドメイン名を取得できるとも限りません。有効にした後も、DNSの対応関係や接続ログから実際に適用されたルールを確認してください。
設定とサブスクリプション
サブスクリプションは設定の取得元、YAMLは設定の構造を表し、ローカル上書きは端末ごとの差異を保持します。変更する前に、現在有効な設定ファイルを確認しましょう。
サブスクリプション
Subscription URL / remote profileリモートURLからノード一覧や設定全体を取得・更新する仕組みです。サブスクリプションの応答形式はYAML、エンコードされたノード一覧などさまざまで、URLの見た目だけでは互換性を判断できません。インポートに成功しても、内容を読み込めたことを示すだけで、ノードが利用できるとは限りません。サブスクリプションURLにアクセス情報が含まれる場合があるため、ログやスクリーンショットを共有するときはURL全体を隠してください。
ノード
Proxy endpoint / proxiesリモートプロキシへの接続設定です。通常、サーバー、ポート、プロトコル、認証情報が含まれます。ノード名は単なるラベルであり、実際の所在地や出口の特性、接続品質を示すものではありません。テストに成功しても、すべてのサイトにアクセスできるとは限りません。接続先の制限、名前解決経路、ルールで選ばれたポリシーも結果に影響します。
遅延
Latency / URL testクライアントが指定された方法でリクエストを送り、応答を受け取るまでにかかった時間です。テスト先、DNS、ハンドシェイク、回線状況によって変わり、ダウンロード速度とは異なります。クライアントによってテスト結果の基準が異なるため、単純に比較できない場合があります。テストに失敗した場合も、テスト先に到達できないだけの可能性があります。実際の接続先と接続ログを使ってノードの状態を確認してください。
YAML
YAML / config.yamlインデントで階層を表すテキストデータ形式です。Clashの設定は通常、config.yamlとして保存します。インデントにはスペースを使い、同じ階層のキーをそろえるなど、リスト項目や文字列も形式に沿って記述する必要があります。YAMLとして構文解析できても、各設定項目がコアに対応しているとは限りません。保存後は設定の読み込み結果とエラー箇所を確認しましょう。
ローカル上書き
Profile override / mergeサブスクリプションの元設定に対して、クライアント側で指定項目をマージまたは変更する仕組みです。ローカルのルール、DNS、ポート設定などを保持するのに便利ですが、具体的なマージ方法はクライアントの実装によって異なります。配列は置き換えられる場合も、追加される場合もあります。変更後は最終的に適用された設定を確認し、サブスクリプションの更新やルールの重複で想定した評価順が変わらないようにしましょう。
混合ポート
mixed-portmixed-portで設定するローカルの待ち受け口です。同じポートでHTTPプロキシとSOCKS5接続を受け付けます。外部コントローラーとは役割が異なり、同じ待ち受けアドレスとポートは使用できません。ポートを変更したら、プロキシを手動設定しているアプリも更新してください。他の端末から利用する場合は、待ち受け範囲、LANアクセスの許可、ファイアウォールも確認しましょう。