core: mihomo
mihomo コア
mihomoは、旧Clash.Metaプロジェクトで使われていたコアの名称です。プロキシプロトコルの接続、DNS処理、ルール照合を担い、グラフィカルな画面はこれらの機能を操作するための層です。クライアントによって同梱されるコアのバージョンは異なるため、画面が更新されてもコアまで更新されたとは限りません。項目が認識されない、プロトコルが使えないといった場合は、アプリ名だけで判断せず、実際のコアのバージョンと起動ログを確認してください。
# glossary
Clash用語ガイドコア、ルール、ネットワークスタック
用語を整理してから設定を変更しましょう。設定項目のレイヤー別に24語を解説し、通信がmihomoに届く仕組み、ルール照合の流れ、サブスクリプション更新で変わる内容を確認できます。
操作手順を確認するには入門ガイド、OSごとの情報を調べるには全プラットフォーム対応のインストール・設定ガイドをご覧ください。この記事では一般的な概念を説明します。対応項目は、実際に使用するコアとクライアントによって異なります。
# カテゴリ 01 · core-clients
コアとクライアント
画面は操作の入口、コアは接続の処理を担います。まず稼働中のコンポーネントを確認し、設定をどこで変更するか判断しましょう。
GUI / profile / settings
クライアント
クライアントは、サブスクリプションのインポート、ノードの選択、接続状況の確認、ネットワーク制御などを行うアプリです。コアを内蔵する場合も、独立したコアプロセスを管理する場合もあります。システムプロキシや自動起動などの設定はクライアント内に保存され、サブスクリプションファイルに含まれないことがあります。別のクライアントへ移行して同じサブスクリプションを読み込んでも、こうしたローカル設定は引き継がれません。権限や通信の取り込み状態を改めて確認してください。
external-controller
外部コントローラー
外部コントローラーは、コアが画面や管理パネル向けに提供する管理インターフェースです。接続情報やログの確認、プロキシグループの選択切り替えなどに利用できます。アプリからプロキシ通信を送るポートとは用途が異なり、ブラウザーのプロキシ先をコントローラーのポートにしても通常のプロキシとしては使えません。通常はローカルからのみアクセスできるようにし、認証を設定してください。遠隔管理が必要な場合も、アクセス制限を別途設計し、インターネット上にそのまま公開しないでください。
mixed-port
混合ポート
混合ポートは、1つの待ち受け口でHTTPプロキシとSOCKSプロキシの両方を受け付ける設定です。アプリは対応する方式で接続できます。一般的な設定例はmixed-port: 7890ですが、実際のポート番号は使用中のクライアントで確認し、そのまま転記しないでください。ポートが開いていても通信が取り込まれているとは限りません。アプリがそのポートを使っているか、待ち受けアドレス、LANからの接続許可、ファイアウォールの設定を確認してください。
# カテゴリ 02 · proxy-protocols
プロキシプロトコル
プロトコルによって、クライアントからサーバーへの接続方法が決まります。ノードのラベルが同じでも、認証、通信方式、セキュリティ設定をそのまま流用できるとは限りません。
proxies
プロキシノード
プロキシノードは、プロキシの出口へ接続するためのパラメーター一式です。通常はサーバーアドレス、ポート、プロトコル、認証情報が含まれ、TLSや通信方式、UDP対応の設定が加わる場合もあります。ノード名は識別用のラベルにすぎず、実際の出口の場所や接続可否を名前だけで判断することはできません。ノードを選んだ後は接続先のサービスで動作を確認してください。同じサーバー上のノードでも、ポートや通信方式の設定によって結果が異なることがあります。
type: ss
Shadowsocks
Shadowsocksは、双方で合意した暗号方式と認証情報を使ってプロキシ接続を確立します。設定では通常、type: ssと指定します。暗号方式、パスワード、関連プラグインの設定をクライアント側とサーバー側で一致させる必要があります。サーバーアドレスが正しいだけでは接続できません。コアによって対応する暗号方式やプラグインが異なる場合もあります。インポートに失敗したら、ルールモードを切り替える前に、まずこれらの項目を確認してください。
type: vmess
VMess
VMessは、ユーザーIDなどの情報で認証するプロキシプロトコルです。WebSocketなどの通信方式と組み合わせて使い、サーバーの要件に応じてTLSを有効にします。ノードの認証情報、通信経路、ホスト名、TLS設定をまとめて一致させる必要があり、プロトコル名はその一部にすぎません。接続に問題がある場合は、デバイスの時刻も確認してください。認証や通信方式の設定が合っていないときは、DNSを変更しても通常は解決しません。
type: vless
VLESS
VLESSは、軽量なプロキシ認証・データ転送プロトコルです。TLSやREALITYなどのセキュリティ機能と組み合わせて使われることがありますが、プロトコル名だけで通信が暗号化されているとは判断できません。ユーザーID、通信方式、サーバー名、セキュリティ層のパラメーターをサーバー側に合わせてください。インポート後にコアが未対応項目を通知した場合は、安全設定をむやみに削除して無理に読み込ませず、コアの機能と設定ファイルの形式を確認してください。
type: trojan
Trojan
Trojanは通常、TLS接続上でプロキシ通信を行い、パスワードで認証します。設定に追加の通信パラメーターが含まれることもあります。サーバーへの接続アドレスと、TLSで使うサーバー名は別の情報です。アドレスに接続できても、証明書の検証が通るとは限りません。証明書エラーが出た場合は、ホスト名、デバイスの時刻、サーバー証明書の状態を確認してください。証明書検証のスキップを通常の対処法として使わないでください。
# カテゴリ 03 · rules-routing
ルールとトラフィック振り分け
ルールは通信先を判定し、プロキシグループは出口を提供します。接続ログでは、適用されたルールと実際に使われたノードをあわせて確認してください。
mode: rule / global / direct
ルールベースの振り分けとプロキシモード
ルールモードでは設定したルールに基づいて出口を決め、グローバルモードではグローバルポリシーを使います。ダイレクトモードでは通常、リモートのプロキシ出口を経由しませんが、コアのDNS設定などが影響する場合はあります。これらのモードが処理するのは、すでにコアに届いている通信です。すべてのアプリの通信をコアに取り込む機能ではありません。通常はルールモードから使い始めます。一時的にグローバルモードに切り替えるとルールの問題かノードの問題かを切り分けやすくなりますが、通信が取り込まれているかの確認は別途必要です。
proxy-groups
プロキシグループ
プロキシグループは、複数のノードやほかのポリシーをまとめ、ルールから参照できる出口として扱います。ルールでグループ名を指定すると、グループの種類と現在の状態に応じて使用するノードが決まります。selectは手動選択、url-testは測定結果に基づく自動選択、fallbackは通常、順番に利用可能な項目を選びます。自動選択グループを使っても、すべてのサイトに最速の経路が選ばれるとは限りません。測定先と実際の接続先は異なる場合があります。
rules / MATCH
ルールの照合順序
通常のrulesリストは上から順に確認され、最初に一致したルールのポリシーが適用されます。同じ接続に対して、後続のルールが出口を再選択することはありません。範囲の広いルールを先に置くと、後続の細かなルールが適用されないことがあります。カスタムルールは内容だけでなく配置も重要です。MATCHは通常、最後のフォールバックとして置きます。変更後は接続を張り直してから照合ログを確認してください。確立済みの長時間接続は、すぐに出口が切り替わらない場合があります。
GEOIP / GEOSITE
GeoIPとGeoSite
GeoIPはIPデータベースに基づいてアドレスを分類し、GeoSiteはドメインのリストに基づいてサイトを分類します。照合する対象も参照するデータも異なります。IPルールでは、先にドメインを名前解決する必要が生じる場合があり、実際の動作はルールのパラメーターやコアの設定にも左右されます。ドメインの分類とIPの所属地域を同じものとして扱わないでください。データベースの更新が遅れることもあります。振り分けが誤っている場合は、実際の接続先と適用されたルールを確認し、より具体的なルールで修正してください。
rule-providers / RULE-SET
ルールプロバイダー
ルールプロバイダーはrule-providersで外部ルールセットを管理し、メインのルール一覧からRULE-SETで参照します。サービスごとにルールを分けて管理するのに便利です。ルールセットの動作タイプ、ファイル形式、内容が一致していなければ、ダウンロードできても正しく読み込めません。特定のサービスの振り分けに問題が起きたら、ノードの稼働状況だけでなく、ルールセットの更新日時、読み込みログ、参照位置も確認してください。
# カテゴリ 04 · dns-network
DNSとネットワークスタック
名前解決の経路、通信の入口、接続の出口はそれぞれ別の要素です。機能を有効にした後は、ルーティングとアプリ固有の通信動作も確認してください。
DNS query path
DNSリーク
DNSリークとは、ドメインの問い合わせが想定した名前解決経路を外れ、意図しないDNSサービスに送られる状態です。Webページが開くかどうかだけを指すものではありません。システムDNS、ブラウザーのセキュアDNS、アプリ内蔵の名前解決機能が結果に影響する場合があります。TUNを有効にしても、個別の確認が不要になるわけではありません。問い合わせ記録、コアのDNSログ、通信を取り込む範囲をあわせて確認してください。テストページに表示されたDNS事業者名だけで結論を出すことはできません。
enhanced-mode: fake-ip
Fake-IP
Fake-IPモードでは、アプリに仮想アドレスを返し、コアがそのアドレスとドメインの対応を保持します。通信がコアに届いた後、ドメインに基づいて振り分けや接続先を決定します。仮想アドレスが見えてもDNS設定の誤りとは限らず、接続先サーバーの実アドレスとして疎通確認に使うこともできません。LAN内の通信やアドレス検証を行う一部のアプリでは例外設定が必要になる場合があります。対象のドメインを特定してから個別に除外し、例外の範囲をむやみに広げないでください。
tun: enable
TUNモード
TUNは仮想ネットワークインターフェースでIPパケットを受け取り、システムプロキシに従わないアプリの通信も一部取り込めます。通常、管理者権限またはOSのVPN許可が必要です。実際の取り込み範囲はルーティング、除外設定、DNS、クライアントの実装によって異なり、スイッチが有効でもすべての通信が対象とは限りません。有効にした後は、対象アプリ、LANへのアクセス、DNSをそれぞれ確認してください。競合が起きた場合は、ほかのVPNや仮想ネットワークアダプターも確認しましょう。
system proxy → local listener
システムプロキシ
システムプロキシは、OSのプロキシ設定をクライアントのローカル待ち受けアドレスとポートに向ける機能です。設定に従うアプリだけがリクエストをコアに送ります。ゲーム、コマンドラインツール、独自のネットワーク処理を行うアプリは、システムプロキシを無視する場合があります。ブラウザーで接続できても、ほかのアプリの通信が取り込まれているとは限りません。クライアントを終了または削除した後に通信できなくなった場合は、OSにプロキシ設定が残っていないか確認してください。初回接続はシステムプロキシの設定手順を参考にしてください。
nameserver / DoH / DoT
DNSアップストリーム
DNSアップストリームは、クライアントがドメインを問い合わせる際に使う名前解決サービスです。従来のDNS、DNS over HTTPS、DNS over TLSなどで通信できます。問い合わせが暗号化されているかと、ダイレクト接続かプロキシ経由かは別の問題です。DoHを選んでも、DNS通信が自動的にプロキシを経由するわけではありません。アップストリームにドメイン名を指定する場合は、その名前の初回解決も必要です。初期解決が完了できない循環が起きないよう、コアの名前解決設定と依存関係を確認してください。
# カテゴリ 05 · subscription-config
サブスクリプションと設定ファイル
まずサブスクリプションに何が含まれるかを確認してから、変更する場所を決めましょう。ノードの更新、ルールの更新、クライアントのアップグレードは別々の操作です。
subscription / profile
サブスクリプション
サブスクリプションは、リンクを使ってノードや設定一式を配布・更新する仕組みです。プロキシプロトコルではなく、同じ内容をすべてのクライアントがそのまま認識できるとは限りません。リンクによってはClashのYAML一式を返し、ノード一覧のみ、または別形式を返す場合もあります。インポート前に、サービス提供元が示す対応形式を確認してください。リンクにアクセス用の認証情報が含まれることがあるため、スクリーンショット、ログ、オンライン変換サービスなどに公開しないでください。手順はサブスクリプションリンクのインポートをご覧ください。
config.yaml
YAML
YAMLはインデントで階層を表すテキスト形式です。Clashの設定では、ノード、プロキシグループ、ルール、DNSなどを記述します。インデントにはタブではなくスペースを使ってください。同じ階層の項目の位置をそろえ、特殊文字を含む値は適切に引用符で囲み、リスト項目も正しい階層に追加します。構文を解析できても、現在のコアがすべての項目に対応しているとは限りません。保存後は読み込みログと最終的に適用された設定を確認してください。
proxy-providers / use
プロキシプロバイダー
プロキシプロバイダーはproxy-providersで外部ノードの一覧を管理し、プロキシグループからuseで参照します。ノードの取得元とローカルのルールを分けて管理するのに便利です。設定一式を含むサブスクリプションとは異なり、ノード一覧だけを取得しても、使えるプロキシグループ、ルール、DNS設定がそろうわけではありません。追加後は取得状況、内容の形式、グループからの参照を確認してください。ファイルを取得できても、ノードが目的のプロキシグループに表示されないことがあります。
delay / test URL / timeout
遅延テスト
遅延テストでは通常、クライアントが指定ノードを経由して測定先にアクセスするまでの時間を計測します。測定先、サーバー負荷、現在のネットワーク経路によって結果は変わります。数値が低くてもダウンロード速度が速いとは限らず、タイムアウトしてもすべてのサービスが利用できないとは限りません。ノードを選ぶ際は、測定結果と実際の接続先へのアクセスをあわせて確認し、接続パネルで想定した出口が使われているか確かめてください。詳しくはノードの速度測定と接続確認をご覧ください。
update / override / merge
サブスクリプションの更新と設定の上書き
サブスクリプションの更新ではリモートの内容を再取得し、設定の上書きでは通常、読み込み時に一部の項目を統合または変更します。前者は内容の更新、後者はローカルでのカスタマイズに使います。ダウンロードしたサブスクリプションファイルを直接編集すると、次回の更新で変更が置き換えられることがあります。上書き機能を使う場合も、リストへの追加、オブジェクトの統合、全体の置き換えのどれに当たるか確認してください。設定の統合順序はクライアントごとに異なります。更新前にローカルの変更を記録し、更新後はルールとプロキシグループの参照が有効か確認してください。