ホーム/応用設定
Clash応用設定ガイド
基本的な接続ができた後、Clashの使い勝手を大きく左右するのはルールエンジンとプロキシグループの組み合わせ方です。この記事ではマッチングの順序、4種類のプロキシグループの違い、DNSとFake-IPの仕組み、TUNモードの内部動作を徹底解説し、各セクションに実際に使えるYAMLスニペットを掲載しています。
ルールエンジンのマッチング方法
Clashのルールは「上から順に、最初にヒットしたら終了」というリストです。すべての通信リクエストはrulesの設定の1行目から順に比較され、どれかのルールにマッチした時点でそのルールの動作を即座に実行し、以降のルールは一切参照されません。
つまりルールの順序そのものが優先度の設計になります。よくある構成は、まず「必ず直接接続」させたいルール（社内アドレスや国内サイトなど）を書き、次に「必ずプロキシを通す」特定のルールを書き、最後にMATCHの兜底ルールで締めくくり「上記のいずれにも該当しない場合の動作」を定義する、という流れです。
rules:
# 1. プライベートネットワーク範囲を優先的に直接接続させ、LAN内デバイスへのアクセスがプロキシを経由して遠回りにならないようにする
- PRIVATE,DIRECT
# 2. 中国本土のIPは直接接続（GEOIPルールセットは自動更新される）
- GEOIP,CN,DIRECT
# 3. 特定ドメインを特定のプロキシグループに強制的に振り分ける
- DOMAIN-SUFFIX,openai.com,US-Node
- DOMAIN-KEYWORD,googlevideo,Auto
# 4. 兜底ルール：上記のいずれにも該当しない通信は自動選択へ
- MATCH,Autoよくある誤解：MATCHルールを途中に書いてしまうケースです。マッチングは最初にヒットした時点で終了するため、MATCHより後のルールは絶対に実行されません。必ずrulesリストの最後の行に置く必要があります。
ルールタイプの詳細
Clashが対応するルールタイプは、大きく分けてドメイン別、ネットワークアドレス別、その他の属性別の3種類です。以下の表はよく使われるものをまとめています。
| ルールタイプ | 例 | 説明 |
|---|---|---|
DOMAIN | DOMAIN,ad.example.com,REJECT | 単一のドメインを完全一致でマッチング |
DOMAIN-SUFFIX | DOMAIN-SUFFIX,github.com,Proxy | そのドメインとすべてのサブドメインにマッチ、最もよく使われる |
DOMAIN-KEYWORD | DOMAIN-KEYWORD,youtube,Proxy | ドメインにキーワードが含まれていればヒット、誤爆に注意 |
IP-CIDR / IP-CIDR6 | IP-CIDR,192.168.0.0/16,DIRECT | IPv4/IPv6アドレス範囲でマッチング |
GEOIP | GEOIP,CN,DIRECT | IPが属する国・地域のデータベースでマッチング |
DST-PORT / SRC-PORT | DST-PORT,443,Proxy | 宛先/送信元ポートでマッチング |
PROCESS-NAME | PROCESS-NAME,WeChat.exe,DIRECT | 接続を発生させたローカルプロセス名でマッチング（デスクトップのみ） |
RULE-SET | RULE-SET,reject,REJECT | Rule Providerのルールセットを参照、詳細は次のセクション |
MATCH | MATCH,Auto | 兜底ルール、必ず最後の行に配置する |
各ルールの最後の項目は「アクション」で、DIRECT（直接接続）、REJECT（ブロック、広告除去でよく使われる）、またはプロキシグループ名（そのグループの戦略に従ってノードを選択させる）のいずれかを指定します。
Rule Provider：ルールセットの購読
何百ものドメインルールを手書きするのは現実的ではありません。Clashにはrule-providersという仕組みがあり、リモートURLからルールセットファイルをダウンロードし、定期的に自動更新できます。設定には1回参照するだけで済みます。
rule-providers:
reject:
type: http
behavior: domain
url: "https://example.com/rules/reject.txt"
path: ./rules/reject.yaml
interval: 86400
rules:
- RULE-SET,reject,REJECTbehaviorはこのルールセットの内容をどう解析するかを決めるもので、3つの値があります。
| behavior | ルールセットの内容 | 典型的な用途 |
|---|---|---|
domain | 1行に1つのドメイン（ワイルドカード前方一致に対応） | 広告フィルタリングやサイト別振り分けのドメインリスト |
ipcidr | 1行に1つのIPアドレス範囲 | GEOIPデータベースにないカスタムIP範囲 |
classical | rulesと同じ書き方の完全なルール行 | 複数のルールタイプを組み合わせた複雑な集合 |
intervalは秒単位で、ルールセットを自動的に再取得する間隔を表します。「新しくブロックすべき広告ドメイン」や「新しく直接接続すべきドメイン」を、手動でメンテナンスせずに最新の状態に保てます。
プロキシグループ：4種類のスケジューリング戦略
プロキシグループ（proxy-groups）は複数の具体的なノードを1つの「戦略ユニット」としてまとめたものです。ルールで参照するのは特定のノードではなくグループ名であり、これによって「自動で最速のノードを選ぶ」「あるノードが落ちたら自動で切り替える」といった動作が実現できます。
select：手動選択
- 現在使用するノードを完全に手動で指定する
- どの回線を使うべきか明確に分かっている場合に最適
- 自動速度測定や自動切り替えは行わない
url-test：自動速度測定
- グループ内のすべてのノードに定期的に速度測定リクエストを送信する
- 常に遅延が最も低いノードを自動的に使用する
- 「面倒なことは考えたくない、とにかく最速がいい」場合に最適
fallback：フェイルオーバー
- 設定順に「正常」な最初のノードを使用する
- 現在のノードの速度測定が失敗した場合のみ次のノードへ切り替える
- 明確な優先順位があり、障害時のみ切り替えたい場合に最適
load-balance：負荷分散
- 異なる接続を複数のノードに分散させる
strategyにはコンシステントハッシュまたはラウンドロビンを選択可能- 複数ノードで負荷を分散し、単一ノードの速度制限を回避したい場合に最適
proxy-groups:
- name: Auto
type: url-test
proxies: [HK01, HK02, JP01]
url: "https://www.gstatic.com/generate_204"
interval: 300
tolerance: 50
- name: US-Node
type: fallback
proxies: [US-West01, US-East01]
url: "https://www.gstatic.com/generate_204"
interval: 300toleranceは「許容誤差」で、単位はミリ秒です。新しい速度測定結果が現在のノードの遅延との差がこの許容範囲内であれば、頻繁なノード切り替えは発生しません。「遅延がほぼ同じ2つのノードを行ったり来たりする」ことを防ぎます。
DNSとFake-IP
DNS解決の正確さは、ルールベース振り分けが正しく機能するかどうかを左右する重要な要素です。ドメインが誤ったIPに解決されたり、プロバイダーのDNSが改ざんされていたりすると、どれだけルールが正確でも意味がありません。ClashのDNSモジュールは、まさにこの問題を解決するために組み込まれています。
中心となるのは2つのドメイン解決モードです。
Fake-IPモード
- 各ドメインにローカルでのみ有効な仮のIPを割り当てる
- 実際のDNS解決は接続が確立される時まで遅延される
- ルールマッチングをドメインで直接行えるため、互換性が最も高い
- デスクトップ版のTUNモードで推奨されるデフォルト設定
Redir-Hostモード
- 実際の解決結果をそのまま返す
- 「従来型」のネットワーク動作に近く、IPに敏感な一部のプログラムとの互換性がある
- ルール内の
IP-CIDR/GEOIPの判定がより正確になる - ルーター/ゲートウェイでの利用シーンでより一般的
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- 223.5.5.5
- 119.29.29.29
fallback:
- https://1.1.1.1/dns-query
- https://8.8.8.8/dns-query
fallback-filter:
geoip: true
geoip-code: CN考え方はこうです：nameserverにはお使いのISPの平文DNSを設定し、まず高速なローカル解決に使用します。fallback-filterが結果を不自然だと判断した場合（解決されたIPが想定地域と一致しない、改ざんの疑いがある、またはそのドメインが実際には別の地域にホストされている）、fallbackにある暗号化DNSに切り替えて再解決を行い、速度と正確性の両方を確保します。
TUNモードの内部動作
システムプロキシは「プロキシを使うと分かっている」アプリ（ブラウザや大半のデスクトップソフト）しか処理できませんが、多くのプログラム（ゲーム、コマンドラインツール、一部のスマホアプリ）はシステムプロキシの設定を読み取りません。そこで必要になるのがTUNモードです。
TUNモードの本質は、OS内に仮想ネットワークアダプターを作成し、システムのデフォルトルートをこのアダプターに向けることです。これにより、あるプログラムが「プロキシを意識している」かどうかに関わらず、送信されるすべてのネットワークパケットはまずこの仮想アダプターを通過し、Clashがそれを捕捉してルールに従って処理した後、直接接続するかいずれかのプロキシノードへ転送するかを決定します。これはアプリケーション層でプログラムに「プロキシを使うよう説得する」のではなく、ネットワーク層で一括してハイジャックするようなものです。
tun:
enable: true
stack: system
dns-hijack:
- any:53
auto-route: true
auto-detect-interface: truestackには通常systemまたはgvisorを選択できます。systemはOSのネイティブネットワークスタックを使用しパフォーマンスに優れ、gvisorは純粋にユーザー空間で実装されたネットワークスタックで互換性が高く、一部の環境でシステムのTUNドライバが不安定な場合に切り替えて試す価値があります。
TUNモードはネットワーク層で動作するため、仮想ネットワークアダプターを作成するためのシステム権限（管理者/root、またはmacOSのシステム拡張の許可）が必要です。これがインストールガイドで繰り返し「管理者として実行」と説明されている理由です。
スクリプトとLogicルール
通常のルールタイプでは足りない場合、Clashの拡張コア（mihomoなど）はより柔軟な2つの記法に対応しています。
- Logicルール：
AND/OR/NOTで複数の条件を組み合わせます。例えば「宛先ポートが443かつ特定のIP範囲に属する」場合のみプロキシを通す、といった条件はAND,((DST-PORT,443),(IP-CIDR,10.0.0.0/8))のように書きます。 - Script Provider：短いスクリプトを書き、実行時にそのリクエストがどのプロキシグループを使うべきかを動的に返す仕組みです。「現在のネットワーク環境に応じて」「時間帯に応じて」など、通常のルールでは表現できない複雑な判定に使います。上級者向けの機能なので、まず通常のルールに習熟してから試すことをおすすめします。
パフォーマンスとチューニング
url-testのintervalを短くすると遅くなったノードをより早く検知できますが、速度測定リクエストの頻度とバッテリー消費も増えます。デスクトップでは300秒、モバイルでは600秒以上を推奨します。- ルールセットを増やしすぎない：
rule-providersを1つ追加するたびにメモリを消費し、ルールマッチングの計算量も増加します。似たようなソースを何十個も重ねるより、活発にメンテナンスされ広範囲をカバーするルールセットを優先的に選びましょう。 rulesを適切に並べる：ヒット率が最も高いルール（例：GEOIP,CN,DIRECT）をできるだけ前に置くことで、大半のリクエストがより早くマッチングを完了し、不要な逐次比較を減らせます。- モバイルではTUNよりシステムプロキシを優先：プロキシを認識しないアプリを捕捉する必要が本当にない限り、TUNモードは一部のスマホでバックグラウンドのバッテリー消費が高くなります。
これらのセクションを実際の設定と照らし合わせて読んだ後は、設定ファイルの完全リファレンスを読み、各項目のデフォルト値と設定範囲を一通り確認して、知識の全体像を構築することをおすすめします。