Clash 上級設定マニュアル

01ポリシーグループの種類と実践

ポリシーグループ(proxy-groups)は設定全体のスケジューリングの中枢です。ルールマッチの結果は通常、特定のノードを直接指すのではなく、いずれかのポリシーグループを指します。グループは自身の種類に応じて、実際の出口を決定します。各グループタイプの挙動の違いを理解することが、長期的にメンテナンスしやすい設定を組み立てる第一歩です。Clash カーネルがサポートする一般的なグループタイプは4種類あります:select、url-test、fallback、load-balanceで、それぞれ異なるスケジューリング課題を解決します。

select:手動選択グループ

select は最も基本的なグループタイプで、出口はクライアント画面上でユーザーが手動で指定します。速度測定やヘルスチェックは一切行わず、選択したノードを手動で切り替えるか、そのノードがサブスクリプションから消えるまでそのまま使い続けます。この「完全に指示に従う」という特性から、設定の最も外側に置いて総合スイッチとして使うのに向いています。複数の用途別グループや地域別グループを DIRECT とあわせて「ノード選択」という名前の select グループにまとめ、ルールは統一してこのグループを指すようにすれば、日常的な切り替えは画面上でワンクリックするだけで済みます。

select グループの必須フィールドは name、type、proxies の3つだけです。proxies リストには具体的なノード名、他のポリシーグループ名、そして2つの組み込みポリシーを混在させて書くことができます。DIRECT はプロキシを経由せず直接接続、REJECT は接続を直接拒否することを意味します。グループ名を参照する際は、スペースや大文字小文字も含めて定義と完全に一致させる必要があります。書き間違えると起動時に「グループが存在しない」というエラーになります。

url-test と fallback:自動スケジューリング

url-test グループは、グループ内のすべてのノードに対して定期的に軽量な HTTP リクエストを送信し、遅延が最も低いノードをその時点の出口として選択します。理解しておくべき重要なパラメータは3つあります。url は速度測定の対象で、慣例として204ステータスコードを返し、レスポンスボディが空のアドレスを使い、測定自体が消費する通信量を極力減らします。interval は測定周期(秒単位)で、よく使われる値は300です。短く設定しすぎるとバックグラウンドリクエストが頻発します。tolerance は切り替えの許容差(ミリ秒単位)で、新たな最適ノードが現在のノードよりこの差分以上速い場合にのみ実際に切り替えます。tolerance を設定しないと、遅延が近い2つのノードが測定のばらつきによって行き来し、出口IPが頻繁に変化することがあります。

fallback グループは proxies リストに書かれた順序で可用性チェックを行い、チェックを通過したリストの先頭ノードを常に使用します。そのノードが利用不可になると次のノードへ移り、復旧すれば自動的に元に戻ります。url-test との本質的な違いは着眼点にあります。url-test は「誰の遅延が最も低いか」に注目し、fallback は「誰が先頭にいて、かつ生きているか」に注目します。そのため fallback は「メイン回線+予備回線」という構成に向いています。最も安定して信頼できるノードを先頭に書き、兜底(バックアップ)用の回線をその後ろに順に並べておけば、通常はメイン回線を使い、メイン回線に障害が起きた際も違和感なく切り替わります。

load-balance:負荷分散

load-balance グループは接続をグループ内の複数ノードに分散させます。strategy フィールドに consistent-hashing を指定すると、宛先ドメインに基づいて一致性ハッシュを行い、同じサイトへのリクエストは常に同じノードに割り振られるため、出口IPの頻繁な変化によるログイン状態の失効を避けられます。round-robin を指定すると接続単位で出口を順番に切り替え、トラフィックはより均等に分散されますが、セッションに敏感なサイトには向きません。実運用では、負荷分散は大容量ダウンロードや一括クロールのような出口IPに敏感でない用途に向いており、安定したログイン状態が必要なサービスには使わないことをおすすめします。

グループのネストと構造設計

実践では「用途別グループが地域別グループを参照する」という2階層構造をおすすめします。まず地域別に複数の url-test グループ(例:「香港自動」「日本自動」)を作り、次に用途別に複数の select グループ(例:「ストリーミング」「AIサービス」「兜底選択」)を作ります。用途別グループの候補には具体的なノードではなく地域別グループの名前を書きます。こうすればサブスクリプションのノードが増減・改名しても地域別グループの層にしか影響せず、ルールと用途別グループはまったく変更する必要がありません。サブスクリプションを乗り換える場合も、地域別グループを再構築するだけで済みます。唯一注意すべきは、グループ間の循環参照を避けることです。AグループがBグループを参照し、BグループがまたAグループを参照すると、カーネルは起動時にエラーを出して読み込みを拒否します。

proxy-groups:
  - name: ノード選択
    type: select
    proxies: [香港自動, 日本自動, フェールオーバー, DIRECT]

  - name: 香港自動
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 60
    proxies: [HK-01, HK-02, HK-03]

  - name: フェールオーバー
    type: fallback
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies: [HK-01, JP-01, SG-01]

  - name: 一括ダウンロード
    type: load-balance
    strategy: consistent-hashing
    proxies: [HK-01, HK-02, JP-01]

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

数千件もの振り分けルールをメイン設定ファイルに直接書き込むと、長期的に2つの問題が生じます。ひとつはメイン設定が肥大化してメンテナンスしづらくなり、1件のルールを調整するために数千行の中から探し出す必要が出てくること。もうひとつは、ルールデータ(広告ドメイン、地域別IP範囲など)自体が継続的に更新されているにもかかわらず、設定に書き込んでしまうとその時点の内容のまま固定されてしまうことです。rule-providers(ルールプロバイダー)はルールを独立したファイルに切り分け、周期的に自動で更新を取得します。メイン設定には参照行を1行残すだけで済むため、ルール管理の標準的な手法となっています。

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

各プロバイダーは名前付きの項目で、主要フィールドを順に説明します。type に http を指定するとリモートアドレスから周期的に取得し、file を指定するとローカルファイルを読み込むだけで自動更新は行いません。url はリモートのルールファイルのアドレスです。path はローカルのキャッシュパスを指定し、省略した場合はカーネルが url のハッシュ値から自動でキャッシュファイル名を付けます。interval は更新周期(秒単位)で、86400 は1日に相当します。ルールデータの更新頻度はさほど高くないため、これより短く設定する必要はありません。

behavior はファイル内容の解釈方法を決める、最も設定を誤りやすいフィールドです。domain はファイルが純粋なドメインリストであることを示し、1行に1ドメイン(+. によるワイルドカード前置をサポート)を記述します。ipcidr はファイルがIPアドレス帯のリストであることを示します。classical はファイルが完全なルールを1行ずつ記述したものであることを示し、DOMAIN-SUFFIX、IP-CIDR、PROCESS-NAME など複数の種類を混在させることができます。behavior とファイルの実際の内容が一致しない場合、軽ければルールがすべてマッチせず、重ければ読み込みエラーになります。format はファイル形式を宣言するもので、yaml と text が最も汎用性が高く、mrs は mihomo カーネル独自のバイナリ形式でサイズが小さく読み込みも高速ですが、domain と ipcidr の2種類の behavior しかサポートしません。

rules での参照方法

プロバイダーを定義したら、rules セクションで RULE-SET,プロバイダー名,ポリシーグループ名 という形式で参照します。ipcidr 系のルールセットには、末尾に no-resolve パラメータを追加することをおすすめします。IP系のルールは対象のIPを取得しないとマッチできないため、接続先がドメインの場合、カーネルは先にDNS解決を1回行ってから比較しようとします。no-resolve を指定するとカーネルにこの解決処理をスキップさせ、ドメイン型の接続は直ちに「マッチしない」とみなして次のルールへ進みます。これにより不要な解決処理のコストを避けられるだけでなく、fake-ip モードで余計な実解決リクエストが発生することも防げます。

rule-providers:
  ad-domains:
    type: http
    behavior: domain
    format: yaml
    url: https://example.com/rulesets/ad-domains.yaml
    path: ./ruleset/ad-domains.yaml
    interval: 86400
  cn-ip:
    type: http
    behavior: ipcidr
    format: mrs
    url: https://example.com/rulesets/cn-ip.mrs
    path: ./ruleset/cn-ip.mrs
    interval: 86400

rules:
  - RULE-SET,ad-domains,REJECT
  - RULE-SET,cn-ip,DIRECT,no-resolve
  - MATCH,ノード選択

マッチ順序と更新のトラブルシューティング

ルールは上から下へ1件ずつマッチが行われ、最初にヒットした時点で判定は終了し、以降のルールは評価されません。そのため、ルールセットの並び順がそのまま優先度になります。拒否系(広告など)を最初に置き、その次に精度の高いドメイン系ルール、範囲が広いIP系ルールを後に置き、最後には必ず MATCH による兜底(受け皿)を用意します。これがないと、どのルールにもマッチしなかった通信の挙動が予測できなくなります。あるサイトがどのルールにマッチしているかを確認したい場合、最も直接的な方法は第7章で紹介するコントロールパネルを開き、コネクションページでその接続のルール列を確認することです。

ルールセットの更新失敗はよくある問題です。トラブルシューティングの考え方としては、まずルールファイルの取得自体もネットワークを経由するという点に注意します。取得先のアドレスが現在のネットワーク環境で直接接続できない場合、コールドスタート(まだ利用可能なプロキシがない状態)では取得に失敗します。対処法は、直接接続できるミラーアドレスを選ぶこと、または初回起動前にあらかじめキャッシュファイルを用意しておくことです。次にカーネルログの provider 関連のエラーを確認します。よくある原因は behavior とファイル内容の不一致、format の指定ミスです。最後の手段として、path が指すキャッシュファイルを手動で削除し、カーネルを再起動して強制的に再ダウンロードさせる方法もあります。

03DNS設定の最適化

Clash の内蔵DNSは、あってもなくてもよい付属機能ではありません。ドメイン系ルールのマッチ、fake-ip マッピングの生成、DNSリクエストがローカルの汚染を回避できるかどうかは、すべてこの設定セクションによって決まります。デフォルト設定でも多くの場面では使えますが、「直接接続ドメインは高速に解決され、プロキシ経由ドメインは正確な結果が得られ、かつ全体として漏洩しない」という状態を実現するには、各フィールドの役割を理解する必要があります。

基本フィールド

enable: true で内蔵DNSを有効化します。listen はリスンアドレスとポートを指定し、TUNモードのDNSハイジャックはシステムからのクエリをここに転送します。enhanced-mode は fake-ip と redir-host のどちらかを選択するもので、両者の使い分けは次章で詳しく説明します。default-nameserver は見落とされやすいフィールドです。後述の nameserver リストに DoH アドレス(https://…/dns-query のような形式)を書く場合、そのアドレス自体もドメイン名であるため、先に解決しておく必要があります。default-nameserver はこの役割を担うため、純粋なIPアドレスしか書けず、ドメイン名を書くと解決の無限ループになってしまいます。

nameserver はメインの解決グループで、大半のドメインの解決を担います。現在のネットワーク環境で安定して直接接続できる暗号化DNSアドレスを設定することをおすすめします。これにより直接接続トラフィックの解決速度と精度が保証されます。平文の53番ポートを使う従来型DNSも使用できますが、一部のネットワークでは平文クエリが中間装置に改ざんされる可能性があるため、DoH または DoT を優先してください。

fallback と fallback-filter

fallback グループは「メイン解決グループの結果が汚染されている可能性がある」ドメインを対象にしています。nameserver と fallback が同時に存在する場合、カーネルは両方のグループへ並行してクエリを送信し、fallback-filter がどちらの結果を採用するかを判定します。geoip: true かつ geoip-code: CN の場合、nameserver が返したIPが中国本土に属していれば、それは中国本土のドメインで結果は信頼できると判断し nameserver の回答を採用します。そうでなければそのドメインは中国本土以外の経路で解決すべきと判断し、fallback の回答を採用します。ipcidr サブフィールドには既知の汚染結果のIP範囲(予約範囲の 240.0.0.0/4 など)を列挙し、nameserver が返したIPがこれらの範囲に入っている場合は直ちに汚染と判定して fallback の結果に切り替えます。

この仕組みの効果としては、中国本土のドメインは近隣の中国国内DNSで解決され、CDNの最適IPが得られます。中国本土以外のドメインの解決結果は fallback グループの暗号化経路を通じて取得され、ローカルの汚染の影響を受けません。注意点として、fallback に設定する暗号化DNSアドレスは、プロキシが利用可能な状態で正常にアクセスできるものである必要があります。そうでない場合、並行クエリのうち fallback 側が長時間タイムアウトし、全体の解決速度が遅くなります。

nameserver-policy:ドメイン別の解決先指定

nameserver-policy は特定のドメインを特定の上流サーバーに割り当てることができ、nameserver と fallback の汎用ロジックよりも優先されます。典型的な使い方は2種類あります。ひとつは、社内ネットワークのドメインは必ず社内DNSサーバーで解決させる必要があり、そうしないと結果が得られないケース。もうひとつは、中国国内でCDN割り振りに敏感な大手サイトを、特定の国内DoHサーバーに固定して、並行クエリによって生じる不確実性を避けるケースです。キーは +. によるワイルドカード前置をサポートし、自身とすべてのサブドメインにマッチします。

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://dns.alidns.com/dns-query
    - https://doh.pub/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:
    "+.corp.example.com": 10.0.0.53

漏洩検証

設定が完了したら、実際に一度検証しておくべきです。プロキシに接続した状態でDNS漏洩検出系のサイトにアクセスし、検出された解決サーバーの帰属地を確認します。中国本土以外のドメインの解決リクエストが依然としてローカルの通信事業者のDNSから発信されているように表示される場合、漏洩が発生しています。よくある原因は、システムに手動指定したDNSが残っている、またはブラウザ内蔵のDoH設定がClashを迂回していることです。ログレベルを debug に切り替えて、各ドメインが実際にどの上流を経由したかを直接確認することもできます。完全な検証手順と2種類のDNSモードの選び方の分析については、ブログ記事『Clash DNS設定と漏洩防止設定の実践ガイド』を参照してください。

04TUNモードとFake-IP

2つの制御方式の違い

システムプロキシの本質は、オペレーティングシステムに対してHTTP/SOCKSポートを宣言することです。宣言した後にそれを使うかどうかは完全にアプリケーション側に委ねられます。ブラウザや多くのGUIアプリはそれに従いますが、多数のコマンドラインツール、一部のゲームクライアント、システムサービスはこの設定を読み込まず、それらの通信はそのまま直接接続されてしまいます。TUNモードは別のアプローチをとります。カーネルが仮想ネットワークアダプタを作成し、システムのデフォルトルートをそこに向けることで、すべてのアプリケーションの通信がネットワーク層で捕捉され、どのアプリケーションの協力にも依存しません。一言でまとめると、システムプロキシは「参加は任意」、TUNは「全面的な制御」です。2つの方式の仕組みの完全な比較は『Clash TUNモードとシステムプロキシの動作原理比較』を参照してください。

tun セクションのフィールド説明

stack はプロトコルスタックの実装を選択します。system はオペレーティングシステムのプロトコルスタックを再利用し、パフォーマンスが最も高くなります。gvisor はユーザー空間のプロトコルスタックで、互換性が高くシステムへの介入が少なくて済みます。mixed は両者を組み合わせ、TCPは system、UDPは gvisor を使うもので、多くの場面で妥当なデフォルト設定です。auto-route はルーティングテーブルへ自動的に書き込み、デフォルトの通信を仮想ネットワークアダプタへ導きます。auto-detect-interface は実際の物理的な出口ネットワークアダプタを自動識別するもので、これは非常に重要です。プロキシノード自体の通信が物理アダプタから送信されるようにし、再び仮想アダプタに入り込まないようにします。この識別が欠けている、または誤っていると通信がループしてしまい、TUNを有効にした直後にネットワークが切断される、という現象になります。strict-route はルーティングルールを厳格化し、一部の通信が仮想アダプタを回避することを防ぎます。dns-hijack は任意のアドレスの53番ポートへのクエリをハイジャックして内蔵DNSに引き渡すもので、通常は any:53 と書き、システムとアプリケーションのDNSクエリがすべて第3章の解決体系に含まれるようにします。

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

Fake-IPの仕組みと fake-ip-filter

fake-ip モードでは、内蔵DNSはクエリを受け取ると実際の解決を行わず、fake-ip-range(デフォルトは予約範囲の 198.18.0.1/16)から仮のIPを割り当ててアプリケーションに返し、内部で「仮IP ↔ ドメイン」のマッピングを記録します。アプリケーションはこの仮IPで接続を開始し、接続がカーネルに到達した時点でマッピングを逆引きして元のドメインを即座に取得し、そのままドメインでルールをマッチさせます。これにより実際の解決の往復が1回省け、接続確立が速くなり、ドメインルールのヒットもより確実になります。実際の解決は、直接接続することが確定した場合、またはプロキシサーバー側の遠隔地で行われる場合にのみ発生します。

副作用として、実際のIPを取得できないと動作しない場面が一部存在します。LAN内のデバイス探索、NTP時刻同期、一部のゲームランチャー、Windowsのネットワーク接続確認機能などは、198.18帯の仮アドレスを受け取るとそのまま異常動作を起こします。fake-ip-filter はこのために用意されたホワイトリストで、そこに列挙されたドメインは実際の解決にフォールバックし、fake-ipマッピングの対象になりません。

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

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

05ドメインスニッフィング

なぜスニッフィングが必要か

カーネルに到達した時点でドメインを取得できない通信には2種類あります。ひとつはアプリケーションが自前でDNS解決を済ませた上でIPに対して直接接続を開始するケース(一部のブラウザが独自のDoHを有効にしている、多くのモバイルアプリが解決ロジックを内蔵している、などがこれに該当します)。もうひとつは redir-host の経路上でドメイン情報が途中で失われる転送のケースです。ドメインがなければ、ドメインベースのルールはすべて機能せず、これらの接続はIPルールか MATCH による兜底に頼るしかなく、振り分けの精度が明らかに下がります。ドメインスニッフィング(sniffer)は通信そのものからドメインを「読み取って」戻します。TLSハンドシェイクのSNIフィールド、HTTPリクエストのHostヘッダー、QUICのハンドシェイク情報には、いずれも宛先ドメインが含まれています。カーネルは転送前にこれらのプロトコルヘッダーを解析し、ドメインを復元してからルールマッチに参加させます。

設定フィールド

sniffer.enable でスニッフィングを有効化します。sniff 以下でプロトコルごとに設定を行います。ports はスニッフィング対象のポートを限定します(TLSは443、HTTPは80がよく使われ、範囲指定も可能です)。override-destination を true にすると、スニッフィングで得たドメインで接続先を上書きしてルールマッチに使用します。force-domain には強制的にスニッフィングするドメインを列挙し、接続に既にドメイン情報がある場合でも再度スニッフィングして確認します。skip-domain にはスニッフィングをスキップするドメインを列挙します。最も一般的な用途は、モバイルプッシュ通知サービスの長時間接続を除外することです。スニッフィングが介入するとこうした接続の保持(キープアライブ)に干渉し、プッシュ通知の遅延を招く可能性があります。

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

2種類のDNSモードとの連携

fake-ip モードでは、大半のドメインはすでにマッピングの逆引きで取得できているため、スニッフィングは「アプリケーションがIPに直接接続する」という漏れた通信をカバーするための補完手段です。redir-host モードではドメインが失われる確率がはるかに高く、スニッフィングはほぼ必須の設定と言えます。設定しないとルールのヒット率が大幅に下がります。スニッフィングは新しい接続ごとにプロトコルヘッダー解析のコストを1回発生させますが、その量はごくわずかで、通常のデバイスでは感知できません。極端な性能要件がある場合は、ports の範囲を絞って標準ポートのみをスニッフィング対象にすることもできます。スニッフィングが有効になっているかどうかは、第7章のパネルのコネクションページで同様に確認できます。接続先がドメインとして表示され、純粋なIPではなくなっていれば、スニッフィングによって復元されたことがわかります。

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

なぜオーバーライドが必要か

サブスクリプション更新の本質は、リモートの最新設定でローカルファイル全体を置き換えることです。設定に手動で追加したルール、調整したDNS、有効にしたTUNは、次回の更新ですべて上書きされて消えてしまいます。オーバーライドの仕組みは「個人カスタマイズ」と「サブスクリプションの内容」を分離します。サブスクリプションはノードの提供だけを担当し、ルール・DNS・TUNといったローカルの方針はオーバーライド層に記述します。サブスクリプションを更新するとオーバーライドは自動的に再適用され、両者は互いに影響しません。ダウンロードページに掲載されている主要なGUIクライアント(第一候補としておすすめの Clash Plus、および Clash Verge Rev など)は、いずれもグラフィカルなオーバーライド機能を備えており、通常は Merge と Script の2形式に分かれます。

Merge オーバーライド:宣言的な統合

Merge オーバーライドはYAMLの断片で、決まった意味づけでサブスクリプション設定に統合されます。辞書型のフィールド(dns、tun、sniffer など)はサブスクリプション側の同名フィールドをそのまま上書きします。リスト型のフィールドは prepend- と append- の接頭辞で挿入位置を制御します。prepend-rules はルールをルールリストの先頭(最優先)に挿入し、append-rules は末尾に追加します。個人的に使う直接接続の例外や社内ネットワークのドメインは prepend に置き、自分用の兜底方針は append に置きます。この方式は宣言的で直感的であり、「ルールを数件追加する」「DNSの一部を変更する」といった大半の要求をカバーします。

prepend-rules:
  - DOMAIN-SUFFIX,internal.example.com,DIRECT
  - PROCESS-NAME,ssh,DIRECT
append-rules:
  - MATCH,ノード選択
dns:
  enable: true
  enhanced-mode: fake-ip
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

Script オーバーライド:プログラムによる変更

Merge では「条件に応じて一括変更する」という要求に対応できません。そうした場合は Script オーバーライドを使います。クライアントは解析済みの設定オブジェクトをJavaScript関数に渡し、関数は変更後のオブジェクトを返します。典型的な場面としては、ノード名の正規表現から地域別グループを自動生成する(サブスクリプションに新しい地域のノードが追加されても自動で分類される)、すべての url-test グループに一律で interval と tolerance を補完する、サブスクリプションに紛れ込んだ期限切れ通知用の「偽ノード」を一括削除する、といったものが挙げられます。スクリプト内では完全なJS構文が使えますが、関数は最終的に必ず return config を行い、フィールド構造を壊さないようにする必要があります。そうしないとカーネルの読み込みが失敗します。

function main(config) {
  config["proxy-groups"]
    .filter((g) => g.type === "url-test")
    .forEach((g) => {
      g.interval = 300;
      g.tolerance = 60;
    });
  return config;
}

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

複数のサブスクリプションを持っている場合、クライアント内で設定を切り替える必要はありません。proxy-providers は第2章のルールプロバイダーと同じ考え方です。各サブスクリプションをノードプロバイダーとして宣言し、ポリシーグループは use フィールドで1つまたは複数のプロバイダーを参照します。filter は正規表現を使って、統合後のノードプールから絞り込みます(例えば名前に「香港」を含むノードだけを残す、など)。これにより1つの設定で複数のサブスクリプションを一括管理でき、どれか1つに障害が起きても全体には影響しません。health-check サブフィールドを使うと、プロバイダー自身が定期的にヘルスチェックを行い、無効なノードは自動でスキップされます。

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

proxy-groups:
  - name: 香港自動
    type: url-test
    use: [provider-a, provider-b]
    filter: "(?i)hk|hong ?kong|香港"

07外部コントロールAPIとパネル

外部コントロールの有効化

Clash カーネルには RESTful なコントロールAPIが組み込まれており、ほぼすべてのGUIクライアントの画面や、すべてのWebコントロールパネルは、内部的にこれを呼び出しています。external-controller はリスンアドレスを指定します。ローカルでしか使わない場合は 127.0.0.1:9090 と書きます。secret はアクセス用のパスワードを設定するもので、すべてのリクエストは Authorization: Bearer ヘッダーにこれを含める必要があります。external-ui は静的パネルのディレクトリを指し、カーネルが直接ホスティングするため、ブラウザでリスンアドレスにアクセスするだけで開けます。

external-controller: 127.0.0.1:9090
secret: "換成足够長的随机口令"
external-ui: ./ui

よく使うAPI一覧

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

curl -X PUT -H "Authorization: Bearer <secret>" \
  -d '{"name":"香港自動"}' \
  "http://127.0.0.1:9090/proxies/ノード選択"

パネルの日常的な使い方

Webパネルで最も価値があるのはコネクションページとログページです。「あるサイトがなぜ間違った出口を通っているのか」を調査する場合、コネクションページで該当する接続を見つけ、そのルール列とプロキシ経路列を確認すれば、どのルールにヒットしたか、どのグループを経由したか、最終的にどのノードから出て行ったかが一目でわかります。設定ファイルを見ながら推測するよりはるかに効率的です。ログページはレベルを debug にすると、各ドメインのDNS解決経路とルールマッチの過程を確認できるため、第3章のDNSの問題を直接観測する手段になります。

もう一点知っておくべき動作の細部があります。パネルやクライアントでプロキシモード(ルール/グローバル/直接接続)を切り替えても、すでに確立済みの古い接続は自動的には切断されず、確立時の経路のまま通信が続きます。切り替えても「反映されていない」と感じた場合は、コネクションページで全接続を切断するか、関連するアプリケーションを再起動してください。3つのモードの通信の流れの違いについては、『Clashのルールモードとグローバルモードの違いと切り替え場面』を参照してください。

08設定の検証とトラブルシューティングのクイックリファレンス

起動前の検証

設定を変更したら、まず検証してから再読み込みすることで、試行錯誤に費やす時間を大幅に節約できます。コマンドライン版カーネルは構文・意味の両面のチェック機能を提供しています:mihomo -t -f config.yaml。問題がなければ成功メッセージが出力され、問題があればエラーの行番号と理由が示されます。YAMLでよくあるつまずきポイントをいくつか挙げます。インデントは必ずスペースを使い、タブが混ざると解析に失敗します。コロンの後には必ずスペースを1つ入れます。ノード名やグループ名に :、#、絵文字などの特殊文字が含まれる場合は引用符で囲む必要があります。リスト項目の - と内容の間にもスペースが必要です。GUIクライアントは設定を保存する際に通常同等のチェックを自動で行うので、そのエラーメッセージも一字一句丁寧に読む価値があります。

mihomo -t -f config.yaml

よくある問題の対応表

次のステップ

本ページで扱ったのは設定面での体系的な知識です。より口語的でよくある質問はFAQにまとめてあり、基礎知識、インストール・設定、使い方のコツ、トラブルシューティングの4つに分類して整理しています。本文中に出てきたプロキシプロトコル、カーネル、ルール関連の用語は用語集で1件ずつ調べられます。単一テーマを深く掘り下げた長文記事はブログで継続的に公開しています。ゼロから始める一連の操作手順に戻りたい場合は、使用チュートリアルで手順どおりに進めてください。