Clash 高度な設定ハンドブック

設定の基礎:ファイル構造と反映方法

これから7章にわたって解説する内容は、最終的にすべて同じ1つの YAML 設定ファイルに落ち込みます。始める前にまず、コアが読み込む設定が実際どこから来て、いくつの部分から構成され、変更後にどう反映を確認するかを理解しておきましょう。この章は全体の基礎であり、これを飛ばして直接設定を変更すると、「変更したのに反映されない」「サブスクリプションを更新したらカスタム設定が全部消えた」といった事態に陥りやすくなります。

設定ファイルの出どころと階層

日常的な利用では、コアが実際に読み込む設定は単一のファイルではなく、通常3層の内容を合成した結果です。最下層はサブスクリプションから取得した元の YAML(ノード一覧とプロバイダー側が用意したグループ・ルールを含む)。中間層はクライアント(Clash Plus、Clash Verge Rev など)が提供するローカルオーバーライド(Merge/Script)で、サブスクリプションの上にフィールドを追加・置換します。最上層はクライアントの画面上の設定(ポート、システムプロキシ、TUN など)で、一部のクライアントはこれらの設定も最終的な設定に統合します。この階層を理解する意味は、長期的に保持したいカスタム設定はすべてオーバーライド層に書くべきで、サブスクリプションファイルを直接編集してはいけない、という点にあります。サブスクリプションが更新されると、直接編集した内容はそのまま上書きされてしまいます。オーバーライドの具体的な方法は第7章を参照してください。

避けて通れない主要フィールド

以下のフィールドは設定ファイルのトップレベルに現れ、以降の章でも繰り返し参照するので、先に把握しておきましょう。

mode について補足すると、通常は rule(ルールに基づく振り分け)を維持すべきです。global は全通信を1つのポリシーに丸投げするもので、「ルールに問題があるかどうか」を一時的に確認する用途にのみ向きます。direct はプロキシを一時的に無効化するのと同じです。3つのモードはいずれもクライアント画面上でワンクリック切り替えでき、ファイルを編集する必要はありません。

変更後の反映確認方法

設定変更後の反映方法は2つあります。クライアント画面の「設定の再読み込み」ボタン(既存の動作状態を切断せずに反映できるため推奨)、またはコアの再起動です。反映を確認する最も確実な方法はログページを見ることです。コアの起動・再読み込み時にはリスンポート、TUN 状態、ルール数などが逐次出力されます。設定に構文エラーがあると再読み込みは失敗し、ログに行番号が示されます。ログの項目が分からない場合は、こちらの記事を参考にしてください:Clash の動作ログの見方。YAML を編集する際の一般的な注意点として、インデントは必ずスペースを使い、タブは使わないでください。YAML はインデントに極めて敏感で、「設定の読み込みに失敗した」という不具合の多くは単なるインデントのずれです。

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

プロキシグループ(proxy-groups)は振り分け体系の中枢です。ルールがマッチしても直接特定のノードを指すわけではなく、プロキシグループを指し、グループが「今どのノードを使うか」を決定します。サブスクリプションには通常あらかじめグループが用意されていますが、各タイプの動作の違いを理解すれば、自分の使い方に合わせて自由に再設計できます。

よく使う4種類の動作の違い

url-test と fallback の本質的な違いに注意:前者は「最速」を追求し、ノードの順位が変わればすぐ切り替えます。後者は「安定性」を追求し、リストの上位ノードが生きている限り決して切り替えません。日常のウェブブラウジングには url-test が快適で、接続の継続性に敏感な用途(オンライン会議、長時間のログイン状態維持)には fallback がより適しています。

参考にできるグループ設定例

proxy-groups:
  - name: 節点選択
    type: select
    proxies: [自動測速, 故障転移, 香港-01, 日本-01, DIRECT]

  - name: 自動測速
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies: [香港-01, 香港-02, 日本-01]

  - name: 故障転移
    type: fallback
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: [香港-01, 日本-01, 新加坡-01]

  - name: 下載専用
    type: load-balance
    strategy: consistent-hashing
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: [香港-01, 香港-02, 香港-03]

重要なパラメータをいくつか説明します。url はヘルスチェックの対象アドレスで、204 ステータスを返す軽量なアドレスを使うのが慣例です。interval はチェック間隔(秒)で、120未満は避けるべきです。頻繁すぎる測定自体がノードの流量を消費します。tolerance は url-test のみに有効で、新旧の最速ノードの遅延差がこのミリ秒数を超えた場合のみ切り替えることを意味し、遅延が近い2つのノード間で頻繁に切り替わる現象を効果的に抑えられます。load-balance の strategy は consistent-hashing(同一の宛先には常に同じノードを使い、ログイン状態の維持に有利)または round-robin(接続ごとに順番に振り分け、より徹底的に分散)から選べます。さらにグループに lazy: true を付けると、使われていないときは測定を一時停止し、通信量をさらに節約できます。

実践:入口—機能—地域の3層構造

プロキシグループは他のプロキシグループを参照できます。これは振り分け体系を設計する際に最も有用な特性です。推奨される構成は3層です。最上層は1つの select 型メイン入口(通常は「自動測速」に手動で固定)。中間層は業務別に分けた機能グループで、「ストリーミング」「AI サービス」「ダウンロード専用」など、各機能グループはすべて select 型で、候補には地域グループとメイン入口を入れます。最下層は地域別に集約した url-test グループ(香港自動、日本自動など)です。これにより日常的な操作は不要で、ある業務を特定の地域に固定したい場合は対応する機能グループでクリックするだけで、他の通信には影響しません。ルールがこれらの機能グループをどう指すかは次章で解説します。

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

数千件の DOMAIN-SUFFIX を設定ファイルの rules セクションに直接記述するのは、保守も更新も困難です。ルールセット(rule-providers)はルールを独立したファイルに分割し、サブスクリプション形式で参照します。メイン設定には1行の RULE-SET だけを残し、ルール本体はコアが定期的に遠隔から取得してローカルにキャッシュします。ルールの更新をメイン設定から分離できるこの改造は、高度な設定の中でも最も効果が高いものです。

behavior と format:ルールファイルの3つの「体質」を見分ける

format はファイル形式を示します。yaml と text は人間が読めるテキスト形式です。mrs は mihomo のバイナリ形式で、読み込みが速く容量も小さいですが、domain と ipcidr の2つの behavior しか対応せず、エディタで直接内容を確認できません。他人が管理するルールリポジトリを参照する際は、behavior と format をファイルの実際の内容と一致させる必要があり、誤ると全体のルールセットの読み込みが失敗します。

宣言と参照の例

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

rules:
  - RULE-SET,streaming,ストリーミング
  - RULE-SET,cn-ip,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,節点選択

interval は自動更新間隔(秒)で、ルール一覧の変動はさほど頻繁ではないため 86400(1日)で十分です。path はローカルキャッシュのパスで、オフライン起動時にはコアがそのままキャッシュを使うため、遠隔取得に失敗しても起動できなくなることはありません。

マッチ順序と no-resolve

rules セクションは上から下へ順にマッチし、命中すれば停止するため、順序がそのまま優先度になります。一般的な配置原則:具体的な業務に対応する厳密なルールを前に置き、GEOIP のような IP ルールは後ろに置きます。IP ルールに遭遇した際、対象がまだドメイン名の場合、コアはまず DNS 解析を行って帰属を判定する必要があるため、前に置くとすべてのリクエストのマッチが遅くなります。IP 系ルールに no-resolve サフィックスを付けると、「対象が IP でなければこの条項をスキップし、解析をトリガーしない」ことを意味し、解析コストを抑える常用手段です。最後の1行は必ず MATCH による兜底とし、そうしなければ未マッチの通信の挙動が予測不能になります。

DNS 設定の最適化

「ルールは正しく書いたはずなのに振り分けが合わない」「ページを開いた瞬間だけ極端に遅い」といった問題の多くは、根本原因が DNS にあります。Clash が DNS モジュールを内蔵しているのは、振り分けの判断がドメイン解析の結果に強く依存しているためです。解析が汚染されると IP ルールの判定を誤り、解析が低速な経路を通ると全リクエストがそれを待つことになります。この章では DNS 各フィールドの役割分担と、国内・海外ドメインを分けて解析する標準的な方法を解説します。

フィールドの役割分担:default-nameserver と nameserver

最も混同しやすいフィールドの組:default-nameserver は1つのことしかしません。それは nameserver に指定した DoH/DoT サーバー自体のドメイン(例えば doh.pub というドメイン自体もまず IP に解析する必要がある)を解析することだけであり、そのため純粋な IP 形式の従来型 DNS を指定する必要があります。nameserver こそが日常のクエリで実際に使われる上流で、暗号化 DNS(DoH/DoT)を指定することを推奨します。平文クエリが経路上で改竄されるのを避けられます。enhanced-mode は解析結果の表示方法(fake-ip または redir-host)を決め、TUN との関係が密接なので、詳細は第4章で展開します。

ドメインごとに異なる上流を使う:nameserver-policy

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://doh.pub/dns-query
    "geosite:geolocation-!cn":
      - https://dns.cloudflare.com/dns-query
      - https://dns.google/dns-query

nameserver-policy は、旧来の fallback + fallback-filter の組み合わせに代わる現代的な設定として推奨されます。ドメインの帰属に応じて直接上流を指定できます。中国本土のドメインは中国本土の公共 DoH に任せて最寄りの CDN ノードを取得し速度を最適化、海外ドメインは国際 DoH に任せて解析の汚染を根本から避けます。geosite: 接頭辞が参照するのはコアに付属するドメイン分類データベースで、自分でドメインリストを管理する必要はありません。全クエリを一度問い合わせてから結果をフィルタする fallback 方式と比べ、policy 方式は経路が短く挙動が予測しやすくなります。

よくある誤解と検証方法

誤解その1:nameserver をすべて海外の DNS にする。海外の上流が国内ドメインを解析すると海外向けの CDN ノードが返り、国内への直接接続の通信がむしろ遅くなります。これは「プロキシを有効にしたら国内サイトも重くなる」の頻出原因の一つで、トラブル対処の手順は通信速度が遅い場合のチェックリストを参考にしてください。誤解その2:ブラウザ内蔵の DoH を無視すること。Chrome/Firefox の「セキュア DNS」設定はクライアントの DNS モジュールを迂回してしまい、fake-ip とドメインルールが両方無効になります。ブラウザの設定でオフにするか、ドメインスニッフィングで兜底するのが推奨です。DNS 設定が想定どおり動作しているか検証する最も直接的な方法は、debug ログを開いて各ドメインが実際に使用している上流を観察することです。解析関連の問題はFAQ ページのトラブル対処カテゴリも参照してください。

TUN モードと Fake-IP

システムプロキシモードでは、「システムプロキシ設定を守る」意思のあるアプリだけがクライアントに通信を渡します。ブラウザはほぼ守りますが、多くのデスクトップアプリ、コマンドラインツール、ゲームクライアントはこの設定を無視して直接接続してしまいます。TUN モードは仮想ネットワークカードを作成してネットワーク層で全通信を横取りします。アプリが対応しているかどうかに関わらず、すべて振り分けの対象に取り込めるのがその核心的な価値です。

TUN を有効化する最小構成

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

auto-route はシステムのルーティングテーブルを自動設定し、デフォルトルートを仮想ネットワークカードに向けます。auto-detect-interface は実際の物理ネットワークカードを自動識別して出口とし、通信が仮想ネットワークカード内でループしてしまう事態を避けます。dns-hijack は任意のアドレスの53番ポートへの平文 DNS クエリをコアの DNS モジュールへハイジャックし、解析の入口を一本化します。この項目は fake-ip が正常に動作するために非常に重要です。実際の利用では通常このセクションを手書きする必要はなく、Clash Plus や Clash Verge Rev などのクライアントに TUN スイッチが用意されており、クライアントが同等の設定を注入してくれます。

stack の3つの実装

特に要望がなければ mixed を選びましょう。あるアプリが TUN 下で異常動作した場合、stack を別の実装に切り替えて試すのが互換性トラブル対処の定石です。

Fake-IP:原理と例外リスト

enhanced-mode: fake-ip の動作方式:アプリがドメイン名クエリを発行すると、DNS モジュールは実際の解析を行わず、198.18.0.0/16 の予約範囲内の「偽の IP」を即座に返し、この偽 IP とドメインの対応関係を記憶します。アプリは偽 IP を使って接続を開始し、コアは接続を受け取った時点でドメインを逆引きし、ドメインルールに基づいて振り分けます。実際の解析が必要な場合は出口側で行われます。メリットは明快です。ローカルでの実際の解析待ちの往復を省略でき、ルールマッチには汚染の可能性があるIPではなく信頼できるドメインが渡されます。対となる redir-host モードは実際の IP を返すためより「従来型」の互換性を持ちますが、解析の待ち時間と汚染のリスクを伴うため、現在は推奨デフォルトとされていません。

fake-ip の代償は、一部のプログラムが解析結果を接続以外の用途(時刻同期、LAN 内発見、IP をサーバーへ報告するなど)に使っており、偽 IP がそれらを誤動作させることです。fake-ip-filter はまさにこの例外リストで、リストに載ったドメインは実際の解析結果を返します。

dns:
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "time.windows.com"
    - "+.ntp.org"
    - "+.stun.*.*"

典型的にリストへ加える必要があるもの:NTP 時刻同期用ドメイン、LAN 内 mDNS ドメイン、STUN やオンライン対戦ゲームなど実アドレスの交渉が必要なサービス。TUN + fake-ip を有効にしたときだけ特定のアプリが異常になる場合、まずこのリストへの追加が必要かを疑ってください。

ドメインスニッフィング

振り分けルールの大部分はドメインを軸に書かれていますが、コアに到達した時点で IP しかなくドメインがない接続もあります。アプリ自体に内蔵の DNS がある(例:ブラウザで DoH を有効にしている)ためクライアントの解析を迂回している場合や、プログラムが直接 IP をハードコードして接続している場合です。この種の接続は GEOIP と兜底ルールにしか頼れず、振り分けの精度が大きく落ちます。ドメインスニッフィング(sniffer)の役割は、ドメインを「取り戻す」ことです。TLS ハンドシェイクの SNI フィールド、HTTP リクエストの Host ヘッダー、QUIC の初期パケットといった平文のメタデータから対象ドメインを読み取り、それを使ってルールマッチに再度参加させます。

有効化とポート範囲

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

sniff の下でプロトコル別にスニッフィング対象のポート範囲を宣言します。スニッフィングは接続の最初の数パケットを読む必要があり、一般的なポートに限定することでコストを無視できるレベルに抑えられます。補足すると、スニッフィングが読み取るのはプロトコルのハンドシェイク段階でもともと平文で送られているメタデータ(SNI、Host)だけで、暗号化されたコンテンツを復号するものではありません。

override-destination、force-domain、skip-domain

override-destination はスニッフィングでドメインを検出した後、接続の宛先アドレスをそれで置き換えるかどうかを決めます。有効にすると、以降のマッチとアウトバウンドはスニッフィングで検出したドメインを基準にし、「偽 IP のマッピング期限切れ」「アプリが古い IP で新しいサービスに接続する」といったずれを補正できるため、一般的には有効化を推奨します。force-domain は強制スニッフィングリストで、リストに載ったドメインは既に解析記録があっても再度スニッフィングして照合します。CDN ドメインと実際のサービスドメインがしばしば一致しないサイトに向いています。skip-domain はスキップリストで、一部のデバイスクラウドサービス(例中の Mijia Cloud)は TLS ハンドシェイクに非標準の識別子を載せるため、スニッフィングで置き換えるとむしろ接続できなくなる場合があり、それらを除外します。この3つのパラメータを組み合わせることで、スニッフィングの介入範囲を細かく制御できます。

いつスニッフィングを有効にすべきか

次の2つのシグナルが必要性を示します。1つはログに宛先が純粋な IP の接続が大量に現れ、最終的に GEOIP や MATCH でしか処理されていない場合。もう1つはドメインルールをきちんと書いたのに、一部アプリの通信が常にマッチしない場合です。スニッフィングを有効にすると、ログを見直した際にこれらの接続にドメインが再び付くようになり、ルールのマッチ状況がすぐに改善します。前章の fake-ip と併用する際、スニッフィングはブラウザの DoH がクライアントの DNS を迂回した後の最後の兜底としても機能します。ちなみに、スニッフィングの有効化前後でブラウザに証明書の警告が出た場合、通常は無関係です。具体的な原因はこちらの分析を参照してください:Clash を有効にした後に HTTPS 証明書エラーが出る原因。

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

第1章で触れた原則を思い出してください。カスタム設定はオーバーライド層に書き、サブスクリプションの原文は変更しません。この章では2つのことを詳しく解説します。クライアントのオーバーライド機能で自分の変更を永続化する方法、そして複数のサブスクリプションを同じグループ体系に統合する方法です。

ローカルオーバーライド:サブスクリプション更新後もカスタム設定を残す

主要なクライアント(Clash Plus、Clash Verge Rev など)はいずれも「オーバーライド/Override」機能を提供しており、一般的な形態は2種類あります。宣言的な Merge——YAML の断片を書いておき、クライアントがサブスクリプションを読み込むたびにそれを統合します。手続き的な Script——短いスクリプト関数を書き、解析済みの設定オブジェクトを受け取って加工し返します。Merge は DNS セクションの追加、カスタムルールの前置といった構造化された変更に向いています。Script は「すべてのグループに一括でノードを追加する」「名前でノードをフィルタする」といった走査処理が必要な場面に向いています。典型的な Merge の断片:

dns:
  enable: true
  enhanced-mode: fake-ip

rules:
  - DOMAIN-SUFFIX,internal.example.com,DIRECT
  - PROCESS-NAME,Steam.exe,DIRECT

Merge の統合セマンティクスはクライアントによって微妙に異なります(全体置換か項目ごとの追加か、ルールが前置か後置か)。初めて使う際は必ずクライアント上で統合後の最終設定をプレビューして期待どおりか確認し、保存・有効化してください。各クライアントのオーバーライド入口の位置は、ブログの画面機能クイックガイドを参考にしてください。

proxy-providers:複数サブスクリプションを統合する正しい方法

複数のサブスクリプションを同時に持っている場合、複数の設定ファイルを切り替えて使うのは避けるべきです。proxy-providers を使って各サブスクリプションを1つのノードプロバイダーとして宣言し、プロキシグループで use フィールドを使って参照すれば、すべてのノードが同じグループ・ルール体系に統合されます。

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

proxy-groups:
  - name: 全部節点
    type: select
    use: [airport-a, airport-b]
  - name: 香港自動
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    use: [airport-a, airport-b]
    filter: "(?i)香港|HK|Hong Kong"

filter は正規表現でノード名を絞り込むもので、地域グループを構築する上で重要です。2つのプロバイダーの香港ノードは自動で同じ「香港自動」グループにまとめられ、速度を競わせられます。use と proxies は同一グループ内で併用でき、手動ノードとサブスクリプションのノードを混在させても問題ありません。

更新戦略とフェイルセーフ

interval: 43200(12時間)はサブスクリプションとして十分頻繁です。path のキャッシュは取得に失敗した際に前回のノード一覧を継続利用することを保証し、あるサブスクリプションの API が不調でも全体が停止することはありません。health-check は各プロバイダーで有効にすることを推奨します。そうしないと url-test グループが遅延データを取得できず、自動選択ができません。また注意点として、プロバイダーの url はコアが直接リクエストを発行するため、サブスクリプションのアドレス自体にプロキシが必要な場合は、プロバイダー側にプロキシ経路を設定するか、あらかじめ直接接続可能な経路を確保しておく必要があります。「鶏が先か卵が先か」のデッドロックを避けましょう。

外部コントロールと管理パネル

コアには RESTful のコントロールインターフェース(external controller)が内蔵されており、クライアントの GUI 自体はこのインターフェースの利用者にすぎません。これを理解すると多くの使い方が広がります。ブラウザのパネルでソフトルーター/サーバー上で動く単体コアを管理したり、スクリプトを書いて定期的にポリシーを切り替えたり、接続データを自分の監視システムに取り込んだりできます。

インターフェースの有効化とアクセス制御

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

external-controller を 127.0.0.1 にリスンさせると、自分のマシンからしかアクセスできません。これはデスクトップ環境での安全なデフォルトです。0.0.0.0:9090 に変更すると LAN 内の他デバイスからもアクセス可能になり、この場合 secret を必ず設定し十分に複雑にする必要があります。このインターフェースは接続の読み取り、ポリシーの変更、設定の再読み込みができ、クライアントを完全に制御できる権限と同等です。リクエスト側は Authorization: Bearer ヘッダーで鍵を渡します。

よく使う API

# すべてのプロキシグループとノードの状態を確認
curl -H "Authorization: Bearer your-password" http://127.0.0.1:9090/proxies

# 「節点選択」グループを指定した候補に切り替える
curl -X PUT -H "Authorization: Bearer your-password" \
  -d '{"name":"香港自動"}' \
  http://127.0.0.1:9090/proxies/節点選択

# 現在のアクティブな接続を確認
curl -H "Authorization: Bearer your-password" http://127.0.0.1:9090/connections

# 指定したノードの遅延テストをトリガー
curl -H "Authorization: Bearer your-password" \
  "http://127.0.0.1:9090/proxies/香港-01/delay?timeout=5000&url=https://www.gstatic.com/generate_204"

さらに /logs と /traffic はストリーミングインターフェースで、ログとリアルタイム流量を継続的にプッシュします。パネルでスクロールするログや速度グラフはここから来ています。PATCH /configs は再起動せずに mode の切り替えやポートの変更が可能です。

Web パネル:単体コアに顔を与える

external-ui は静的な Web ページのディレクトリを指し、コアはそれをコントロールポートの /ui パスで公開します。external-ui-url はコアに自動でパネルのリソースパッケージをダウンロード・展開させます。コミュニティでよく使われるパネルには metacubexd、yacd とその派生版があり、機能はおおむね似ています。グループの切り替え、遅延テスト、接続一覧、ルールとログの確認などです。この使い方は「サーバーやルーター上で単体の mihomo コアを動かす」場面に最も適しています。コアのインストールパッケージはダウンロードページのコア入手セクションから入手できます。デスクトップ利用者には通常不要で、Clash Plus や Clash Verge Rev などのクライアントは同様の機能をすでにローカル画面に組み込んでいます。