Clash高度な設定ガイド

01 / POLICY

プロキシグループの種類と実践的な構成

まずノード、プロキシグループ、最終ポリシーを区別する

Clash設定におけるプロキシノードは具体的な接続パラメータ、プロキシグループはノードや他のプロキシグループを整理する仕組み、ルール末尾に記述するのが最終ポリシー名です。3者は画面上に同時に表示されることがありますが、役割は異なります。たとえば購読に複数のノードがある場合、それらをまず「ノード選択」という select グループにまとめ、「開発サービス」「ストリーミング」などの用途別グループから「ノード選択」を参照できます。ルールは用途別グループを指定するだけで、個別ノードに一つずつ紐付ける必要はありません。これによりノードを変更してもルールを修正せずに済み、購読更新後に分流ロジックを行ごとに整理し直す必要もありません。

プロキシグループ名は、スペースや大文字・小文字も含め、ルールの宛先と完全に一致させる必要があります。設定を解析できても、そのポリシーが実際に存在するとは限りません。クライアントによっては読み込み時にポリシーが見つからないと通知しますが、別のケースではルールに一致した時点で初めて問題が表面化します。名前を変更したら設定をリロードし、接続詳細やログでルールが一致した対象グループを確認してください。ウェブページが開くかどうかだけで判断しないでください。ブラウザキャッシュ、既存接続の再利用、OSのDNSキャッシュによって古い結果が一時的に残ることがあります。

よく使う4種類のグループの役割

url-test は相互に代替可能なノード群に適しています。主なパラメータはテスト先 url、テスト間隔 interval、許容差 tolerance です。間隔を短くしすぎると接続数と電力消費が増え、特にモバイル端末で顕著になります。差を小さくしすぎると選択結果が頻繁に変わることがあります。テスト先には、安定してアクセスでき、サイズの小さいレスポンスを返すURLを指定してください。テスト成功が示すのは、現在のネットワークから候補ノードを経由してテスト先までの経路が利用可能ということだけで、対象サービスのハンドシェイク、地域判定、アカウント状態まで正常とは限りません。

fallback は順序を重視します。「主回線を優先し、利用できない場合だけ予備回線へ切り替える」場面に適しています。一方、load-balance は同時接続を複数ノードへ分散します。送信元アドレスを安定させたいログイン、決済、インスタントメッセージ、長時間接続のサービスを負荷分散グループへ直接入れるのは避けてください。一貫性ハッシュを使っても、ドメイン変更、接続再構築、ルール変更によって出口が変わる可能性があります。

保守しやすい階層構成

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - 自動選択
      - フォールバック
      - DIRECT

  - name: 自動選択
    type: url-test
    use:
      - airport-main
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

  - name: フォールバック
    type: fallback
    use:
      - airport-main
    url: https://www.gstatic.com/generate_204
    interval: 600

  - name: 開発サービス
    type: select
    proxies:
      - ノード選択
      - 自動選択
      - DIRECT

  - name: 最終マッチ
    type: select
    proxies:
      - ノード選択
      - DIRECT

この構成では、「ノードをどう選ぶか」と「用途ごとにどこへ接続するか」を分離しています。use が参照するのは proxy-providers の名前で、proxies が参照するのは具体的なノードまたは他のプロキシグループ名です。両者は置き換えられません。購読ノードが多い場合は、provider とフィルター条件で候補を管理し、購読内容が変わるたびに proxies を手作業で修正するのを避けます。クライアントの上書き機能でプロキシグループへ項目を追加できる場合も、同じ階層を保ってください。ノードの取得元は provider、用途の意味付けはローカルのプロキシグループで管理します。

グループ同士で循環参照を作ってはいけません。たとえば「ノード選択」に「自動選択」を含め、「自動選択」の proxies に再び「ノード選択」を入れると、最終的な出口を決められなくなります。実際の修正ではルールの末端から逆向きに確認できます。ルールは用途別グループ、用途別グループは全体の入口、全体の入口は最終的にノードまたは DIRECT を指す構成です。各参照経路は必ず終端に到達できるようにします。REJECT や DIRECT のような組み込みポリシーについては、同名ノードを別途作成する必要はありません。

プロキシグループを検証する際は、まずクライアント画面で想定した項目を明示的に選択し、対象アプリの既存接続を閉じてからリクエストを再実行します。次に接続履歴で、ルールタイプ、ルール内容、プロキシグループ、最終ノードを確認してください。画面に古いグループ名が表示される場合、現在の実行設定がまだリロードされていない可能性があります。グループに新しいノードがない場合は、providerの更新成功とフィルター式による全除外を確認します。ルールの優先順位について詳しくは、カスタムルール構文とマッチング優先順位を参照してください。

02 / RULE PROVIDERS

ルールセットを購読で管理する

ルール内容をメイン設定から分離する

ルール数が増えた後も、すべての項目をメイン設定の rules に書き続けると、3つの問題が起こります。設定更新でローカル修正が上書きされ、重複ドメインを追跡しにくくなり、読み込み失敗時にどのルール群が原因か特定しづらくなります。rule-providers は外部ルールセットの取得元、動作タイプ、ファイルパス、更新間隔を定義するためのものです。メインのルール欄では RULE-SET によって、マッチング順序のどこに置くか、マッチ時にどのプロキシグループを使うかだけを指定します。

ルールセットも上から下へ評価する仕組みを回避するものではありません。RULE-SET,developer,開発サービス を国内直結ルールの前に置くか後ろに置くかで、重複するドメインの結果は直接変わります。設計時はまず用途の優先順位を決め、その後にルールセットを並べてください。ダウンロードファイルの名前や容量順に並べるものではありません。確実性の高いカスタムドメインは前方に置き、LANと必要な直結ルールを先に、広範な地域集合を後ろに配置し、最後に MATCH で未一致の通信を受けます。

provider の各フィールド

rule-providers:
  developer:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/developer.yaml
    url: https://example.com/rules/developer.yaml
    interval: 86400

  private-network:
    type: file
    behavior: ipcidr
    format: text
    path: ./ruleset/private-network.txt

rules:
  - RULE-SET,developer,開発サービス
  - RULE-SET,private-network,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,最終マッチ

type: http はコアが url から取得してキャッシュすることを示し、type: file はローカルファイルだけを読み取ることを示します。例のドメインは構造を示すためのもので、実際には自分でアクセスできることを確認したルールソースへ置き換えてください。path はキャッシュまたはローカルルールファイルの保存先です。同じ設定内のproviderで同じパスを共有しないでください。後から書き込まれた内容が先のファイルを上書きする可能性があります。相対パスの基準は、クライアントがコアに設定する作業ディレクトリによって異なります。デスクトップクライアントでは通常、現在開いているターミナルのディレクトリではなく、独自の設定ディレクトリに割り当てられます。

behavior はルールの内容をどう解釈するかを決めます。domain はドメイン集合、ipcidr はIPv4・IPv6のネットワーク、classical は各行に完全なルールタイプを含める形式に適しています。選択を誤ると、ファイルのダウンロードには成功しても想定どおりにマッチしません。たとえば DOMAIN-SUFFIX,example.com を含む classical 形式の内容を domain として宣言すると、解析方法が一致しません。まずルール提供元の元の形式を確認し、ファイル拡張子だけでbehaviorを推測しないでください。

format はルール内容のエンコード形式を表します。一般的には yaml、text、またはコアが対応するバイナリ形式です。形式ごとに内容の構造は異なります。YAMLのdomain providerでは、トップレベルの payload 配列がよく使われます。テキスト形式では通常、項目を1行ずつ保存します。購読元がMihomo形式を明示している場合は、その説明に従ってください。通常のhostsファイル、広告フィルター構文、ブラウザー拡張機能のルールを、そのままClashのルールセットとして扱わないでください。

interval の単位は秒で、更新確認の周期を制御します。設定を読み込んだ後、初回取得まで必ずその時間待つという意味ではありません。周期を短くしすぎないでください。ルールソースの更新頻度は通常ノード状態ほど高くなく、頻繁な取得は起動時とネットワークの負荷を増やすだけです。クライアントに「ルールセットを更新」する操作がある場合は、取得元を変更した後に手動で一度実行し、ログでHTTPステータス、解析結果、キャッシュパスを確認できます。

ドメイン集合、IP集合、no-resolve

ドメインルールは、リクエストにドメイン情報が残っている場合に最も直接的です。IP-CIDRルールは宛先IPを対象とします。IPルールの末尾に no-resolve を付けると、そのルールのマッチング時に、宛先IPを得るためのドメイン解決を自動で行わないという意味になります。DNSを無効化するものではなく、アプリがすでに行った名前解決を妨げるものでもありません。純粋なIP接続では、コアは宛先IPを直接マッチングできます。このパラメータを付けるかどうかは、前段のDNS・スニッフィング処理が十分な情報を提供しているか、追加の名前解決を発生させる価値があるかで判断してください。

更新失敗時の確認手順

まず「ダウンロード失敗」と「解析失敗」を区別します。ダウンロード失敗では、接続、証明書、タイムアウト、HTTPステータスに関する情報がログに出ることが多く、解析失敗ではファイル自体は取得できているものの、フィールド、インデント、behavior、formatが要件に合っていない可能性があります。次に、現在のネットワーク経路からURLへアクセスできるかを確認します。ルールproviderのダウンロード通信がどのようにルーティングされるかは、コアの起動段階と設定に左右されます。初回読み込み時に、まだ作成されていないポリシーへ依存すると、処理順序の問題が起こることがあります。

続いてキャッシュディレクトリに書き込み権限があるか確認します。デスクトップクライアントがGUIで設定を管理している場合、path をシステム保護下のディレクトリへ向けるのは避けてください。ファイル名は互いに重複しないようにし、まだ作成されていない絶対パスにディレクトリ構造を依存させないでください。最後に、メインルールに対応する RULE-SET が存在し、名前がproviderのキーと一致していることを確認します。providerのダウンロードに成功しても、rules から参照されていなければキャッシュを消費するだけで、分流には使われません。

ルールセットの取得元が不安定な場合は、最小限の動作構成を残してください。基本的な直結、必要なプロキシ、最終ルールをすべてリモートファイルに依存させない構成です。こうしておけば、providerが一時的に更新できなくても、既存キャッシュやローカルの基本ルールで設定を起動できます。中国本土は直結し、それ以外の通信をプロキシに送る構成全体の順序は、中国本土・海外向けルール分流の考え方を参照し、そのうえで本章の方法に従って安定した大規模集合をproviderへ分割してください。

03 / DNS

DNS設定の最適化と漏れの確認

DNSが分流チェーンのどこにあるかを理解する

DNS設定は単に名前解決サーバーを変更するだけではありません。Mihomo DNSを有効にすると、コアはどの上流へ問い合わせるか、問い合わせ通信をどの経路に通すか、実アドレスとFake-IPのどちらを返すか、解決結果をルールマッチングへどう利用するかを判断します。アプリがシステムDNSへ直接リクエストする場合もあれば、独自の暗号化DNSを使う場合もあります。ブラウザーがセキュアDNSを有効にしていることもあります。まずリクエストがコアへ入っているか確認してからでなければ、nameserverを調整しても意味がありません。

一般的な流れは、アプリがドメインを要求し、システムまたはTUNがDNSリクエストをコアへ渡し、コアがドメインルールに従って上流を選び、結果またはFake-IPを取得・割り当て、その後の接続確立時にドメインを復元して分流を実行するというものです。アプリがシステムの名前解決を迂回して独自のDNSサーバーへ直接アクセスする場合は、TUNルーティング、DNSハイジャック、アプリ設定によってリクエストを同じ経路へ取り込む必要があります。システムDNSのアドレスを公共DNSへ変更するだけで、すべての問い合わせがClashのポリシーに従うとは限りません。

トラブルシューティングしやすい基本設定

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://cloudflare-dns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  direct-nameserver:
    - https://dns.alidns.com/dns-query
  respect-rules: true

default-nameserver は主に、暗号化DNSの上流自体のドメインを解決するために使われます。そのため、通常は直接アクセスできるIPアドレスを指定し、「DNSサーバーのドメインを解決するには、まずそのDNSサーバーへ接続しなければならない」という循環依存を避けます。すべてのサービスドメインに対する最終的なデフォルト回答の取得元ではありません。通常の問い合わせで主に使われる上流は nameserver で、従来型DNSのIP形式も、コアが対応する暗号化DNSアドレスも指定できます。

proxy-server-nameserver はプロキシサーバー自体のドメインを解決するために使います。ノードアドレスをドメインで指定している場合、プロキシ接続を確立する前に実IPを取得する必要があり、まだ確立していないプロキシチェーンに依存することはできません。この上流は現在の直結環境から安定してアクセスできる必要があります。ノードアドレスがIPそのものなら重要度は下がりますが、明確な導入解決経路を残しておくと、購読元の切り替えにも対応しやすくなります。

direct-nameserver では、直結が想定されるドメインの名前解決経路を指定できます。respect-rules と組み合わせる場合は、ルールとDNSの依存関係に特に注意してください。設定が複雑すぎると、問い合わせにルールの情報が必要なのに、そのルールも問い合わせ結果に依存する状況が起こります。トラブルシューティングでは、まず確実に到達できる少数の上流を使い、通常の問い合わせとプロキシノードの名前解決が正常であることを確認してから、ドメイン別分流のnameserver-policyを追加するのがおすすめです。

nameserver-policyを正確に使う

dns:
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "+.example.internal":
      - 192.168.1.1
    "rule-set:developer":
      - https://cloudflare-dns.com/dns-query

nameserver-policy はドメインに応じて名前解決の上流を選択し、社内ドメイン、特定サービス、地域ドメインなどの要件に適しています。これは「どこへ問い合わせるか」を決めるもので、接続通信のプロキシポリシーと直接同じではありません。ドメインをローカルDNSで解決しても、接続が必ず直結になるわけではなく、最終的には rules が決定します。反対に、リモートの暗号化DNSからアドレスを取得しても、サービス接続が必ずプロキシを通るとは限りません。名前解決の経路と接続の経路を分けて考えると、矛盾して見える一致結果を理解しやすくなります。

社内DNSやルーターで回答する必要があるドメインには、明確なサフィックスに対してLAN内DNSを指定できます。広すぎるワイルドカードをすべて社内サーバーへ渡すのは避けてください。ネットワーク外へ移動した際に、大量のタイムアウトが発生する可能性があります。ノートPCでネットワークを頻繁に切り替える場合は、オフィスネットワーク専用ルールを別の上書き設定に分け、必要なときだけ有効にする方が、すべての環境のメイン設定へ恒久的に書き込むより適切です。

IPv6、キャッシュ、フォールバック動作

ipv6: false は通常、DNSモジュールがAAAAレコードを返さないことを示しますが、OSレベルでIPv6を無効にするわけではありません。アプリが別の名前解決経路からIPv6アドレスを取得したり、IPv6へ直接接続したりすれば、想定した経路を迂回する可能性があります。ネットワークのIPv6が安定しない、プロキシノードがIPv6に対応していない、ルールセットがIPv4しか対象にしていない場合は、まずDNSからIPv6を返さないようにすると接続待ちを減らせます。IPv6が必要な場合は、TUNルート、ルールセット、出口の対応状況も同時に確認してください。

DNSキャッシュにより、変更結果がすぐに反映されないことがあります。設定をリロードしたら、クライアント内部のキャッシュを消去してください。必要に応じてOSとブラウザーのキャッシュも削除し、接続を再確立します。閉じていないブラウザータブで連続更新してルールを判断するのは避けてください。HTTP/2、HTTP/3、接続プールによって古い接続が再利用される可能性があります。確実な方法は、対象アプリの接続を閉じ、キャッシュを消去し、設定をリロードしてから、DNSログと接続履歴を組み合わせて再テストすることです。

DNSが想定どおり動作しているか確認するときは、4つの事実を記録します。アプリが問い合わせたドメイン、リクエストがコアへ入った方法、実際に使われた上流、最終的に接続が一致したルールです。「検査サイトに表示されたDNS」だけでは、ブラウザーのセキュアDNS、システムキャッシュ、上流転送、コア設定のどれが原因か特定できません。複雑な障害が発生した場合は、ヘルプセンターでDNS、システムプロキシ、接続ログの順に確認してください。

04 / TUN & FAKE-IP

TUNモードとFake-IPの連携

システムプロキシとTUNの適用範囲

システムプロキシは、OSのプロキシ設定に従うアプリにだけ影響します。ブラウザーや多くのデスクトップソフトは対応していますが、コマンドラインツール、ゲーム、仮想マシン、一部のストアアプリ、独自のネットワークスタックを実装したソフトは無視することがあります。TUNモードは仮想ネットワークインターフェースを作成し、システムルートを通じてより多くのTCP・UDP通信をコアへ渡すため、適用範囲が広くなります。その分、ルーティング、DNS、インターフェース選択に介入するため、設定を誤った際の影響も通常のシステムプロキシより明確です。

TUNを有効にする前に、通常のプロキシモードでノード、ルール、DNSがすべて動作することを確認してください。いきなりTUNへ移行すると、ノード障害、DNSループ、ルーティング競合が重なり、根本原因を判断しにくくなります。推奨順序は、ノード接続の確認、ルール一致の確認、TUNの有効化、DNSハイジャックとFake-IPの有効化です。一度に変更する変数を一組に絞り、復元可能な設定のコピーを残してください。

TUNの基本パラメータ

tun:
  enable: true
  stack: mixed
  dns-hijack:
    - any:53
    - tcp://any:53
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  mtu: 1500

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

stack はTUN通信をどのネットワークスタックで処理するかを決めます。Mihomoでよく使われる選択肢は system、gvisor、mixed です。システムスタックは一般に性能面で直接的な経路を取り、gVisorのユーザー空間スタックはプラットフォームや特殊なネットワークで互換性が異なり、mixedは組み合わせた処理に使われます。すべてのOSに適した固定の正解はありません。デフォルト設定が安定しているなら、パラメータを複雑にするためだけに変更する必要はありません。UDP、LANアクセス、特定のゲームで問題が出た場合に、ネットワークスタックを単独の変数として比較テストしてください。

auto-route はコアに必要なルートを自動追加させ、auto-detect-interface は現在のデフォルト出口を識別します。有線、無線、テザリング、VPNを切り替えるノートPCでは自動検出が便利です。一方、サーバー、多数のNICを持つホスト、ポリシールーティング環境ではインターフェースを明示する必要がある場合があります。ログで通信が何度もTUNへ入り、プロキシノードへの接続までTUNへ戻されている場合は、出口インターフェース、ルート除外、既存VPNによるループを確認してください。

strict-route はTUNを経由する通信をより厳密に制御しますが、具体的な効果と権限要件はOSによって異なります。迂回を減らす助けになる一方、OSが自動処理していたルーティング競合を表面化させることもあります。有効化後にLANプリンター、共有フォルダー、仮想マシンのネットワークへ到達できなくなった場合は、すべてのLANアドレスをプロキシポリシーへ追加する前に、プライベートネットワークのルールとルート除外を確認してください。

dns-hijack は指定ポートのDNS通信をコアへ渡します。any:53 は一般的なUDP問い合わせを対象にし、TCP形式も追加すると、切断された応答後のTCP再試行に対応できます。ただし、HTTPSやTLSベースのアプリ独自DNSを自動的にすべて捕捉できるわけではありません。この通信は見た目には通常の暗号化接続なので、アプリ設定、ドメインルール、完全なルーティング経路で処理する必要があります。ハイジャックが必要かどうかは、アプリがシステムDNSに従うかで決まります。

Fake-IPの仕組み

Fake-IPモードでは、ドメインの問い合わせを受けても実際の宛先アドレスをすぐにアプリへ渡さず、予約済みアドレスプールから対応アドレスを割り当てます。アプリがそのアドレスへ接続すると、コアは対応関係から元のドメインを復元し、ドメインルールとプロキシ転送を実行します。これにより、アプリが後続処理でIPだけを送ってもコアがドメインのコンテキストを保持でき、ドメイン分流が安定し、実アドレスをローカルで取得してからポリシーを決める必要性も減ります。

198.18.0.0/15 はベンチマーク用途の予約アドレス範囲で、Fake-IPによく使われます。設定するアドレスプールは、既存のLAN、コンテナネットワーク、検証用ネットワーク、企業ルーティングと競合しないようにしてください。現在のネットワークが同じ範囲を使っていると、システムがFake-IPを実際のルート宛先と誤認する可能性があります。その場合は競合しない予約範囲へ変更し、関連接続を再起動してDNSキャッシュを消去し、古いマッピングが使われないようにします。

実アドレスが必要なプロトコルやDNSの動作を検証するプロトコルは、Fake-IPに適さない場合があります。代表例はLANホスト名、STUN、ネットワーク接続性チェック、特定ゲームの検出プロトコル、一部のデバイス制御サービスです。これらは fake-ip-filter に入れてください。フィルター項目はできるだけ正確にし、まずログでドメインを確認してからサフィックスやワイルドカードを追加します。広範囲のドメインをまとめて除外すると、Fake-IPがドメイン情報を保持する利点が大きく損なわれます。

MTU、UDP、LANアクセス

MTUが大きすぎると、一部のトンネル、モバイルネットワーク、VPNを重ねた環境でフラグメンテーションやパケットロスが起こり、ウェブページの一部リソースが止まる、TLSハンドシェイクがタイムアウトする、UDPが不安定になるといった症状が出ます。小さすぎるとパケット数と処理負荷が増えます。特定サイトが遅いというだけで、むやみにMTUを下げないでください。まずTUN使用時だけ発生するかを確認し、異なるネットワークとプロトコルで比較し、ログに再送やハンドシェイク失敗がないか観察します。変更幅を記録できる範囲に保ち、TUNを再起動してからテストしてください。

LANアクセスでは、ルールとルーティングの両方を考慮する必要があります。ルールでRFC1918のプライベートネットワーク、リンクローカルアドレス、実際のLANドメインを DIRECT にできますが、DIRECTが決めるのは接続をプロキシノード経由にしないことだけで、OSのルートが正しいインターフェースを向く保証はありません。TUNの自動ルートがLAN経路を奪っている場合は、ルート除外と厳格ルートの設定も確認してください。同じネットワークの端末へプロキシを共有する場合は、リッスンアドレス、allow-lan、ファイアウォールの追加設定が必要です。詳しくはmixed-portとLAN共有を参照してください。

05 / SNIFFER

ドメインスニッフィングと接続の復元

スニッフィングで解決できる問題

ルールシステムはドメインによる分類を得意としますが、一部のアプリは接続時に宛先IPしかコアへ公開しません。ドメインスニッフィングは接続初期のデータからHTTP Host、TLS ClientHelloのSNI、対応プロトコルに含まれる宛先ドメインを識別し、復元したドメインをルールマッチングに利用します。HTTPS本文を復号したり、ページ内容を読み取ったりするものではありません。確認できる情報は、プロトコルのハンドシェイク段階に元々含まれているドメインフィールドから得られます。

スニッフィングとFake-IPはいずれもドメインのコンテキストを保持できますが、経路が異なります。Fake-IPはDNS問い合わせの段階でドメインとマッピングアドレスの関係を作り、スニッフィングは接続確立時にプロトコルデータからドメインを復元します。両方を有効にすることも可能です。Fake-IPはコアDNSを経由する接続を処理し、スニッフィングはその名前解決を迂回した接続や、宛先IPを直接使う一部のケースを補います。DNSがすでに安定してマッピングを提供しているなら、すべての障害をスニッフィングのせいにする必要はありません。

プロトコルとポートで範囲を制限する

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: true
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  skip-domain:
    - "Mijia Cloud"
    - "+.push.apple.com"
  skip-src-address:
    - 192.168.0.0/16
  skip-dst-address:
    - 192.168.0.0/16

parse-pure-ip は、最初に純粋なIPとして現れる宛先接続に対してスニッフィングを試みます。これはドメイン分流を補う代表的な場面です。force-dns-mapping はDNSマッピングと連携し、すでに存在する対応関係を利用します。クライアントごとのコア設定テンプレートではデフォルト値が調整されていることがあるため、変更前に購読元の原文だけでなく、実際の実行設定を確認してください。

override-destination はドメインを識別した後、後続接続の宛先をスニッフィング結果で上書きするかどうかを決めます。有効にすると一部のドメイン分流は改善しますが、誤認識の影響も直接的になります。まずはHTTPなど明確な場面をプロトコル項目単位で有効にし、最初から全体を上書きするのは避けてください。変更後は接続詳細で元の宛先、スニッフィングしたドメイン、最終ルールを確認し、変化が想定どおりか確かめます。

ポート範囲を広げても、識別精度が上がるとは限りません。スニッファーは接続前半のデータをプロトコルとして解析するため、HTTP、TLS、QUICではないことが明らかなポートまで強制的に試すと、誤判定と処理負荷が増えるだけです。一般的なポート以外のサービスは、実際のアプリに合わせて追加してください。たとえば内部HTTPSサービスが9443で動作しているなら、そのポートをTLS範囲へ追加します。これを対象にするために、すべてのポートをTLSスニッフィングへ渡すべきではありません。

QUIC、ECH、見えない境界

QUICは通常UDPを基盤とし、識別できるかどうかはコア、ネットワークスタック、ハンドシェイク情報が利用可能かに左右されます。ブラウザーはネットワークの変化後にTCP/TLSへフォールバックすることがあるため、同じサイトでも接続履歴に異なるプロトコルが現れます。トラブルシューティングでは一度のアクセスだけで判断せず、TCPとUDPを分けて観察してください。ノードやネットワークのUDP対応が不安定な場合、比較のためにアプリのQUICを一時的に無効化できますが、これは切り分けの手段であり、実際のUDP経路の確認に代わるものではありません。

暗号化されたクライアントハローなどの仕組みにより、中間層から見えるドメイン情報が減ることがあります。ハンドシェイクに識別可能な平文ドメインがなければ、スニッフィングで業務名を推測することはできません。その場合は、コアDNS、Fake-IPマッピング、アプリプロセスルール、宛先IPルールに依存します。設定の目標は、複数の信頼できる情報源を補完的に使うことであり、スニッフィングですべての接続を覆うことではありません。

CDNの共有IPもスニッフィングが有効な理由の一つです。IPだけで判断すると、同じアドレスにまったく異なる複数のドメインが載っていることがあります。広いネットワーク範囲で分流すると、別のサービスまで誤って巻き込む可能性があります。ドメインを取得できるなら、ドメインルールを優先してください。接続にドメイン情報が本当にない場合だけ、IP-CIDR、GEOIP、最終ルールへフォールバックします。

スキップリストと誤判定への対処

skip-domain は、スニッフィングや宛先上書きに適さないことが分かっているドメインを対象外にします。skip-src-address と skip-dst-address では、特定の送信元・宛先ネットワークを除外できます。スマートホーム、キャスト、LAN検出、メーカーのプッシュ通知で異常が起きた場合は、まずログで具体的な接続を特定し、最も狭い範囲で除外してください。プライベートネットワーク全体を直接スキップするのは簡単ですが、ドメイン分流が必要なローカルコンテナや開発環境から情報を奪う可能性があります。

識別されたドメインがアプリの想定と異なる場合は、まず対象がCDN、リダイレクト、サードパーティの静的リソースを経由していないか確認します。1つのページがメインドメイン、ログインドメイン、画像ドメイン、計測エンドポイントへ同時に接続するのは正常です。接続一覧に複数の名前が現れること自体は誤判定ではありません。本当の誤判定は、上書きを有効にすると元々使えていた接続が失敗し、そのプロトコルの override-destination を無効にすると復旧する形で現れます。また、ログのスニッフィング結果が証明書やサービスの対象と明らかに一致しないことも手掛かりです。

プロセスルールは補助として使えますが、プロセス情報を取得できる範囲、権限、精度はプラットフォームによって異なります。特にモバイルアプリのサンドボックス、システムサービス、コンテナ環境では注意が必要です。安定したドメインルールで解決できる場合はドメインを優先します。ドメインがなく、プロセス情報が信頼できる場合にだけプロセスルールを検討し、どちらも使えない場合にIP範囲と最終ルールへ進みます。この降格順序の方が、すべての通信をアプリ名に固定するよりも、複数プラットフォームで保守しやすくなります。

06 / OVERRIDES

ローカル上書きと複数購読の統合

リモート購読を入力として扱い、完成品とみなさない

リモート購読は主にノードを提供し、ときにはプロキシグループ、ルール、DNSも含みます。購読から生成されたYAMLを直接編集すると、次回の更新でローカル内容が上書きされることがほとんどです。より安定した構成は、購読を更新可能な入力として扱い、長期的に使うルール、ポリシー名、DNS、TUNパラメータをローカル上書き層に保存する方法です。クライアントは購読を更新するたびに上書きを再適用し、実行設定の一貫性を保ちます。

クライアントによって上書きの名称や機能は異なり、スクリプト、拡張設定、マージ設定、設定の前処理などの形で提供されます。Clash Plusなどのクライアントでは、実際の画面に表示される設定入口を基準にしてください。どの方式でも、リモートの元購読、ローカル上書きソース、コアの最終実行設定の3つを区別します。トラブルシューティングで最も重要なのは最後の1つです。画面上で保存に成功しても、マージ結果が想定どおりとは限りません。

マッピングと配列のマージの違い

YAMLのマッピングはキーと値で構成されます。たとえば dns の下にある enable です。配列は順序を持つ項目の集合で、rules や proxy-groups が該当します。マッピングはキー単位で上書きできることが多い一方、配列では置換、先頭への追加、末尾への追加、重複排除が関係します。マージツールが配列を全体置換する場合、ローカルにルールを1行書いただけで、購読元のルールがすべて消える可能性があります。追加方式の場合、重要なカスタムルールを末尾へ置くと、永遠に一致しないことがあります。

そのため、まずクライアントのマージ仕様を確認してから、上書き構造を決めてください。ルール配列には通常、精密なローカルルールを広範なルールより前に置く「先頭追加」機能が必要です。プロキシグループ配列では名前による置換または追加、DNSマッピングではキー単位の上書きが適しています。Mergeという名前の機能がすべて同じ動作をすると仮定しないでください。クライアントを更新したりプラットフォームを移行したりした後は、最終設定を再出力して比較してください。

# ローカルで管理するロジックの例。具体的なマージ入口はクライアントに従う
prepend-rules:
  - DOMAIN-SUFFIX,example.internal,DIRECT
  - DOMAIN-SUFFIX,github.com,開発サービス

override:
  mode: rule
  log-level: info
  dns:
    enable: true
    enhanced-mode: fake-ip

append-proxy-groups:
  - name: ローカルサービス
    type: select
    proxies:
      - DIRECT
      - ノード選択

上記の prepend-rules、override、append-proxy-groups はマージ意図を示すためのもので、Mihomoのメイン設定で一般的に使えるトップレベルキーではありません。実際のクライアントでは、GUIフォーム、JavaScript処理スクリプト、独自の拡張構文を使う場合があります。この部分をそのままコア設定へ貼り付けないでください。コアへ渡す最終結果は、標準の rules、proxy-groups、dns などのフィールドで構成されている必要があります。

providerで複数のノードソースを組み合わせる

proxy-providers:
  provider-a:
    type: http
    url: https://example.com/subscription/a
    path: ./providers/a.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

  provider-b:
    type: http
    url: https://example.com/subscription/b
    path: ./providers/b.yaml
    interval: 21600
    filter: "(?i)香港|HK|Hong Kong"
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: すべてのノード
    type: select
    use:
      - provider-a
      - provider-b

  - name: 香港自動
    type: url-test
    use:
      - provider-a
      - provider-b
    filter: "(?i)香港|HK|Hong Kong"
    url: https://www.gstatic.com/generate_204
    interval: 600

proxy-providers を使うと、複数の購読をそれぞれ独立して更新・キャッシュし、プロキシグループから use で参照できます。複数の購読テキストを直接連結するよりも問題を特定しやすく、あるソースが停止しても他のproviderは読み込めます。各providerには異なる path を指定する必要があります。購読URLは機密性の高い設定なので、ログのスクリーンショット、公開ルールリポジトリ、共有設定へコピーしないでください。例のアドレスは構造を示すためだけのものです。

filter は通常、ノード名で絞り込みます。正規表現は購読元の実際の命名に合わせてください。フィルター後にグループが空になるのは、複数購読の統合でよくある障害です。まずproviderが実際に読み込んだノード名を確認し、その後に式をテストします。地域名の日本語表記だけを頼りに作成しないでください。(?i) を使うと、対応する正規表現でラテン文字の大文字・小文字を無視できますが、中国語の別名、旗の記号、略称は取得元に合わせて調整する必要があります。

2つのソースに同名ノードがあると、画面上の識別やポリシー参照が曖昧になる可能性があります。最も確実なのは、前処理段階でノードに取得元のプレフィックスを付けるか、購読提供元に一意な名前を付けてもらうことです。クライアントがprovider単位のプレフィックスに対応している場合は、マージ層で「A-」「B-」などの短い識別子を統一的に追加できます。ノードの並び順で区別するのは避けてください。購読更新後に順序が変わる可能性があります。

複数購読更新の障害を分離する

更新に失敗したときは、すべてのキャッシュを一度に削除せず、providerを一つずつ確認してください。まずリクエストが成功したか、次にYAMLを解析できるか、その後フィルター後にもノードが残っているか、最後にプロキシグループが正しく参照しているかを確認します。あるproviderの失敗によって、基本設定からDIRECTやローカルのフォールバックグループまで失われないようにします。全体の入口に複数の独立したproviderから生成されたグループを含めておけば、単一ソースに異常があっても手動で切り替えられます。

マージ後の設定では、ポート競合、ポリシー名の重複、ルール宛先の欠落も確認してください。複数の完全な購読を直接マージすると、mixed-port、external-controller、DNSリッスンアドレス、「ノード選択」という名前のグループが重複して定義されがちです。ノードの取得元は複数あっても構いませんが、制御ポートとコアの基本ポリシー構造は1つの正規定義にしてください。これらのグローバルフィールドをローカル層で固定し、リモート入力をノードだけに限定するのが最も低コストです。

クライアントを移行するとき、購読URLだけをエクスポートしないでください。ローカルのプロキシグループ名、ルールセットの取得元、上書き順序、Fake-IPフィルター、providerのパスも記録します。クライアントごとに対応する拡張マージ構文は異なる可能性がありますが、標準Mihomo設定の部分は再利用できます。まず新しいクライアントで最小構成を作り、provider、ポリシー、ルール、TUNを段階的に移行すると、大量の拡張フィールドを一度に読み込んで起動できなくなる事態を避けられます。

07 / CONTROLLER

外部コントローラーとセキュリティ境界

コントロールインターフェースでできること

Mihomoの外部コントロールインターフェースは、GUIクライアントやウェブパネルから実行状態の読み取り、ポリシーの切り替え、接続とログの確認、設定のリロードなどを行うためのものです。通常のプロキシポートではなく、権限は明らかに高くなります。デスクトップクライアントに組み込まれた画面は通常、ローカルのコントロールインターフェースを使ってコアを管理します。独立したウェブパネル、リモート運用、他のツールからの接続が必要な場合にだけ、リッスン範囲を手動で調整してください。

コントロールインターフェースとパネルの静的ファイルは別物です。external-controller はAPIのリッスンアドレス、external-ui はローカルパネルファイルのディレクトリを定義します。ブラウザーでパネルを開いても、ポリシーや接続を表示するにはパネルがAPIへ接続する必要があります。ページは表示されるのにデータが空の場合、パネルファイル自体ではなく、コントロールアドレス、認証、CORS許可、プロトコルの不一致が原因であることが多いです。

本機で使うための最小構成

external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./ui
external-ui-name: metacubexd

external-controller-cors:
  allow-origins:
    - http://127.0.0.1
    - http://localhost
  allow-private-network: true

本機だけで管理する場合は、127.0.0.1 での待ち受けを優先してください。これによりコントロールポートがLANインターフェースへ直接公開されません。secret はAPI認証に使います。例の値は自分で生成した強度の高いランダム文字列に置き換え、本機の設定に保存してください。コントロールパネルでキーの入力を求められた場合は、ここに設定した値を使います。変更後はコアを再起動またはリロードし、パネルの接続設定も更新してください。

external-ui はパネルの静的リソースディレクトリです。一部のクライアントはパネルのダウンロードと管理を自動で行うため、手動設定は不要です。自分で配置する場合は、ディレクトリが存在し、コアプロセスに読み取り権限があることを確認してください。external-ui-name が有効かどうかは、現在のコアとダウンロード方式に依存します。画面に古い内容が表示され続ける場合は、実際のディレクトリ、ブラウザーキャッシュ、クライアントによるフィールドの上書きを確認してください。

CORSの許可は、どのウェブページのオリジンがブラウザーからコントロールAPIを呼び出せるかを決めます。許可するオリジンは、広く開放するのではなく、正確なプロトコル、ホスト、ポートの組み合わせで指定してください。パネルを本機の静的サービスから開く場合、ブラウザーのオリジンは http://127.0.0.1:ポート になることがあります。fileプロトコルで直接開く場合は別の制限があります。まずブラウザーの開発者ツールで拒否されたOriginを確認し、正確な項目だけを追加してください。

LAN管理における追加の制約

external-controller: 0.0.0.0:9090
secret: "your-password"

external-controller-cors:
  allow-origins:
    - http://192.168.1.20:8080
  allow-private-network: true

0.0.0.0 で待ち受けると、コントロールインターフェースが利用可能なすべてのネットワークインターフェースにバインドされます。LANから管理する必要が本当にある場合だけ使ってください。さらにOSのファイアウォールで、信頼できるネットワーク範囲または指定した管理端末に送信元を制限します。パネルのログイン入力欄だけに頼ってはいけません。パネルに入力したキーはAPI呼び出しに使われますが、ネットワーク層で信頼できない端末がポートへ到達すること自体を先に防ぐ必要があります。

端末が公共Wi-Fiへ接続する場合、すべてのインターフェースで長期間待ち受けるリスクはさらに高くなります。OSのファイアウォールでプライベートネットワークとパブリックネットワークを分けるか、不要なときはループバック待ち受けへ戻してください。インターネット越しのリモート管理でコントロールポートを直接公開するのは避けます。より適切なのは、まず管理されたプライベートネットワークの経路を確立し、LANサービスと同じように接続しながら、API認証も維持する方法です。

プロキシポートの allow-lan とコントロールインターフェースのリッスン範囲は同じではありません。LAN端末にmixed-portの利用を許可しても、コントロールAPIまでLANへ公開する必要はありません。反対に、コントロールインターフェースがすべてのアドレスで待ち受けても、プロキシポートが自動的に利用可能になるわけではありません。プロキシの待ち受け、コントロールの待ち受け、OSのファイアウォール、認証を個別に確認し、一方を直すためにもう一方のアクセス範囲を広げないようにします。

パネル接続時のトラブルシューティング手順

最初に、コアが想定したアドレスとポートで待ち受けているか確認します。ポートが他のプログラムに使われていると、コアのログにbind失敗が出ることが多く、クライアントが独自のコントロールポートへ自動変更する場合もあります。そのため、最終的な値は実行設定とログを基準にしてください。次に同じ端末上でAPIへ到達できるかを確認し、その後にパネルをテストします。API自体に到達できないなら、ブラウザーキャッシュを何度も削除する前に、待ち受けとファイアウォールを処理してください。

3番目に認証を確認します。「未認証」が返る場合は、キーが空、間違っている、またはパネルが指定どおり送信していない可能性があります。コピー時に余分なスペースを入れず、YAMLの外側の引用符をキーの一部とみなさないでください。4番目にCORSを確認します。ブラウザーのコンソールにクロスオリジン拒否が表示されても、API自体は応答していて、ブラウザーがパネルによる読み取りだけを拒否している可能性があります。その場合はすべてのオリジン制限を解除せず、パネルの正確なオリジンを追加してください。

5番目にプロトコルとアドレスを確認します。HTTPSページからHTTPのコントロールインターフェースを呼び出すと、ブラウザーが混在コンテンツのルールでリクエストをブロックすることがあります。パネルで localhost を指定した場合、それはブラウザーを実行している端末を指します。パネルをスマートフォンで開くなら、localhostはMihomoが動作するPCではなくスマートフォンです。LAN経由でアクセスする場合は、そのLAN上にあるPCのアドレスを入力し、ファイアウォールがスマートフォンからの接続を許可していることを確認してください。

ログ、接続情報、最小限の公開

コントロールパネルには、アクセス先ドメイン、宛先アドレス、プロセス情報、ポリシー選択が表示されることがあり、いずれも端末のネットワーク利用情報に該当します。トラブルシューティングのスクリーンショットを共有する前に、購読名、ノードアドレス、コントロールキー、LAN内アドレス、問題に関係のないアクセス履歴を隠してください。ログレベルはトラブルシューティングに必要な範囲に保ちます。詳細すぎるログを長期間有効にすると、ストレージ消費と情報漏えいのリスクが増えます。

第三者製パネルを使う前に、それがAPIクライアントにすぎず、コア設定の代わりにはならないことを理解してください。ポリシーの切り替えは通常、実行状態に対する操作です。設定をリロードした後も維持されるかどうかは、クライアントとグループタイプによって異なります。ポリシーを長期的に固定する場合は、ローカル設定またはクライアントの永続化機能で指定し、ウェブパネルで一度クリックするだけに頼らないでください。購読更新でプロキシグループが再生成されると、名前の変更によって以前の選択を復元できなくなることもあります。

設定完了後に一連の検証を行います。クライアントを再起動し、コントロールポートが正常に待ち受けていることを確認します。許可した端末からパネルを開き、キーで接続します。select グループを切り替えて新しい接続を観察します。設定をリロードして状態が想定どおりか確認し、最後に信頼できないネットワークインターフェースからポートへ到達できないことをテストします。これにより「パネルが開くか」だけでなく、認証、アクセス境界、設定の永続性まで検証できます。

コントロールインターフェースを変更してクライアントが起動できなくなった場合は、まずループバックアドレスへ戻し、外部UIの拡張フィールドを一時的に削除して、コア設定が読み込める状態にします。その後、項目を一つずつ戻してください。よくある原因は、ポートの競合、YAMLのインデントミス、クライアントによる同一フィールドの管理、無効なパネルディレクトリです。その他の起動・設定読み込みの問題は、ヘルプセンターでエラーログを検索してください。再インストールが必要な場合は、ダウンロードページで現在のプラットフォームに対応するクライアントを選択します。