設定項目 / 概念の違い / トラブル時の確認ポイント

Clash用語集

画面上の設定からカーネルの項目まで、よく使う24の用語を6カテゴリで解説します。まず通信がクライアントに入る経路を確認し、次にルールが出口を選ぶ仕組みを見て、最後にDNSとサブスクリプションの設定を確認しましょう。

6カテゴリの用語
設定項目を確認
個別リンクを共有

処理を担うカーネルと操作画面

カーネルとクライアント

クライアントは操作画面を提供し、カーネルは接続を処理します。トラブルの確認時はウィンドウのタイトルだけでなく、両方の名称を記録してください。

Clashクライアント#: GUI / clientクライアントは、サブスクリプションのインポート、プロキシグループの選択、ログの確認、プロキシのオン・オフなどを操作する画面を提供します。実際の接続処理は通常カーネルが担います。同じカーネルでも、組み合わせるクライアントによって画面の項目名や設定の統合方法が異なることがあります。設定項目が反映されない場合は、カーネルの対応状況に加え、クライアントがその項目を最終的な実行設定に反映しているか確認してください。

mihomoカーネル#: mihomo / Clash MetamihomoはClash Metaから派生したプロキシカーネルで、プロトコル接続、ルール判定、DNS処理、TUNなどを担います。クライアントの画面にClashと表示されていても、同じカーネルが動作しているとは限りません。プロトコルの種類、ルール構文、実験的な設定項目は、実際に動作しているカーネルのドキュメントと起動ログで確認してください。

ノード#: proxies / outboundノードは通常、選択可能なリモートプロキシの出口を指し、プロトコル、サーバーアドレス、ポート、認証情報などを含みます。クライアントをインストールして使えるのは接続ツールであり、ノードは利用可能な設定やサブスクリプションから取得する必要があります。ノード名は表示用のラベルにすぎず、経由地、帯域、利用可能性を示すものではありません。接続トラブル時は実際の設定値とエラーログを確認してください。

遅延テスト#: url-test / timeout遅延は指定したテスト先と方法で測定する応答時間です。ダウンロード速度と同じではなく、単純なネットワーク往復時間とも限りません。クライアントごとにテスト先が異なる場合があるため、結果を単純に比較することはできません。タイムアウトした場合は、テスト先に到達できない、ノードに接続できない、名前解決に問題があるといった原因が考えられます。実際のサイトへの接続状況とログも確認してください。

ローカルの入口とリモートへの通信

プロキシプロトコル

ローカルアプリが接続するプロキシの入口と、クライアントがリモートサーバーへの接続に使うプロトコルは、異なる階層のものです。

HTTPプロキシ#: HTTP / CONNECTHTTPプロキシでは、アプリがプロキシの入口にリクエストを送信します。HTTPS接続では通常、CONNECTメソッドでトンネルを確立します。アプリにローカルのHTTPプロキシアドレスを設定しても、リモートノードがHTTPプロトコルを使うとは限りません。HTTPプロキシ自体がすべての通信を自動的に暗号化するわけではありません。接続先サイトのHTTPS、ローカル入口までの通信、リモートノードの暗号化は、それぞれ分けて考えてください。

SOCKS5#: SOCKS / UDP ASSOCIATESOCKS5は、接続先アドレスと接続リクエストをプロキシの入口に送るプロトコルです。ブラウザー、開発ツール、コマンドラインプログラムのプロキシ設定でよく使われます。TCPに対応し、UDP転送の方式も定義されていますが、実際にUDPを利用できるかはアプリ、クライアント、リモートへの経路によって異なります。ドメインをローカルとプロキシ側のどちらで名前解決するかも、アプリの設定で確認してください。

Shadowsocks#: type: ssShadowsocksはリモートプロキシプロトコルの一種です。サーバーと暗号化方式や認証情報を一致させる必要があります。サーバーアドレスとポートだけでは、通常、接続を確立できません。プラグインなどの追加要件もサーバー側と合わせてください。インポート後に接続できない場合は、まずカーネルが該当方式に対応しているか確認し、その後に設定値を点検してください。すぐにルールモードが原因と判断するのは避けましょう。

TLS#: TLS / SNI / servernameTLSは通信を保護し、サーバーの身元を検証するプロトコルです。さまざまなプロキシプロトコルの外側の通信で使われます。SNIはハンドシェイク時に送られるサーバー名情報です。証明書の検証では、名前が一致するか、証明書が信頼できるかも確認します。ハンドシェイクに失敗した場合は、システム時刻、サーバー名、証明書チェーンを確認してください。証明書検証の無効化を通常の対処方法にするのは避けましょう。

接続がカーネルに届いてから

ルールと通信振り分け

ルールは「どの出口に送るか」を決め、プロキシグループは「現在どのノードを選んでいるか」を決めます。両方を確認してください。

ルールによる通信振り分け#: mode: rule / rulesルールモードでは、rulesを上から順に照合し、通常は最初に一致したルールで接続先の出口を決めます。たとえば、DOMAIN-SUFFIX,example.com,PROXYはexample.comとそのサブドメインをPROXYに送ります。末尾のMATCH,PROXYは、それ以前のルールに一致しなかった接続を受け持ちます。範囲の広いルールを先に置くと、後続の細かいルールが適用されないことがあります。

プロキシグループ#: proxy-groups / select / url-testプロキシグループは複数の出口をまとめ、ルールから参照できる名前を付ける仕組みです。設定にはproxy-groupsを使います。selectグループでは手動で選択し、url-testグループでは指定したアドレスへのテスト結果に基づいて自動選択します。自動テストで、すべてのサイトに最速の経路が選ばれるとは限りません。ルールがグループを指定している場合は、グループ内で現在選択されている項目も確認してください。

GeoIP#: GEOIP,CN,DIRECTGeoIPはIPアドレスの地理情報データベースに基づき、接続先を判定します。特定の地域のIPアドレスを指定した出口に送る用途などで使われます。ドメインを分類するGeoSiteとは異なり、サイトの運営元やサービス内容を単独で判定するものではありません。ドメインへの接続でIPルールに一致させるには、先に名前解決が必要な場合があります。データベースの状態、名前解決の結果、ルールの順序が判定に影響します。

ルールセット#: rule-providers / RULE-SETルールセットでは、ドメイン、IPアドレス範囲、その他の照合条件を個別に管理します。rule-providersで読み込み、RULE-SETルールから参照します。宣言した動作タイプとファイル形式は、実際の内容に合わせる必要があります。ファイルを取得できても、メイン設定でルールが使われているとは限りません。トラブル時は、読み込みログ、参照名、出口の名前、ルールの配置順を順に確認してください。

通信の取り込み方法と出口の選び方

ネットワークモード

システムプロキシとTUNは通信を取り込む方法、ルールモードとグローバルモードは出口の選び方です。一方を有効にしても、もう一方の役割を自動的に置き換えることはありません。

システムプロキシ#: system proxy / loopbackシステムプロキシは、OSにローカルプロキシのアドレスを登録し、その設定に従うアプリからクライアントの待ち受けポートへリクエストを送ります。一部のゲーム、コマンドラインプログラム、独自のネットワーク設定を持つアプリは、システムプロキシを使わないことがあります。スイッチをオンにしても、すべての接続が取り込まれるわけではありません。クライアントを終了した後にウェブページを開けなくなった場合は、OSに終了済みのポートを指すプロキシ設定が残っていないか確認してください。

TUNモード#: tun / auto-route / dns-hijackTUNは仮想ネットワークインターフェースとルーティング設定を使って通信を取り込み、システムプロキシを使わない一部のプログラムにも対応できます。通常は適切な権限やサービスコンポーネントが必要です。対象となる通信の範囲は、ルートの除外設定、ネットワーク環境、クライアントの実装によって異なります。他のVPNと競合する場合は、複数の通信取り込みツールを切り替え続けるのではなく、まずデフォルトルートとDNSを確認してください。

グローバルモード#: mode: global / GLOBALグローバルモードでは、カーネルに届いた接続を、通常のrulesで振り分けずにGLOBALで現在選択されている出口へ送ります。変更されるのは出口の選択方法であり、もともとクライアントを経由しないプログラムが自動的にプロキシ対象になるわけではありません。ルールの問題を一時的に切り分ける際には使えますが、GLOBALで選択中の項目を確認してください。ルールモードに戻した後は、従来のルール判定も確認しましょう。

混合ポート#: mixed-port: 7890混合ポートは、1つの待ち受けポートでHTTPとSOCKSのプロキシ接続を受け付けます。設定項目はmixed-portです。7890はよくある例で、すべてのクライアントがこのポートを使うわけではありません。アプリに手動設定する際は、現在有効な値を確認してください。LAN内の他の端末から接続できるかどうかは、待ち受けアドレス、allow-lan、ファイアウォールにも左右されます。ポート番号を変えるだけでは解決しません。

ドメイン、アドレス、名前解決の経路

DNSと名前解決

DNSはアドレスの取得を担い、通信振り分けルールは接続の出口を選びます。ウェブサイトを開けるだけでは、想定どおりの名前解決経路を通ったとは判断できません。

DNS名前解決#: dns / nameserverDNSはドメイン名をIPアドレスなどのレコードに変換します。アプリは通常、接続先にアクセスする前に問い合わせを行います。システム、ブラウザー、カーネルはそれぞれキャッシュを持ったり、別のDNSサーバーを使ったりするため、DNSを1か所変更してもすべてのアプリに反映されるとは限りません。名前解決の問題を調べる際は、接続先ドメイン、プロキシサーバーのドメイン、DNSサーバー自身への接続に必要なアドレス取得を区別してください。

Fake-IP#: enhanced-mode: fake-ipFake-IPはドメインにマッピング用アドレスを割り当てます。アプリがそのアドレスに接続すると、カーネルがドメイン情報を復元し、通信振り分けに利用できます。ログに表示されるマッピング用アドレスはウェブサイトの実サーバーのアドレスではなく、ノードの所在地を判断する材料にもなりません。実際の名前解決結果を必要とするアプリでは、ドメインごとに例外設定が必要な場合があります。すべてのドメインをまとめて除外するのは避けてください。

DNS漏えい#: resolver path / DNS interceptionDNS漏えいとは、カーネルで処理する想定の問い合わせが別のDNSサーバーに送られるなど、名前解決リクエストが想定した経路から外れることです。検出ページに表示されたDNSサーバーが転送やエニーキャストを使っている場合もあるため、名称や地域だけで判断しないでください。システムDNS、ブラウザーの暗号化DNS、TUNのDNS横取り設定、実際のログをあわせて確認します。Fake-IPを有効にしただけで、すべてのDNSリクエストが制御されているとは限りません。

nameserver-policy#: dns.nameserver-policynameserver-policyは、ドメインの照合条件に応じてDNSの上流サーバーを指定します。ドメインごとに異なるDNSサーバーを使うための設定です。問い合わせ先を決めるもので、通信の出口をrulesの代わりに決定するものではありません。変更後は、照合構文、DNSサーバーへの接続経路、古いキャッシュも確認してください。キャッシュに残った古い応答を、新しい設定が読み込まれていない証拠と誤認しないようにしましょう。

設定の取得元と最終的な適用内容

サブスクリプションと設定

サブスクリプションの更新、ローカルでの編集、クライアントのオーバーライドが同時に存在する場合があります。設定の問題を調べる際は、最終的にカーネルへ渡された設定を確認してください。

サブスクリプション#: subscription / profileサブスクリプションは、リンクを通じてノード一覧や設定一式を配信します。内容は提供元とクライアントへのインポート方法によって異なります。更新が成功しても、確認できるのは通常、コンテンツを取得できたことまでです。現在の設定が有効か、プロキシグループが存在するか、利用可能な出口が選択されているかも確認してください。サブスクリプションのリンクにはアクセス情報が含まれていることが多いため、ログやスクリーンショットを共有する際はリンクと認証情報を隠してください。通常の公開URLのように扱ってはいけません。

YAML#: config.yaml / indentationYAMLはClash設定でよく使われる構造化テキスト形式で、インデントによってマッピングやリストの階層を表します。編集時はスペースによるインデントを統一し、タブで代用しないでください。特殊文字を含む文字列は引用符の扱いにも注意が必要です。構文チェックに通っても、設定項目名、ノード参照、現在のカーネルの対応状況が正しいとは限りません。

オーバーライド#: override / merge / patchオーバーライドでは、DNSやルールなどのローカル設定をサブスクリプションの元データとは別に保存し、クライアントが統合して実行用設定を生成します。サブスクリプション更新後も残したい設定を保持するのに便利ですが、統合順序や配列の処理方法はクライアントによって異なります。ルールの重複、設定項目の消失、順序の変化が見つかった場合は、サブスクリプションとオーバーライドのファイルだけでなく、最終設定も確認してください。

proxy-providers#: proxy-providers / useproxy-providersは、提供元ごとにノードを読み込みます。プロキシグループからuseで参照できるため、ノードの更新とメイン設定の管理を分けられます。プロキシの出口を読み込む機能であり、照合条件を読み込むrule-providersとは異なります。提供元ファイルの形式、参照名、更新状況を確認してください。プロバイダーを定義しただけでは、利用可能なプロキシグループから参照されず、想定した選択肢に表示されないことがあります。