Mihomoコア
Mihomoは接続処理、ルール判定、プロキシプロトコル、DNSなどのネットワーク処理を担うコアで、以前はClash.Metaという名称でした。Clash Verge Revはグラフィカルな操作画面を提供しますが、実際のネットワーク通信はコアが処理します。そのため、クライアントの機能とコアの対応機能は分けて確認してください。設定の互換性に問題がある場合は、クライアント名だけで判断せず、実行中のコアと対応フィールドを確認しましょう。
コア関連の設定を見る →用語集 / 設定項目インデックス
Clash用語：コア・サブスクリプション・ルール
まず、通信がどのようにクライアントへ取り込まれるかを確認し、次にルールで接続先がどう選ばれるかを見ていきます。設定項目別に25の基本用語をまとめており、各項目はURLのアンカーから直接参照できます。実際の操作は入門ガイドまたは応用設定をご覧ください。
確認の流れ：クライアントが通信を取り込む → ルールがポリシーを選ぶ → ノードが接続を確立する。DNSはドメイン名の名前解決に必要なアドレスを返し、サブスクリプションとYAMLは各工程の設定を提供します。
コアとクライアント
画面、通信の入口、ネットワーク処理にはそれぞれ異なる役割があります。スイッチが有効でも、すべてのアプリの通信がコアに届いているとは限りません。
クライアント
クライアントは設定、プロキシグループ、接続履歴、ログ、システム設定を管理するアプリです。Clash Verge Revはデスクトップ向けのGUIクライアントです。クライアント、コア、リモートのプロキシサービスは別々の役割を持ち、画面で設定を管理し、コアが接続を処理し、リモートサービスがプロキシの出口を提供します。インストール後、想定どおりに接続するには、対応する設定を読み込み、適切なポリシーを選ぶ必要があります。
クライアントと対応プラットフォームを見る →システムプロキシ
システムプロキシは、ローカルプロキシのアドレスとポートをOSに登録し、この設定に従うアプリの通信をクライアントへ転送します。ネットワーク通信をすべて取り込む機能ではありません。コマンドラインツール、ゲーム、独自にネットワークを管理するアプリなどは、システムプロキシを参照しない場合があります。ブラウザーは接続できるのに特定のアプリが直接接続する場合は、まずそのアプリのプロキシ設定を確認し、必要に応じてTUNモードを検討してください。
TUNモード
TUNモードは仮想ネットワークインターフェースとルーティングを使って、取り込み対象の通信をコアへ転送します。システムプロキシに従わないアプリで役立ちます。通信がコアに届いた後も、ルールに従って直接接続するかプロキシを使うかが決まるため、TUNを有効にしてもすべての接続がプロキシ経由になるわけではありません。有効化には通常、システム権限やサービスのサポートが必要です。他のVPNと併用する場合は、ルートやDNSの競合も確認してください。
混合ポート
混合ポートは、1つのローカル待ち受けポートでHTTPとSOCKSのプロキシ接続を受け付けます。YAMLではmixed-portに対応し、Clash Verge Revでは7897がよく使われます。ポート番号に決まりはありませんが、変更した場合は手動でポートを指定しているアプリも更新してください。他のプロセスによるポートの使用、待ち受けアドレスの誤り、LANアクセスの許可設定は、それぞれ分けて確認しましょう。
プロキシプロトコル
プロトコルによってクライアントとサーバーの通信方法が決まります。パラメーターはサーバー側の設定に合わせる必要があります。プロトコル名だけでは、速度や安定性は判断できません。
ノード
ノードはコアで使うリモートプロキシ接続のパラメーター一式です。通常、サーバーアドレス、ポート、プロトコル、認証情報が含まれ、表示名は識別用のラベルにすぎません。ノードに接続できても、すべてのサイトにアクセスできるとは限りません。ルール、接続元のネットワーク、接続先のサービスもあわせて確認してください。一覧に表示される遅延は、テスト先と測定方法によって変わります。ダウンロード速度に換算できる値ではなく、実際の通信の成功を保証するものでもありません。
Shadowsocks
Shadowsocksは、所定の暗号化方式と鍵を使ってプロキシ接続を確立します。設定では通常type: ssと記述します。サーバー、ポート、暗号化方式、パスワードを一つずつ照合してください。プラグインを使うサービスでは、種類とパラメーターも互換性に影響します。読み込み後に接続できない場合は、暗号化方式をむやみに変更せず、サービス提供元の元のパラメーターと照らし合わせましょう。
VMess
VMessはユーザーIDなどを使って認証するプロキシプロトコルで、さまざまなトランスポート方式やTLS設定と組み合わせて利用できます。ノード情報にはユーザーIDだけでなく、パス、Host、サーバー名などのトランスポートパラメーターが含まれる場合があります。関連情報が欠けるとハンドシェイクに失敗することがあります。認証の問題をポート障害と取り違えないよう、システム時刻も確認してください。
VLESS
VLESSはユーザーIDなどの情報で認証しますが、プロトコル自体に通信の暗号化機能はありません。実際の接続では通常、TLS、REALITYなどのトランスポート設定も必要です。サーバー名、公鍵、トランスポートパスなど、サーバー側が要求するパラメーターはプロトコル名だけでは判断できません。読み込む前に、使用中のコアがその組み合わせ全体に対応しているか確認してください。typeの変更はプロトコル変換ではありません。
Trojan
Trojanは通常、TLS接続でプロキシ通信を転送し、パスワードで認証します。サーバーアドレスに接続できても、ネットワーク経路が到達可能であることを示すにすぎません。その後の接続には、正しいパスワード、サーバー名、証明書の検証結果が必要です。証明書エラーが発生した場合は、システム時刻、ドメイン名、サーバー証明書を優先して確認してください。証明書検証の無効化を通常の解決策にしないでください。
ルールとプロキシグループ
ルールは「この接続をどこへ振り分けるか」、プロキシグループは「どの出口を選ぶか」を決めます。まず一致したルールを確認し、次にグループ内の選択を確認しましょう。
ルールベースの振り分け
ルールベースの振り分けでは、ドメイン、IP、ポートなどの条件に応じて、接続を直接接続、拒否、または指定したポリシーへ振り分けます。ルールモードでは通常、上から順に判定し、一致したルールのポリシーを適用します。そのため、詳細なルールは条件の広いルールより前に置くのが基本です。サイトの接続先が想定と異なる場合は、まず接続履歴で実際に適用されたルールを確認してから順序を見直してください。ノードを切り替えるだけではルーティング結果が変わらないことがあります。
ルールの管理方法を見る →プロキシグループ
プロキシグループはノードや他のグループをまとめ、ルールから参照できる名前を付ける設定です。接続先の選び方はグループのタイプで異なります。selectは手動選択、url-testは指定条件でのテスト結果に基づく選択、fallbackは順番に利用可能な項目を使います。ルールに記述するグループ名は設定と一致させてください。テスト結果は、指定されたテスト先とその時点のネットワーク環境での結果です。
ドメイン末尾のルール
DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致します。たとえばDOMAIN-SUFFIX,github.com,PROXYは、設定にPROXYポリシーがあれば、github.comとそのサブドメインを対象にできます。任意の文字列を含むかどうかの判定ではないため、無関係なドメインに同じ文字列が含まれているだけでは一致しません。特定のドメインだけに一致させる場合はDOMAINを使います。
GeoIP
GeoIPは、IPアドレスデータベースの登録情報に基づいて接続を分類します。たとえばGEOIP,CN,DIRECTは、該当する分類の接続先を直接接続に振り分けます。判定結果は実際の接続先IPとローカルのデータベースによって決まり、企業の登記上の所在地、アクセスしたユーザーの位置とは関係ありません。CDNを利用するサイトは異なるIPアドレスに解決される場合があります。振り分けが誤っていると感じたら、DNSの結果とデータベースの更新状況を確認してください。
MATCHフォールバックルール
MATCHにはドメインやIPの条件を追加せず、それまでのルールに一致しなかった接続を処理します。通常はrulesの最後に置きます。MATCH,PROXYは、残りの通信をPROXYという名前のポリシーへ振り分ける指定であり、特定のノードを自動的に選ぶものではありません。先頭に置くと、後続のルールが適用されなくなることがあります。
DNSとネットワーク
名前解決、通信の取り込み、プロキシの出口はそれぞれ別の工程です。まずリクエストがどこから送信されるかを確認し、次に想定した経路を通っているかを調べましょう。
DNS
DNSはドメイン名をIPアドレスなどのレコードに変換します。Webサイトへの接続前に行われる一般的な処理です。クライアントのDNS設定には、待ち受けアドレス、上流DNSサーバー、問い合わせのルーティング、キャッシュが関係します。DNSサーバーのアドレスを設定しても、すべてのアプリがそれを使うとは限りません。問題を調べる際は、「名前解決できない」状態と「アドレスは取得できたが接続できない」状態を区別してください。ログの手がかりも対処方法も異なります。
Fake-IP
Fake-IPモードはアプリに仮想アドレスを返し、コアで仮想アドレスと元のドメイン名の対応を管理します。関連する通信がコアに届くと、ドメイン名を使って処理します。ドメイン情報を維持しやすくなりますが、名前解決と接続が正しい経路を通る必要があります。DNSモードを有効にするだけでなく、通信の取り込み設定も確認してください。実際のIPアドレスが必要なLAN内のサービスや特殊なアプリでは、問題に応じて対象外にする範囲を設定できます。
DNS漏れ
DNS漏れは問い合わせが想定した経路から外れ、利用を意図していないDNSサーバーに届く現象です。特定の地域のDNSサーバー名が表示されただけで、必ず問題があるとは限りません。アプリ内蔵の暗号化DNS、システムの名前解決設定、他のVPN、ルーティングルールなどが問い合わせ先を変える場合があります。テスト条件、クライアントのログ、アプリの設定をあわせて確認し、まず「本来どのDNSサーバーに問い合わせる想定か」を明確にして、実際の経路と一致するか調べてください。
ドメイン名スニッフィング
ドメイン名スニッフィングは、接続開始時に確認できる情報から接続先のドメイン名を推定し、ルール判定の手がかりを補います。対象には一部のHTTPリクエスト情報やTLSハンドシェイク情報などがあります。任意のHTTPS本文を復号する機能ではなく、すべての接続でドメイン名を特定できるわけでもありません。検出結果によってルーティングに問題が出る場合は、対象を絞ってスニッフィングや対象範囲の設定を確認し、すべての接続へ安易に広げないでください。
DNSリダイレクト
クライアントのTUN設定では、DNSリダイレクトは通常、条件に合う従来型DNSの問い合わせをコアのリゾルバーへ転送し、まとめて処理することを指します。公共ネットワークなどで悪意を持ってDNSの応答を書き換える行為とは、設定の目的が異なります。文脈に応じて意味を判断してください。従来型DNSのポートを取り込んでも、アプリが独自に送信するDoHやDoTには影響しない場合があるため、アプリ内のDNS設定も確認しましょう。
DNSとTUNの設定を見る →サブスクリプションと設定ファイル
サブスクリプションは設定を配布し、YAMLはその内容を記述し、ローカル上書きは変更を保持します。取得後は、設定が有効になっていることも確認してください。
サブスクリプション
サブスクリプションはリンクを使ってノード一覧や設定全体を配布し、クライアントがリンクにアクセスして内容を取得します。配信形式はサブスクリプションによって異なり、Clash YAML、エンコードされたノード一覧、その他の形式があります。リンクを開けても、現在のクライアントですぐ使えるとは限りません。サブスクリプションURLに個人用のアクセス情報が含まれる場合があります。ログやスクリーンショットを共有する前にURL全体を隠し、第三者に同じアクセス権を使われないようにしてください。
サブスクリプションの追加手順を見る →YAML設定ファイル
YAMLはインデントでマッピング、リスト、階層構造を表します。Clashの設定ではdns、proxies、proxy-groups、rulesなどの項目によく使われます。編集時はスペースでインデントし、同じ階層の項目をそろえてください。リスト項目のハイフンも構造の一部です。構文を解析できても、各フィールドが使用中のコアに対応しているとは限りません。保存後は設定の検証結果と実行ログも確認しましょう。
サブスクリプション変換
サブスクリプション変換では、元のノードや設定をクライアントで読み込める形式に整え、テンプレートを使ってプロキシグループやルールを生成する場合もあります。形式を変換しても、サーバーのパラメーターが補われたり、非対応プロトコルが使えるようになったりするわけではありません。オンラインサービスには元のサブスクリプションURLやノードの認証情報が渡る可能性があります。利用前にサービスの提供元を確認してください。すでに対応形式のサブスクリプションは、そのまま読み込める場合があります。
ローカル上書き
ローカル上書きは、サブスクリプションの設定をもとにローカルの変更を適用する仕組みです。DNS、ルールなどのカスタム設定を保持し、更新のたびに編集し直す手間を省けます。機能によって、フィールドのマージ、リストの置き換え、スクリプト処理など方法が異なり、すべてのリストが自動で追加されるとは限りません。変更前に元の内容を保存し、変更後は最終的に適用された設定を確認してください。特にルールの順序、ポリシー名、リストの内容が想定どおりか確認しましょう。
サブスクリプション更新
サブスクリプションを更新すると、リモートの内容が再取得され、ノードのパラメーター、プロキシグループ、ルールが変わる場合があります。ただし、更新と現在の設定への切り替えは別の操作です。ダウンロード、内容の解析、設定の有効化、コアの再読み込みはそれぞれ別の工程なので、問題が起きたら順番に確認してください。更新間隔はサービス提供元の推奨と実際の利用状況に合わせて設定します。更新後に接続できなくなった場合は、ノード名の変更と、ローカル上書きで参照している項目が引き続き有効かを確認しましょう。