Clash 上級設定マニュアル:プロキシグループ、ルールセット、DNS、TUN、外部コントロールAPI

CH-01

プロキシグループの種類と実践

プロキシグループ(proxy-groups)は振り分けルールと具体的なノードの間の中間層です。ルールがヒットするとプロキシグループに処理が渡され、プロキシグループは自身のロジックに従って実際に使用するノードを決定します。各タイプの判定メカニズムを理解することが、設定を「動く」から「使いやすい」へ改善する第一歩です。mihomoがサポートする主要なタイプは5種類あり、判定ロジックが大きく異なるため、タイプの選択ミスは遅延の揺れや頻繁な切断の典型的な原因になります。

5種類のタイプの判定ロジック

タイプ	選択方法	典型的なシナリオ	注意点
`select`	手動で指定、自動切り替えなし	固定の出口地域が必要なアカウント系サービス	ノードが失効しても自動で切り替わらず、手動対応が必要
`url-test`	定期的に遅延を測定し最速ノードを選択	日常的な閲覧、低遅延重視	遅延が近いと頻繁に切り替わる場合があるため `tolerance` の設定が必要
`fallback`	リスト順に先頭から使用可能なノードを採用	メイン+バックアップの高可用構成	ノードの順序=優先度なので手動で並べる必要がある
`load-balance`	戦略に従って複数ノードに接続を分散	マルチスレッドダウンロード、単一ノードの帯域制限の分散	出口IPが固定されないため、ログイン状態に敏感なサイトには不向き
`relay`	複数ノードを順番に連結してチェーン化	特殊な経路要件	遅延が積み重なりやすく、全ノードが有効な場合のみ通信可能

url-test の3つの重要パラメータ

url は測速先のアドレスで、通常204の空レスポンスを返すアドレスを選べばトラフィックの消費を無視できます。interval は測速の周期(秒)で、短すぎるとサブスクリプションノードの測速トラフィックが増大し、長すぎるとノードが劣化してもなかなか切り替わりません。日常的には300前後がバランスが良いでしょう。tolerance は切り替えの許容差(ミリ秒)で、新しいノードが現在のノードよりこの差以上速い場合のみ切り替えが行われます。tolerance を設定しない場合、遅延が60msと65msの2つのノードが頻繁に切り替わり、切り替えのたびに転送中の接続が中断される可能性があります。最低50は設定することをおすすめします。

proxy-groups:
  - name: 自動測速
    type: url-test
    proxies: [HK-01, HK-02, JP-01]
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: フェイルオーバー
    type: fallback
    proxies: [メイン-HK, サブ-JP, 予備-US]
    url: https://www.gstatic.com/generate_204
    interval: 180

  - name: 負荷分散ダウンロード
    type: load-balance
    strategy: consistent-hashing
    proxies: [SG-01, SG-02, SG-03]

load-balance の2種類の strategy

consistent-hashing は宛先アドレスのハッシュに基づき、同じサイトへのリクエストは常に同一ノードに固定されるため、分散と接続の安定性を両立できるデフォルト推奨設定です。round-robin は接続ごとにノードを順番に切り替え、分散効果が最も高いですが、同じサイトへの異なるリクエストが別々のIPから送信されるため、セッション検証が厳しいサービスではログアウトされやすく、純粋なダウンロード用途のグループにのみ使用を推奨します。

グループの組み合わせパターン

実運用では通常2層構造にします。下層に「HK自動」「JP自動」のような地域別のurl-testグループを作り、上層にこれらの地域グループと「手動選択」を並べて収めるselectグループを1つ作成し、ルールは統一的にこの上層のselectグループを指すようにします。これにより日常は自動測速に任せつつ、固定の地域が必要な場合はクライアントのパネルでワンクリックで該当地域グループに切り替えられ、ルールを変更する必要がありません。プロキシグループは他のプロキシグループを入れ子で参照することもできます(proxiesリストにグループ名を書くだけ)が、循環参照を作ってはいけません——コアはそのような設定の読み込みを拒否します。3種類の自動タイプのより詳細な比較とパラメータ実験については、ブログのプロキシグループタイプの比較を参照してください。どのノードをグループに収めるべきか分からない場合は、まずノード選定の4つの観点をご覧ください。

ヒント

サブスクリプションが提供するノード名は変わることがあります(例:「HK-01」が「香港01」に変更される)。proxies にノード名を直接記述したグループはそれに伴い機能しなくなります。include-all: true と filter: "(?i)hk|港" を組み合わせて正規表現でノードを収集する方式に変えれば、サブスクリプション更新後もグループが自動的に追従し、リストを手動で管理する必要がなくなります。

CH-02

ルールセットのサブスクリプション管理

数千件の振り分けルールをrulesセクションに直接積み上げるのは、設定の保守性を損なう主な原因です。サブスクリプションが更新されるたびに手動で追加したルールが上書きされてしまいますし、特定のサイト群の振り分けを調整したい場合も長いリストから一件一件探す必要があります。rule-providers はルールを用途別に個別ファイルへ分割し、サブスクリプション形式で読み込む仕組みです。rulesセクションには数十行の「骨格」だけを残すことで、可読性と保守性が大きく向上します。

rule-providers の各フィールドの意味

type は http(リモートサブスクリプション、intervalに従って自動更新)または file(ローカルファイル、自分で管理)を指定します。behavior はこのルールファイルの内容形式を示します——domain は純粋なドメインリスト、ipcidr は純粋なIPレンジのリスト、classical は各種ルールタイプを混在させられ汎用性が最も高いですが、マッチングのオーバーヘッドがやや大きくなります。format は yaml、text、そしてmihomo独自のバイナリ形式mrsをサポートし、mrsはサイズが小さく読み込みが速いため、大規模なルールセットではmrsを優先すべきです。path はローカルキャッシュのパス、interval は自動更新の周期(秒)で、ルールセットの変更頻度は高くないため86400(1日)で十分です。

rule-providers:
  streaming:
    type: http
    behavior: classical
    format: yaml
    url: https://example.com/rules/streaming.yaml
    path: ./rule-sets/streaming.yaml
    interval: 86400
  cn-ip:
    type: http
    behavior: ipcidr
    format: mrs
    url: https://example.com/rules/cn-ip.mrs
    path: ./rule-sets/cn-ip.mrs
    interval: 86400

rules:
  - RULE-SET,streaming,ストリーミンググループ
  - RULE-SET,cn-ip,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,自動測速

ルールの順序とフォールバック

rulesセクションは上から下へ順にマッチングし、ヒットした時点で停止します。つまり順序=優先度です。個人の例外ルールは最上部に、大規模なルールセットは中間に、GEOIP,CN,DIRECT のような地理ルールは後方に配置し、最終行には必ず MATCH によるフォールバックを置いてください——フォールバックがない場合、マッチしなかったトラフィックの挙動はコアのデフォルト動作に依存し、問題調査の際に非常に分かりにくくなります。もう一つよくある落とし穴は、IP系のルール(GEOIP/IP-CIDR)をドメインルールより前に置くことです。IPルールは対象IPを取得するために一度DNS解決をトリガーするため、マッチングが遅くなるだけでなく、意図しない解決動作を招く場合があります。解決が必要かつトリガーしたくない場合は、ルールに no-resolve パラメータを追加してください。

GeoIPとGeoSiteデータベース

GEOIP,CN はコアが読み込むGeoIPデータベースに依存し、GEOSITE ルールはGeoSiteデータベースに依存します。両者とも時間の経過とともに古くなります——データベースが古すぎると、実際には中国本土にあるIPが海外と誤判定され、誤って代理経路に振り分けられることがあります。多くの現行メンテナンス中のクライアントは設定画面に「Geoデータベースを更新」する入口を用意しているので、1~2か月ごとに手動で実行することをおすすめします。mihomoでは設定に geo-auto-update: true と更新周期を宣言すれば、コアが自動的に取得することもできます。データベースファイルはクライアントの作業ディレクトリ内、設定ファイルと同階層に保存され、更新後は設定を再読み込みして反映させる必要があります。

注意

RULE-SET が参照する名前は rule-providers で定義されたキーと完全に一致させる必要があります(大文字小文字を区別)。未定義のルールセットを参照すると設定全体の読み込みに失敗し、クライアントのログに具体的な名前が表示されるので、エラー発生時はまずこの点を確認してください。

CH-03

DNS設定の最適化

振り分けの正確性は半分がDNSに依存します。ドメイン解決が汚染されると、GEOIPルールが得るのは誤ったIPとなり、振り分けが全面的に狂います。適切でないサーバーで解決すると、現在の経路から離れたCDNノードを取得してしまい、「ノードの遅延は低いのにWebページが遅い」という現象として現れます。dnsセクションは設定の中で最も調整する価値のある部分です。

enhanced-mode:redir-hostとfake-ip

モード	動作方式	利点	代償
`redir-host`	実際にドメインを解決し、接続に実IPを持たせる	動作が直感的で、LAN機器/デバッグツールとの互換性が良い	ドメインごとに実際の解決待ちが発生し、解決結果が汚染される可能性がある
`fake-ip`	予約範囲の仮IPを即座に返し、接続時にコアがドメインへマッピングし直す	解決待ちが不要で、ドメイン情報が完全に保持され、振り分けが最も正確	仮IPは外部プログラムから実アドレスとして扱えず、フィルターリストとの併用が必要

プロキシクライアントのデフォルト選択として、fake-ip は総合的な体験がより良く、特にTUNモードではほぼ標準構成です(第4章参照)。fake-ip-filter は実IPを必ず取得すべきドメインを列挙するためのものです——LAN機器の検出、NTP時刻同期、一部のゲームプラットフォームの接続性チェックなどは仮IPを受け取ると正常に動作しません。よくある記述例は以下の通りです。enhanced-modeを切り替えた後は、クライアントのDNSキャッシュを一度クリアすることをおすすめします(多くのクライアントは設定画面にボタンを用意しているか、コアを再起動すれば良い)。これにより新旧マッピングの混在を避けられます。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - time.windows.com
    - "+.ntp.org"
  nameserver:
    - https://223.5.5.5/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

nameserver、fallbackとグループ別解決

nameserver はメインの解決グループで、中国本土から直接接続可能なDoHサーバーを設定することをおすすめします。これにより中国本土のドメイン解決が速く、近隣のCDNを取得できます。fallback は検証グループで、海外のDoHを設定します——コアは両方の結果を比較し、nameserverが返したIPが fallback-filter で宣言された範囲(例:geoip-codeがCN)の外にある場合、汚染の可能性があると判断し、fallbackの結果に切り替えます。この仕組みにより、中国本土での解決速度と海外での解決の純度を両立できます。さらに nameserver-policy を使ってドメインごとに解決サーバーを指定することも可能です。例えば特定のルールセット内のドメインをすべて海外のDoHに任せるといった使い方で、精度は最も高くなりますが設定量も増えるため、必要に応じて使用してください。

解決プロトコルの選択

DNSサーバーアドレスは複数のプロトコルプレフィックスに対応しています。純粋なUDP(223.5.5.5)は最速ですが平文なので改ざんされる可能性があります。DoT(tls://)とDoH(https://)は暗号化通信で耐汚染性が高く、すべてのサーバーをDoH形式で記述することをおすすめします。注意点として、DoHサーバーのドメイン自体も解決が必要で、コアは default-nameserver(純粋なIPのUDPサーバーを指定すべき)を使ってこのブートストラップを行います。これを書き忘れると起動時にすべての解決が失敗します。速度低下がDNSに関係していると疑う場合は、3層特定法のローカル設定層の項目を一つずつ排除してください。その他の解決関連の問題はよくある質問のトラブル対処カテゴリにまとめています。

CH-04

TUNとFake-IP

システムプロキシは「プロキシ設定を尊重する」アプリケーションにのみ有効で、コマンドラインツール、ゲームクライアント、一部IMのUDPトラフィックはこれを回避します。TUNモードはシステム内に仮想ネットワークカードを作成し、すべてのレイヤー3トラフィックをコアに取り込んで処理する、最も網羅的な制御方式であり、UDPや非標準ポートのトラフィックを処理する正しい解決策です。

主要パラメータ

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-route はルーティングテーブルを自動的に書き込み、デフォルトルートを仮想ネットワークカードに向けます。無効にすると手動でルートを設定する必要があるため、通常は有効のままにします。auto-detect-interface はコアが実際の物理出口ネットワークカードを自動識別し、プロキシトラフィックのループを回避します。マルチネットワークカード構成(有線+無線、仮想マシンのNIC)では必須です。dns-hijack は53番ポートへの平文DNSリクエストをコアのDNS処理にハイジャックします。fake-ipと組み合わせることでTUN下のドメイン振り分けの正確性が保証されます——これがTUNとFake-IPがほぼ常にセットで使われる理由です。アプリケーションが仮想ネットワークカードを通じて発行するDNSクエリはコアに受け止められ、即座に仮IPを返します。以降の接続が仮IPレンジにヒットすると、コアが元のドメインを逆引きし、ドメインルールに基づいて正確に振り分けます。全過程でシステムのリゾルバに依存しません。

stackの3種類のプロトコルスタック

値	実装	特徴
`system`	OSのネットワークスタックを利用	スループットが良く、リソース消費が低い。一部システムでは互換性の細かい問題がある
`gvisor`	ユーザー空間のネットワークスタック	互換性が最も安定しているが、性能とメモリ消費はやや劣る
`mixed`	TCPはsystem、UDPはgvisorを使用	両者を両立する現時点での一般的な推奨設定

各プラットフォームの権限付与の違い

TUNはネットワークカードを作成するシステム権限が必要で、プラットフォームごとに手順が異なります。Windowsでは管理者権限でクライアントを実行するか、クライアントの設定でシステムサービスをインストールしてサービスに権限を代行させれば日常的な権限昇格は不要になります。macOSでは初回有効化時にシステム拡張機能/ネットワーク拡張機能の許可ダイアログが表示されるので、「システム設定 → プライバシーとセキュリティ」で許可してからスイッチを再度オンにしてください。Linuxではrootが必要か、コアのバイナリに cap_net_admin 権限を付与する必要があります。Androidは TUN ではなく VpnService と呼ばれ、初回有効化時にVPN接続の許可ダイアログが表示されるので同意すれば動作しますが、メーカーの省電力ポリシーによってバックグラウンドサービスが強制終了され切断されることがよくあるため、クライアントを省電力ホワイトリストに追加する必要があります。詳細はAndroid利用時の注意点を参照してください。iOSクライアント(App Store版Clash Plusなど)はNetwork Extensionを基盤としており、許可フローはシステムが一括して管理します。各プラットフォームのクライアントの入手方法はダウンロードページをご覧ください。

注意

TUNとシステムプロキシを同時に有効にしても競合はしませんが、問題を調査する際は制御方式を一つだけに絞ることをおすすめします。そうしないとトラフィックがどの経路を通っているか判断しにくくなります。TUNを無効化した後にネットワーク異常が発生する場合は、ルーティングテーブルの残留が原因であることが多く、コアまたはシステムのネットワークを一度再起動すれば復旧します。

CH-05

ドメインスニッフィング

すべての接続が自然にドメイン情報を持っているわけではありません。アプリケーションが独自のDNSを使用している場合(ブラウザ内蔵のDoHなど)、コアが見るのは単なる目的IPだけで、ドメインルールはすべて外れ、GEOIP判定に頼るしかなくなります。fake-ip-filterで許可されたドメインも同様に実IPの形で現れます。ドメインスニッフィング(sniffer)はトラフィック自体からドメインを復元します——HTTPリクエストのHostヘッダー、TLSハンドシェイクのSNIフィールド、QUICの初期パケットには平文のドメインが含まれており、コアはこれを読み取って接続のメタデータを書き換え、再度ドメインルールを適用することで、こうした「IPしか見えない」接続を正確な振り分けの対象に戻します。

設定例

sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080-8880]
      override-destination: true
    TLS:
      ports: [443, 8443]
    QUIC:
      ports: [443]
  skip-domain:
    - "+.push.apple.com"
  force-domain:
    - "+.v2ex.com"

sniff の下でプロトコルごとにスニッフィング対象のポート範囲を宣言し、3種類のプロトコルでほとんどのシナリオを網羅します。override-destination はスニッフィングで得たドメインで接続の宛先を上書きするかどうかを決め、有効にすると振り分けとログの両方がドメインで表示されます。skip-domain はスニッフィング後にむしろ問題が起きるドメインを除外します——一部のプッシュサービスや証明書検証が厳しいクライアントは宛先が書き換えられると接続に失敗するため、そうした場合は該当ドメインをここに追加します。force-domain は逆に、ヒットしたドメインに対して強制的に上書きを実行します。

いつ必要でいつ不要か

fake-ipを有効にしていて、アプリケーションがすべてコアのDNSを通じて解決している場合、接続自体がすでにドメイン情報を持っているため、スニッフィングによる効果は限定的です。本当に恩恵を受けるのは、TUN下で独自のDoHを使うブラウザのトラフィック、システムの解決を回避するモバイルアプリ、そしてredir-hostモードでの振り分け精度の補完です。スニッフィングは新規接続ごとの先頭パケットに対して一度解析を行うだけなのでCPU負荷はごく小さく、常時有効でも問題ありません。ただし特定のアプリでスニッフィングを有効にした後に異常な切断が発生する場合は、まず宛先の上書き動作を疑い、skip-domainで対象を絞って除外するべきで、全体を無効化するべきではありません。ログ(第7章参照)の接続項目がIPからドメインに変わっていれば、スニッフィングが有効に機能している証拠です。

CH-06

ローカルオーバーライドと複数サブスクリプションの統合

サブスクリプションが配布する設定ファイルを直接編集するのは最もよくある保守上の誤りです。サブスクリプションを更新するたびに、手動での変更がすべて失われてしまいます。正しいやり方は「サブスクリプションが提供するノード」と「自分で管理するルール、DNS、プロキシグループ」を分離することです——サブスクリプションはノードを担当し、ローカルオーバーライドはそれ以外のすべてを担当します。サブスクリプションを更新してもノードだけが更新され、個人の設定は常に変わりません。

クライアント層のオーバーライド機構

現行メンテナンス中のデスクトップクライアントには一般的にオーバーライド機能が組み込まれています。Clash Verge Rev は「グローバル拡張設定」とスクリプトオーバーライドを提供し、YAMLマージやJavaScript関数でサブスクリプション設定が反映される前に任意のフィールドを書き換えられます。Clash Plus、FlClash もそれぞれのオーバーライド/ミックス入口を提供しています。Verge Revの Merge オーバーライドを例にすると、プレフィックスの意味は次の通りです:prepend- は元のリストの先頭に挿入、append- は末尾に追加、フィールド名を直接書くとそのセクション全体を置き換えます。

prepend-rules:
  - DOMAIN-SUFFIX,internal.example.com,DIRECT
append-rules:
  - MATCH,自動測速
dns:
  enable: true
  enhanced-mode: fake-ip

上記の例は、社内直結ルールを1件、すべてのサブスクリプションルールの前に挿入し(優先的にヒットするよう保証)、フォールバックルールを1件追加し、dnsセクションを全体的に置き換えています。ルール系のオーバーライドはprependを優先して使うべきです。rulesは順序でマッチングされるため、前に挿入することで確実に有効になります。

コア層のproxy-providersによる複数サブスクリプションの統合

複数のサブスクリプションを同時に保有している場合、クライアント内で設定を切り替える必要はありません。proxy-providers を使って複数のサブスクリプションをノードのソースとして1つの設定にまとめて取り込むことができます:

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

proxy-groups:
  - name: 全ノード
    type: select
    use: [sub-a, sub-b]
  - name: 香港自動
    type: url-test
    use: [sub-a, sub-b]
    filter: "(?i)hk|香港"
    url: https://www.gstatic.com/generate_204
    interval: 300

プロキシグループは use で provider を参照し、ノード名を1つずつ書く必要はありません。filter の正規表現によるフィルタリングと組み合わせれば、2つのサブスクリプションの香港ノードが自動的に同一の測速グループに統合されます。サブスクリプションはそれぞれ interval に従って更新され、互いに影響しません。health-check により provider 内のノードが独立して生存確認され、失効したノードがグループに残り続けることを防ぎます。2つのサブスクリプションで同名のノードが出た場合コアは競合エラーを出すので、providerの override.additional-prefix でノード名に統一的なプレフィックスを付けて区別できます。

外部コントロールパネル

mihomoコアはRESTfulな制御インターフェース(通称 external controller)を公開しており、クライアントのパネル自体もその利用者の一つです。このインターフェースを開放すれば、独立したWebパネルを接続したり、コマンドラインで直接コアに問い合わせ・操作したりできます——リモートでルーターのコアを管理したり、自動化スクリプトを書いたりする際に利用します。

インターフェースの有効化

external-controller: 127.0.0.1:9090
secret: "your-secret"
external-ui: ./ui
external-ui-url: https://example.com/panel.zip

external-controller はリスニングアドレスを宣言します。自分のマシンだけで使う場合は 127.0.0.1:9090 と記述し、LAN内の他のデバイスからアクセスする(ルーターを管理するなど)場合は 0.0.0.0:9090 に変更します。この場合 secret は必ず強力なパスワードに設定してください——このインターフェースはすべての接続記録を読み取り、ノードを切り替えられるため、無防備な状態はLAN内の誰にでも制御権を渡すことに等しくなります。external-ui は静的パネルのディレクトリを指し、コアは同じポートの /ui パスでこれを配信します。external-ui-url はコアがパネルの圧縮ファイルを自動的にダウンロードして解凍し、そのディレクトリに配置してくれるので、手動デプロイが不要になります。

よく使うインターフェース一覧

メソッドとパス	機能
`GET /proxies`	全ノードとプロキシグループ、および現在の選択項目を一覧表示
`PUT /proxies/:name`	特定のselectグループの選択ノードを切り替え
`GET /connections`	アクティブな接続を確認(宛先、ヒットしたルール、使用ノード)
`GET /logs`	ストリーミング形式でコアのログを読み取り
`PUT /configs`	一部の設定をホットリロード(モード切り替えなど)
`GET /traffic`	リアルタイムの上り/下り速度ストリーム

コマンドラインでインターフェースが利用可能か確認し、手動でノードを一度切り替えてみます:

curl -H "Authorization: Bearer your-secret" \
  http://127.0.0.1:9090/proxies

curl -X PUT \
  -H "Authorization: Bearer your-secret" \
  -H "Content-Type: application/json" \
  -d '{"name":"香港自動"}' \
  http://127.0.0.1:9090/proxies/手動選択

接続ビューで振り分けを調査する

このインターフェースの最も実用的な日常的価値は、「あるサイトが実際にどのルールを通ったか」を調査できることです。パネルの接続ページ(または GET /connections)を開き、ドメインでフィルタリングすると、各接続にヒットしたルールと最終的な出口ノードが表示されます。振り分けが期待通りでない場合、まずここでルールの記述ミスか、順序の問題か、DNS/スニッフィング層でドメインが取得できていないか(項目が純粋なIPで表示されているのがその兆候で、第3章・第5章に戻って対処)を確認してください。設定を当てずっぽうに変更するより、はるかに効率的です。ログレベルは設定内で log-level: info により調整可能で、調査中は一時的に debug に変更し、特定が終わったら必ず戻してください。ログの過剰出力によるパフォーマンス低下を避けるためです。