Clash 上級設定マニュアル

設定ファイルの骨格と読み方の約束

Clash のすべての動作は1つの YAML 設定ファイルによって駆動されます。クライアント画面上のあらゆるスイッチ——プロキシモード、LAN 共有、TUN、パネルポート——は最終的にこのファイルのどこかのフィールドに落とし込まれます。トップレベルフィールドの役割分担を理解することが、以降のすべての章を読み解く前提となります:インバウンド部分はトラフィックがどこから入るか(ポート、TUN 仮想NIC)を決め、アウトバウンド部分はトラフィックがどこから出るか(ノード、プロキシグループ)を決め、ルール部分は「どのトラフィックをどの出口に流すか」を決め、DNS とスニッフィング部分はカーネルが接続の実際のターゲットをどう識別するかを決めます。

トップレベルフィールド一覧

読み方の約束

以降のすべての YAML サンプルは3つの約束事に従います:インデントは常にスペース2つ、タブは使用しません;真偽値は常に小文字の true / false;各サンプル断片はクライアントのオーバーライド欄(オーバーライドの章参照)に直接貼り付けて効果を確認でき、サブスクリプション本文を変更する必要はありません。フィールド名の完全なリストと逐条解説は用語クイックリファレンスの設定ファイルフィールド分類に収録されており、本ページでは上級利用で実際に手を加える必要がある部分のみを展開します。

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

プロキシグループ(proxy-groups)はノードとルールの間のスケジューリング層です。ルールは特定のノードを直接指すのではなく、プロキシグループを指します。グループ内でどのノードを実際に使うかが決まります。この間接性には2つの利点があります:サブスクリプションのノードが増減・改名されてもルールを合わせて変更する必要がないこと、そして「自動速度測定」「フェイルオーバー」「手動指定」などの異なる戦略で用途別のトラフィックを管理できることです。

よく使う4種類のタイプ

また relay(チェーン中継)タイプもありますが、mihomo ではもう推奨されておらず、チェーン接続が必要な場合はノードレベルの dialer-proxy フィールドで実装することを推奨します。動作がより制御しやすくなります。

重要パラメータの選び方

自動型プロキシグループの動作は4つのパラメータで決まります。url はヘルスチェックの対象アドレスで、軽量かつ安定した検査エンドポイントを選ぶべきです。よく使われるのは https://www.gstatic.com/generate_204;interval は検査周期(秒)で、短すぎると頻繁に検査が発生してトラフィックが無駄になり、長すぎるとフェイルオーバーが遅くなります。日常用途では300秒がバランスの良い値です;tolerance は url-test にのみ有効で、新旧ノードの遅延差がこのミリ秒数を超えた場合のみ切り替えることを意味し、50~100 に設定すると遅延が近い2つのノード間での揺れ戻りを防げます;lazy を true にすると、使用されていないグループはヘルスチェックを行わず、バックグラウンドの検査量を大幅に減らせます。

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

  - name: 自動測速
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 60
    lazy: true
    proxies:
      - 香港節点
      - 日本節点

  - name: 香港節点
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    include-all: true
    filter: "(?i)hk|hong|港"

ネスト構成の実践

大規模管理の一般的な方法は2層構造です:下層はリージョン別に自動グループを構築(香港、日本、シンガポールそれぞれに1つの url-test グループを設け、filter の正規表現で全ノードから絞り込む)、上層は用途別に手動グループを構築(ストリーミング、開発ツール、総合出口それぞれに1つの select グループを設け、候補項目は個別のノードではなくリージョングループとする)。これによりサブスクリプションのノードが変わってもリージョングループが自動的に再収納され、ユーザーは日常的に上層グループ間を切り替えるだけで済み、パネルの一覧が数百のノード名で溢れることもありません。include-all: true と filter の組み合わせは mihomo が提供するフィルタリング構文で、正規表現は大文字小文字を区別しないので (?i) プレフィックスを付けることを推奨します。グループを書き終えたら、rules 内の出口名とグループ名が一字一句一致していることを確認してください。YAML でグループ名にスペースや特殊文字が含まれる場合は、引用符で囲む方が安全です。

ルール分流の基礎とマッチング順序

ルール(rules)は Clash のコアとなるスケジューリングテーブルで、mode: rule のときのみ有効になります。各ルールは「タイプ、マッチ値、出口」の3つの部分で構成され、カーネルは新しい接続ごとに上から下へ順に照合し、最初に一致した時点で停止し、以降のルールは処理されません。この「最初のマッチ優先」の原則は、ルールの順序そのものが優先度であることを意味します:同じドメインが10行目と200行目の両方にマッチする場合、有効になるのは常に10行目です。「あるサイトがなぜ間違った出口に振られているか」を調査する際は、まずログやパネルの接続ページでどのルールに命中したかを確認してください。

よく使うルールタイプ

• DOMAIN:完全一致のドメインマッチング、まったく同じホスト名のみ命中。
• DOMAIN-SUFFIX:サフィックスマッチング、example.com は自身と全サブドメインの両方に命中し、最もよく使われるタイプです。
• DOMAIN-KEYWORD:キーワードマッチング、ドメイン内のどこかにキーワードが含まれれば命中、誤爆範囲が広いため慎重に使用してください。
• IP-CIDR / IP-CIDR6:ターゲット IP のネットワークセグメントでマッチング、内部ネットワークの直接接続や特定サービスの IP セグメントによく使われます。
• GEOIP:IP 地理データベースでマッチング、GEOIP,CN,DIRECT は日本国内 IP の直接接続の標準的な書き方です(中国本土向けサイトを利用する場合は CN を該当国コードに変更)。
• GEOSITE:内蔵ドメイン分類ライブラリでマッチング(mihomo の特性)、1つのルールで一連のサイトをカバーします。
• PROCESS-NAME:接続を発生させたプロセス名でマッチング、特定のアプリを全体的に直接接続または全体的にプロキシ経由にするのに適しており、デスクトップ環境と TUN モードで使用可能です。
• RULE-SET:外部ルールセットを参照、次章を参照。
• MATCH:デフォルトルール、残り全てのトラフィックにマッチし、必ず最後の1行にのみ配置します。

no-resolve と並び順の推奨

IP タイプのルール(IP-CIDR、GEOIP)には隠れた副作用があります:接続先がドメインの場合、カーネルは比較の前にまずドメインを IP に解析する必要があり、この解析はローカル DNS を経由する可能性があるため、マッチングを遅らせるだけでなく不要な解析リクエストを発生させることもあります。IP ルールの末尾に no-resolve パラメータを追加すると、そのルールは純粋なドメイン接続をスキップし、もともと IP であるターゲットのみと比較するようになります。実践上の並び順の推奨は:プロセスルールと完全一致ドメインルールを最前面に、ドメインサフィックスとルールセットを中間に、GEOIP,CN のような IP ルールを全ドメインルールの後に、MATCH を最後に配置することです。これにより大部分の接続はドメイン段階で分流が完了し、解析をトリガーしません。

rules:
  - PROCESS-NAME,Telegram,節点選択
  - DOMAIN,dl.google.com,節点選択
  - DOMAIN-SUFFIX,openai.com,節点選択
  - RULE-SET,ads-block,REJECT
  - RULE-SET,cn-sites,DIRECT
  - GEOSITE,category-games,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,節点選択

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

数千行のドメインルールを直接メイン設定に書き込むと、2つの長期的コストが発生します:設定ファイルが肥大化して読みづらくなること、そしてルールライブラリの更新時に設定全体を差し替えなければならないことです。rule-providers(ルールプロバイダー)はルールを独立したファイルとして外部化し、カーネルが周期的に自動ダウンロード・更新し、メイン設定には1行の RULE-SET 参照だけを残します——ルール内容の保守はこれによりメイン設定から分離され、これがコミュニティが維持する大規模分流ルールライブラリの標準的な導入方式です。

フィールド構造

rule-providers:
  cn-sites:
    type: http
    behavior: domain
    format: yaml
    url: "https://example.com/rules/cn-domains.yaml"
    path: ./rules/cn-sites.yaml
    interval: 86400
  ads-block:
    type: http
    behavior: domain
    format: mrs
    url: "https://example.com/rules/reject.mrs"
    path: ./rules/ads-block.mrs
    interval: 86400

type を http にするとリモートダウンロードを意味します(他に file でローカルファイル参照);path はローカルキャッシュパスで、ダウンロードに失敗してもカーネルはキャッシュを継続使用するため、一度のネットワーク不調でルールセット全体が失われることはありません;interval は自動更新周期(秒)で、ルールライブラリは通常1日1回更新されるため 86400 で十分です。format は yaml、text、そして mihomo 独自のバイナリ形式 mrs をサポートし、後者はサイズが小さく読み込みが速いため、大規模ルールセットではこちらを優先してください。

behavior の3つの値

behavior はファイルの実際の内容と一致していなければならず、間違えるとルールセット読み込み後に全く命中しなくなります——これがルールセットが機能しない最も一般的な原因で、次に多いのが RULE-SET の参照名と provider のキー名が一致していないケースです。また注意点として、ルールセット自体のダウンロードリクエストも1つのトラフィックです。ルールライブラリの配信元にプロキシ経由でのアクセスが必要な場合は、provider に proxy: 節点選択 を追加してダウンロード出口を指定し、初回起動時に「ルールがダウンロードされていないためルールが使えない」というデッドロックを避けてください。

DNS 設定の最適化と漏洩防止

DNS は上級設定の中で投資対効果が最も高く、また最も見落とされがちな部分です。デフォルトでは、オペレーティングシステムの DNS クエリはプロキシを経由しません:トラフィック自体は暗号化転送されていても、ドメイン解析リクエストは依然として平文でローカルの通信事業者の DNS サーバーに送信される可能性があります——これが「Clash DNS 漏洩」の由来で、解析記録からどのサイトにアクセスしたかが丸ごと露出してしまいます。カーネルの dns モジュールを有効化し正しく階層化して設定することで、解析動作も管理下に置くことができます。

リゾルバーの3つの階層

mihomo の DNS 設定は3層に分かれています。default-nameserver は1つのことだけを行います:後続の DoH/DoT サーバー自身のドメインを解析することで、そのため純粋な IP アドレスを記入する必要があります;nameserver はメイン解析グループで、大部分のクエリを担当し、暗号化転送をサポートする DoH アドレスの記入を推奨します;fallback はオプションのバックアップグループで、fallback-filter と併用します——メイングループが返した結果がフィルタ条件に一致する場合(例えば解析結果が GEOIP CN の範囲外にある場合)、バックアップグループの結果に切り替えます。この仕組みの目的は、国内ドメインを応答の速い国内リゾルバーで処理し、海外ドメインを汚染されていない暗号化リゾルバーで処理することで、速度と正確性を両立させることです。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  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
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

nameserver-policy による精細な分流

fallback の「結果による二択」ではまだ細かさが足りない場合、nameserver-policy はクエリされたドメインに応じて直接リゾルバーを指定できます:キーはドメインサフィックス、geosite: 分類、あるいは rule-set: 参照でも構わず、値はリゾルバーのリストです。典型的な使い方は geosite:cn を国内 DoH に、それ以外を海外 DoH に振ることで、結果を得てから修正するのではなく、クエリの入口段階で振り分けを完了させます。

dns:
  nameserver-policy:
    "geosite:cn":
      - https://doh.pub/dns-query
    "+.internal.corp":
      - 10.0.0.53

TUN モードと Fake-IP のメカニズム

システムプロキシの本質は「通知」です:オペレーティングシステムがプロキシアドレスを環境設定に書き込み、その約束に従うアプリケーション(ブラウザ、大半のデスクトップソフト)が自ら Clash にトラフィックを渡します。しかしコマンドラインツール、一部のゲームクライアント、ほぼすべての UDP トラフィックはこの約束を意に介さず、それらの接続はプロキシを直接バイパスします。TUN モードは異なるアプローチを取ります——システム内に仮想NICを作成してデフォルトルートを引き受け、すべてのトラフィックをネットワーク層で捕捉するため、アプリケーションが回避する余地がありません。両方式の完全な比較とシーン別選択については、ブログ記事「Clash TUN モードとシステムプロキシの違いとは」をご覧ください。

tun フィールドの設定

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

stack は TUN パケットの処理プロトコルスタックを決定します:system はオペレーティングシステムのネットワークスタックを直接再利用し、パフォーマンスは良いがシステム環境に敏感です;gvisor はユーザー空間実装で互換性が最も安定しています;mixed は両者の長所を取ったもの(TCP は system、UDP は gvisor を使用)で、現在多くのシーンで推奨される値です。auto-route は自動的にルーティングテーブルに書き込みトラフィックを仮想NICに導き、auto-detect-interface は物理出口NICを自動識別してループバックを防ぎます;これら2つは通常オンのままにしておくべきで、ルーターなど複雑なネットワークトポロジでルーティングを手動制御する必要がある場合を除きます。dns-hijack は任意のアドレスの53番ポートに送られる平文 DNS クエリを強制的にカーネル解析へハイジャックするもので、TUN モードで DNS 漏洩を防ぐ重要な要素です。デスクトップ環境で TUN を有効にするには管理者権限またはインストール済みのシステムサービスが必要で、Clash Plus と Clash Verge Rev は初回オン時に権限付与をガイドします。

Fake-IP:解析結果が 198.18 から始まる理由

enhanced-mode: fake-ip は TUN と最も相性の良い解析モードです。そのメカニズムは:アプリケーションがドメインクエリを発生させると、カーネルは実際の解析を行わず、予約ネットワークセグメント 198.18.0.0/16 から即座に「フェイク IP」を割り当てて返し、この IP とドメインの対応を記憶します;アプリケーションがフェイク IP を持って接続を発生させると、カーネルは対応関係を逆引きしてドメインを復元し、ドメインルールに従って分流します。利点は2つ:実際の解析の待ち時間が省け、接続確立が速くなること;ドメイン情報がルールマッチング段階まで保持され、分流精度が解析に影響されないことです。代償は実際の IP に依存する一部のプログラムが異常になることです——LAN 内発見、NTP 時刻同期、一部のゲームランチャーなど。この種のドメインは fake-ip-filter ホワイトリストに追加し、実際の解析を通すようにすべきです:

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

使用シーンが主にブラウザで、かつ解析結果をサードパーティプログラムに渡す必要が頻繁にある場合は、enhanced-mode: redir-host(実 IP モード)に戻すこともできます。代償は接続ごとに実際の解析完了を待つ必要があることです。両モードはいつでも切り替え可能で、切り替え後は一度 DNS キャッシュをクリアしてから様子を見ることを推奨します。

ドメインスニッフィング:IP をドメインに復元する

ルール分流の理想的な入力はドメインですが、カーネルに到達した時点で IP しか残っていないトラフィックが2種類あります:1つはアプリケーション自身の DNS(例えばブラウザ内蔵の DoH)がカーネル解析をバイパスし、接続先が直接実 IP になっているケース;もう1つは Fake-IP のホワイトリスト外にもかかわらず過去の解析結果をキャッシュしているプログラムがあるケースです。ターゲットが IP しか残っていない場合、すべてのドメインルールが無効になり、トラフィックは GEOIP か MATCH のデフォルトルールに落ちるしかありません——分流精度が大きく損なわれます。ドメインスニッフィング(sniffer)はこれを補う手段です:カーネルは接続ヘッダーの平文の特徴(HTTP リクエストの Host ヘッダー、TLS ハンドシェイクの SNI フィールド、QUIC の初期パケット)を検査し、実際のドメインを「嗅ぎ取って」、それを使って再度ルールマッチングを行います。

設定例

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

3つのプロトコルブロックはそれぞれどのポートでスニッフィングを試みるかを宣言します;override-destination が true の場合、スニッフィングで得たドメインで接続先アドレスを上書きし、以降のルールとログもドメインで表示されるようになります。force-domain にリストされたドメインは既に解析結果があっても強制的にスニッフィング値で上書きされ、CDN ドメインと解析結果が一致しないサイトの処理に適しています;skip-domain は逆で、リストされたターゲットはスニッフィングをスキップします——Apple プッシュや一部メーカーの長時間接続は接続ヘッダーの検査に敏感なため、スキップリストに入れることで意図しない切断を避けられます。スニッフィングはプロトコルハンドシェイク段階でもともと平文だったフィールドを読み取るだけで、暗号化されたペイロードは一切復号しません;オーバーヘッドは各新規接続の最初のパケットに集中しており、日常使用ではほぼ感じられません。TUN + Fake-IP + スニッフィングの3点セットを同時に有効化することが、現時点で最も分流精度が高い組み合わせです。

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

サブスクリプションファイルはサーバー側で生成され、更新のたびにローカルの内容全体を上書きします——サブスクリプションファイルを直接手動で編集して DNS を変更したりルールを追加したりすると、次の更新時にすべて失われます。正しい方法は個人のカスタマイズを「オーバーライド」層に置くことです:クライアントはサブスクリプションを読み込むたびに、あなたのオーバーライド内容を自動的に最終設定にマージします。サブスクリプションはサブスクリプション、カスタマイズはカスタマイズで、互いに干渉しません。これは Clash を長期的に使う上で最も確立すべき習慣です。

各クライアントのオーバーライド機能

ダウンロードページで第一に推奨する Clash Plus には内蔵のオーバーライドエディタがあり、YAML 断片の形でフィールドを追加または置換でき、本ページのすべてのサンプルの実践に適しています;Clash Verge Rev は Merge(宣言的マージ)と Script(JavaScript プログラム的修正)の2つのグローバル拡張を提供し、Merge では dns、tun などのキーがサブスクリプション内の同名フィールドをそのまま置換し、プレフィックス記法によりリストへの追加が実現でき、複雑なロジックには Script を使います;FlClash も設定オーバーライドをサポートし、モバイル環境でも同様にカスタムルールを保持できます。更新停止したクライアントからオーバーライド設定を移行する完全な手順は、ブログ記事「Clash for Windows の更新終了後は何を使うべきか」をご覧ください。典型的な Merge オーバーライドの例は以下の通りです:

dns:
  enable: true
  enhanced-mode: fake-ip
prepend-rules:
  - DOMAIN-SUFFIX,corp.example.com,DIRECT
append-rules:
  - GEOIP,CN,DIRECT

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

複数のプロバイダーのサブスクリプションを持っている場合、クライアント内で設定を何度も切り替える必要はありません。proxy-providers は各サブスクリプションを1つのノードプロバイダーとして宣言し、プロキシグループ内で use を使って参照することを許可します。複数のサブスクリプションのノードが同一のグループ体系に統合され、統一された速度測定・分流が可能になります:

proxy-providers:
  provider-a:
    type: http
    url: "https://example.com/sub-a?token=xxxx"
    path: ./providers/a.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
  provider-b:
    type: http
    url: "https://example.net/sub-b?token=xxxx"
    path: ./providers/b.yaml
    interval: 3600

proxy-groups:
  - name: 全部節点
    type: url-test
    use:
      - provider-a
      - provider-b
    url: https://www.gstatic.com/generate_204
    interval: 300

provider レベルの health-check は、ノードがどのグループにも使われる前からヘルス状態を持つようにします;filter、exclude-filter フィールドは provider 層で期限切れ通知やトラフィック案内などのノードでない項目を先にフィルタリングできます。注意点として、2つのサブスクリプションに同名のノードが存在すると読み込み時に競合が発生する可能性があるため、override.additional-prefix で各 provider のノードに統一のプレフィックスを付けて由来を区別できます。複数デバイスでこの統合設定を共有する LAN 活用法については、ブログ記事「Clash の混合ポートと LAN 接続許可の設定」も参考にしてください。

外部コントロールパネルの導入

カーネルは実行時に一連の RESTful API を公開し、プロキシグループの切り替え、遅延テスト、接続の確認、設定の再読み込みはすべてこれを通じて行うことができます——デスクトップクライアントのグラフィカルインターフェースは本質的にこの API のラッパーです。Clash がルーター、NAS、またはヘッドレスサーバー上で動作している場合(デプロイの考え方はブログ記事「ルーターで Clash カーネルを直接動かす方式の概要」を参照)、外部コントロールパネルが唯一手軽な管理入口となります。

API とパネルを有効化する

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

external-controller は API のリスニングアドレスを指定します。自分のマシンのみで管理する場合は 127.0.0.1 のままにし、LAN 内の他デバイスからのアクセスが必要な場合は 0.0.0.0 に変更します;secret は API アクセストークンで、パネル接続時に Authorization: Bearer ヘッダーで携帯します。external-ui はローカルの静的パネルディレクトリを指し、external-ui-url と組み合わせるとカーネルがパネルのリリースパッケージを自動ダウンロードでき、その後ブラウザで http://127.0.0.1:9090/ui にアクセスすれば開けます。コミュニティでよく使われるパネルには metacubexd、zashboard、yacd 系列があり、いずれも純粋な静的ページなので好みのものを選べば構いません;デスクトップユーザーは通常単独デプロイの必要はなく、Clash Plus と Clash Verge Rev にはすでにパネルビューが組み込まれています。

API を直接呼び出す

# カーネルバージョンを確認
curl -H "Authorization: Bearer your-strong-secret" \
  http://127.0.0.1:9090/version

# 「節点選択」グループを「香港節点」に切り替える
curl -X PUT -H "Authorization: Bearer your-strong-secret" \
  -d '{"name":"香港節点"}' \
  http://127.0.0.1:9090/proxies/節点選択

# 指定グループの遅延テストをトリガーする
curl -H "Authorization: Bearer your-strong-secret" \
  "http://127.0.0.1:9090/group/自動測速/delay?url=https://www.gstatic.com/generate_204&timeout=3000"

ここまでで、7つのテーマの上級設定を網羅しました。おすすめの実践パスは:まずガイドページで基本的な接続経路を確認し、DNS とプロキシグループの2章から着手して段階的にサンプルを当てはめ、1つ変更するたびにパネルの接続ビューで効果を確認することです;フィールドの意味はいつでも用語クイックリファレンスで調べられ、クライアントの選択と入手方法はダウンロードページ、サイトの位置づけと保守方針はプロジェクト紹介をご覧ください。