Clashの基本用語集
設定項目の場所から、コア、サブスクリプション、ルール、DNSの意味を確認できます。
まずカテゴリを選び、用語カードを確認してください。各カードでは概念や役割、混同しやすいポイントを解説しています。わからない項目があれば、カードのアンカーリンクを共有して質問できます。設定の説明は主にmihomoを対象としており、クライアントによって画面上の名称が異なる場合があります。
config.yaml → 用語 → 操作
手順に沿って初期設定を行う ›
コアとクライアント
操作を行う画面、通信を転送するコア、通信をコアに渡す方法を区別しましょう。
- mihomocore / プロキシコア
- 接続を実際に処理するプログラムです。mihomoはClash Metaから名称変更され、設定の読み込み、DNS処理、ルール照合、リクエストの転送を担います。クライアントとコアの更新時期は一致するとは限りません。設定項目が使えるかどうかを判断する際は、アプリ名だけでなく、稼働中のコアとそのバージョンを確認してください。
- GUIクライアントgraphical user interface / グラフィカルユーザーインターフェース
- サブスクリプションの追加、プロキシの選択、ログの確認などを、コマンドを一つずつ入力せずに操作できます。GUIはグラフィカルユーザーインターフェースの略で、通常は画面の背後でプロキシコアも起動します。同じコアを使うクライアントでも、設定の統合方法、権限管理、設定の保存先は異なる場合があります。
- システムプロキシsystem proxy / アプリのプロキシ設定
- まずはシステム設定に従うアプリから、ローカルのプロキシポートに接続するために使います。システムプロキシを有効にしても、通常はプロキシアドレスが設定されるだけで、すべての通信が取り込まれるわけではありません。ターミナルツール、ゲーム、独自のネットワーク機能を持つアプリなどは、この設定を無視することがあります。クライアント終了後にネットワークの問題が起きた場合は、古いプロキシアドレスがシステムに残っていないか確認してください。
- TUNモードvirtual network interface / 仮想ネットワークインターフェース
- システムプロキシを参照しないアプリの通信を取り込みたい場合は、TUN仮想ネットワークインターフェースを検討します。システムのルーティングと連携して通信をコアに渡す方式で、通常は管理者権限、サービスモード、またはOSのVPN許可が必要です。スイッチを有効にしただけでは通信を取り込めるとは限りません。ルート、DNS、除外設定を確認し、ほかのVPNとの競合にも注意してください。
- 外部コントローラーexternal-controller / 管理インターフェース
- このインターフェースを使って、クライアントや管理パネルから状態の確認、ポリシーの切り替え、接続の管理を行えます。
external-controllerで待ち受けアドレスを指定します。例：127.0.0.1:9090。ブラウザーに入力するプロキシポートとは異なります。ローカルで管理するだけならローカルアドレスで待ち受け、リモートアクセスが必要な場合は認証とアクセス範囲を設定してください。
設定ファイルの項目
まずファイルの構造を把握し、実際に有効な値を確認しましょう。ダウンロードした元ファイルだけを編集しないよう注意してください。
- YAMLconfig.yaml / 構造化テキスト
- 設定を編集するときは、まず元のインデントを維持してください。YAMLは構造化テキスト形式で、
config.yamlなどに使われます。インデントは階層、ハイフンはリスト項目を表し、インデントにはタブではなくスペースを使います。特殊文字を含む値は引用符で囲む必要がある場合があります。保存後は構文を確認してから、設定を再読み込みしてください。
- mixed-portlistener / 混合待ち受けポート
- アプリのプロキシポートには、この項目に設定された実際の値を入力してください。
mixed-port: 7890は、同じポートでHTTPとSOCKSのプロキシ接続を受け付ける設定です。ポート番号は変更でき、すべてのクライアントで固定されているわけではありません。ほかのプログラムがポートを使用中の場合、コアが正常に待ち受けできないことがあります。ログを確認してから、両方の設定を調整してください。
- allow-lanlocal network / LANからのアクセス
- 同じLAN内のほかのデバイスからプロキシを使う必要がある場合に限り、有効にすることを検討してください。
allow-lan: trueでLANからの接続を許可できますが、実際に接続できるかどうかは待ち受けアドレスやOSのファイアウォールにも左右されます。有効にする前にネットワークの安全性を確認し、必要に応じて認証を設定してください。この項目は、端末自身が通常のインターネット接続を行うために必須ではありません。
- moderule / global / direct
- 普段使いでは、まず
mode: ruleを選び、ルールに応じて接続先を振り分けます。globalは通信をグローバルポリシーに渡し、directは直接接続します。ここでいうグローバルモードの対象は、コアに渡された通信です。モードを切り替えても、もともとコアを経由しないアプリが自動的にプロキシを使うわけではありません。
- log-levellogging / ログレベル
- 問題の調査では、ログの詳細度を調整します。主な値は
info、warning、error、debugです。ログを詳しくすると、設定の読み込み、ルール、接続の問題を特定しやすくなりますが、出力量も増えます。ログを共有する前に、サブスクリプションURL、認証情報、公開したくないアクセス履歴を削除してください。
プロキシプロトコル
アプリからローカルプロキシに接続する方式と、コアからリモートサーバーへの接続に使うプロトコルを区別しましょう。
- HTTPプロキシHTTP / CONNECT
- 手動プロキシ設定に対応するアプリでは、HTTPプロキシを選んで待ち受けアドレスを入力できます。HTTPSサイトへの接続では、通常CONNECTメソッドでトンネルを確立します。接続先サイトのHTTPSと、クライアントからプロキシまでの通信が暗号化されるかどうかは別の話です。一般的なHTTPプロキシがすべての通信を自動的に暗号化するわけではなく、汎用的なUDP転送の代わりにもなりません。
- SOCKS5TCP / UDP ASSOCIATE
- アプリが対応している場合、SOCKS5を使ってローカルプロキシに接続できます。SOCKS5はTCPに対応し、UDPを扱う仕組みも定義していますが、アプリ、クライアント、リモート側の通信経路がそれぞれ対応している必要があります。ドメイン名をローカル側とプロキシ側のどちらで解決するかはアプリの使い方によって異なります。SOCKS5を選んだだけでDNSも必ずプロキシ経由になるとは限りません。
- ShadowsocksSS / 暗号化プロキシプロトコル
- このタイプのノードを追加するときは、サーバーアドレス、ポート、パスワード、暗号方式を確認してください。Shadowsocksは双方で合意した設定を使ってプロキシ通信を行います。設定が一致しないと、通常は接続できません。暗号方式や拡張機能の対応状況はコアによって異なる場合があるため、ノード名だけで互換性や速度を判断しないでください。
- VMessUUID / 転送設定
- 設定時は、ユーザー識別用のUUIDと転送設定をあわせて確認してください。VMessは複数の転送方式に対応しています。アドレスとポートが正しくても、パス、ホスト名、TLS設定が一致しなければ接続に失敗することがあります。システム時刻が大きくずれていると認証に影響する場合もあるため、時刻同期とコアのログも確認してください。
- TrojanTLS / サーバー認証
- このタイプのノードに接続するときは、パスワード、サーバー名、証明書の要件を確認してください。Trojanは通常、TLS接続内でプロキシ通信を行います。TLSは通信を保護し、サーバーの身元を検証するために使われます。証明書エラーが発生した場合は、まず時刻、ドメイン名、サーバー側の設定を確認してください。証明書検証の無効化を通常の解決策にしないでください。
ルールと通信の振り分け
まず照合条件を確認し、次に接続先の名前を確認しましょう。ルールの順序やデータファイルによって結果が変わります。
- ルールによる振り分けrules / 条件に応じた接続先の選択
- ルールモードでは、ドメイン名や宛先IPなどの条件に応じてリクエストの接続先を決めます。ルールは通常上から順に確認され、最初に一致した項目で接続先が決まるため、個別の例外は広い条件のルールより前に置いてください。接続先には
DIRECTでの直接接続や、プロキシグループを指定できます。グループ名は設定内の名前と一致させてください。
- DOMAIN-SUFFIXdomain matching / ドメインのサフィックス照合
- ドメイン名とそのサブドメインの両方を対象にする場合に使います。たとえば
DOMAIN-SUFFIX,example.com,DIRECTは、example.comとwww.example.comに一致します。ドメインのサフィックス境界で照合するため、別のドメイン名に同じ文字列が含まれているだけでは一致しません。
- GeoIPGEOIP / IPアドレスの分類
- IPアドレスの国や地域に応じて通信を振り分ける場合は、GeoIPデータを参照します。
GEOIP,CN,DIRECTは、データベースでCNに分類されたIPアドレスへの通信を直接接続にします。ドメイン名へのルール適用時には、名前解決が関わることがあります。データベースの更新や分類には誤差があるため、IPアドレスの分類だけでサーバーの実際の所在地は保証されません。
- GeoSiteGEOSITE / ドメイン名の集合
- 多数のドメイン名をサービスやカテゴリごとに管理する場合は、GeoSiteのデータセットを参照できます。IPアドレスを分類するGeoIPとは異なり、整備されたドメイン名の一覧をもとに照合します。カテゴリ名は読み込んだデータファイルによって異なるため、ルールを追加する前にカテゴリの有無と、使用中のコアに適したデータソースを確認してください。
- MATCHfallback rule / 最終ルール
- ルール一覧の末尾にMATCHを置き、それ以前のルールに一致しなかったリクエストの接続先を指定します。たとえば
MATCH,PROXYは、残りのリクエストをPROXYという名前のポリシーに渡します。MATCH自体はWebサイトの地域を判定しません。早い位置に置くと、その後のルールが確認されなくなります。
DNSとネットワーク
ドメイン名の解決と接続の確立を分けて確認し、あらゆるネットワークの問題をひとつの設定項目だけで説明しないようにしましょう。
- DNSdomain name system / ドメインネームシステム
- ドメイン名にアクセスする前に、アプリは通常DNSを使ってIPアドレスなどを問い合わせます。名前解決と、その後のWebサイトへの接続は別の処理です。特定のIPアドレスにアクセスできても、ドメイン名の解決が正常とは限りません。システム、ブラウザー、プロキシコアのいずれも名前解決に関わる場合があります。問題を調べる際は、まず問い合わせ元と使用中のリゾルバーを特定してから、該当する設定を変更してください。
- Fake-IPenhanced-mode / 合成アドレスへのマッピング
- このDNS方式を有効にすると、まずコアが合成アドレスをアプリに返し、そのアドレスとドメイン名の対応を記録します。アプリがそのアドレスに接続すると、コアはドメイン名を使ってリクエストを処理するため、表示されたアドレスがWebサイトの実際のグローバルIPとは限りません。一部のアプリやLAN内サービスでは互換性の問題が起きることがあります。その場合はノードを何度も切り替えるのではなく、該当ドメインをフィルター対象に設定してください。
- nameserverupstream resolver / 上流リゾルバー
- mihomoの
dnsセクションで、上流の名前解決サービスを指定する項目です。リストにはコアが対応する形式のアドレスを指定できます。ただし、個々の問い合わせ先はドメイン別のポリシーや、プロキシノードの名前解決設定などにも左右されます。システムのすべてのDNSリクエストが通る唯一の出口とは限りません。変更後は通信の取り込み範囲とキャッシュも確認してください。
- DNSリークresolver path / 想定外の名前解決経路
- まず想定する名前解決経路を明確にしてから、リークの有無を判断してください。通常は、Web通信がプロキシ経由でもドメイン名の問い合わせがローカルネットワーク経由になるなど、想定外のリゾルバーに問い合わせが送られる状態を指します。検出結果はブラウザーのセキュアDNS、システム設定、TUNによる通信の取り込み、キャッシュも含めて判断してください。リゾルバーの所在地が異なるだけでは、すべての通信経路を判断できません。
- DNSリダイレクトdns-hijack / TUN内のDNSリダイレクト
- mihomoの設定では、
dns-hijackは対象となるDNSリクエストを内蔵の名前解決モジュールへリダイレクトする項目です。悪意のあるDNS改ざんを指す一般的な意味とは異なります。TUNと組み合わせて使われることが多いものの、対象となる宛先やプロトコルのみを取り込みます。ブラウザーから送信される暗号化DNSも自動的に検出・取り込みできるとは限りません。
サブスクリプションとノード
設定の取得元、個々の接続情報、接続先の選び方を区別してから、テスト結果を確認しましょう。
- サブスクリプションURLsubscription / 設定の取得元
- サービス提供元から発行されたサブスクリプションURLをクライアントに追加し、設定やプロキシ項目の一覧を取得します。URLによって、完全なYAML、エンコードされたリスト、その他の形式が返されるため、クライアントのインポート方法との互換性を確認してください。URLにはアカウントへのアクセス情報が含まれることが多いため、認証情報と同様に管理し、スクリーンショットや問い合わせで公開しないでください。更新に失敗しても、すべてのノードが無効になったとは限りません。
- ノードproxy entry / プロキシ接続項目
- ノードは、コアで利用できる接続情報一式です。通常はサーバーアドレス、ポート、プロトコル、認証情報が含まれます。表示名は設定の提供元が付けたもので、実際の場所や接続先を正確に示すとは限りません。接続先サービスにアクセスできるかどうかは、回線、リモート側の出口、接続先の制限にも左右されます。名前だけで判断しないでください。
- レイテンシlatency / 指定したテストの所要時間
- まずテスト方法と宛先を確認してから、レイテンシを比較してください。クライアントのテスト結果は通常、プロキシ経由で指定のリクエストを完了するまでの時間を示し、ネットワーク、接続確立、宛先からの応答に左右されます。ICMPの往復時間だけを表すものではありません。レイテンシが低くてもダウンロード速度が速いとは限らず、タイムアウトもテスト先に到達できないだけの場合があります。
- proxy-providersproxy collection / プロキシ項目の取得元
- 設定ファイルで、独立して更新できるプロキシの集合を宣言する項目です。取得元にはリモートURLまたはローカルファイルを指定できます。プロキシグループからこの集合を参照すると、含まれるノードを利用し、設定に応じて更新やヘルスチェックを実行できます。通常はプロキシ項目だけを管理するもので、DNSやルールを含む完全な設定の代わりにはなりません。すべてのサブスクリプションURLをそのまま指定できるわけではありません。
- プロキシグループproxy-groups / 接続先の選択方式
- 複数のノードから接続先を選ぶ場合は、プロキシグループで接続先をまとめて指定します。
selectは手動選択、url-testはテスト結果に基づく選択、fallbackは順番に利用可能な項目を探す方式です。実際の動作は設定値によって異なります。ルールからグループ名を指定していても、グループ内の選択が実際の接続先を左右するため、問題を調べる際は適用されたルールと最終的なノードの両方を確認してください。