Clash 高度な設定マニュアル

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

プロキシグループは設定ファイルの中で要となる層だ。ルールが決めるのは「どの種類のトラフィックをどのグループに渡すか」、プロキシグループが決めるのは「今このグループがどのノードを使うか」。分岐運用がスムーズかどうかは、プロキシグループの構造設計が合理的かどうかで八割決まる。mihomo カーネルは5つの基本タイプをサポートしており、挙動の違いは以下の通り。

5種類の挙動の違い

select は最も一般的でありながら過小評価されやすいタイプだ。自動判断を一切行わないが、それゆえに挙動が完全に予測可能で、「人が判断を下す」総合入口に適している。url-test と fallback の違いは混同されやすい——前者は常に「現時点で最速」を追求するため、ノードが不安定なときに頻繁に切り替わることがある。後者は「リスト上位で使えるもの」を追求し、現行ノードが失効したときのみ切り替わるため安定性を優先する。リモートデスクトップや音声通話のようなインタラクティブなアプリでは、切り替えは接続の再構築を意味するため、url-test より fallback のほうが体感が良いことが多い。

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

自動測速グループの挙動は3つのパラメータで制御される。interval は測速周期(秒)で、300 が一般的な値。短すぎると大量の探測リクエストが発生し、モバイル環境ではバッテリー消耗にもつながる。tolerance は許容差(ミリ秒)で、新たな最速ノードが現行ノードよりこの値以上速くならないと切り替えが発生しない。50 程度から始めると無意味な切り替えを大きく減らせる。lazy を true にすると、トラフィックが流れていない間は測速をスキップし、ノード数が多い構成では探測コストをかなり抑えられる。

実戦的なグループ構造

推奨される構造は3層だ。最上位に select の総合入口を1つ、中間層は地域や用途で分類、最下層に具体的なノードを置く。ルールは常に最上位または中間層のグループを指し、ノードを直接指定しない——これにより契約プロバイダーやノード名が変わってもルールを書き換える必要がない。例:

proxy-groups:
  - name: 节点选择
    type: select
    proxies: [自动测速, 故障转移, 香港节点, 日本节点, DIRECT]

  - name: 自动测速
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
    proxies: [HK-01, HK-02, JP-01]

  - name: 故障转移
    type: fallback
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: [HK-01, JP-01, SG-01]

  - name: 香港节点
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: [HK-01, HK-02]

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

数百から数千のルールをメイン設定に直接書き込むのは、保守性の悪化への第一歩だ。サブスクリプションが更新されればすべてやり直しになり、1つのルールを調整するにも長大なファイルの中を探し回る必要がある。ルールセット(rule-providers)はルールを独立した外部ファイルへ切り出す仕組みで、メイン設定には参照だけを残し、ルール内容は周期的に自動更新される。メイン設定は十数行のシンプルさを保てる。

behavior の3種類

各ルールセットには behavior を必ず指定する必要があり、これがファイル内容の解析方式を決定する。3種類は混在させられない。domain タイプのファイルはドメイン(+. ワイルドカードプレフィックス対応)のみを含み、マッチング効率が最も高い。ipcidr は IP 帯(CIDR 表記)のみ。classical は完全なルール構文(DOMAIN-SUFFIX、IP-CIDR、DST-PORT などの混在)を許すが、柔軟な一方でマッチングコストはやや高い。原則として、domain または ipcidr で済むなら classical を使わず、混合条件が本当に必要な場面のみ classical に任せる。

format と更新周期

format は yaml、text、および mihomo 独自のバイナリ形式 mrs に対応する。mrs は事前コンパイル済みの成果物で容量が小さく読み込みも速いため、大規模なドメイン/IP 集合(たとえば地域全体の IP データベースなど)には優先的に選びたい。自分で手書き管理する小規模なルールセットは yaml か text で十分。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
  - MATCH,节点选择

参照構文は RULE-SET,ルールセット名,ポリシー。ルールはあくまで上から順に1つずつ照合し、マッチしたら停止する。RULE-SET の並び順も通常のルールと同様に重要だ。ヒット率の高い集合を前に置き、IP 系のルールはドメイン系ルールの後に置く(IP ルールは DNS 解決を発生させるため、前倒しは無駄になる)。MATCH の兜底ルールは常に最終行に置く。

DNS 設定の最適化

DNS は分岐品質の土台だ。ドメイン解決が汚染されれば、IP ルールは誤った IP に基づいて判定してしまう。解決サーバーの選定が不適切なら、直接接続のトラフィックが迂回したり CDN が低速なノードに割り当てられたりする。カーネルには完全な DNS モジュールが組み込まれており、各フィールドの役割を理解すれば、「ルールは正しく書いたはずなのに効かない」という問題の大半は自然に解消する。

nameserver と default-nameserver の役割分担

nameserver はメインの解決サーバーリストで、すべての業務ドメインの解決を担当する。DoH(DNS over HTTPS)アドレスを使うことで、平文 53 番ポートへの干渉を回避できるため推奨される。ここで鶏と卵の問題がある。DoH アドレス自体もドメイン名であり、それ自身も解決される必要がある——これが default-nameserver の存在理由だ。nameserver リストに現れるドメインのみを解決する役割で、純粋な IP による従来型 DNS を指定する必要がある。両者は役割が異なり、互いに置き換えることはできない。

nameserver-policy によるドメイン別振り分け

nameserver-policy はドメインパターンごとに専用の解決サーバーを指定できる。国内向けドメインは国内 DNS で最寄りの CDN を取得し、それ以外は信頼できる暗号化 DNS で汚染を回避する。geosite 分類の参照に対応しており、1行で大きなドメインカテゴリをカバーできる。旧式の fallback + fallback-filter の組み合わせより直感的で挙動も制御しやすいため、現在推奨される分岐解決方式だ。

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

enhanced-mode は拡張解決モードを決定し、値は fake-ip または redir-host のいずれか。TUN との連携の詳細は次章で展開する。listen はカーネル DNS のリスンアドレスで、TUN モードでは dns-hijack と組み合わせてシステムの DNS クエリをこちらへリダイレクトし、解決がすべてカーネル経由になるようにする。

TUN と Fake-IP

システムプロキシモードの本質的な弱点は「プロキシ設定に従うプログラムしか制御できない」ことだ。コマンドラインツール、ゲーム、一部のクライアントソフトはシステムプロキシをそもそも読み取らない。TUN モードはシステム内に仮想ネットワークアダプタを作成し、すべてのトラフィックをネットワーク層でカーネルに取り込むことで、この「取り込み漏れ」問題を根本から解決する。UWP アプリのループバック制限、ターミナルの git やパッケージマネージャーも、TUN モードなら個別対応が不要になる。

TUN の有効化と stack の選択

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 へリダイレクトするもので、TUN と Fake-IP を連携させる要となる部分だ。stack は仮想ネットワークアダプタのプロトコルスタック実装を決定する。system はOS のネットワークスタックを直接使い、スループットが良好。gvisor はユーザー空間実装で互換性が高い。mixed は両者の折衷で、TCP は system、UDP は gvisor を使う。デスクトップ環境では mixed から試すのがよい。プラットフォームごとに有効化の前提条件が異なる。

Fake-IP の原理と fake-ip-filter

Fake-IP は TUN と連携する解決方式だ。プログラムがドメインクエリを発行すると、カーネルは実際の解決完了を待たずに、予約されたセグメント(デフォルト 198.18.0.1/16)から即座に「偽の IP」を返し、そのマッピング関係を記憶する。接続が到達した時点で偽 IP から逆引きしてドメインを特定し、直接ドメインルールでマッチングする——直列の DNS 待ちを1回省けるため接続確立が速くなり、ルールの命中精度も上がる。代償として、一部のプログラムは偽 IP を受け取ると不具合を起こす。LAN 検出、時刻同期、ネットワーク接続性チェックのような「IP を本物として扱う」用途は除外が必要で、これが fake-ip-filter の役割だ。

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

フィルターリストにマッチしたドメインは実際の解決を行い、本物の IP を返す。リストは精密であるべきで、増やしすぎると Fake-IP の効果が薄れていく。また、Fake-IP と redir-host を切り替えた後、システムやブラウザに古い解決キャッシュが残っている場合があり、一定時間一部のサイトの挙動がおかしくなることがある。クライアントを再起動するか、システムの DNS キャッシュをクリアすれば解消する。

ドメインスニッフィング

ルールで最も書きやすいのはドメインルールだが、カーネルに到達した時点で IP しか持たずドメインを持たないトラフィックが2種類ある。1つはプログラム自身が DNS 解決を行った上で IP に直接接続するケース(カーネルの解決プロセスを迂回している)、もう1つは Fake-IP マッピングの範囲外のケースだ。ドメインがなければ DOMAIN-SUFFIX 系のルールはすべて空振りし、トラフィックは IP ルールか兜底ルールに落ち込むしかない。ドメインスニッフィング(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-cdn.net"
  skip-domain:
    - "+.push.apple.com"

sniff 以下ではプロトコルごとにスニッフィング対象のポート範囲を宣言し、宣言したポートのみをスニッフィングする。範囲を絞るほどオーバーヘッドは小さくなる。override-destination はスニッフィングでドメインを取得した後、それで接続の宛先を上書きするかどうかを決める——有効にすると接続はドメイン形式で処理が継続され、ルールマッチングと DNS の振り分けもドメインベースで行われる。force-domain はマッチしたドメインに対してスニッフィングによる上書きを強制するもので、Fake-IP を受け取ってもなお自前で IP に接続してしまうアプリへの対処によく使われる。skip-domain はホワイトリストで、マッチしたドメインは上書きをスキップする。プッシュ通知サービスのような接続先に敏感な長時間接続はここに入れておき、スニッフィングによる干渉を避けるのがよい。

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

サブスクリプションから配布された設定ファイルに直接変更を加えるのは、初心者が最もよく陥る保守上の落とし穴だ。サブスクリプションが更新されると、プロバイダー側のテンプレートがローカルファイル全体を上書きし、すべての手動編集が瞬時にゼロになる。ブログ「Clash のサブスクリプション更新失敗をどう調査するか」で紹介する事例のかなりの部分がこれが原因だ。正しい対処は「プロバイダー提供分」と「自分で書いた分」を分離することだ。サブスクリプションはノードの供給元としてのみ扱い、カスタマイズ内容はオーバーライド層または独立した provider に置く。

クライアント側オーバーライド:Merge と Script

Clash Verge Rev は2段階のオーバーライドを提供しており、いずれもサブスクリプション更新後・カーネル読み込み前に作用するため、サブスクリプションによって消されることは決してない。Merge オーバーライドは宣言的だ。YAML の断片を書き、フィールド単位で最終設定にマージする。DNS 設定の追加、rule-providers の追加、いくつかのカスタムルールを先頭に固定するといった構造的な変更に向いている。Script オーバーライドは JavaScript 関数で、完全な設定オブジェクトを受け取り変更後のオブジェクトを返す。ロジックが必要な場面に向いている——名前の正規表現でノードをフィルタリングする、プロキシグループへノードを一括投入する、ノード数に応じてグループを動的生成するなど。両者は併用可能で、まず Merge を優先し、本当にプログラミングが必要な場合のみ Script を使うのがよい。Clash Plus も同様にサブスクリプションとローカル設定を分離管理する方式を提供しており、各クライアントの差異はクライアント比較を参照。

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

複数のプロバイダー契約を持っている場合、設定を切り替えて回す必要はない。proxy-providers は各サブスクリプションを1つのノード供給元として宣言し、それぞれ独立して更新される。策略グループの use フィールドを通じて、複数の供給元のノードを同じグループへ集約できる。

proxy-providers:
  airport-a:
    type: http
    url: https://a.example.com/sub?token=xxxx
    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://b.example.com/sub?token=xxxx
    path: ./providers/airport-b.yaml
    interval: 43200

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]

use と proxies は同一グループ内で併存できる。前者は provider の全ノードを取り込み、後者は手書きのノードや他のグループを追加する。health-check を使うと provider 側で到達確認を持てるため、url-test グループが参照する際にその結果を直接再利用できる。interval はサブスクリプションの取得周期(秒)で、43200(半日)であれば大半のプロバイダーに十分。ある provider の取得が失敗しても他の供給元には影響しない。これも複数サブスクリプション構造が本来持つ耐障害性の利点だ。

外部コントロールパネル

カーネルは実行時に一連の RESTful コントロール API を公開しており、ノード切り替え、遅延テスト、接続一覧の確認、設定のリロードはすべてこれを通じて行われる——デスクトップクライアントの UI は本質的にこの API のラッパーだ。外部コントロールを直接使う価値があるのは主に2つの場面。1つはルーターやサーバー上でカーネルを単体運用しGUIがない場合。もう1つはブラウザパネルやスクリプトで自動管理を組みたい場合。

インターフェースの有効化と認証

external-controller: 127.0.0.1:9097
secret: "your-strong-secret"
external-ui: ./ui

external-controller はリスンアドレスとポートを宣言する。ローカルのみで使うなら 127.0.0.1 にバインドする。LAN 内の他デバイスからのアクセス(たとえばスマホでルーター上のカーネルを管理する場合)が必要な場合のみ 0.0.0.0 にバインドし、この場合 secret には十分に強度のあるランダム文字列を必ず設定すること——すべてのリクエストは Authorization ヘッダーにこれを含める必要がある。external-ui は静的な Web パネルのディレクトリを指し、カーネルが直接ホスティングするため、ブラウザでコントロールアドレスにアクセスすれば開ける。主流のオープンソース Web パネル(metacubexd、yacd 系)は、このディレクトリに展開するだけで使える。

API による自動化

インターフェースは標準の HTTP + JSON で、curl だけで操作できる。全プロキシグループとノード状態の確認:

ある select グループで選択中のノードを切り替えるには、グループ名に対して PUT リクエストを送る:

よく使うエンドポイントには /connections(リアルタイムの接続一覧。「このトラフィックは結局どのポリシーを通ったのか」を調査する第一の現場)、/logs(ログストリーム)、/configs(実行時にポートやモードを変更)などがある。これらのエンドポイントをスクリプトに組み込めば、定期測速や異常時の自動切り替えといった無人運用のロジックを実現できる。

参照の道筋と関連記事

7章の内容には明確な依存関係がある。プロキシグループとルールセットは骨格、DNS は土台、TUN・Fake-IP・スニッフィングは「取り込み漏れの有無、マッチングの精度」を解決し、オーバーライドと統合は長期的な保守を解決し、外部コントロールは実行時の観測と自動化を担う。実際に困っている章から入って構わない、頭から通読する必要はない。設定中に見慣れない用語が出てきたら、用語集が「カーネルとクライアント / プロキシプロトコル / ルールとプロキシグループ / DNS とトラフィック処理 / 設定ファイルフィールド」の5分類で定義を収録している。設定変更後にエラーや異常な挙動が出たら、まずよくある質問のトラブルシューティング分類を確認する。どのクライアントを使うか未決定なら、クライアント比較がプラットフォームと利用習慣に応じた選定結論を示している。初回インストール時の完全なチェックリストはブログ「Clash クライアント初回インストール設定チェックリスト」を参照。本ページはカーネルの設定フィールドの変化に応じて継続的に更新するので、ブックマークしておくことを推奨する。