01 / CORE & CLIENT
コアとクライアント
クライアントは管理を、コアは設定の実行を担います。まず役割を区別し、機能の対応状況と設定の適用先を確認しましょう。
- mihomomihomo core
- Clash Metaから派生したプロキシコアで、プロトコル接続、DNS処理、ルール照合を担います。Clashエコシステムの複数のクライアントで実行コンポーネントとして利用されています。クライアント名にmihomoが含まれているとは限らないため、設定画面やコア情報で実際に使われているコアを確認してください。新しいプロトコルやフィールドの対応状況は、現在のコアのバージョンと関連ドキュメントで確認しましょう。インストーラーの名前だけでは判断できません。
- Clash MetaClash Meta
- Clashエコシステムでコア機能を拡張していたプロジェクトの旧名称で、後に使われるmihomoという名称へとつながっています。古いガイドやサブスクリプションの分類、一部のアプリ名には、現在もMetaの表記が残っています。「Meta対応」とあっても、Clashという名前のクライアントならすべて使えるという意味ではありません。対象のフィールド、プロトコルパラメーター、コアのバージョンを確認してください。
- クライアントClient
- ユーザーが直接操作するアプリケーションで、サブスクリプション管理、ノード選択、接続状況の確認、システム設定などの画面を提供します。Clash Verge Revはこの層にあたり、通常は制御インターフェースを通じてコアを管理します。同じコアを使うクライアント同士でも、設定のマージ、権限管理、ログ表示は異なる場合があります。ガイドを参照する際は、実際の画面でボタンの位置を確認してください。
- コアCore
- 実行設定を読み込んで接続を確立するソフトウェアコンポーネントです。待ち受けポート、DNS処理、ルールによる振り分けを担います。クライアントの更新時にコアも更新される場合と、コアの更新が別の画面から行われる場合があります。互換性の問題を調べるときは、クライアントとコアのバージョン、エラーが出たフィールドを記録してください。コアの系譜についてはプロトコルガイドをご覧ください。
02 / PROTOCOLS
プロキシプロトコル
プロトコルはクライアントとサーバー間の通信方法を定めます。ノードのパラメーターはサーバー側の設定と一致させる必要があり、種類名を書き換えて別のプロトコルに変えることはできません。
- ShadowsocksSS
- 共有鍵と指定された暗号方式を使ってプロキシ接続を確立するプロトコルです。ノードには通常、サーバーアドレス、ポート、パスワード、暗号方式が含まれます。クライアントがノードの暗号方式とオプションのプラグインに対応している必要があります。インポート後に認証やハンドシェイクのエラーが発生した場合は、まずこれらのパラメーターを確認してください。名前が似た暗号方式でも、相互に置き換えられるとは限りません。
- VMessとVLESSVMess / VLESS
- V2RayやXrayのエコシステムで使われる別々のプロトコルで、設定には通常、ユーザーID、トランスポート方式、セキュリティレイヤーのオプションも含まれます。VLESS自体はペイロードを暗号化しないため、実際のセキュリティはTLSなど外側の設定にも左右されます。接続のトラブル対処では、プロトコルの種類だけでなく、WebSocketのパス、サービス名、その他のトランスポートパラメーターも確認してください。サーバーアドレスだけでは不十分です。
- TrojanTrojan over TLS
- 通常はTLSで通信を保護し、パスワード認証を使うプロキシプロトコルです。証明書の検証は接続時の重要な処理です。サーバー名はTLSハンドシェイク時の名前通知と証明書の検証に使われ、接続先として入力したアドレスとは異なる場合があります。証明書エラーが出た場合は、システム時刻、サーバー名、サーバー証明書を確認してください。証明書検証の無効化を通常の解決策にするのは避けましょう。
- Hysteria2とTUICQUIC-based Proxy Protocols
- QUICをベースにした2種類のプロキシプロトコルです。通常はUDPで通信しますが、認証パラメーターや輻輳制御などの設計は異なります。ネットワークによるUDPの制限、サーバー設定の不一致、通信経路の品質変化などが利用可否に影響します。速度やモバイル端末のバッテリー消費はプロトコル名だけでは判断せず、同じ端末、近いネットワーク環境、同じ用途で実際に比較してください。
03 / RULES & ROUTING
ルールと振り分け
ルールによって接続の出口が決まります。条件だけでなく、ルールの順序や参照先のポリシー名も確認してください。
- ルールベースの振り分けRule-based Routing
- 設定の順にドメインやアドレスなどの条件を照合し、接続を直接接続、プロキシグループ、拒否のいずれかに振り分けます。通常は上から順に調べ、最初に一致したルールが適用されます。そのため、条件の広いルールを先に置くと、後続の詳細なルールに一致しなくなることがあります。ルールの内容はクライアントのルール画面で、実際の適用結果は接続画面で確認すると、ルールファイルだけを見るより原因を特定しやすくなります。
- GeoIPIP-based Classification
- アドレスデータベースを使い、地域やアドレスの種類に応じて接続先IPを照合する仕組みです。たとえば
GEOIP,private,DIRECT,no-resolveはプライベートアドレスの照合に使えます。一致結果はデータベースの内容に依存し、サーバーの物理的な所在地をリアルタイムに証明するものではありません。no-resolveを指定すると、ルール照合のためのドメイン解決を行いません。ただし、接続先IPがすでにある場合は照合に使われることがあります。
- GeoSiteDomain-based Classification
- データベース内のドメイン集合を照合する仕組みで、同じサービスやカテゴリのドメインを1つのルールにまとめる際によく使われます。たとえば
GEOSITE,cn,DIRECTのように指定します。分類名が現在読み込まれているデータファイルに存在する必要があり、データソースによって集合の内容も異なります。ドメイン集合を照合するGEOSITEと、接続先アドレスを照合するGeoIPは、単純に置き換えられません。
- MATCHと組み込みポリシーMATCH / DIRECT / REJECT
MATCHは、通常ルールの末尾に置くフォールバック用のマッチタイプで、前のルールに一致しなかった接続を処理します。DIRECTは直接接続、REJECTは拒否を意味し、どちらも組み込みポリシーです。例にあるPROXYは通常、設定作成者が独自に付けたプロキシグループ名です。同じ名前の定義が設定内に必要で、固定の組み込みキーワードではありません。
04 / GROUPS & NODES
プロキシグループとノード
ノードはサーバーへの接続方法を定義し、プロキシグループは出口の選び方を定義します。画面で選択中のグループやノードは、ルールからの参照関係と合わせて確認してください。
- プロキシグループProxy Group
- 複数のノードや別のプロキシグループをまとめ、ルールから参照できる出口名を定義します。
selectは手動選択、url-testはテスト結果に基づく選択、fallbackは利用可否と順序に応じた切り替え、load-balanceはアルゴリズムによる接続の分散に使います。プロキシ画面でグループを変更しても、そのグループを実際に参照する通信にのみ影響します。グループ同士が入れ子になっている場合もあります。
- ノードProxy Node
- プロキシサーバーへの接続方法を定義する一連のパラメーターで、通常はプロトコル、サーバーアドレス、ポート、認証情報を含みます。ノードの表示名はラベルにすぎず、名前だけで接続先の場所、性能、利用可否は判断できません。エラー報告を共有する際はプロトコルの種類とエラー情報を残しつつ、パスワード、ユーザーID、サブスクリプションURL全体などの機密情報を隠してください。
- 遅延テストLatency Test
- 指定したテスト先へのリクエスト時間から、プロキシ経路の応答状況を推定します。通常、システムコマンドのICMP pingとは異なります。テスト先、接続の再利用、ハンドシェイク、ネットワーク状況などによって結果は変わり、ダウンロード速度を示すものでもありません。タイムアウトはノードが利用できない場合だけでなく、テスト先にアクセスできない場合にも起こります。実際のサービスでの接続と接続ログも合わせて確認してください。
- url-testAutomatic Test Group
- 定期的なテスト結果をもとにノードを自動選択するプロキシグループの種類で、手動での切り替えを減らしたい場合に便利です。
intervalはテスト間隔を設定し、toleranceはわずかな応答時間の変動による頻繁な切り替えを抑えます。テスト先は実際の利用状況を反映するものを選んでください。テスト結果が速くても、すべてのサービスが速くなるとは限りません。ポリシーが変わっても、確立済みの接続がすぐに切り替わるとは限りません。
05 / SUBSCRIPTIONS & CONFIG
サブスクリプションと設定ファイル
サブスクリプションは設定を取得する方法、設定ファイルはコアが読み込むデータです。インポート、選択、上書き、実行はそれぞれ別の段階です。
- サブスクリプションSubscription
- URLからプロキシノードや設定一式を取得・更新する配布方法です。提供元によって返される形式は異なります。設定画面でインポートした後は、該当する設定を選択し、プロキシ画面でプロキシグループを確認してください。サブスクリプションURLにアクセス用の認証情報が含まれる場合があるため、公開しないでください。更新に失敗したときは、何度も更新を押すのではなく、まずURLの有効性と返された内容を確認しましょう。
- YAMLYAML Configuration Format
- Clashの設定でよく使われる構造化テキスト形式で、インデントによって階層を表し、リストやキーと値で設定を記述します。インデントにはタブではなくスペースを使い、特殊文字を含む文字列では引用符にも注意してください。構文を解析できても、構造が基本的に正しいことしか確認できません。現在のコアがフィールドに対応していることや、ノードのパラメーター、ルールの参照先が正しいことを示すものではありません。
- 設定ファイルProfile / config.yaml
- ノード、プロキシグループ、ルール、DNS、待ち受けポートなどを記述するファイルです。サブスクリプションからダウンロードするほか、ローカルからインポートすることもできます。設定画面に保存された元ファイルが、コアの読み込む最終的な設定一式とは限りません。クライアントが全般設定や上書きルールを追加する場合があります。「ファイルを変更したのに動作が変わらない」ときは、選択中の設定、再読み込みの結果、実際に動作中の設定を確認してください。
- 上書きとマージOverride / Merge
- 元のサブスクリプション設定にローカル設定を重ねる仕組みで、ポート、DNS、カスタムルールなどを保持し、サブスクリプション更新後の再編集を減らすためによく使われます。フィールドが置き換えられるかマージされるか、配列をどう扱うか、複数の変更をどの順序で適用するかはクライアントの実装によって異なります。変更前にバックアップを取り、再読み込み後に最終設定を確認してください。同じ設定が別の層から再度上書きされることがあります。
06 / NETWORK & SYSTEM
ネットワークとシステム設定
通信の取り込み、名前解決、出口の選択は、それぞれ別の段階です。スイッチがオンでも、DNS問い合わせや接続が想定どおり完了したとは限りません。
- システムプロキシSystem Proxy
- OSのプロキシ設定をクライアントのローカル待ち受けアドレスに向け、システムプロキシ設定に従うアプリのリクエストをプロキシポートに送ります。システムプロキシを無視するプログラムは取り込めず、コマンドラインツールの環境変数も自動設定されません。有効にした後は、接続画面に対象アプリのリクエストが表示されるか確認してください。設定手順はシステムプロキシ設定ガイドをご覧ください。
- TUNモードTUN Mode
- 仮想ネットワークインターフェースとルーティング設定を使ってIPパケットを受け取る方式で、より多くのアプリの通信を取り込みたい場合に使います。通常、対応するシステム権限やサービスが必要です。取り込みが成功するかどうかは、ルート、インターフェース、DNS、除外設定などにも左右されます。TUNは通信をコアに取り込む方法を示すもので、取り込まれた後はルールに応じて直接接続またはプロキシ接続になります。全通信をプロキシ経由にするモードと同じではありません。
- DNSDomain Name System
- ドメイン名をIPアドレスなどのレコードに変換する問い合わせシステムです。名前解決の結果は接続の確立や一部のルール照合に影響します。クライアントDNS、システムDNS、アプリ独自の暗号化DNSが同時に使われ、それぞれ別の問い合わせを処理する場合があります。トラブル対処では、接続先ドメイン、プロキシサーバーのドメイン、リゾルバー自体の通信経路を分けて確認してください。一か所だけを変更して全体を判断しないようにしましょう。
- Fake-IPSynthetic IP Mapping
- プロキシDNSが合成アドレスを返し、コア内部にアドレスとドメインの対応関係を保持する方式です。その後の接続を元のドメインに基づいて振り分けやすくなります。検索結果に合成アドレスが表示されても、実際のWebサイトがそのアドレスを使っているとは限らず、それだけで名前解決の失敗とも判断できません。一部のアプリではフィルター設定によって実アドレスでの名前解決が必要です。変更後は古いDNSキャッシュや既存の接続にも注意してください。
- DNSリークDNS Leak
- DNS問い合わせが想定した名前解決経路から外れる現象です。たとえば指定したリゾルバーで処理するつもりが、別のシステムやアプリの経路から問い合わせが送られる状態を指します。判断する前に設定の意図を確認してください。直接接続での名前解決が必ずしも異常とは限りません。テストページに表示されたリゾルバーの地域だけではDNSリークを証明できないため、アプリの名前解決方式、クライアントログ、実際のDNS設定を照合してください。詳しくはDNSに関するよくある質問をご覧ください。
- UWPループバックUWP Loopback
- 一部のWindowsアプリコンテナーがローカルのループバックアドレスにアクセスする際に関係するネットワーク分離制限です。ローカルプロキシでよく使われる
127.0.0.1もループバックアドレスです。ループバックの免除を設定すると指定アプリからローカルサービスへアクセスできますが、ノードの選択やアプリのプロキシ動作が自動で変更されるわけではありません。特定のストアアプリだけが接続できない場合は、UWPループバックのトラブル対処をご確認ください。ネットワーク設定全体をすぐにリセットする必要はありません。