CONFIGURATION INDEX · 27 TERMS
Clash Meta 設定用語集
カーネルアーキテクチャ、プロキシプロトコル、ルールベースルーティング、サブスクリプション設定、ネットワーク診断に分けて主要概念を整理しています。各項目では設定上の位置、実際の役割、混同しやすい境界を説明し、YAMLの確認、サブスクリプションのインポート、接続経路のチェックに役立つ内容をまとめています。
CATEGORY ROUTES
設定階層から探す
C-01 · CORE
カーネルとアーキテクチャ
クライアント画面、プロキシカーネル、ローカル待受ポート、システムトラフィックの取り込みがどう関係するかを説明します。この層を理解すると、画面操作の問題、カーネル設定の問題、OSのネットワーク設定の問題を切り分けやすくなります。
- mihomo
-
別名:Metaカーネル
mihomoはClashの発展を受け継いだプロキシカーネルの名称で、設定の読み込み、ローカルポートの待受、リモート接続の確立、ルール照合を担います。GUIクライアントは通常、サブスクリプション管理、ポリシー切り替え、ログ確認を画面にまとめますが、実際にトラフィックを処理するのはカーネルです。
クライアントによって搭載されているカーネルのリリース時期が異なるため、同じ設定でも項目の互換性に差が出る場合があります。未知の項目や起動失敗が発生したら、まず使用中のカーネルの種類と更新状況を確認してください。
- Clash Meta
-
関連:mihomo、Meta設定
Clash Metaは当初、Clashを基盤にプロトコル、DNS、トラフィック取り込み機能を拡張したカーネル分岐を指していました。また、そのカーネルを中心に形成されたクライアントエコシステムを表す言葉としても使われます。現在の技術文書でMetaカーネルと書かれている場合は、文脈からmihomoを具体的に指すか判断する必要があります。
Clash Metaは特定のGUIクライアントだけを指す名称ではありません。Windows、macOS、Android、iOS、Linux向けクライアントは画面が異なっていても、基盤となる設定概念はおおむね共通しています。
- GUIクライアント
-
英語:Graphical User Interface Client
GUIクライアントはプロキシカーネルにグラフィカルな操作層を提供します。サブスクリプションのインポート、ポリシーグループの選択、プロキシモードの切り替え、システムプロキシの有効化・無効化、ログ確認などが主な機能です。設定ファイルを直接編集する頻度は下げられますが、設定項目そのものの意味は変わりません。
画面上のスイッチは、最終的にカーネルのパラメーターやシステム設定へ変換されます。クライアントを比較する際は、画面の機能、カーネルのバージョン、プラットフォーム対応、設定の互換性を分けて確認し、ボタン名だけで機能が同じだと判断しないでください。
- Mixed Port
-
設定キー:mixed-port
Mixed PortはHTTPとSOCKS5のリクエストを同時に受け付けるローカル待受ポートです。アプリはこのポートへ接続するだけで、カーネルがリクエストの種類に応じて処理します。デスクトップ環境で設定するポート数を減らしたい場合に便利です。
リモートノードのポートとは別の概念です。Mixed Portは本機でアプリからの接続を待ち受け、ノードのポートはリモートサービスへの接続に使われます。ローカルポートが他のプログラムで使用中の場合、カーネルは待受を開始できず、ログにバインド失敗が記録されることがあります。
- TUNモード
-
関連:仮想ネットワークインターフェース、ルーティングの取り込み
TUNモードは仮想ネットワークインターフェースでシステムトラフィックを受け取り、カーネルがルールに従って出口を決める方式です。システムプロキシ設定を参照しないアプリにも適しており、通常のHTTPプロキシより広い範囲の接続を扱えます。
TUNの有効化には通常、システム権限、ルーティングテーブル、DNS設定が関係し、一部のプラットフォームではサービスコンポーネントのインストールも必要です。イントラネットに接続できない、通信が切れる、名前解決が不安定といった場合は、TUNのルート、インターフェースの除外項目、DNSモードをあわせて確認してください。
C-02 · PROTOCOL
プロキシプロトコル
プロキシプロトコルは、クライアントがリモートサービスと通信する方法を定めます。アドレスとポートは接続入口にすぎず、プロトコル種別、認証情報、転送方式、TLSパラメーターがそろって初めてノードが有効な接続を確立できます。
- ノード
-
英語:Proxy Node
ノードは設定内でポリシーグループから選択できるプロキシ接続項目です。通常は名前、サーバーアドレス、ポート、プロトコル種別、認証パラメーターを含みます。ノード名は画面で識別するためのもので、実際の回線品質や所在地が名前どおりとは限りません。
ノードが一覧に表示されるのは、設定が解析されたことを示すだけで、接続確認が成功したことを意味しません。利用可能か確認するには、DNS、ハンドシェイク、証明書、認証情報、リモートサービスの状態も調べる必要があります。
- プロキシプロトコル
-
関連:認証、転送、暗号化
プロキシプロトコルは、クライアントとリモートサービスがプロキシ接続を確立する際に従う通信仕様です。必要な認証項目、暗号化方式、転送パラメーターはプロトコルによって異なるため、サーバーアドレスが同じでも種別を自由に置き換えることはできません。
サブスクリプションの変換や設定の手動編集では、重要な項目が1つ欠けただけでもハンドシェイクに失敗することがあります。ログに出るタイムアウト、認証失敗、証明書エラーは発生段階が異なるため、使用するプロトコルに沿って項目ごとに確認してください。
- Shadowsocks
-
略称:SS
Shadowsocksは一般的な暗号化プロキシプロトコルです。設定には通常、サーバーアドレス、ポート、パスワード、暗号化方式が含まれます。クライアントとサーバーは同じ暗号化方式を使用する必要があり、項目が一致しないと有効なセッションを確立できません。
設定によってはプラグインや転送オプションが付加されます。これらの拡張パラメーターにはクライアントのカーネル対応が必要です。インポート後にノードを利用できない場合は、変換時にサブスクリプションからプラグイン項目が失われていないか確認してください。
- Trojan
-
よくある構成:Trojan + TLS
Trojanは通常、TLS接続上でプロキシ通信を運びます。主な設定項目はサーバーアドレス、ポート、パスワード、サーバー名、証明書検証です。サーバー名はTLSハンドシェイクに使われ、ノードの表示名や接続先アドレスと同じとは限りません。
証明書エラーを単純にノードの遅延問題として扱うべきではありません。システム時刻、サーバー名、証明書チェーン、中間ネットワークによる干渉などがTLS検証に影響します。ログに出ている具体的なエラーとあわせて判断してください。
- VMessとVLESS
-
関連する転送方式:TCP、WebSocket、gRPC
VMessとVLESSはよく使われる2種類のプロキシプロトコルで、どちらもTCP、WebSocket、gRPC、TLSなどの転送方式と組み合わせられます。名前が似ていても項目を相互利用できるわけではなく、ユーザー識別子、暗号化オプション、フロー制御、転送パラメーターは個別に扱う必要があります。
この種のノードを調べるときは、まずプロトコル本体を確認し、次に転送層の経路、ホスト名、TLS設定を確認します。ポートやポリシーグループだけを変更しても、項目の不一致による接続失敗は解消できないことが多いです。
C-03 · ROUTING
ルールとルーティング
ルールシステムは接続の特徴をポリシーグループへ対応付けます。照合順序、名前解決結果、フォールバックルールが最終的な出口を左右するため、ルールを変更するときは1行だけでなく通信経路全体を確認する必要があります。
- ルールベースルーティング
-
英語:Rule-based Routing
ルールベースルーティングは、ドメイン、宛先IP、送信元IP、プロセス、外部ルールセットなどから接続の出口を決める処理です。一致した接続はプロキシポリシーグループへ渡すことも、直接接続することも、設定に従って拒否することもできます。
ルーティング結果はルールの順序と、クライアントが実際に取得できた情報に左右されます。ドメインがシステム外でIPへ解決されていると、一部のドメインルールは照合に必要な条件を失うことがあります。その場合はDNSモードも確認してください。
- ルールモード
-
画面上の表記例:Rule
ルールモードは、設定内のrulesリストを上から順に確認し、通常は最初に一致したルールでポリシーを決めます。直結、プロキシ、その他の出口を使い分けられるため、すべての通信を同じノードへ送る必要がありません。
ルールモードに切り替えても、ポリシーグループ内のノード選択は有効です。ルールがどのグループへ入れるかを決め、ポリシーグループがそのグループで使うノードや動作を決めます。両者は異なる階層です。
- ポリシーグループ
-
設定キー:proxy-groups
ポリシーグループは複数のノードや他のポリシーを1つの論理的な出口にまとめます。ルールは通常、個別ノードではなくポリシーグループ名を参照します。手動選択、自動テスト、フェイルオーバー、負荷分散などが代表的なタイプです。
ポリシーグループは他のグループを参照できるため、設定が多層の選択関係になることがあります。グループ名を変更する場合は、rulesや他のポリシーグループからの参照も確認しないと、設定の読み込みに失敗したり、意図しない出口へフォールバックしたりします。
- RULE-SET
-
関連:Rule Provider
RULE-SETはメインルールリストから独立したルール集合を参照し、一致した接続を指定したポリシーへ渡します。大規模なドメインやIPのリストを個別に管理でき、メイン設定へすべて記述する必要がありません。
ルール集合は、Provider領域でソース、behaviorタイプ、更新周期を先に宣言する必要があります。リモートファイルを取得できない、形式とbehaviorが一致しない、参照名を誤っているといった場合、対応するRULE-SETは想定どおりに動作しません。
- GeoIP
-
例の意味:GEOIP,CN,DIRECT
GeoIPは、対象IPが地理データベースでどの地域に属するかを基に照合します。ドメイン文字列ではなくIPを扱うため、DNSの解決先、データベースのバージョン、コンテンツ配信ネットワークの振り分けに影響されます。
同じドメインでも、ネットワーク環境によって異なる地域のアドレスへ解決されることがあり、GeoIPの結果も変わります。ドメイン単位で正確に制御したい場合は、通常、対象のGeoIPルールより前にドメインルールを置きます。
- MATCH
-
役割:最終フォールバック
MATCHは通常、ルールリストの末尾に置かれ、それまでのルールに一致しなかった接続を受け取ります。未知の通信に対するデフォルトの出口を決めるため、設定確認では見落とせない項目です。
MATCHを早い位置に置くと、後続ルールが照合されません。多くの接続がMATCHへ入る場合は、前方のルールが正常に読み込まれているか、ドメイン情報を取得できているか、ルールタイプが現在の通信に適しているかを確認してください。
C-04 · CONFIG
サブスクリプションと設定
サブスクリプションはリモートコンテンツを届け、YAMLは設定構造を表し、クライアントは保存・更新・読み込みを担います。この3つを分けて確認すると、ダウンロード失敗、解析失敗、実行失敗を切り分けやすくなります。
- サブスクリプション
-
よくある形式:リモートURL
サブスクリプションは、サービス提供者が公開し定期的に更新する設定ソースです。ノード、ポリシーグループ、ルール、変換済みの完全なYAMLなどを含む場合があります。クライアントはURLを保存し、手動操作または設定した周期でコンテンツを再取得します。
サブスクリプションをブラウザで開けても、返される内容が現在のクライアントに適しているとは限りません。解析に失敗した場合は、レスポンス形式、項目の互換性、アクセス権限、中間変換サービスの出力も確認してください。
- YAML
-
設定の拡張子:.yaml または .yml
YAMLはClash設定でよく使われるテキストシリアライズ形式です。インデントで階層を表し、コロン、ハイフン、リストで項目を構成します。インデントや文字構造に敏感なため、コピー時にタブが混入したり空白の階層が崩れたりすると解析に失敗することがあります。
構文が正しいことは、ドキュメントを解析できることを示すだけで、項目が現在のカーネルに対応しているとは限りません。設定を編集したら、まず読み込みログを確認し、ポリシーグループ、DNS、ルールが完全に表示されるか検証してください。
- Proxy Provider
-
設定キー:proxy-providers
Proxy Providerはノード一覧をメイン設定から独立したソースへ分離します。ローカルファイルまたはリモートURLを利用でき、更新間隔とヘルスチェックも設定できます。ポリシーグループはuse項目でProvider内のノードを参照します。
Providerの更新成功は、メインサブスクリプションも置き換わったことを意味しません。両者にはそれぞれ更新経路があります。ノード一覧が古い場合は、現在のノードがメイン設定由来か、どのProvider由来かを確認してください。
- 設定ファイル
-
クライアント画面での呼び方:Profile
設定ファイルは、ポート、DNS、ノード、ポリシーグループ、ルールなどを保存するYAMLドキュメントです。クライアントは複数の設定を保存できますが、通常カーネルに読み込まれるのは現在選択中の設定だけです。
設定を切り替えると、ポリシー一式と待受パラメーターが変わります。ノードだけを切り替える操作とは異なります。変更が反映されない場合は、現在の設定を編集しているか、必要な再読み込みやカーネル再起動を行ったか確認してください。
- 自動更新間隔
-
よく使われる単位:秒、分、時間
自動更新間隔は、クライアントまたはProviderがリモートコンテンツを再取得するまでの待機時間です。短くすると変更を早く取得できますがリクエスト数が増え、長くするとノードやルールが古い状態のまま長く残る可能性があります。
更新間隔を変更しても、すでに使えなくなったサブスクリプションURLは直りません。手動更新も失敗する場合は、まずリンクの到達性、レスポンス状態、プロキシループ、サブスクリプション形式を確認してから周期を調整してください。
C-05 · NETWORK
ネットワークと診断
接続問題は、名前解決、ローカル待受、システムルーティング、リモートハンドシェイクにまたがることがあります。診断では障害がどの段階で起きたかを記録してから該当ログを確認し、1回の遅延テストだけで全体を判断しないようにします。
- DNS
-
英語:Domain Name System
DNSはドメインをIPアドレスへ変換します。Clash Metaでは上流の名前解決サーバー、代替の解決経路、ルーティング動作を設定し、ドメイン検索とプロキシルールを連携させられます。
ドメインを解決できるか、名前解決リクエストがどの経路を通るか、接続が最終的にどの出口を使うかは、関連していますが別の問題です。DNSを変更したら設定を再読み込みして新しい接続を確立し、古いキャッシュの影響を避けてください。
- Fake-IP
-
設定値:enhanced-mode: fake-ip
Fake-IPモードはアプリに予約アドレスを返し、カーネルが予約アドレスと元のドメインの対応関係を管理します。そのアドレスへ接続すると、カーネルはドメイン情報を復元してからドメインルールと実際の名前解決を適用できます。
一部のLAN機器、特殊なドメイン、実際の名前解決結果を必要とするアプリでは、除外リストへの追加が必要になる場合があります。LAN検出、ログイン認証、特定アプリに異常があるときは、DNS設定をすべて削除するのではなくfake-ip-filterを確認してください。
- DNSリーク
-
診断対象:名前解決の経路
DNSリークとは、ドメイン検索が想定した設定済みの名前解決経路を通らず、別のネットワークインターフェース、システムDNS、または予定していない上流サーバーへ渡される状態です。検索経路の逸脱を示すもので、すべての接続がプロキシを迂回することと同義ではありません。
検証時は、システムDNS、ブラウザのセキュアDNS、TUN設定、Clashのログを同時に確認してください。検査ページに表示された名前解決サービスだけではリーク元を断定できないため、現在のネットワークと上流設定も照合する必要があります。
- 遅延
-
よく使われる単位:ms
遅延は、テストリクエストを送信してから応答を受け取るまでの時間です。クライアントに表示される数値は通常、指定されたテスト先を対象としており、その時点の経路、ハンドシェイク、宛先の応答状態だけを反映します。
遅延が小さくても大容量ファイルの転送速度が高いとは限らず、すべてのWebサイトが同じ経路を通ることも保証しません。ノード選択では接続の安定性、パケットロス、帯域幅、対象サービスへの実際のアクセス結果も確認してください。
- システムプロキシ
-
関連:HTTP、HTTPS、SOCKS
システムプロキシは、OSのプロキシ設定をClashのローカル待受ポートへ向け、設定に従うアプリのリクエストをカーネルへ渡します。システム設定を無視するアプリは通常対象外で、すべてのUDP通信を自動的に取り込むわけでもありません。
クライアントを終了する前にシステムプロキシを元の状態へ戻すと、停止したローカルポートをシステムが参照し続けるのを防げます。ブラウザは使えるのに他のアプリが使えない場合は、そのアプリがシステムプロキシに対応しているか確認し、必要ならTUNモードを検討してください。
- プロキシループ
-
よくある症状:更新タイムアウト、接続の繰り返し
プロキシループは、プロキシリクエストが同じプロキシ入口へ戻され、経路上で繰り返し転送される異常状態です。サブスクリプション更新、ノード接続、ローカルサービスがシステムプロキシを誤って継承すると、ループが発生することがあります。
トラブル対処では、一時的にシステムプロキシを無効にし、サブスクリプションのリクエストがプロキシ経由になっていないか確認します。アプリの除外項目とTUNルートも確認してください。ログに同じ宛先とローカルポートへの接続が繰り返し記録される場合、ループを判断する重要な手がかりになります。