mihomoカーネル
Proxy engine / mihomomihomoはClashエコシステムのプロキシカーネルで、設定の読み込み、ルール照合、DNS処理、接続の転送を担います。カーネルはGUIではありません。設定が使えるかどうかは、実際に動作しているカーネルと対応フィールドを確認してください。同じクライアント名でも、インストール環境が違えばカーネルの機能が同じとは限りません。
mode: rule
CLASH / CONFIGURATION GLOSSARY
カーネル、ルール、DNS、ポート。設定の該当箇所から用語を探し、実際に適用された値と照らし合わせましょう。
このページでは、よく使われる24の用語を解説します。各項目には個別のアンカーがあり、説明へのリンクをコピーできます。初めて設定する方は入門ガイドをご覧ください。エラーが発生している場合はトラブルシューティングガイドで症状から原因を確認できます。
接続を処理するカーネル、操作画面、接続パラメーターを区別しましょう。
mihomoはClashエコシステムのプロキシカーネルで、設定の読み込み、ルール照合、DNS処理、接続の転送を担います。カーネルはGUIではありません。設定が使えるかどうかは、実際に動作しているカーネルと対応フィールドを確認してください。同じクライアント名でも、インストール環境が違えばカーネルの機能が同じとは限りません。
mode: rule
GUIクライアントでは、サブスクリプションの管理、プロキシ選択、ログ確認、システムプロキシの切り替えができます。画面上の設定がカーネル設定を生成・上書きする場合もあるため、トラブル時は読み込んだ元ファイルだけでなく、実際に適用されている設定を確認してください。クライアントを選ぶ際は、まずOSとアーキテクチャを確認し、必要な機能の場所を確かめましょう。詳しくはクライアント比較をご覧ください。
プロキシノードは、リモート接続に必要なパラメーターの一式です。通常、サーバーアドレス、ポート、プロトコル、認証情報が含まれます。リストに表示されても設定が認識されたというだけで、接続できるかはパラメーターやネットワーク、サーバーの状態によって異なります。ノード名は識別用のラベルにすぎず、実際の接続元地域やプロトコルを示すものではありません。
proxies:
クライアントは指定したテスト先へノード経由で接続し、応答時間を測定することがあります。ICMP pingとは異なり、結果はテスト先やハンドシェイク、通信経路に左右されます。ダウンロード速度や、すべてのWebサイトへの接続性を示すものではありません。timeoutが発生した場合は、まずテスト先に到達できるか確認し、トラブルシューティングガイドに沿って端末のネットワークとノード接続を調べてください。
type: url-test
プロトコルごとに設定項目が異なります。トランスポート層と認証情報も合わせて確認してください。
Shadowsocksは暗号化プロキシプロトコルです。サーバーアドレス、ポート、暗号化方式、パスワードをサーバー側の設定に合わせる必要があります。サブスクリプションを読み込めても接続できない場合は、まず暗号化方式とプラグインの要否を確認してください。他のプロトコルの項目で代用することはできません。UDPを転送できるかどうかはノードの設定とサーバーの対応状況によって決まり、SSという名称だけでは判断できません。
type: ss
VMessはクライアントとサーバーの設定を合わせて使うプロキシプロトコルで、認証にはUUIDがよく使われます。WebSocketやTLSを使う場合は、パスやホスト名、証明書の設定も確認してください。UUIDが正しくても接続できるとは限りません。ログに認証エラーやハンドシェイクエラーが記録されている場合は、トランスポートの設定を調べる前にシステム時刻が正確か確認してください。
type: vmess
VLESSは軽量なプロキシプロトコルで、TLSと同等の通信暗号化を単独では提供しません。TLSやREALITYを使うか、flowを設定するかはサーバー側の設定に従ってください。プロトコル名だけを書き換えてノードを変換することはできません。読み込む前に、使用中のカーネルが必要な組み合わせに対応しているか確認しましょう。フィールドの非対応をサーバー障害と誤認しないためにも重要です。
type: vless
Trojanは通常、TLS経由でプロキシ接続を行い、パスワードで認証します。トラブル時はアドレスとパスワードに加え、サーバー名や証明書の検証結果も確認してください。証明書検証の無効化を、安易な解決策として使うべきではありません。サーバー側でWebSocketなど別のトランスポートを使う場合は、クライアントにも対応するパラメーターが必要です。サーバーのポートだけを入力しても接続できません。
type: trojan
ルールが接続の処理先を決め、プロキシグループが接続経路を選びます。
ルールモードではrulesのリストを上から順に照合し、一致した接続を指定されたポリシーで処理します。ルールを編集する際は、具体的な条件を広い条件より前に置き、接続ログで一致したルールを確認して変更が反映されたか確かめてください。末尾のMATCHは、それまでのルールに一致しなかった接続を処理するためによく使われます。グローバルモードでは、ルールモードと同じ経路になるとは限りません。
DOMAIN-SUFFIX,example.com,DIRECT
プロキシグループは、複数のノードや他のポリシーをまとめ、ルールから参照できる名前を付けたものです。selectは手動選択、url-testはテスト結果に基づく選択に使います。グループ内の選択でルール順は変わらず、すべてのアプリがそのグループを使うわけでもありません。「ノードを切り替えても接続元が変わらない」場合は、接続がどのグループに一致したかを確認し、変更した選択肢がそのグループで有効か調べてください。
proxy-groups:
DIRECTはプロキシノードを経由せず、接続先へ直接アクセスすることを表します。REJECTは一致した接続を拒否します。どちらも組み込みポリシーです。一方、PROXYはカスタムグループ名として使われることが多いため、設定内に該当する名前があるか確認してください。DIRECTでも端末側のルーティング設定をすべて迂回するわけではありません。拒否ルールが誤って適用されたかは、一致したルールの記録を確認してください。
DOMAIN-SUFFIX,example.com,REJECT
GeoIPはIPデータベースに登録された地域情報をもとに接続先のアドレスを照合します。コンテンツの発信地域や運営会社の所在地を判定するものではありません。CDNやIPアドレスの変更で結果が変わることがあります。ルールのno-resolveは、そのルールのためにドメイン解決を開始しないようにします。特定のドメイン群を安定して照合したい場合は、IPの地域情報だけに頼らずドメインルールを使いましょう。
GEOIP,CN,DIRECT,no-resolve
まずドメインの名前解決経路を確認し、次に通信がカーネルへ入る経路を調べましょう。
DNS名前解決は、ドメイン名を接続に必要なアドレスへ変換します。名前解決の経路と、接続そのものの経路は別です。カーネルのDNSを有効にしても、アプリのリクエストがそのリゾルバーに届いているか確認が必要です。ブラウザーのセキュアDNSやシステム設定が別の経路を使う場合もあります。ドメイン名では開けないのにIPアドレスでは接続できる場合は、DNS応答、キャッシュ、実際に使われているDNSサービスを確認してください。
dns:
Fake-IPはDNSリクエストに合成アドレスを返し、カーネル内にドメインとの対応を保持することで、後続の接続をドメイン名に基づいて処理しやすくします。特定のアプリで互換性の問題が起きた場合はfake-ip-filterを確認してください。モードを切り替えた後は、古いDNSキャッシュを消去し、接続を張り直してください。応答に合成アドレスが含まれていても、それだけで異常とは限りません。後続の通信が対応表を保持するカーネルに届くかどうかが重要です。
enhanced-mode: fake-ip
TUNは仮想ネットワークインターフェースを通じてIP層の通信を受け取り、システムプロキシ設定を参照しない一部のアプリにも対応できます。権限、ルーティング、DNSの連携が必要で、有効にすればすべての通信を必ず取り込めるわけではありません。トラブル時はまず仮想インターフェースとルートが作成されているか確認してください。他のVPNとの同時利用でルートが競合することがあるため、原因を切り分ける際は一つずつ停止して試してください。
auto-route: true
DNS漏れとは、ドメインの問い合わせが想定した名前解決経路から外れ、意図しないDNSサービスに知られる状態です。確認時はシステム、ブラウザー、クライアントの設定を調べ、端末からの問い合わせ先と再帰リゾルバーの出口を区別してください。地域表示だけで判断することはできません。暗号化DNSで分かるのは該当する問い合わせ経路が暗号化されていることだけで、想定したプロキシを通った証明にはなりません。
設定の取得元、ファイル構造、個別に更新するリソースを区別しましょう。
サブスクリプションURLは、ノード一覧や設定一式を取得するためのリモートアドレスであり、クライアントソフトそのものではありません。更新できない場合は、まず応答内容と対応形式を確認してください。URLに認証情報が含まれることがあるため、ログやスクリーンショットを共有する際はアドレス全体を隠してください。Webページやログイン画面、エラーメッセージが返された場合、ファイルの拡張子を変えても有効なYAML設定にはなりません。
サブスクリプションの追加手順を見るYAMLはインデントでデータの階層を表します。Clashの設定はconfig.yamlというファイルで保存されることがよくあります。編集時はTabではなくスペースを使い、同じ階層のインデントをそろえてください。構文解析に通っても、各フィールドが使えるかどうかはカーネルによって異なります。エラー行の周辺だけでなく、その上位階層のインデントも確認してください。エラー行だけを修正しても、構造上の問題が残ることがあります。
config.yaml
Proxy Providerはノード群を個別に読み込み・更新できるリソースとして管理し、プロキシグループから参照します。リソースの読み込み後、useなどの設定でグループに追加する必要があります。providerを定義しただけでは、完全なルール分岐設定にはなりません。ノード一覧が空の場合は、リソースの取得、内容の解析、プロキシグループからの参照を個別に確認し、問題を切り分けてください。
proxy-providers:
Rule Providerはルール条件のセットを個別に管理し、RULE-SETで処理ポリシーを指定します。リソース形式はbehaviorやformatの設定と一致させる必要があります。ルールセットも、設定内で参照された位置に応じて上から順に照合されます。ルールリソースを更新してもプロキシグループは変わりません。一致後の接続先は、そのルールセットを参照するルールで指定されます。
rule-providers:
ローカルの待ち受け、アプリの設定、LANアクセスを分けて確認しましょう。
システムプロキシは、プロキシアドレスをOSの設定に登録し、その設定に従うアプリで使えるようにします。すべての通信を取り込む機能ではありません。ブラウザーでは使えても他のアプリで使えない場合は、ノードをすぐに切り替えるのではなく、対象アプリがシステムプロキシを参照しているか確認してください。クライアントを終了した後もネットワークに接続できない場合は、停止したポートを指すプロキシ設定がシステムに残っていないか確認しましょう。
mixed-portは、1つのローカルポートでHTTPプロキシとSOCKSプロキシの両方を受け付けます。アプリに設定するアドレスとポートは、実際の待ち受け設定に合わせてください。ポートが使用中だと待ち受けに失敗します。設定例の数字が、クライアントで現在使われているポートとは限りません。以下の7890は設定項目の例です。実際の値はクライアントの設定と起動ログで確認してください。
mixed-port: 7890
127.0.0.1とIPv6の::1はいずれもローカル端末を指し、アプリからローカルプロキシへ接続する際によく使われます。一部のWindows UWPアプリではサンドボックスによってループバックが制限されるため、アプリごとにループバックの除外設定を確認してください。LANアクセスを有効にしても、この権限設定の代わりにはなりません。他のデバイスで127.0.0.1を指定すると、Clashを実行しているPCではなく、そのデバイス自身に接続します。
127.0.0.1 / ::1
allow-lanは、他のデバイスからカーネルのプロキシ待ち受けサービスへ接続できるかを制御します。待ち受けアドレスやファイアウォールの設定も必要です。信頼できるネットワークで必要な場合に限って有効にし、アクセスを制限してください。プロキシポートとコントロールインターフェースは用途が異なるため、どちらもインターネットに公開しないでください。他のデバイスから接続する際は、クライアントを実行している端末のLAN内アドレスを指定し、端末間で通信できることを確認してください。
allow-lan: true