Clash
Clash ecosystemClashはもともと、ルールに基づいて動作するプロキシカーネルを指す名称です。現在は、Clash互換の設定方式に対応するクライアントのエコシステム全体を指して使われることもあります。「Clash設定に対応」と書かれていても、すべてのクライアントが同じフィールドやプロトコルに対応しているとは限りません。設定エラーを調べる前に、インストーラー名やウィンドウのタイトルだけでなく、実際に動作しているカーネル名を確認してください。
設定用語 / 対応フィールド / 使用上の注意
Clash用語集
設定のテーマから用語を探せます。各項目では概念、対応するフィールド、よくある誤解を解説します。フィールドの説明はmihomoを基準としており、クライアントの画面では名称が異なる場合があります。
カーネルとクライアント
接続を処理するカーネルと、設定を管理する画面を切り分けて、問題がどの層で起きているかを確認しましょう。
mihomo
Core / 旧Clash.Metamihomoは、Clash.Metaを引き継いで開発されたオープンソースのプロキシカーネルです。接続処理、DNS名前解決、プロトコル通信、ルールの実行を担います。単独で動作させることも、GUIクライアントから起動・管理することもできます。設定ドキュメントにあるtunやsnifferなどのフィールドを利用できるかは、カーネルのバージョンと実行プラットフォームを確認してください。
GUIクライアント
GUI clientGUIクライアントは、サブスクリプションの追加、プロキシグループの選択、ログの確認、システム連携などを行うための画面をカーネルに提供します。画面上で変更した設定は、クライアント側でマージしてからカーネルに渡されることがあります。そのため、編集したファイルが最終的に有効な設定とは限りません。クライアントとカーネルのバージョンは別々に記録してください。問い合わせの際は、画面のスクリーンショットだけでなく両方のバージョンを伝えると、原因を特定しやすくなります。
システムプロキシ
System proxyシステムプロキシは、OSのプロキシ設定をクライアントのローカル待ち受けアドレスに向けます。たとえば、ループバックアドレス上のHTTPポートやmixedポートを指定します。この設定に従うアプリだけが通信を送るため、一部のコマンドラインツールやゲームは独自のネットワーク設定を使います。システムプロキシを有効にしても、すべての通信が取り込まれるわけではなく、すべてのDNS問い合わせ経路が自動で変更されるわけでもありません。
遅延テスト
URL test / Delayクライアントは通常、ノード経由で指定されたテスト先にアクセスし、実装に応じてリクエストの所要時間を記録します。ICMP pingと同じとは限りません。テスト先、接続の再利用、タイムアウト設定、テスト時のネットワーク状況が結果に影響します。テスト値が低くても、そのテスト経路の応答が速かったことを示すにすぎません。ダウンロード帯域、動画の通信速度、ほかのサイトへの接続可否を直接判断することはできません。
プロキシプロトコル
プロトコルは、クライアントとプロキシサーバー間の通信方式を定めます。ノードの設定はサーバー側の設定と一致させる必要があります。名称が同じでも、そのまま設定を置き換えられるとは限りません。
プロキシノード
Proxy / proxiesプロキシノードは、プロキシサーバーへの接続に必要な設定のまとまりで、通常はtype、server、port、認証フィールドを含みます。ノードはproxiesに直接定義するか、プロキシプロバイダーから読み込めます。表示名はローカルで参照するための識別子にすぎません。名前に含まれる地域名や倍率だけで、実際の経路、性能、サービス内容を判断しないでください。
HTTPプロキシ
type: http / CONNECTHTTPプロキシは、HTTPプロキシの仕組みでリクエストを中継します。HTTPS接続では通常、CONNECTでトンネルを確立します。設定にあるHTTPプロキシノードはリモートの出口であり、クライアントがローカルで開くHTTP待ち受けポートとは別のものです。接続先がHTTPSでも、クライアントからプロキシサーバーまでの通信が自動的にTLSで保護されるわけではありません。ノードの通信設定を確認してください。
SOCKS5
type: socks5SOCKS5は、TCP接続とUDP転送の仕組みを備えたプロキシプロトコルです。ユーザー名とパスワードによる認証にも対応しています。プロトコル自体に通信を暗号化する機能はないため、「パスワードが必要」というだけで通信が暗号化されているとは限りません。UDPを実際に利用できるかは、アプリが対応する仕組みを使うか、サーバーが対応しているか、ノード設定で機能が有効かによって異なります。
Shadowsocks
type: ssShadowsocksは暗号化に対応したプロキシプロトコルで、mihomoのノード設定ではtype: ssを指定します。サーバーアドレス、ポート、暗号化方式、パスワードを一致させる必要があります。ノード名を変更してもプロトコルは変わりません。プラグインやUDP転送を使う場合は、カーネルの対応状況を確認し、サーバー側と設定を一致させてください。
Trojan
type: trojan / TLS / SNITrojanはTLSで通信を保護するプロキシプロトコルで、ノード設定ではtype: trojanを指定します。接続の成否はパスワードだけでなく、接続先アドレス、SNI、証明書チェーン、通信方式にも左右されます。証明書エラーが発生したら、まずドメイン名、端末の時刻、証明書の状態を確認してください。証明書検証の無効化を通常の対処法にしないでください。
ルールとプロキシグループ
ルールは接続の種類を判定し、プロキシグループは、その接続に最終的に使う出口を決めます。
ルール分岐
mode: rule / rulesルール分岐では、ドメイン、IP、プロセスなどの条件に応じて、接続を直接接続、拒否、プロキシのいずれかに振り分けます。ルールモードでは通常、rulesを上から順に照合し、最初に一致したルールで処理先が決まります。詳細な例外は、広い範囲を対象とするルールより前に配置してください。ルールが参照するプロキシグループ名が実在することも確認しましょう。グローバルモードでは、同じ順序で接続が振り分けられるとは限りません。
プロキシグループ
proxy-groups / select / url-test / fallbackプロキシグループは、複数のノードやほかのプロキシグループをまとめ、ルールから参照できる安定した出口名を提供します。selectは通常、手動選択に使います。url-testはテスト結果に基づいて選択し、fallbackは優先順に利用可能な出口を探します。選択結果はテスト先や各種パラメーターに左右されます。グループ内のノードが利用可能でも、すべてのサービスに接続できるとは限りません。
GeoIP
GEOIP / GeoIP.mmdb / geoip.datGeoIPは、データベースに記録されたIPアドレスの割り当て情報に基づいて照合します。たとえばGEOIP,CN,DIRECTのように指定します。リアルタイムの位置情報ではなく、サイトの言語や運営主体を直接示すものでもありません。CDNのアドレス変更も結果に影響します。実際に使われるデータファイルは、カーネルのデータモードによって異なります。no-resolveを追加する場合は、ドメイン名をきっかけとした名前解決が制限されることも把握しておきましょう。
GeoSite
GEOSITE / geosite.datGeoSiteは、サービスや用途別に整理されたドメインの集合で、GEOSITEルールから参照できます。カテゴリ名と収録範囲はデータソースによって管理されるため、提供元が異なれば同じ分類があるとは限りません。新しいドメインがすぐに反映される保証もありません。GeoSiteはドメインの集合を照合するもので、IPアドレスの割り当て情報を使うGeoIPの代わりにはなりません。更新後はデータの読み込みログを確認してください。
MATCH
MATCH,DIRECTMATCHは追加の条件を指定しないフォールバックルールで、通常はrulesの末尾に置きます。それより前のルールに一致しなかった接続を処理します。接続先にはプロキシグループのほか、DIRECTなどの組み込みポリシーも指定でき、必ずプロキシを使うわけではありません。リストの先頭に置くと、後続の通常ルールは照合されなくなります。ルールを追加する前に、順序を確認することが重要です。
DNSとネットワークスタック
名前解決の経路と接続の経路は別々です。通信が適切に取り込まれているかを判断するには、アプリ、OS、カーネルの設定をあわせて確認してください。
DNS
Domain Name System / dnsDNSはドメイン名をIPアドレスなどのレコードに変換します。mihomoのdnsセクションでは、内蔵名前解決サービスとその上流サーバーを設定します。nameserverを指定しても、すべてのアプリが自動的にそのサーバーを使うわけではありません。OSのリゾルバーやブラウザー内蔵の暗号化DNSが、別の経路を使うこともあります。トラブル時は、どのアプリが問い合わせを行い、どこに送信され、名前解決後の接続がどの経路を通るかをそれぞれ確認してください。
TUNモード
tun / Virtual network interfaceTUNモードは、仮想ネットワークインターフェースを介して、システムのルーティングで転送されたIPパケットを受け取ります。システムプロキシに従わないアプリの通信も、一部取り込める場合があります。追加の権限やネットワークスタック、ルート設定が必要になることが多く、実際の対象範囲は除外ルール、IPv6、ほかのVPNにも左右されます。tun.enableを有効にするだけでなく、ルーティングテーブル、接続ログ、DNSの取り込み状況も確認してください。
Fake-IP
enhanced-mode: fake-ip / fake-ip-filterFake-IPは、ドメイン名の問い合わせに対して合成アドレスを返し、カーネルがそのアドレスとドメイン名の対応を保持する仕組みです。接続がカーネルに届くと、この対応を使ってルール分岐を行います。合成アドレスは接続先サーバーの実際のアドレスではないため、位置情報の判定には使えません。実際の名前解決結果が必要なサービスは、互換性に応じてfake-ip-filterに設定してください。変更後は、古いDNSキャッシュの影響にも注意が必要です。
DNS漏れ
DNS leak / Resolver pathDNS漏れとは、ドメイン名の問い合わせが想定外の経路を通り、意図しないDNSリゾルバーに送られる状態です。確認時は、システムDNS、アプリ内蔵のDoH、IPv6、ネットワーク切り替え後のフォールバック動作も考慮してください。Webサイトから見える出口IPだけでは判断できません。テストページに表示されるリゾルバー名は手がかりにすぎないため、想定した経路やカーネルログと照らし合わせ、繰り返し確認してください。TUNモードが有効だからといって、漏れがないとは限りません。
ドメイン名スニッフィング
sniffer / Host / SNIドメイン名スニッフィングは、HTTPのHostや一部のTLSハンドシェイクに含まれるSNIなど、接続から確認できるプロトコルメタデータを抽出し、IPアドレスしか分からない接続の情報を補います。任意のHTTPS通信を復号する機能ではなく、すべての接続からドメイン名を取得できるわけでもありません。snifferを有効にした後は、プロトコルや接続先ごとに動作を確認してください。DNS設定や正確なルールデータの代わりにはなりません。
サブスクリプションと設定ファイル
完全な設定、ノードの一覧、ルールの一覧を区別すると、適切なインポート方法と更新時に上書きされる内容を判断できます。
サブスクリプション
Subscription URL / Profileサブスクリプションは、URL経由でノードや設定を取得・更新する仕組みであり、プロキシプロトコルではありません。URLの応答は、完全なYAML、エンコードされたノード一覧、その他の形式の場合があります。クライアントに合った方法でインポートしてください。サブスクリプションURLにはアカウントの認証情報が含まれる場合があるため、機密情報として扱いましょう。ログやスクリーンショットを公開する際はURL全体を隠してください。更新に失敗しても、キャッシュ済みのノードがすぐにすべて無効になるとは限りません。
YAML
config.yaml / Mapping / SequenceYAMLはmihomoの設定に使われるデータシリアライズ形式です。マッピングでフィールドの対応関係を表し、リストで項目の集合を表します。インデントによって階層が決まるため、空白を使い、タブと空白を混在させないでください。特殊文字を含む値は、構文に従って引用する必要があります。YAMLパーサーがファイルを読み込めても、書式が正しいことしか確認できません。フィールドの型、プロキシグループ名の参照、カーネルの対応状況も確認してください。
プロキシプロバイダー
proxy-providers / useプロキシプロバイダーはproxy-providersで定義し、リモートまたはローカルのソースからノードの一覧を読み込みます。プロキシグループのuseフィールドから参照します。ノードの更新と、ルールやプロキシグループの構成を分離できるため、ローカルのルール分岐を維持したい場合に便利です。プロバイダーの取得元が、任意の完全な設定ファイルに対応しているとは限りません。トラブル時は、応答内容、キャッシュ先、更新状況、参照名の一致を確認してください。
ルールプロバイダー
rule-providers / RULE-SET / behaviorルールプロバイダーはrule-providersで更新可能なルールセットを読み込み、RULE-SETルールでメインのルール一覧に組み込みます。behaviorはドメイン、IPアドレス範囲、クラシック形式などのデータ種別を指定し、formatはファイル形式を指定します。どちらもデータソースに合わせてください。プロバイダーを定義しただけではルール分岐に使われません。参照する位置と、rules内での順序も確認してください。
上書きとマージ
Override / Merge / Effective configuration上書きとマージは、サブスクリプションの設定を基にローカル設定を維持または追加する処理で、ポートやDNSの変更、ルールの追加などに使われます。動作はクライアントによって異なり、項目全体を置き換える場合もあれば、マージする場合もあります。リストの先頭に追加するか、末尾に追加するかも実装によって異なります。変更後は最終的に有効な設定を確認し、再読み込みしてください。override.yamlはよく使われるファイル名ですが、すべてのクライアントが自動で読み込む共通の設定ファイルではありません。