設定項目・概念の違い・参照先

Clashの用語解説

Clashをダウンロード使い方を見る

設定項目の階層ごとに用語を確認できます。まずクライアントとカーネルを区別し、設定、ルール、通信の取り込み、DNSを理解しましょう。各用語の見出し横にあるアンカーから、個別に共有できます。

設定の取得元通信の取り込み方接続の出先

CORE / PROTOCOL

カーネルとプロトコル

クライアントの画面、カーネルの機能、リモートサーバーにはそれぞれ役割の違いがあります。「未対応のプロトコル」と表示されたら、まず実際に動作しているカーネルを確認してください。

mihomo: core · mihomomihomoは、Clash Metaの後継で使われるカーネル名です。プロキシプロトコル、ルール判定、DNS、接続処理を担います。Clash Verge RevなどのGUIクライアントはカーネルを操作する画面を提供しますが、両者は別のプロジェクトです。設定項目を確認するときは、クライアント名だけでなく、現在のカーネルのバージョンを参照してください。

クライアントとカーネル: GUI / coreクライアントはサブスクリプション管理、トレイメニュー、システムプロキシ、設定画面を担当し、カーネルは通信を処理します。画面上のスイッチは、設定を生成する場合もあれば、システムサービスを呼び出す場合もあります。問題を調べる際は、クライアント名とカーネル情報を分けて記録すると、画面上の動作をカーネルの制限と取り違えずに済みます。

プロキシノード: proxiesノードはプロキシサーバーへの接続設定で、通常、サーバーアドレス、ポート、プロトコル、認証情報を含みます。ノード名は単なるラベルであり、出口の場所、帯域、利用できるサービスを名前だけで判断することはできません。ノードの利用可否は、接続ログ、接続先サイト、サーバーの状態をあわせて確認してください。

プロキシプロトコル: type · Shadowsocks / VMess / Trojanプロキシプロトコルは、クライアントとプロキシサーバー間のデータ交換方法を定めます。ノードのtypeでプロトコルの種類を指定します。プロトコル、トランスポート方式、TLSは別々の設定項目で、ひとつを指定してもほかの設定の代わりにはなりません。インポートに失敗した場合は、カーネルの対応状況とサーバーから提供された設定一式を確認してください。

ノードの遅延: URL test · timeoutクライアントに表示される遅延は、通常、ノード経由でテスト先にアクセスするまでの時間です。単純なICMPの往復時間とは限りません。テスト先、接続時のハンドシェイク、ネットワーク経路によって結果は変わり、遅延が小さくてもダウンロードが速いとは限りません。タイムアウトは、そのテストが制限時間内に完了しなかったことを示します。判定方法は遅延テストの手順をご覧ください。

PROFILE / STRUCTURE

設定ファイルの構造

まず現在有効なProfileを確認し、サブスクリプション更新とローカル変更がどのようにマージされるかを確認しましょう。

Profile設定ファイル: config.yaml · ProfileProfileはカーネルが読み込む完全な設定ファイルです。一般的に、プロキシの定義、プロキシグループ、ルール、DNS設定が含まれます。クライアントには複数のProfileを保存できますが、実際の動作は通常、選択中の設定と適用された上書き内容に基づきます。切り替え後は、一覧の選択状態だけでなく、プロキシグループやルールも変わっているか確認してください。

YAML: mapping · sequence · indentationYAMLはClash設定でよく使われるデータ形式です。インデントで階層を表し、ハイフンでリスト項目を示します。インデントにはスペースを使い、同じ階層の項目は位置をそろえます。特殊文字を含む文字列は引用符で囲むと安全です。保存前にキーの重複、真偽値、リストの位置を確認しましょう。構文を解析できても、項目の意味が正しいとは限りません。

サブスクリプション: remote profile · update intervalサブスクリプションはリモートURLからノードや設定を取得・更新する仕組みです。返される内容は、完全なProfileの場合もノード一覧のみの場合もあります。更新間隔は次回の取得時期を決めるもので、ノードが常時利用できることを保証するものではありません。サブスクリプションURLにはアカウントへのアクセス情報が含まれる場合があります。ログやスクリーンショットを共有する前に、該当するURLを削除してください。

プロキシプロバイダー: proxy-providers · useproxy-providersでノードの取得元を個別に定義し、プロキシグループからuseでプロバイダー名を参照します。これにより、ローカルのプロキシグループやルール構成を保ったまま、ノード一覧を更新できます。プロバイダーファイルと完全なProfileでは構造が異なります。完全なサブスクリプションをプロバイダーのURLに指定する前に、返される形式が一致するか確認してください。

ローカル上書き: override · merge · patchローカル上書きは、リモート設定に変更を加えて保持する仕組みです。ポート、DNS、独自ルールの設定などに使われます。サブスクリプションからダウンロードしたファイルを直接編集すると、次回の更新で変更が失われることがあります。上書きを保持できるかは、クライアントの実装によって異なります。変更後は最終的に適用される設定を確認し、特にリスト項目が追加、置換、並べ替えのどれに当たるかを確認してください。

RULES / OUTBOUND

ルールによる振り分け

ルールが接続先を判定し、プロキシグループが出先を決めます。マッチ条件と出先の名前は、分けて確認してください。

ルールによる振り分け: rules · MATCHルールモードでは、設定された順に接続を判定し、通常は最初に一致したルールで出先が決まります。ルールの末尾に指定するプロキシグループ名は、設定内に存在している必要があります。DIRECTとREJECTは組み込みの出先です。MATCHを最後に置くと、ほかのルールに一致しなかった接続を処理できます。早い位置に置くと、後続のルールが適用されません。

プロキシグループ: proxy-groups · select / url-test / fallbackプロキシグループは複数の出先をまとめ、ルールから参照できる名前を付けるものです。selectは手動選択、url-testはテスト結果に基づく自動選択、fallbackは通常、順番に利用可能な項目を選択します。グループを入れ子にする場合は、参照が循環しないよう注意してください。詳しくはプロキシグループの応用設定をご覧ください。

DOMAIN-SUFFIX: DOMAIN-SUFFIX,github.com,PROXYドメインの末尾で照合するルールです。github.comを指定すると、そのドメインとサブドメインが対象になり、ワイルドカードは不要です。指定したドメインだけに一致するDOMAINや、文字列を含むかどうかで判定するキーワードルールとは異なります。接続にIPアドレスしかなく、ドメインと紐付けられない場合は、ドメインルールに一致しないことがあります。

GeoIP: GEOIP,CN,DIRECTGeoIPは、接続先IPアドレスを地理情報データベースの分類に基づいて判定します。Webページの言語で判定するものではありません。データベースの更新が遅れている場合があり、CDNを使うサイトでは、DNSの応答によって分類が異なることもあります。接続先を判定する機能であり、プロキシノードの実際の出口地域を直接証明するものではありません。調査時は接続先IPと一致したルールをあわせて確認してください。

ルールセット: rule-providers · RULE-SET · behaviorルールセットを使うと、ドメイン、IPアドレス範囲、その他のルールをまとめて管理できます。rule-providersで定義し、rulesから参照します。behaviorは、domain、ipcidr、classicalなど、ルールの解釈方法を指定するため、内容に合った値が必要です。ルールセットを更新しても、参照する位置は自動で変わりません。優先順位は、メインのルール一覧の順序で決まります。

CAPTURE / LISTENER

通信を取り込む方法

「通信がカーネルに入っているか」と「入った通信の出先」は別々に確認します。ひとつのスイッチだけで両方を判断することはできません。

システムプロキシ: system proxy · HTTP / SOCKSシステムプロキシはOSにプロキシのアドレスとポートを登録し、その設定に従うアプリで利用します。一部のコマンドラインツール、ゲーム、独自の通信設定を持つアプリは自動で追従しません。有効にしただけですべての通信が取り込まれるわけではありません。動作確認では、まずブラウザーで新しい接続を行い、次にクライアントの接続画面で記録を確認してください。手順はシステムプロキシの設定をご覧ください。

TUNモード: tun · auto-route · dns-hijackTUNは仮想ネットワークデバイスとルーティングを使ってIP通信を取り込み、システムプロキシに従わない一部のアプリにも対応します。通常、OSの権限が必要で、ルート除外やDNSの取り込みなどの設定と連携して動作します。有効にした後にネットワークへ接続できなくなった場合は、サービスの権限、ルーティング、名前解決の経路を順に確認してください。原因を調べずにノードを何度も切り替えるのは避けましょう。

TUN stack: stack: system / gvisor / mixedstackはTUNパケットの処理に使うネットワークスタックを指定します。一般的な選択肢はsystem、gvisor、mixedです。利用できる選択肢、互換性、動作はプラットフォームやカーネルのバージョンによって異なり、すべての端末に共通する最適な値はありません。変更するときはほかの設定を変えず、問題が発生するアプリの接続を改めて確認してください。

混合プロキシポート: mixed-port: 7890mixed-portは、ひとつの待ち受けポートでHTTPとSOCKSのプロキシ接続を受け付けます。7890はよく使われる設定例です。アプリにプロキシを手動で設定する場合、アドレスとポートを現在の設定に合わせてください。LANからの接続には待ち受けアドレスやファイアウォールの設定も関係するため、端末上で接続できても、ほかの端末から接続できるとは限りません。

出力モード: mode: rule / global / directルールモードはルール一覧に基づいて出先を選び、グローバルモードは通常、全体用のプロキシグループから選択します。ダイレクトモードでは、カーネルに入った通信を直接接続します。モードが制御するのは出先の選択であり、アプリの通信をカーネルに取り込む機能ではありません。そのため、グローバルモードでも端末全体の通信が取り込まれるとは限りません。違いは出力モードの解説をご覧ください。

DNS / DOMAIN MAPPING

DNS解決

まず、どこでドメインを問い合わせ、問い合わせ先がどこかを確認してから、Fake-IPやドメインスニッフィングを調整してください。

DNS解決: dns · nameserverDNS解決は、ドメイン名をIPアドレスなどのレコードに変換する処理です。アプリ、OS、カーネル、プロキシサーバーが関与する場合があります。ブラウザー独自の暗号化DNSが有効だと、システム設定とは異なる経路で問い合わせることがあります。接続に失敗した場合は、名前解決の失敗、接続の失敗、ルール選択の誤りを切り分けてください。Webページが開けないだけでノードが使えないと判断することはできません。

Fake-IP: enhanced-mode: fake-ipFake-IPモードはアプリに対応用のIPアドレスを返し、カーネル内でそのアドレスとドメインの紐付けを保持します。アプリがそのアドレスへ接続すると、カーネルがドメインを復元して通信を振り分けます。このアドレスはWebサイトの実サーバーのものではありません。後続の通信が正しくカーネルに入る必要があり、DNSの応答を変えるだけでは通信を取り込めません。

Fake-IPフィルター: fake-ip-filter · fake-ip-filter-modefake-ip-filterとフィルターモードの設定により、ドメインに実際のDNS解決結果を使うかどうかを制御します。LAN内のサービスや、実アドレスが必要なアプリへの対応によく使われます。リスト内のドメインをどう扱うかは、現在のフィルターモードとあわせて判断してください。一覧にあるかどうかだけでは判定できません。互換性の問題が起きたら、まず該当ドメインを特定し、範囲を絞って変更してから再テストしてください。

DNSリーク: resolver path · encrypted DNSDNSリークとは、ドメインの問い合わせが想定外の経路を通ることです。たとえば、プロキシ経由にする想定の問い合わせが、ローカルのDNSリゾルバーへ送られるケースがあります。検査ページに表示されるリゾルバー名は手掛かりのひとつです。ブラウザーの暗号化DNS、システム設定、クライアントのログもあわせて確認してください。ローカルでの直接問い合わせが想定されたドメインまで、設定ミスと決めつける必要はありません。

ドメインスニッフィング: sniffer · HTTP Host · TLS SNIドメインスニッフィングは、対応プロトコルの接続メタデータからドメイン情報を取得します。たとえばHTTP Hostや、確認可能なTLS SNIが対象です。取得したドメインはルール判定に利用できますが、接続全体を復号する機能ではなく、すべての暗号化通信で動作するわけでもありません。元の接続先を上書きするか、どのポートを対象にするかは、必要に応じて設定し、影響範囲を広げすぎないようにしてください。