Clash YAML 設定の深掘り：ルール分流・Fake-IP 実践

YAML の骨格：まず押さえるトップレベル項目

Clash 系コア（mihomo を含む）の設定は、多くの場合 proxies・proxy-groups・rules の三本柱で理解できます。ここに dns と tun が加わると「名前解決」と「トラフィックの取り込み方」まで含めて設計できるようになります。まずは骨格だけ抜き出すと、サブスクから流し込まれた長大なファイルでも迷いにくくなります。

port や socks-port、mixed-port はローカル待受ポートです。ブラウザ拡張やアプリが「HTTP プロキシ」「SOCKS5」のどちらを前提にしているかで、片方だけ有効にするか mixed-port にまとめるかを決めます。mode は rule（ルールに従う）／global（常にプロキシ）／direct（常に直結）の切り替えで、日常運用では rule が基本です。log-level を一時的に debug に上げると、どのルールにマッチしたかをログで追いやすくなります。

設定の全体像を把握したうえで、GUI クライアントを使う場合でも「中身がどうなっているか」を読めるようにしておくと、トラブル時に原因を切り分けやすいです。ほかの解説はブログ一覧からも辿れます。当サイトのダウンロードページから入手できる各クライアントは、多くがこの YAML を裏で編集・保存しています。

プロキシグループ：名前がルール側の「宛先」になる

proxy-groups は、ルールの最後に書く 策略名（ポリシー名）と一対一で対応します。つまり rules で DOMAIN-SUFFIX,google.com,🔰プロキシ と書くなら、proxy-groups に name: 🔰プロキシ が存在している必要があります。名前の付け方は自由ですが、絵文字や記号を含めるとクライアントによって表示が崩れることがあるので、運用チーム内で規則を揃えると安全です。

代表的なタイプと使いどころ

select は手動選択です。用途別に「動画用」「仕事用」などを分けたいとき向きです。url-test は遅延計測で自動的にノードを選びます。interval（計測間隔）や tolerance（切り替えの許容差）を調整すると、頻繁な切り替えを抑えられます。fallback は可用性重視で、先頭から順に生存確認し、通ったノードを使います。サブスクの並び順が安定している環境では扱いやすいタイプです。

relay はチェイン（多段中継）用で、リストの順にトラフィックを渡します。レイテンシは伸びやすい一方、特定の構成を試す用途では有用です。load-balance は同一グループ内で負荷分散したい場合に使いますが、セッションの持ち方や対象プロトコルによって挙動が変わるため、期待どおりかログで確認することが大切です。

ヒント

グループの proxies 配列には、実サーバー名だけでなく、別のグループ名を入れ子にできます。ただし循環参照にならないよう、ツリー構造を意識してください。深い入れ子はデバッグが難しくなるので、まずはフラットに近い形から始めるのがおすすめです。

ルール分流：上から順に「最初の一致」が勝つ

Clash の rules はリストの先頭から評価され、最初にマッチした行で決着がつきます。だから「細かい例外」を上に、「広い許可／拒否」を下に置く、という順序設計が分流の要です。最下行の MATCH,最終グループ は全体の落とし穴であり、ここを DIRECT にするかプロキシグループにするかで挙動が大きく変わります。

よく使うルールタイプ

DOMAIN／DOMAIN-SUFFIX／DOMAIN-KEYWORD：ホスト名ベース。サブドメインをまとめたいときは DOMAIN-SUFFIX が扱いやすいです。
IP-CIDR／GEOIP：宛先 IP や国コードで振り分けます。GEOIP,CN,DIRECT のように国内向けを直結させる構成はよく使われます（データベースの更新状況に依存します）。
PROCESS-NAME／PROCESS-PATH：特定アプリだけ別経路にしたいとき。OS やクライアントの権限によっては取得できない場合もあります。
RULE-SET（mihomo 等）：外部のルールセットを参照し、リストを分割管理できます。購読 URL の鮮度と到達性が運用の鍵になります。

分流で失敗しやすいのは、「DNS で返った IP」だけを見てしまうケースです。Fake-IP を使うと名前解決の段階と接続の段階で見え方が変わるため、次章とセットで理解するとルールの意図がずれにくくなります。

Fake-IP モード：名前解決をローカルで完結させる

Fake-IP は、クライアントに対して「仮の IPv4 アドレス」を返し、実際の接続時に内部でドメインへ再紐付けする仕組みです。多くの環境では 198.18.0.0/16 付近が使われます。これにより、ローカルアプリは早い段階で接続先を確定でき、DNS クエリの扱いをコア側で統一しやすくなります。

dns.enhanced-mode を fake-ip にすると、この動作が有効になります。一方 redir-host は、より素直に「実 IP／実名前」を返す方向に振る舞います。どちらが優れているというより、クライアント OS、アプリの種類、ルールの書き方と相性を見て選びます。LAN 内ホスト名や、Fake-IP と相性の悪いアプリ向けには fake-ip-filter で例外を列挙するのが定石です。

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'connectivitycheck.gstatic.com'
  nameserver:
    - https://dns.google/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

fake-ip-filter に載せた名前は、Fake-IP を使わず従来どおりの解決に回されます。ストリーム配信や証明書ピンニングが厳しいアプリで不具合が出た場合、まずここを疑うとよいでしょう。

注意

Fake-IP を有効にしたうえで、OS の DNS をコアと別系統にしてしまうと、名前と接続の対応が食い違い、意図しない直結やループに見える挙動が出ることがあります。TUN 利用時は dns-hijack やクライアントの「システムプロキシ／仮想 NIC」設定と合わせて、クエリがコアに集まるか確認してください。

DNS 設定とルールを両輪で見る

分流は rules だけでは完結しません。nameserver-policy でドメインごとに DNS を分けたり、fallback と fallback-filter で「污染（ポイズニング）っぽい応答を疑ったら別 DNS に切り替える」といった防御線を張れます。mihomo では DNS まわりの表現力が高いので、サブスク付属の最小構成のまま運用するか、自前で詰めるかで安定性に差が出ます。

また、HTTPS の SNI や QUIC が絡むと、ドメインルールと実トラフィックの見え方が一致しないことがあります。そのときはログレベルを上げ、どのポリシーに落ちているかを確認しながら、RULE-SET の更新や PROCESS-NAME の補強を検討します。

ミニマム構成の考え方（例）

以下は概念をつかむための極小イメージです。実際の proxies はサブスクから自動生成されることが多く、手で触るのは proxy-groups と rules、そして dns のことが多いでしょう。

mode: rule
log-level: info

proxies: []
proxy-providers: {}

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
  - name: AUTO
    type: url-test
    proxies: []
    url: http://www.gstatic.com/generate_204
    interval: 300

rules:
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

この例では中国向けを直結し、それ以外を PROXY に流します。実運用ではプライバシー要件や社内ドメイン、ストリーミングの地域制限など、例外ルールをその上に積み上げていきます。

つまずきどころと切り分け

よくある症状として、特定サイトだけ遅い・開かない・証明書エラーになる、といったものがあります。Fake-IP 有効時はまず fake-ip-filter を見直し、次にそのドメインがどのルールに当たっているかを確認します。url-test が頻繁に切り替わる場合は tolerance を広げる、計測 URL を変える、ノード一覧の並びを整理するなどの対策があります。

ルールが想定と違うときは、優先順位の逆転（広いルールを上に書いてしまった）を疑ってください。また GEOIP はデータの更新が必要で、期待した国コードと異なることがあります。最終的にコアやルールセットのドキュメントを当たり、自分のバージョンでサポートされている記法かを確認すると早いです。オープンソースのソースコードや Issue は学びの宝庫ですが、インストーラの入手は当サイトのダウンロードページを主な入口にすると、クライアントとコアの組み合わせが明確になります。

まとめ

Clash YAML の理解は、単なる記法の暗記ではなく「名前解決 → ルール照合 → プロキシグループ」の流れを頭に置くことから始まります。プロキシグループの設計が整理されていれば、ルール追加のたびに全体がぐちゃぐちゃになりにくく、Fake-IP と DNS を適切に組み合わせれば、意図しない漏洩や判定ミスを減らせます。

設定ファイルの細部はコアのバージョンで差分が出るため、一度ベースラインを理解したあとは、自分の使うクライアントと mihomo のリリースノートをセットで追うのが近道です。GUI で快適に編集しつつ、YAML の筋を読めるようになると、サブスク更新後のトラブルにも冷静に対応できるようになります。

複数端末で同じ方針を再現したい場合や、まずは安定したビルドから試したい場合は、クライアントのダウンロードページで OS に合ったパッケージを選ぶとスムーズです。細かい分流設計に時間をかけるほど、土台となるアプリのインストールと更新が単純であるほど運用負担が下がります。→ 無料で Clash をダウンロードし、設定の検証を始める