CORE / CLIENT
コアとクライアント
画面、通信の入口、プロキシ処理を実行するプログラムを区別しましょう。
- Mihomoコア Mihomo core
- Mihomoは、プロキシプロトコルの接続、ルールの照合、DNS処理を担うプログラムの中核で、設定には通常YAMLを使います。コア自体は、サブスクリプション管理画面を備えたデスクトップアプリやモバイルアプリとは異なります。単独で動かす場合は、通常、設定ファイルやコマンドライン、制御インターフェースから管理します。GUIクライアントを使う場合は、クライアントがコアを呼び出します。
- Clash Meta Former project name
- Clash Metaは、Mihomoプロジェクトで以前使われていた名称です。旧チュートリアルやサブスクリプションの説明、クライアント名の一部には現在も残っています。名称の似た設定を見つけても、すべての項目が共通して使えるとは限りません。互換性を確認するときは、アプリ名にMetaが含まれるかではなく、実際に使われているコアとそのバージョンの対応状況を確認してください。
- クライアント Client application
- クライアントは、サブスクリプションのインポート、プロキシグループの選択、ログの確認、システムネットワーク設定などを行う画面を提供します。画面の機能、権限管理、内蔵コアは個別に更新されるため、同じコアを使っていても操作感は異なります。クライアントを比較するときは、対応プラットフォーム、設定の上書き方法、通信の取り込み方も確認しましょう。詳しくはクライアントの選び方をご覧ください。
- システムプロキシ System proxy
- システムプロキシは、ローカルのHTTPやSOCKSなどのプロキシ入口をOSの関連設定に登録し、その設定に従うアプリのリクエストをコアへ渡します。一部のゲームやコマンドラインプログラム、独自にネットワーク接続を管理するアプリは、この入口を使いません。システムプロキシを有効にしても、すべての通信が取り込まれるわけではなく、接続が直接接続になるかプロキシノードを経由するかも決まりません。
- ノード Proxy outbound
- ノードは通常、プロキシの出力設定を指し、サーバーアドレス、ポート、プロトコル、認証情報、トランスポートの設定などが含まれます。ノード名は識別用のラベルにすぎず、名前に含まれる地域だけでは実際の出口の場所を証明できません。インポートできたことはデータを読み取れたという意味であり、接続できるかどうかは設定値、サーバーの状態、利用中のネットワークにも左右されます。
PROTOCOL
プロキシプロトコル
プロトコルは通信方式を定めます。下位のトランスポート、認証、TLSはそれぞれ個別に確認してください。
- HTTPプロキシ HTTP proxy
- HTTPプロキシは一般的なアプリケーション層のプロキシインターフェースで、ブラウザーでは通常、アドレスとポートを直接指定できます。HTTPSサイトへアクセスする場合、クライアントは通常CONNECTメソッドでトンネルを確立し、その中でサイトとTLS通信を行います。プロキシ入口自体の暗号化と、サイトがHTTPSを使うことは別の話です。混同しないようにしましょう。
- SOCKS5 SOCKS version 5
- SOCKS5は汎用プロキシプロトコルで、TCP接続を中継できます。UDPの中継には、クライアント、サーバー、アプリのすべてが対応している必要があります。SOCKS5自体に通信の暗号化機能はないため、プロキシポートを使っているだけで経路全体が暗号化されるわけではありません。ドメインをアプリ側で名前解決するか、プロキシに任せるかは、アプリとプロキシ設定によって異なります。
- Shadowsocks Encrypted proxy protocol
- Shadowsocksは、所定の暗号方式と鍵でプロキシ通信を行うプロトコルです。設定では通常、
ssと表記します。クライアントとサーバーで互換性のある暗号方式と認証パラメーターを使う必要があります。異なる世代のプロトコルは、名前を変更するだけでは置き換えられません。ノードがプラグインに依存する場合は、現在のコアがそのプラグインとオプションに対応しているかも確認してください。
- VMess VMess protocol
- VMessは、UUIDなどのパラメーターで認証するプロキシプロトコルで、異なる下位トランスポートと組み合わせて使えます。ノード設定のプロトコル種別、WebSocketなどのトランスポート設定、TLSはそれぞれ別の階層にあり、サーバー側の設定と一致させる必要があります。UUIDが正しいだけでは設定が完全とは限らないため、アドレス、ポート、パス、サーバー名なども確認してください。
- Trojan TLS-based proxy protocol
- Trojanは通常、TLS接続上でプロキシデータを転送し、パスワードで認証します。接続に失敗した場合、ネットワーク接続、TLSハンドシェイク、パスワード認証のどの段階で問題が起きたか、ログで切り分けてください。証明書の検証にはサーバー名や証明書チェーンなどが関係します。証明書検証を無効にする方法を、通常のトラブル対処として使うのは避けてください。
RULE / POLICY
ルールとプロキシグループ
ルールは通信の振り分け先を決め、プロキシグループは実際に使う出口を決めます。
- ルールベースルーティング Rule-based routing
- ルールベースルーティングでは、Ruleモードでドメイン、IP、プロセスなどの条件を設定順に確認し、最初に一致したルールで指定されたプロキシグループへ接続を渡します。具体的な例外ルールは、広い範囲を対象とするルールより前に置くのが基本です。想定と異なる出口になる場合は、設定に対象ドメインが含まれているかだけでなく、実際に一致したルールとプロキシグループの選択を確認してください。
- プロキシグループ Proxy group
- プロキシグループは、ノードやほかのプロキシグループをまとめた論理上の出口で、ルールから参照できます。
selectは手動選択、url-testはテスト結果に基づく選択、fallbackは利用可否と設定順に基づく切り替えに使います。グループ名は参照先と一致させてください。グループ内のノードを切り替えると、そのグループを参照する新しい接続には反映されますが、確立済みの接続が必ず移行するとは限りません。
- GeoIP IP geolocation matching
- GeoIPは、IPアドレスの地域情報をもとに照合します。たとえば、
GEOIP,CN,DIRECTのように指定します。判定対象はアドレスのデータであり、サービスの登記上の所在地やユーザーの居住地ではありません。共有インフラ、IPアドレスの割り当て変更、データベースの更新状況によって判定が変わることがあります。特定のサイトを正確に処理したい場合は、ドメインルールも併用できます。
- GEOSITE Domain category matching
- GEOSITEは、ドメイン分類データを使ってサービスやサイトの集合を照合します。たとえば、
GEOSITE,category-ads-all,REJECTのように指定します。分類名、対象範囲、更新頻度は利用するデータソースによって異なり、すべてのデータソースに同じ分類が含まれるわけではありません。サーバーのIPアドレスから地域を判定するGeoIPとは異なり、ドメインの集合を照合します。
- MATCH Catch-all rule
- MATCHは照合条件を付けないフォールバックルールで、通常は
rulesリストの末尾に置きます。たとえば、MATCH,PROXYのように指定します。この場合、PROXYは設定内に存在するノードまたはプロキシグループを指し、固定の組み込み出口ではありません。MATCHをリストの前方に置くと、一致した接続は後続のルールで処理されなくなります。
DNS / NETWORK
DNSとネットワークモード
通信の取り込み、ドメインの名前解決、接続テストはそれぞれ別の処理です。
- TUNモード Virtual network interface
- TUNモードは、仮想ネットワークインターフェースとルーティング設定を使って通信をコアへ送ります。システムプロキシ設定に従わないアプリにも対応できます。変わるのは通信をコアへ取り込む方法であり、RuleやGlobalなどの出力モードに取って代わるものではありません。実際に取り込まれる範囲は、ルート、除外設定、システム権限、クライアントの実装によって異なります。有効にした後は、LANやほかのVPNとの互換性も確認してください。
- DNS Domain Name System
- DNSは、ドメインに対応するアドレスなどのレコードを問い合わせる仕組みです。名前解決の結果は、その後の接続先や一部のIPルールの判定に影響します。MihomoのDNS設定では、コアの名前解決動作と関連する問い合わせ経路を制御します。ただし、DNSサービスを有効にしただけで、システムやすべてのアプリがそれを使うわけではありません。ブラウザーのセキュアDNS、アプリ独自の名前解決、システムの名前解決は個別に確認してください。
- Fake-IP Synthetic address mapping
- Fake-IPは、アプリに仮想アドレスを返し、コア内でそのアドレスと元のドメインの対応関係を管理するDNS拡張モードです。コアが接続を受け取ると、この対応情報を使ってドメインを保持し、ルール判定を続けられます。実際の名前解決結果を必要とするLAN内サービスや特定のアプリに問題がある場合は、
fake-ip-filterを使って切り分けてください。ドメインをフィルターに追加しても、直接接続が指定されるわけではありません。
- DNSリーク DNS leak
- DNSリークは通常、問い合わせが想定した経路を通らず、意図しないDNSサービスに届く状態を指します。ブラウザーで個別に有効にしたセキュアDNS、アプリ独自の名前解決、通信が取り込まれていないシステムリクエストなどが、経路の違いを生むことがあります。検査ページに表示されるDNSサービス名は手がかりのひとつです。名前だけで結論を出さず、システム設定、ブラウザー設定、コアのログも確認してください。
- 遅延テスト Latency test
- クライアントの遅延テストでは通常、指定した宛先へリクエストを送り、プロキシ経路の応答を確認します。結果はテスト先、名前解決、接続ハンドシェイク、ネットワークの混雑状況、テストの実装に左右されるため、クライアントが異なる結果を単純に比較できるとは限りません。テストに成功してもすべてのサイトへアクセスできるとは限らず、遅延が小さくてもダウンロード速度が速いとは限りません。
SUBSCRIPTION / CONFIG
サブスクリプションと設定ファイル
内容の構造を確認してから、インポート、更新、実際の読み込みを区別しましょう。
- サブスクリプション Subscription
- サブスクリプションは、リンクから更新可能なノード情報や設定を取得する方法で、特定のプロキシプロトコルを指すものではありません。返される内容はノード情報だけの場合も、DNS、プロキシグループ、ルールなどを含む完全な設定の場合もあります。リンクには認証情報が含まれることが多いため、スクリーンショットやログを共有するときは必ず隠してください。実際のインポート手順はサブスクリプションのインポートガイドをご覧ください。
- サブスクリプション形式 Subscription format
- サブスクリプション形式とは、リンクから返されるデータの構造です。完全なYAML設定、ノード一覧、エンコードされた共有リンクの集合などがあります。ファイルの拡張子やリンクの見た目だけでは、形式が正しいとは判断できません。クライアントのインポート機能がその構造に対応しているか確認してください。完全な設定を、ノードデータ専用のproviderとしてそのまま使うことは通常できません。解析に失敗した場合は、ログインページやエラーページが返っていないか、リンクが無効になっていないかを先に確認します。
- YAML Structured configuration text
- YAMLはMihomoの設定に使われる構造化テキスト形式で、インデント、キーと値、リストによって階層を表します。インデントにはスペースを使い、同じ階層の項目はそろえてください。特殊文字を含む文字列には引用符が必要な場合があります。YAMLの構文が正しいことは、構造を解析できるという意味にすぎません。項目名や値、プロキシグループの参照がコアの要件を満たすかどうかは、設定チェックとログでも確認してください。
- rule-providers Rule set providers
rule-providersは、ローカルまたはリモートのルールセットと、内容の種類、形式、更新方法を定義します。定義後は、rules内でRULE-SETを使ってルールセットを参照し、適用する出口のプロキシグループを指定してください。ルールセットが提供するのは照合条件であり、ノードを自動的に選ぶものではありません。ノード情報を提供するproxy-providersとは区別してください。
- 設定の更新 Profile update
- 設定の更新は、サブスクリプションやリモートリソースを再取得する操作で、クライアントやコアのアップデートとは異なります。ダウンロードの成功、設定の解析、コアによる新しい設定の読み込みは、それぞれ個別に確認してください。リモート更新によって、サブスクリプションの内容を直接編集した変更が上書きされることがあります。継続的にカスタマイズする場合は、クライアントが対応する上書き機能を使うのがおすすめです。トラブル対処の手順は日常メンテナンスの章をご覧ください。